Cuentas Corrientes y Riesgo Crediticio - Estructura de Carpetas

Credit-Risk.-.md

@@ -0,0 +1,40 @@
+# 💳 Cuentas Corrientes y Riesgo Crediticio
+
+SIG-CM incorpora un motor de validación de riesgo en tiempo real diseñado para operar con clientes frecuentes, agencias y clientes B2B (Business to Business). Este módulo permite a los clientes diferir sus pagos sin comprometer la seguridad financiera de la empresa.
+
+---
+
+## ⚙️ Parámetros del Perfil Crediticio (`ClientProfile`)
+
+Para que un cliente pueda operar con "Cuenta Corriente", un Administrador o Gerente debe habilitarle un perfil financiero. Este perfil consta de las siguientes reglas:
+
+*   **Límite de Crédito (`CreditLimit`):** El monto máximo de deuda que el cliente puede acumular.
+*   **Plazo de Pago (`PaymentTermsDays`):** Los días de gracia por defecto que tiene para pagar una factura (ej: 15, 30, 45 días). Se usa para calcular dinámicamente la fecha de vencimiento (`DueDate`) de la orden.
+*   **Bloqueo Preventivo (`IsCreditBlocked`):** Un interruptor de emergencia. Si se activa, el cliente no puede seguir comprando a crédito, sin importar si tiene saldo a favor.
+*   **Motivo de Bloqueo (`BlockReason`):** Texto explicativo visible para el cajero (ej: *"Enviado a Legales"*, *"Cheque rechazado"*).
+
+---
+
+## 🧮 Cálculo de Deuda en Tiempo Real
+
+El sistema **no guarda** un campo estático con la deuda del cliente (lo que podría generar desfasajes de datos). En su lugar, la calcula dinámicamente en cada transacción.
+
+Cuando se consulta la deuda de un cliente (`ClientProfileRepository.CalculateCurrentDebtAsync`), el motor de base de datos ejecuta:
+1.  Busca todas las órdenes (`Orders`) pertenecientes al cliente.
+2.  Filtra aquellas cuyo estado de pago sea **distinto** a `Paid` (Pagado) o `Cancelled` (Cancelado).
+3.  Suma el `TotalAmount` de las deudas activas.
+
+---
+
+## 🛡️ Flujo de Validación en el Punto de Venta (POS)
+
+Cuando un Cajero intenta imputar un pago utilizando el método **"Cuenta Corriente"**, el sistema ejecuta una barrera de triple validación antes de confirmar la venta en el `OrderService`:
+
+1.  **Validación de Existencia:** Verifica si el cliente tiene un perfil financiero asignado. Si es "Consumidor Final", la venta a crédito se rechaza.
+2.  **Validación de Bloqueo:** El sistema lee el campo `IsCreditBlocked`. Si está activo, interrumpe el flujo y le muestra al cajero el `BlockReason`.
+3.  **Validación Matemática (Hard Limit):** 
+    Se calcula la fórmula: `Deuda Actual + Total de la Nueva Orden`.
+    *   Si el resultado es **menor o igual** al `CreditLimit`, la orden se aprueba, se genera y los avisos pasan a estado `Pending` (listos para publicar).
+    *   Si el resultado **supera** el límite, la transacción se aborta (Rollback), protegiendo a la empresa de sobregiros.
+
+> 💡 **Nota Operativa:** Si una venta se divide en múltiples pagos (Ej: 50% Efectivo, 50% Cuenta Corriente), el motor de riesgo **solo evalúa el monto que se intentará imputar a la cuenta corriente**, brindando flexibilidad al cliente para cubrir el excedente en efectivo.

Home.md

@@ -34,4 +34,37 @@ Navega por las siguientes secciones para entender el comportamiento interno del
 *   [📊 Liquidación Cruzada (Settlement)](Settlement.-)
 *[🛠️ Sistema de Reclamos y Auditoría](Claims-and-Audit.-)
 
+---
+
+## 📂 Arquitectura del Repositorio (Estructura de Carpetas)
+
+El proyecto utiliza una arquitectura de "Monorepo Lógico", separando claramente el Backend de los distintos clientes Frontend.
+
+
+📦 SIG-CM
+ ┣ 📂 src
+ ┃ ┣ 📂 SIG-CM.API             # 🟢 Capa de Presentación (Controladores REST, Middleware, Program.cs)
+ ┃ ┣ 📂 SIG-CM.Application     # 🟡 Casos de Uso, DTOs, Interfaces de Servicios y Validaciones (FluentValidation)
+ ┃ ┣ 📂 SIG-CM.Domain          # 🔴 Entidades Core (Listings, Users, Orders) e Interfaces de Repositorios
+ ┃ ┗ 📂 SIG-CM.Infrastructure  # 🔵 Acceso a Datos (Dapper), Implementación de Servicios, QuestPDF y MercadoPago
+ ┃
+ ┣ 📂 admin-panel              # 💻 Frontend Gerencial (React 19, Vite, Tailwind)
+ ┃ ┣ 📂 src
+ ┃ ┃ ┣ 📂 components           # Componentes reutilizables y Modales (ej: ListingDetailModal)
+ ┃ ┃ ┣ 📂 pages                # Vistas principales (PricingManager, Dashboard, CategoryManager)
+ ┃ ┃ ┣ 📂 services             # Clientes Axios (api.ts) y llamadas al Backend
+ ┃ ┃ ┗ 📂 store                # Estado global con Zustand (authStore)
+ ┃
+ ┗ 📂 counter-panel            # 💻 Frontend de Punto de Venta / Caja (React 19, Vite, Tailwind)
+   ┣ 📂 src
+   ┃ ┣ 📂 components           # Componentes de POS, Buscadores y Checkout
+   ┃ ┣ 📂 hooks                # Custom hooks (useDebounce, useCashSession)
+   ┃ ┣ 📂 pages                # Vistas de mostrador (UniversalPosPage, CashRegisterPage, TreasuryPage)
+   ┃ ┣ 📂 services             # Clientes Axios (api.ts)
+   ┃ ┗ 📂 store                # Estado de Carrito con Zustand (cartStore)
+
+Arquitectura Backend: El backend sigue los principios de la Clean Architecture (Arquitectura Limpia). El dominio (Domain) no tiene dependencias, mientras que la infraestructura (Infrastructure) conoce los detalles de la base de datos (SQL Server + Dapper).
+
+---
+
 > **💡 Tip:** Si eres un nuevo desarrollador en el equipo, te recomendamos empezar leyendo el **Motor de Cotización**, ya que es el corazón financiero de la aplicación.