Este mapa está pensado para navegar la forma real del backend: estructura del agregado, flujo de promociones, flujo de pagos, reconciliación, persistencia y lecturas operativas. Prioriza estructura, secuencia y anclajes de implementación por encima de la prosa exhaustiva.
`Ticket` sigue siendo la raíz económica de verdad.
El backend conserva la separación del modelo entre captura, maestros aplicados y ledger explicado.
Vista transitoria compartida de precios con orquestación ordenada por familia.
El motor usa una `ItemPricingView` transitoria en vez de recomputar cada método por separado.
`COMBO` es estable y determinístico, pero sigue siendo heurístico y no un optimizador global exhaustivo.
Lo que queda ya no son familias faltantes, sino heurísticas más profundas en estados ambiguos del ticket.
Consulta, aplicar, redistribución posterior y seguimiento explícito alrededor del vuelto.
Las promociones de pago se resuelven a través de la tupla real del catálogo de pagos `idmdep + ididmdep + cuota`.
`POSTPAGO` es explícito, itemizado y reconciliado contra saldo pre-pago por movimiento.
Validadores estructurales más una capa de cierre final más fuerte.
Los validadores cubren forma, referencias, vínculo pago/promoción y restricciones de no-ledger.
La finalización usa el resumen de reconciliación para imponer invariantes económicos que los validadores por sí solos no cubren completos.
La suite ya incluye escenarios extremos válidos e inválidos de consulta/aplicar.
Las lecturas normales ahora se apoyan primero en persistencia normalizada, con instantánea como capa de respaldo y auditoría.
El resumen operativo, el detalle operativo, la reconciliación y la hidratación normal ya se apoyan en filas relacionales persistidas.
`snapshotJson` sigue almacenado, pero hoy su rol es compatibilidad, respaldo y auditoría, no fuente primaria de lectura operativa.
Los plugins de test de Maven ahora ejecutan Mockito como `-javaagent` explícito, evitando la vieja advertencia de self-attach dinámico en JDK 25. Es un cambio pequeño, pero importa en un proyecto que ya está claramente en etapa de endurecimiento final.
No es exhaustiva; solo lo suficiente para saltar de concepto a la implementación.
| Área del Modelo | Estado | Anclajes Principales | Evidencia Principal |
|---|---|---|---|
| Agregado / lifecycle | Implementado | TicketService | `TicketServiceTest`, `TicketControllerTest` |
| Motor ITEM | Implementado Bordes heurísticos | ItemPromotionEngine, ComboPromotionEngine, CantidadPromotionEngine | suite de tests del motor de promociones |
| Consulta / aplicar / postpago | Implementado | PaymentPromotionEngine, TicketService | escenarios de reconciliación en `TicketServiceTest` |
| Lecturas operativas | Implementado | TicketOperationalSummary, TicketOperationalDetail | tests de servicio/controller + SQL Server IT |
| Persistencia / mapper | Implementado Híbrido | TicketPersistenceMapper | mapper test + repository tests + SQL Server IT |
Lectura ejecutiva del estado real del código contra el modelo y la alineación actual.
| Tema | Completion Rate | Nota Corta |
|---|---|---|
| Agregado `Ticket` | 94% | Estructura central estabilizada y coherente con el modelo. |
| `articulos[]` / `items[]` / `promociones[]` / `pagos[]` / `movimientos[]` | 95% | Separación conceptual ya consolidada en runtime, API y persistencia. |
| Motor `MAYORISTA` | 90% | Resuelto con tramos, beneficio al cliente y reglas tempranas. |
| Motor `VENTAXBULTO` | 82% | Implementación conservadora sólida; pueden quedar variantes reales de negocio. |
| Motor `GRUPOMAYORISTA` | 90% | Pool grupal y selección de tramo ya cerrados. |
| Motor `COMBO` | 86% | Determinístico y fuerte, pero todavía heurístico en casos complejos. |
| Motor `CANTIDAD` | 89% | Soporta descuentos, recargos y acumulatividad/no acumulatividad. |
| Promociones por convenio | 92% | La elegibilidad por `cliente.convenio.id` ya está en la cadena de motores. |
| `CUPON` no financiero | 93% | Semántica cerrada como promo textual sin impacto económico. |
| Promociones de pago | 90% | `CONSULTA`, `APLICAR`, snapshot y consumo agregado ya endurecidos. |
| `POSTPAGO` | 88% | Flujo explícito, itemizado y reconciliado con vuelto absorbente. |
| Distribución de pagos | 94% | Proporcional sobre saldo neto por movimiento, no FIFO. |
| Tratamiento fiscal de movimientos derivados | 91% | Escalado proporcional sobre `nucleoimpositivo[]` ya consistente. |
| Reconciliación y finalize | 92% | Invariantes fuertes, validaciones estructurales y resumen de cierre robusto. |
| Persistencia normalizada | 89% | Dominante en lectura normal; el snapshot ya quedó como respaldo. |
| Read models operativos | 87% | Summary y detail ya exponen breakdown económico útil para operación. |
| Tests end-to-end de caja real | 84% | Buena base ya cubierta; aún se puede ampliar con más escenarios pesados. |
| SQL Server IT de dominio | 83% | Más fuerte que al inicio, pero todavía ampliable en flows complejos. |