rckrdmrd/erp-core
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0086695b4c
erp-core/docs/05-user-stories/mgn-007/US-MGN-007-003-003-entrega-parcial-backorder.md

7.3 KiB
Raw Blame History

US-MGN-007-003-003: Entrega Parcial con Backorder

RF Asociado: RF-MGN-007-004 Módulo: MGN-007 - Ventas Básico Epic: Entregas de Ventas Prioridad: P1 Story Points: 3 Sprint: Sprint 17 Estado: Ready for Development Fecha: 2025-11-24

User Story

Como usuario de almacén, Quiero que el sistema genere automáticamente backorders para cantidades pendientes, Para gestionar entregas parciales sin perder trazabilidad de lo que falta entregar.

Descripción Detallada

Un backorder es una nueva delivery que se crea automáticamente cuando se valida una entrega parcial (qty_done < qty_ordered).

Ejemplo:

  • Delivery DO/2024/0001: qty_ordered=100, qty_done=60
  • Al validar, sistema crea backorder DO/2024/0002 con qty_ordered=40 en draft
  • Backorder hereda: cliente, productos, ubicaciones
  • Backorder tiene referencia al delivery origen: backorder_of_id

Criterios de Aceptación

Escenario 1: Crear backorder automáticamente (Camino Feliz)

Dado que delivery tiene línea: qty_ordered=100, qty_done=60, Cuando valido delivery, Entonces sistema crea backorder con qty_ordered=40, vincula backorder_of_id al delivery original.

Escenario 2: No crear backorder si entrega completa

Dado que delivery tiene qty_ordered=100, qty_done=100, Cuando valido delivery, Entonces sistema NO crea backorder.

Escenario 3: Backorder hereda datos del original

Dado que se crea backorder, Cuando se genera, Entonces copia: customer_id, location_from_id, location_to_id, order_id, reference.

Escenario 4: Backorder en estado draft editable

Dado que se crea backorder, Cuando se completa creación, Entonces backorder está en estado draft (puede editarse antes de validar).

Escenario 5: Notificar creación de backorder

Dado que se crea backorder, Cuando se completa, Entonces sistema crea mensaje en chatter: "Backorder DO/2024/0002 creado para 40 unidades".

Escenario 6: Backorder múltiples líneas

Dado que delivery tiene 3 líneas, 2 parciales y 1 completa, Cuando valido, Entonces backorder solo incluye las 2 líneas con cantidades pendientes.

Reglas de Negocio

  • RN-1: Backorder se crea solo si existe qty_pending > 0 en alguna línea.
  • RN-2: Backorder se genera en estado draft.
  • RN-3: Backorder hereda todos los datos del delivery original.
  • RN-4: backorder_of_id vincula al delivery origen.
  • RN-5: Solo líneas con qty_pending > 0 se copian al backorder.
  • RN-6: Número secuencial: Siguiente en secuencia DO/{year}/{seq}.
  • RN-7: Se notifica en chatter del delivery original y de la SO.

Tareas Técnicas

Backend

  • Service: DeliveryService.createBackorder(originalDelivery, pendingLines)
  • Calcular qty_pending por línea: qty_ordered - qty_done
  • Filtrar líneas con qty_pending > 0
  • Copiar header del delivery original
  • Generar número secuencial para backorder
  • Vincular backorder_of_id
  • Crear backorder en estado draft
  • Crear mensaje en chatter (delivery original + SO)
  • Unit tests (>80%)
  • Integration tests

Frontend

  • Badge: Mostrar "Backorder creado" en delivery validada
  • Link: Enlace a backorder desde delivery original
  • Tabla: Mostrar backorders en vista de SO
  • Indicador visual: qty parcial vs total en líneas
  • Component tests
  • E2E test: "should create backorder for partial delivery"

Database

  • Columna: inventory.deliveries.backorder_of_id (FK → deliveries.id)
  • Índice: idx_deliveries_backorder_of_id

Mockups / Wireframes

Notificación después de validar entrega parcial:

┌─────────────────────────────────────────────┐
│ ✓ Delivery DO/2024/0001 validada            │
├─────────────────────────────────────────────┤
│ Entregado: 60 unidades                      │
│                                             │
│ ⚠ Backorder creado:                         │
│   DO/2024/0002 (40 unidades pendientes)     │
│   [Ver Backorder]                           │
│                                             │
│ [OK]                                        │
└─────────────────────────────────────────────┘

Vista SO mostrando backorders:

┌─────────────────────────────────────────────┐
│ Sales Order SO/2024/0001                    │
├─────────────────────────────────────────────┤
│ Entregas:                                   │
│ • DO/2024/0001 [done] - 60 unid. (parcial)  │
│   └─ Backorder: DO/2024/0002 [draft] - 40  │
│                                             │
│ Progreso: 60/100 (60%) ▓▓▓▓▓▓░░░░           │
└─────────────────────────────────────────────┘

Casos de Prueba

Funcionales

  1. TC-001: Backorder creado si qty_done < qty_ordered
  2. TC-002: No backorder si qty_done = qty_ordered
  3. TC-003: Backorder hereda datos correctamente
  4. TC-004: backorder_of_id vinculado correctamente
  5. TC-005: Solo líneas pendientes en backorder
  6. TC-006: Backorder en estado draft
  7. TC-007: Número secuencial generado
  8. TC-008: Mensaje creado en chatter

No Funcionales

  1. Performance: < 200ms para crear backorder
  2. Seguridad: Mismos permisos que delivery original

Dependencias

  • US bloqueantes:
    • US-MGN-007-003-002 (Validar Entrega)
  • Módulos requeridos: MGN-005 (Inventario)

Notas de Implementación

  • Backorder se crea dentro de la misma transacción que la validación
  • Frontend: Mostrar claramente la relación entre delivery original y backorder
  • Considerar límite de backorders encadenados para evitar loops infinitos
  • Validar que las cantidades del backorder suman correctamente

Estimación Detallada

Tarea Horas
Backend 1.5
Frontend 1
Testing 1
Code Review 0.5
TOTAL 4 horas = 3 SP

Definition of Done

  • Código implementado según ET
  • Tests pasando (>80%)
  • Code review aprobado
  • Backorder se crea automáticamente
  • Solo líneas pendientes incluidas
  • Vinculación correcta
  • Estado draft correcto
  • Mensaje en chatter creado
  • QA validado
  • PO aprobado

Referencias