Try Sidebar
@@ -1,34 +1,34 @@
|
||||
# 🏦 Flujo de Caja, Arqueo Ciego y Auditoría
|
||||
|
||||
La tesorería del sistema está diseñada bajo el principio de "Zero Trust" (Cero Confianza) en el punto de venta, requiriendo validación centralizada.
|
||||
|
||||
## 🙈 El Arqueo Ciego
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
Cuando un cajero termina su turno, no puede ver un reporte de "Cuánto debería tener en la caja". El flujo es el siguiente:
|
||||
1. El cajero abre la sesión declarando el **Fondo Inicial**.
|
||||
2. Al cerrar, debe contar sus billetes físicos y tickets de tarjeta, e ingresarlos manualmente al sistema (`DeclaredCash`, `DeclaredCards`).
|
||||
3. El Backend toma estos valores y los contrasta contra los cobros reales (Payments).
|
||||
4. El sistema calcula el `TotalDifference`.
|
||||
5. La sesión queda bloqueada en estado `PendingValidation`.
|
||||
|
||||
## ⚖️ Liquidación y Validación
|
||||
La caja no se considera legalmente cerrada hasta que un **Administrador o Tesorero** revisa el "Acta de Cierre" impresa, la compara con el dinero recibido en mano, ingresa sus notas y liquida la sesión (`Closed`).
|
||||
|
||||
---
|
||||
|
||||
## 🕵️ Sistema de Reclamos y Ajuste Técnico
|
||||
|
||||
Si un cliente presenta una queja (ej: un error de tipeo en el diario impreso), el cajero abre una incidencia (`Claim`).
|
||||
|
||||
**Resolución Transaccional:**
|
||||
Cuando un moderador resuelve el problema (ej: otorgando 2 días gratis extra), el sistema protege los datos así:
|
||||
1. Toma una "Fotografía" (`Snapshot`) de los valores originales del aviso (texto original, fechas originales).
|
||||
2. Guarda la fotografía en la columna `OriginalValues` del reclamo.
|
||||
3. Aplica los nuevos valores técnicos al aviso principal.
|
||||
4. Genera un log inmutable en la tabla `AuditLogs`.
|
||||
|
||||
# 🏦 Flujo de Caja, Arqueo Ciego y Auditoría
|
||||
|
||||
La tesorería del sistema está diseñada bajo el principio de "Zero Trust" (Cero Confianza) en el punto de venta, requiriendo validación centralizada.
|
||||
|
||||
## 🙈 El Arqueo Ciego
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
Cuando un cajero termina su turno, no puede ver un reporte de "Cuánto debería tener en la caja". El flujo es el siguiente:
|
||||
1. El cajero abre la sesión declarando el **Fondo Inicial**.
|
||||
2. Al cerrar, debe contar sus billetes físicos y tickets de tarjeta, e ingresarlos manualmente al sistema (`DeclaredCash`, `DeclaredCards`).
|
||||
3. El Backend toma estos valores y los contrasta contra los cobros reales (Payments).
|
||||
4. El sistema calcula el `TotalDifference`.
|
||||
5. La sesión queda bloqueada en estado `PendingValidation`.
|
||||
|
||||
## ⚖️ Liquidación y Validación
|
||||
La caja no se considera legalmente cerrada hasta que un **Administrador o Tesorero** revisa el "Acta de Cierre" impresa, la compara con el dinero recibido en mano, ingresa sus notas y liquida la sesión (`Closed`).
|
||||
|
||||
---
|
||||
|
||||
## 🕵️ Sistema de Reclamos y Ajuste Técnico
|
||||
|
||||
Si un cliente presenta una queja (ej: un error de tipeo en el diario impreso), el cajero abre una incidencia (`Claim`).
|
||||
|
||||
**Resolución Transaccional:**
|
||||
Cuando un moderador resuelve el problema (ej: otorgando 2 días gratis extra), el sistema protege los datos así:
|
||||
1. Toma una "Fotografía" (`Snapshot`) de los valores originales del aviso (texto original, fechas originales).
|
||||
2. Guarda la fotografía en la columna `OriginalValues` del reclamo.
|
||||
3. Aplica los nuevos valores técnicos al aviso principal.
|
||||
4. Genera un log inmutable en la tabla `AuditLogs`.
|
||||
|
||||
Esto garantiza que siempre se sepa qué modificó el moderador y cómo estaba el aviso originalmente.
|
||||
@@ -1,27 +1,27 @@
|
||||
# 📦 Gestión de Catálogo, Rubros y Combos
|
||||
|
||||
El catálogo en SIG-CM soporta una arquitectura polimórfica. Un "Producto" puede ser un aviso, un espacio en radio, un bien físico o un "Combo" (Bundle).
|
||||
|
||||
## 🌳 Árbol de Categorías (Taxonomía)
|
||||
|
||||
Las categorías funcionan bajo una estructura de árbol (Padre > Hijo). Existen reglas estrictas para mantener la integridad en la base de datos:
|
||||
1. **Regla de Inserción:** No se pueden crear sub-categorías dentro de un Rubro si este ya contiene avisos directos.
|
||||
2. **Regla de Movimiento (Drag & Drop):** No se puede mover una categoría padre dentro de uno de sus propios hijos (prevención de referencias circulares).
|
||||
3. **Fusión (Merge):** Al fusionar la Categoría A hacia la B, se trasladan sus avisos, atributos dinámicos y operaciones permitidas; luego, la Categoría A se elimina.
|
||||
|
||||
---
|
||||
|
||||
## 🍔 Combos (Bundles) y Prorrateo de Precios
|
||||
|
||||
Un "Combo" (`TypeCode: BUNDLE`) es un producto padre que agrupa múltiples productos hijos (que pueden pertenecer a empresas distintas).
|
||||
|
||||
**Regla de Negocio Crítica:**
|
||||
Al vender un Combo por un precio cerrado (Ej: $10,000), el sistema debe desglosar ese dinero entre los componentes hijos para la futura [Liquidación Cruzada](Settlement).
|
||||
|
||||
**¿Cómo se calcula el prorrateo?**
|
||||
* Si el componente tiene un `FixedAllocationAmount` configurado por el administrador, se asigna ese valor directo.
|
||||
* Si no, se usa una **Regla de Tres Simple** basada en el precio de lista actual de los hijos:
|
||||
* *Ejemplo:* Combo a $1,000.
|
||||
* Hijo A (Vale $800 en lista). Hijo B (Vale $400 en lista). Total suma teórica: $1,200.
|
||||
* Asignación A = `$1,000 * (800 / 1200) = $666.66`
|
||||
# 📦 Gestión de Catálogo, Rubros y Combos
|
||||
|
||||
El catálogo en SIG-CM soporta una arquitectura polimórfica. Un "Producto" puede ser un aviso, un espacio en radio, un bien físico o un "Combo" (Bundle).
|
||||
|
||||
## 🌳 Árbol de Categorías (Taxonomía)
|
||||
|
||||
Las categorías funcionan bajo una estructura de árbol (Padre > Hijo). Existen reglas estrictas para mantener la integridad en la base de datos:
|
||||
1. **Regla de Inserción:** No se pueden crear sub-categorías dentro de un Rubro si este ya contiene avisos directos.
|
||||
2. **Regla de Movimiento (Drag & Drop):** No se puede mover una categoría padre dentro de uno de sus propios hijos (prevención de referencias circulares).
|
||||
3. **Fusión (Merge):** Al fusionar la Categoría A hacia la B, se trasladan sus avisos, atributos dinámicos y operaciones permitidas; luego, la Categoría A se elimina.
|
||||
|
||||
---
|
||||
|
||||
## 🍔 Combos (Bundles) y Prorrateo de Precios
|
||||
|
||||
Un "Combo" (`TypeCode: BUNDLE`) es un producto padre que agrupa múltiples productos hijos (que pueden pertenecer a empresas distintas).
|
||||
|
||||
**Regla de Negocio Crítica:**
|
||||
Al vender un Combo por un precio cerrado (Ej: $10,000), el sistema debe desglosar ese dinero entre los componentes hijos para la futura [Liquidación Cruzada](Settlement).
|
||||
|
||||
**¿Cómo se calcula el prorrateo?**
|
||||
* Si el componente tiene un `FixedAllocationAmount` configurado por el administrador, se asigna ese valor directo.
|
||||
* Si no, se usa una **Regla de Tres Simple** basada en el precio de lista actual de los hijos:
|
||||
* *Ejemplo:* Combo a $1,000.
|
||||
* Hijo A (Vale $800 en lista). Hijo B (Vale $400 en lista). Total suma teórica: $1,200.
|
||||
* Asignación A = `$1,000 * (800 / 1200) = $666.66`
|
||||
* Asignación B = `$1,000 * (400 / 1200) = $333.33`
|
||||
12
Home.md
12
Home.md
@@ -25,14 +25,14 @@ SIG-CM es una plataforma distribuida diseñada para gestionar el ciclo de vida c
|
||||
Navega por las siguientes secciones para entender el comportamiento interno del sistema:
|
||||
|
||||
### ⚙️ Reglas de Negocio (Core)
|
||||
* [🧠 Motor de Cotización y Tarifas](Pricing-Engine.-)
|
||||
* [📦 Gestión de Catálogo y Combos (Bundles)](Catalog-and-Bundles.-)
|
||||
* [💳 Cuentas Corrientes y Riesgo Crediticio](Credit-Risk.-)
|
||||
* [🧠 Motor de Cotización y Tarifas](Pricing-Engine)
|
||||
* [📦 Gestión de Catálogo y Combos (Bundles)](Catalog-and-Bundles)
|
||||
* [💳 Cuentas Corrientes y Riesgo Crediticio](Credit-Risk)
|
||||
|
||||
### 🏦 Operaciones y Tesorería
|
||||
* [🛒 Flujo de Caja y Arqueo Ciego](Cash-Register.-)
|
||||
* [📊 Liquidación Cruzada (Settlement)](Settlement.-)
|
||||
* [🛠️ Sistema de Reclamos y Auditoría](Claims-and-Audit.-)
|
||||
* [🛒 Flujo de Caja y Arqueo Ciego](Cash-Register)
|
||||
* [📊 Liquidación Cruzada (Settlement)](Settlement)
|
||||
* [🛠️ Sistema de Reclamos y Auditoría](Claims-and-Audit)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,38 +1,38 @@
|
||||
# 🧠 Motor de Cotización y Tarifas (`PricingService`)
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
El cálculo del precio de un aviso clasificado no es lineal. El sistema utiliza un algoritmo progresivo que evalúa el texto y aplica reglas jerárquicas configuradas en el `Admin Panel`.
|
||||
|
||||
## 🧮 Fórmula Base
|
||||
El costo total de un aviso se calcula en el siguiente orden:
|
||||
|
||||
1. **Precio Base del Producto:** Define el valor mínimo (Ej: $5,000). Si el producto incluye duración (Ej: cubre 30 días), se calcula el *Costo Diario* (`BasePrice / DurationDays`).
|
||||
2. **Costo por Palabras Extra:** Se cuentan las palabras y se restan las "Palabras Base" gratuitas. Las palabras excedentes se tasan según escalones (`WordPricingRanges`) o un precio *fallback*.
|
||||
3. **Costo por Caracteres Especiales:** Símbolos como `!`, `$`, `%` se cobran por unidad.
|
||||
4. **Recargos de Estilo (Surcharges):** Negrita, Recuadro o Posición Destacada.
|
||||
5. **Descuentos y Promociones:** Cupones promocionales (Monto fijo o Porcentaje).
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Reglas Ocultas de Normalización de Texto
|
||||
|
||||
Para evitar que los clientes "engañen" al sistema uniendo palabras con símbolos (ej: `VENDO!AUTO!BARATO`), el motor realiza los siguientes pasos antes de cotizar:
|
||||
|
||||
1. **Extracción de Símbolos:** Primero cuenta cuántos caracteres especiales hay según la configuración del rubro.
|
||||
2. **Limpieza:** Reemplaza los caracteres especiales por **espacios en blanco** (`VENDO AUTO BARATO`).
|
||||
3. **Conteo Real:** Separa el texto limpio por espacios y saltos de línea para obtener la cantidad real y honesta de palabras.
|
||||
|
||||
---
|
||||
|
||||
## 🎫 Lógica de Cupones y Promociones
|
||||
|
||||
* **Promociones Automáticas:** Se aplican solas si cumplen la condición (`MinDays` o `DaysOfWeek`).
|
||||
* **Cupones Manuales:** El cajero o el usuario web ingresa el código. El sistema verifica:
|
||||
* Que no esté vencido (`ExpiryDate`).
|
||||
* Que el cupón global no haya superado su límite (`MaxUsages`).
|
||||
* Que el **usuario específico** no haya superado su límite personal de usos (`MaxUsagesPerUser`).
|
||||
|
||||
# 🧠 Motor de Cotización y Tarifas (`PricingService`)
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
El cálculo del precio de un aviso clasificado no es lineal. El sistema utiliza un algoritmo progresivo que evalúa el texto y aplica reglas jerárquicas configuradas en el `Admin Panel`.
|
||||
|
||||
## 🧮 Fórmula Base
|
||||
El costo total de un aviso se calcula en el siguiente orden:
|
||||
|
||||
1. **Precio Base del Producto:** Define el valor mínimo (Ej: $5,000). Si el producto incluye duración (Ej: cubre 30 días), se calcula el *Costo Diario* (`BasePrice / DurationDays`).
|
||||
2. **Costo por Palabras Extra:** Se cuentan las palabras y se restan las "Palabras Base" gratuitas. Las palabras excedentes se tasan según escalones (`WordPricingRanges`) o un precio *fallback*.
|
||||
3. **Costo por Caracteres Especiales:** Símbolos como `!`, `$`, `%` se cobran por unidad.
|
||||
4. **Recargos de Estilo (Surcharges):** Negrita, Recuadro o Posición Destacada.
|
||||
5. **Descuentos y Promociones:** Cupones promocionales (Monto fijo o Porcentaje).
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Reglas Ocultas de Normalización de Texto
|
||||
|
||||
Para evitar que los clientes "engañen" al sistema uniendo palabras con símbolos (ej: `VENDO!AUTO!BARATO`), el motor realiza los siguientes pasos antes de cotizar:
|
||||
|
||||
1. **Extracción de Símbolos:** Primero cuenta cuántos caracteres especiales hay según la configuración del rubro.
|
||||
2. **Limpieza:** Reemplaza los caracteres especiales por **espacios en blanco** (`VENDO AUTO BARATO`).
|
||||
3. **Conteo Real:** Separa el texto limpio por espacios y saltos de línea para obtener la cantidad real y honesta de palabras.
|
||||
|
||||
---
|
||||
|
||||
## 🎫 Lógica de Cupones y Promociones
|
||||
|
||||
* **Promociones Automáticas:** Se aplican solas si cumplen la condición (`MinDays` o `DaysOfWeek`).
|
||||
* **Cupones Manuales:** El cajero o el usuario web ingresa el código. El sistema verifica:
|
||||
* Que no esté vencido (`ExpiryDate`).
|
||||
* Que el cupón global no haya superado su límite (`MaxUsages`).
|
||||
* Que el **usuario específico** no haya superado su límite personal de usos (`MaxUsagesPerUser`).
|
||||
|
||||
> ⚠️ **Atención:** Los descuentos se aplican sobre el subtotal de *Días contratados*, pero **después** de sumar los recargos visuales.
|
||||
16
_Sidebar
Normal file
16
_Sidebar
Normal file
@@ -0,0 +1,16 @@
|
||||
### 🏠 General
|
||||
* [Volver al Inicio](Home)
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Reglas de Negocio
|
||||
* [Motor de Cotización](Pricing-Engine)
|
||||
* [Catálogo y Combos](Catalog-and-Bundles)
|
||||
* [Cuentas Corrientes](Credit-Risk)
|
||||
|
||||
---
|
||||
|
||||
### 🏦 Operaciones
|
||||
* [Caja y Arqueo](Cash-Register)
|
||||
* [Liquidación Cruzada](Settlement)
|
||||
* [Reclamos y Auditoría](Claims-and-Audit)
|
||||
Reference in New Issue
Block a user