Autor: Iker Acevedo¶
Fecha creación: 2026-09-16
Estado: preprod
Orquestador — LiquidarPedidosDinamicoUseCase¶
Es la única clase del motor Dinámico que toca infraestructura (Mongo). Todo lo que invoca — Clasificador, Validador, Resolvedor, Calculadoras, ConstructorPeticion — es dominio puro, sin I/O. Vive en Aplicacion/CasosUso/Liquidacion/LiquidarPedidosDinamicoUseCase.cs, junto al DepurarLiquidacionUseCase.cs legacy (mismo directorio, distinto namespace de C#).
Partición: cómo decide qué motor usa cada pedido¶
flowchart LR
A[("ConfiguracionLiquidacionTransportadora")] --> B["Agrupar por NombreEnPedidos
(normalizado: trim + mayúsculas)"]
C[("Pedidos entrantes
(PedidosInter)")] --> D{"¿Existe configuración para
Transportadora del pedido?"}
B --> D
D -- "No existe" --> E["Lote LEGACY"]
D -- "Sí" --> F{"MotorLiquidacion"}
F -- "Dinamica" --> G["Lote DINÁMICOS
(persiste)"]
F -- "Sombra" --> G
F -- "Legacy" --> E
F -- "Deshabilitado" --> H["No se procesa"]
G --> I["LiquidarAsync"]
E --> J["DepurarLiquidacionUseCase.DepuraLiquidacionInter"]
style H fill:#fce4ec,stroke:#ad1457
Fuente: carpeta de diagramas.
Particionar(JArray pedidos, List<ConfiguracionTransportadora> configuraciones) agrupa las configuraciones de ConfiguracionLiquidacionTransportadora por NombreEnPedidos (normalizado: trim + mayúsculas), y por cada pedido compara su campo Transportadora (normalizado igual) contra ese diccionario:
- Existe configuración y
MotorLiquidacionesDinamicaoSombra→ lote Dinámicos. - Cualquier otro caso (
Legacy,Deshabilitado, o sin configuración) → lote Legacy.
Devuelve (JArray Dinamicos, JArray Legacy). Los dos lotes se procesan en la misma invocación de Function.cs — no son excluyentes.
LiquidarAsync — el pipeline sobre el lote Dinámico¶
Por cada pedido del lote Dinamicos:
- Mapea el pedido crudo a
PedidoLiquidable(MapeadorLiquidacionDinamica.MapearPedido). - Corre pipeline completo (Clasificar → Validar trayecto → Resolver tarifa → Calculadoras →
ConstructorPeticion) — ver Visión general § Pipeline. - Si algún paso no puede avanzar, la guía queda registrada como
GuiaNoLiquidadacon suMotivoNoLiquidacion— sin reintento automático. - Inserta los documentos resueltos directo en Mongo, vía
IDocumentRepository.InsertarLiquidacionesLogighoAsync— la misma colección y el mismo repositorio que usa Legacy en su rama de pruebas locales (#if DEBUG). Ver Infraestructura para la confirmación completa. - Devuelve
ResumenLiquidacionDinamica(DocumentosLiquidados, NoLiquidadas).
Una transportadora en Sombra corre exactamente este mismo pipeline — la única diferencia es que el resultado no se persiste. Sirve para validar una configuración nueva (tarifas, trayectos, tope de kilos) contra pedidos reales, sin arriesgar un solo documento en LiquidacionesLogigho.
Function.cs — el entry point real¶
Es quien de verdad arranca la Lambda:
- Obtiene de Mongo
ConfiguracionLiquidacionTransportadora,TarifasTransportadoraTiendayTrayectosTransportadora. - Los mapea a dominio con
MapeadorLiquidacionDinamica. - Llama
Particionar. - Ejecuta
LiquidarAsyncsobre el lote Dinámico. - Si quedan pedidos en el lote Legacy, invoca
DepurarLiquidacionUseCase.DepuraLiquidacionInter(...)sobre ellos.
Fases del proyecto¶
El README.md de LiquidacionDinamica/ no numera fases F1-F4 de forma explícita y centralizada — se mencionan sueltas en comentarios de código (TarifaTransportadoraTienda.cs, TrayectoTarifa.cs). Reconstruido a partir de esos comentarios y del estado real del código:
| Fase | Qué cubre | Estado |
|---|---|---|
| F1 | Modelos de configuración + validación externa (script + front) | Hecho |
| F2 | Calculadoras de peso, dominio puro | Hecho |
| F3/F4 | Infraestructura y capa de aplicación completas — orquestación end-to-end, persistencia de auditoría, ejecución real de pagos de Marketing/Referido | Parcial — LiquidarPedidosDinamicoUseCase y MapeadorLiquidacionDinamica ya cubren buena parte de esto, pero la colección AuditoriaLiquidaciones todavía no tiene quién escriba en ella (ver Frontend → Auditoría de Excepciones) |
El README puede estar desactualizado respecto al código — esto es una foto tomada el 2026-09-16, no una fuente viva.
Tests¶
No hay un archivo de test propio para LiquidarPedidosDinamicoUseCase dentro de ApiLambdaLiquidacionesLogighoAOT.Tests/LiquidacionDinamica/ — la carpeta cubre solo el dominio puro (Calculadoras, Políticas de Peso, Validación) y el mapeador de infraestructura. El propio código del orquestador señala que ese "cableado" (leer Mongo, particionar, invocar Legacy) no tiene cobertura de test dedicada todavía.
Historial de cambios¶
| Fecha | Autor | Cambio |
|---|---|---|
| 2026-09-16 | Iker Acevedo | Documentación inicial del orquestador y de Function.cs. |