Flujo de Reclamos y Ajustes. - Detalle de Liquidación Cruzada.

Cash-Register.-.md

@@ -3,7 +3,11 @@
 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
+
 ![Arquitectura Cierre Caja](images/Flujo-de-Cierre-de-Caja.drawio.svg)
+
+---
+
 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`).

Claims-and-Audit.-.md

@@ -0,0 +1,32 @@
+# 🛠️ Sistema de Reclamos y Auditoría (Claims & Audit)
+
+![Reclamos y Ajustes Técnicos](images/Flujo-de-Reclamos-y-Ajustes-Técnicos.drawio.svg)
+
+---
+
+## 🕵️ Gestión de Incidencias (Reclamos)
+Los errores ocurren en el día a día (un texto mal tipeado en mostrador, un aviso que salió en el rubro equivocado, etc.). SIG-CM maneja estos reclamos con un flujo bidireccional que protege la integridad financiera.
+
+### Flujo Operativo:
+1. **Apertura (Cajero):** El cajero desde el *Counter Panel* busca el aviso problemático y levanta un ticket (`Claim`), indicando el motivo de la queja del cliente. 
+2. **Atención (Moderador):** Desde el *Admin Panel*, un supervisor analiza el caso. Puede decidir compensar al cliente (ej. dándole 2 días extra de publicación gratis por el error).
+3. **Aplicación de Ajuste Técnico:** El moderador inyecta los nuevos parámetros y el sistema actualiza el aviso original.
+
+### 🔒 Protección de Datos (Snapshotting)
+Para evitar que se pierda el historial de lo que *realmente* pidió el cliente al principio, el backend ejecuta una **Transacción Segura**:
+* Antes de aplicar la corrección técnica, toma una fotografía (Snapshot) de cómo estaban el texto y las fechas originales.
+* Esta "foto" se guarda permanentemente en la columna `OriginalValues` del reclamo.
+* De este modo, contabilidad y gerencia siempre pueden ver por qué un aviso de 3 días terminó publicándose 5 días.
+
+---
+
+## 📖 Registro de Auditoría (AuditLogs)
+Toda la plataforma opera bajo el principio de **Trazabilidad Absoluta**. La tabla `AuditLogs` funciona como la caja negra de un avión. 
+
+El sistema intercepta y registra de forma inmutable:
+* 🔑 **Logins:** Quién y cuándo ingresó al sistema.
+* 💸 **Tesorería:** Aperturas y cierres de caja, registrando si el cajero tuvo diferencias de dinero.
+* 📝 **Entidades:** Alta, modificación o baja de clientes, cupones, reglas de precios y promociones.
+* ⚖️ **Moderación:** Qué usuario aprobó o rechazó qué aviso.
+
+> 🛡️ **Seguridad:** Los registros de esta tabla no poseen un endpoint de borrado (`DELETE`). No pueden ser modificados ni eliminados desde ninguna interfaz de usuario, garantizando su validez absoluta para revisiones gerenciales.

Home.md

@@ -5,7 +5,11 @@ Este espacio documenta la arquitectura, reglas de negocio y flujos operativos de
 ---
 
 ## 🎯 Visión General
+
 ![Arquitectura Global](images/SIG-CM.drawio.svg)
+
+---
+
 SIG-CM es una plataforma distribuida diseñada para gestionar el ciclo de vida completo de las ventas publicitarias y de productos físicos, desde la recepción en mostrador (POS) o web, hasta la publicación, facturación y liquidación cruzada entre empresas.
 
 ### 🛠️ Stack Tecnológico

Pricing-Engine.-.md

@@ -1,5 +1,9 @@
 # 🧠 Motor de Cotización y Tarifas (`PricingService`)
+
 ![Arquitectura Venta](images/Venta-Multi-Producto.drawio.svg)
+
+---
+
 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

Settlement.-.md

@@ -1 +1,20 @@
+# 📊 Liquidación Cruzada (Settlement)
+
 ![Liquidación Cruzada](images/Flujo-de-Liquidación-Cruzada.drawio.svg)
+
+---
+
+## 🤝 ¿Qué es la Liquidación Cruzada?
+En SIG-CM, un cliente puede comprar un **Combo (Bundle)** que incluya productos de diferentes medios o empresas (por ejemplo, pagar un aviso en el *Diario Papel* que incluye de regalo una mención en la *Radio*). 
+
+Dado que el cliente paga todo el combo junto en la caja (a una sola empresa facturadora), el sistema debe calcular al final del mes **quién cobró el dinero** y **quién prestó realmente el servicio**, para que las empresas puedan transferirse los saldos correspondientes.
+
+## ⚙️ Reglas de Negocio del Motor de Liquidación
+
+Para que las cuentas sean exactas, el Backend aplica las siguientes reglas estrictas:
+
+1. **Filtro de Cobro Efectivo:** El sistema **solo** liquida dinero que realmente ingresó a la caja. Ignora las ventas en Cuenta Corriente que aún estén impagas. Solo se toman en cuenta los ítems cuya orden maestra tenga el estado `PaymentStatus = 'Paid'`.
+2. **Detección de Deuda Cruzada:** El algoritmo busca específicamente los ítems de venta donde la empresa que emitió la factura (`BillingCompanyId`) es **distinta** a la empresa dueña del producto (`ServiceCompanyId`).
+3. **Consolidación:** Suma los importes netos (`SubTotal`) y cuenta la cantidad de transacciones, agrupando los resultados en pares exactos (Ej: *La Empresa A le debe $X a la Empresa B por Y cantidad de transacciones*).
+
+> 💡 **Nota Técnica:** Todo este cálculo se realiza de directamente en el motor de la base de datos (SQL Server) a través de un Query de agrupación en el `ReportRepository`, lo que garantiza velocidad sin importar el volumen de ventas.