Flujo del remito

El recorrido completo, desde que PAMI autoriza hasta que el paciente firma. Es el flujo central del producto: casi toda feature toca alguna de estas etapas.

El recorrido

1 · Autorización

Llega desde PAMI por scraping (ver PAMI SII) o se carga a mano. Sus renglones (AuthorizationDetails) dicen qué elemento se autoriza, en qué cantidad y si es obligatorio.

2 · Remito solicitado

De una autorización aprobada salen uno o más remitos. Acá se define lo más importante del ciclo: el tipo (entrega / visita / retiro) y, por línea, la causa de cambio (DELIVERY, CHANGE, RECHARGE, OTHER, SERVICE, NOACTION).

La causa de cambio queda fijada acá y no puede mutar

Ni al aceptar, ni al entregar. Un remito creado como "entrega" y luego editado a "recambio" revienta al cerrar: el paciente no tiene un suministro de ese elemento para recambiar. Hay una validación explícita en DeliveryNoteServiceV3 que compara la causa entrante contra la persistida, línea por línea.

En este punto las líneas tienen amountRequired.

3 · Aceptación en depósito

El operario revisa lo que va a salir, ajusta cantidades y elementos, y confirma. Lo hace sp_accept_delivery_note, que:

1. valida que el usuario tenga acceso a ese depósito (WAREHOUSESUSERS),
2. computa needsReservation por tipo de remito + causa de cambio,
3. valida disponibilidad con sp_validate_stocks_v2,
4. crea o actualiza las líneas (DELIVERYNOTESDETAIL),
5. crea las reservas (SUPPLIESRESERVATION).

Las líneas quedan con amountAccepted. La reserva no baja stock: lo bloquea para que no se asigne a otra entrega.

Errores típicos: DELIVERY_NOTE_NOT_FOUND, AMOUNT_ZERO_EXISTING_LINE, INSUFFICIENT_STOCK.

4 · Hoja de ruta

Varios remitos se agrupan en un viaje (DELIVERYNOTESDISPATCH). Cada parada es un detalle (DELIVERYNOTESDISPATCHDETAIL), que puede ser una entrega o una tarea genérica.

Estados de la parada (códigos de EntityStatus):

PLN (planificada) → TLV (en viaje) → FIN (finalizada)
                         ├─→ PAU (pausada)
                         ├─→ FAL (fallida)
                         └─→ CAN (cancelada)

Una hoja de ruta se puede editar (fecha y transportistas, mientras esté PLN), y una tarea fallida o cancelada se puede reanudar o transferir a otra hoja.

5 · Carga del vehículo

El stock se transfiere del depósito al vehículo. A partir de acá, lo que el transportista ve en BullStock sale de la tabla local supply_for_roadmap, que es el espejo del stock del vehículo proyectado para esa hoja de ruta.

6 · En el domicilio

El transportista abre la tarea en BullStock y, según el tipo de remito:

Tipo	Qué hace
Entrega	Escanea el serial de lo que deja y confirma cantidades
Retiro	Escanea o registra lo que se lleva; si el equipo nunca se registró, el SP lo crea on-the-fly
Visita técnica	Ambas cosas por línea, según la causa de cambio de cada una

Todo esto funciona sin conexión: si no hay señal, la operación se encola y se sincroniza después. Ver Offline-first.

7 · Firma digital

El paciente (o quien reciba) firma en pantalla. Se guarda la imagen más la metadata forense: hash, IP, geolocalización, tipo de red, DNI y datos del firmante, y versión de la app.

8 · Cierre

El momento crítico. sp_close_delivery_note_v2 recibe el JSON de líneas y despacha al sub-SP que corresponde según el tipo de remito:

Detalle completo en Cierre de remito.

9 · Resultado

Al cerrar bien, quedan actualizados:

• SUPPLIES — nueva ubicación (ATENTITYCODE/ATENTITYID) y estado de cada unidad.
• SUPPLYMOVEMENTHISTORY — se cierra el tramo anterior y se abre el nuevo.
• PATIENTSUPPLIES — se cierran los PS que dejaron de estar con el paciente y se crean los nuevos.
• SUPPLIESRESERVATION — se liberan las reservas consumidas.
• EVENTSLOGS — la traza de auditoría.

Casos que suelen sorprender

Caso	Qué pasa
Sobre-entrega	El operario puede entregar más de lo aceptado. Es válido: el SP genera líneas sintéticas. El cierre no debe fallar por eso
Líneas colapsadas	Mobile puede mandar una línea con un array de productId en vez de una línea por producto. El SP las expande
Retiro de algo no registrado	Si el paciente devuelve un equipo que nunca se cargó al sistema, el SP crea el Supply on-the-fly y lo aparea contra los PS huérfanos
PS sin supply	Un PATIENTSUPPLIES con SUPPLYID en NULL es normal: se dio de alta algo seriable sin conocer la serie. El SP lo materializa al retirar o visitar
Genérico seriado	Un supply cargado como producto "Genérico" se reclasifica al producto real por el prefijo del número de serie

Antes de gritar "bug"

Casi todos los fallos de cierre reportados terminaron siendo parametrización, no código: un EntityStatus que falta en ese ambiente, un ELEMENTS.ELEMENTTYPE mal cargado, un producto sin SKU, un PS huérfano. Recorré el checklist de la visión general de stored procedures antes de abrir el SP.