Análisis Funcional: Módulo Caja (efectivo por punto de venta)

Date: 2026-08-05 · Actualizado: 2026-09-14 Status: Vigente — describe el módulo tal como está implementado hoy en main (E4, E4-multi y E4b, las tres mergeadas). Lo poco que sigue pendiente está marcado como tal, caso por caso, y listado en Preguntas Abiertas. Autor: Product Owner + UI Engineer Agents (metodología Raxar Factory) Fuentes: revisión "Revisión desarrollo Caja Soterex" (2026-08-05, Teresa Ortiz y Diego Sánchez de CIS-EC + Carlos San Martín de CIS-AR), ADR-005, ADR-007, los diseños técnicos de E4/E4-multi, y el código de main.

Por qué existe este paquete aparte

El Análisis Funcional original es del 2026-07-24 y no cubre el módulo Caja: cuando se escribió, el módulo no existía ni estaba pedido. Llegó después, con la entrega E4 del plan v2, y se construyó guiado por ADRs y diseños técnicos — sin pasar por un análisis funcional propio. Este paquete paga esa deuda.

No reemplaza al análisis original: lo complementa. Todo lo que hace a transacciones, roles, prefondeo y administración sigue viviendo allá.

Cómo leer este documento

Todo lo que este paquete describe está implementado y funcionando, salvo lo que se marca explícitamente como pendiente. Leelo en presente.

Nota para quien lo leyó antes del 2026-09-14. Este paquete se escribió el 2026-08-05, cuando E4b todavía era un plan, y quedó lleno de marcas "✅ implementado hoy" / "📋 planificado". Las tres sub-entregas se mergearon el 2026-08-06 (PRs #14, #15 y #16), así que durante más de un mes esas marcas dijeron exactamente lo contrario de la realidad: presentaban como vigente el modelo de dos saldos —que ya no existe— y como futuro el de tres capas, que es el que corre. Se eliminaron. Un análisis funcional tiene que describir el sistema que hay; la historia de cómo llegó vive en los ADRs y en los planes.

El plan de ejecución de E4b, con el detalle de cada sub-entrega, está en 2026-08-05-e4b-ajustes-caja-reunion-cliente.

Dos cosas se implementaron distinto de como las había escrito el plan, ambas decididas al construirlas y documentadas en ADR-007:

• El cierre de caja no genera ningún movimiento de retiro. El plan decía conservarlo; al implementarlo resultó que dejaba la caja mostrando cero con la plata físicamente en el PDV, y hacía ambiguo el saldo heredado cuando dos cierres caían en el mismo segundo. La plata se queda en la caja y la apertura siguiente arranca con ese saldo.
• Una sola caja abierta por usuario, garantizado por la base de datos y no solo por código.

Lo que sigue pendiente de verdad, a la fecha de esta actualización:

• El aviso entre la Holding y el Prefondeo País no existe: repartir a los países más de lo que la Holding recibió no avisa nada, a diferencia de la frontera de abajo (país → caja), que sí avisa. Está documentado en ADR-010 (Proposed) y planificado como entrega F2 del plan v3.
• El filtro por motivo en Reportes → Cajas (sí existe en la pantalla de Caja).
• Los comprobantes membretados de apertura y cierre.
• El bloque de UI "Circuito de fondos" que diseña el documento 6.

Índice

1. Resumen del alcance — qué problema resuelve, para quién, qué queda afuera, y el glosario del dominio.
2. Modelo de saldos — cómo se mueve la plata entre las capas, con el ejemplo numérico de la reunión. Empezá por acá si es tu primer contacto con el módulo.
3. Flujos de Caja — apertura, cierre, fondeo, ajuste, pago, alta de cajas, tipo de cambio.
4. Diagramas de Actividad — secuencias entre actores, el circuito completo del dinero, y los casos de concurrencia.
5. Secuencias de Pantalla — cada pantalla del módulo, su ruta, su permiso y sus estados.
6. UX de múltiples cajas y fondeo — criterio de diseño de lo más delicado: elegir caja, distinguir fondeo de ajuste, alertar sin bloquear.
7. Preguntas Abiertas — qué falta confirmar con el cliente y qué quedó pendiente de implementar.