Ciclo de vida de una venta — Aquazaku

Ciclo de vida de una venta — Aquazaku A lifecycle diagram generated by Archify. 01 / Estados 02 / Terminales 03 / Outcomes REGISTRADA · pos o seller crea la venta · Estados 01 REGISTRADA pos o seller crea la venta PENDIENTE_PAGO · stock descontado · Estados 02 PENDIENTE_PAGO stock descontado PAGO_PARCIAL · abona una parte · Estados 03 PAGO_PARCIAL abona una parte PAGO_TOTAL · verificación pendiente · Estados 04 PAGO_TOTAL verificación pendiente COMPLETADA · stock + caja cerrada · Estados 05 COMPLETADA stock + caja cerrada ANULADA · stock devuelto + audit · Terminales · terminal ANULADA stock devuelto + audit terminal FALLO_AUDITORIA · monto inconsistente · Terminales · terminal FALLO_AUDITORIA monto inconsistente terminal sin pago inmediato abona parte completa verificado cliente se va monto != venta Legend start active state decision terminal success failure / exit

Por qué un state machine, no 'mismo día en curso'

  • • La regla 'mismo día en curso' falla en bordes temporales: un pago a las 23:59 contra una venta de ayer parece inválido aunque no lo sea.
  • • El state machine es forward-only: REGISTRADA → PENDIENTE_PAGO → PAGO_PARCIAL/TOTAL → COMPLETADA. Los pagos parciales son un estado válido, no un error de redondeo.

Quién anula, quién verifica

  • • Anular antes de cobrar: cualquier rol con permiso ventas:anular (ADR-0003). Stock devuelto a su lote original.
  • • El auditor detecta PAGO_TOTAL con monto inconsistente y lo manda a FALLO_AUDITORIA. La reversión corre por el contador, no por el pos que cobró.

ANULADA siempre deja huella

  • • Toda anulación se registra en audit_log con el método, el rol_ejercido y el motivo. ANULADA no es un delete — es un terminal con datos.
  • • El stock que se había descontado vuelve a su lote. Si el lote ya no existe, el sistema lo manda a un lote de 'recuperación' para auditoría posterior.