Skip to main content

Fase 3: Operación Crítica del WMS, Idempotencia y Condiciones de Carrera

Objetivo: Habilitar el registro físico de movimientos en almacén bloqueando colisiones de datos simultáneas y duplicados de red.

1. Track Backend (.NET 10 & PostgreSQL)​

[ ] Task 3.1: Lógica Transaccional de Movimientos (Kardex)​

  • Descripción: Implementar la escritura inmutable de transacciones del almacén.
  • Detalle:
    • Crear e instanciar servicios para movimientos de inventario (wms.movimientos_inventario y wms.movimientos_inventario_detalle).
    • Restringir la base de datos a nivel de roles y políticas de seguridad para prohibir instrucciones de modificación (UPDATE) o eliminación (DELETE), garantizando el Ledger de Kardex.

[ ] Task 3.2: Aislamiento Pesimista con Bloqueo de Filas (FOR UPDATE)​

  • Descripción: Blindar los saldos físicos contra actualizaciones simultáneas.
  • Detalle:
    • Escribir queries con bloqueo de fila nativo (FOR UPDATE) en Entity Framework Core al recuperar el stock de medicamentos.
    • Asegurar el flujo del Lock Wait para poner en cola de espera cualquier transacción concurrente que colisione con el mismo registro en disco.

[ ] Task 3.3: Middleware de Idempotencia Transaccional​

  • Descripción: Crear filtros de infraestructura para evitar cargos dobles causados por reconexiones de red.
  • Detalle:
    • Desarrollar un filtro global de acción en .NET 10 (IdempotentFilter.cs).
    • Extraer y comprobar el valor de la cabecera Idempotency-Key (UUIDv4) contra una caché rápida en memoria de 120 segundos antes de ejecutar mutaciones en base de datos.

2. Track Frontend (React SPA & Dexie.js)​

[ ] Task 3.4: Formularios de Operación WMS y Módulo Comercial​

  • Descripción: Diseñar pantallas de captura para el flujo físico de inventario y las operaciones comerciales críticas.
  • Detalle:
    • Crear las interfaces de usuario para el WMS: Registro de Entradas (Recepcón de OC), Surtido/Picking guiado por ruta FEFO con escaneo de código de barras por cada ítem, y Ajustes/Mermas con motivo de ajuste.
    • Implementar el flujo de Pedido en Borrador (COM_Bor): guardado parcial en pending_pedidos de Dexie, reanudación desde cualquier dispositivo y transición a estado Enviado al confirmar (RF-COM-07).
    • Implementar el flujo de Transferencias Inter-CEDIS: selección de origen/destino, escaneo de lotes, confirmación de recepción con diferencias (RF-WMS-05).
    • Implementar el módulo de Corte de Caja (FAC_Cor): desglose de ventas por forma de pago, cálculo automático de diferencias de arqueo y generación del registro de cierre de turno (RF-FAC-07).
    • Implementar el flujo de Clasificación de Devoluciones: captura del motivo (7 categorías), destino del lote (reintegro al WMS o baja sanitaria) y nota de crédito al cliente.

[ ] Task 3.5: Almacenamiento Local de Transacciones en Cola (Dexie.js)​

  • Descripción: Habilitar todas las colas offline en IndexedDB con el prefijo pending_ para cada flujo operativo.
  • Detalle:
    • Crear y mapear los almacenes locales en la instancia de Dexie correspondiente al módulo:
      • pending_movimientos (WMS: entradas, salidas, ajustes)
      • pending_pickings (WMS: confirmaciones de surtido por lote)
      • pending_pedidos (Comercial: borradores y pedidos capturados sin red)
      • pending_abonos (Crédito: registros de pago capturados en campo)
    • Modificar el comportamiento de todos los formularios: si falla la comunicación de red, el payload se almacena localmente con estado Pendiente y libera la pantalla sin bloquear al operador.

[ ] Task 3.6: Inyección Automática de Llaves de Idempotencia​

  • Descripción: Diseñar la firma criptográfica de peticiones desde el cliente.
  • Detalle:
    • Configurar las peticiones de envío del frontend para inyectar una cabecera HTTP Idempotency-Key con un valor UUIDv4 generado mediante la API nativa de JavaScript crypto.randomUUID().