rckrdmrd/erp-transportistas-v2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ec43d9c6cd
erp-transportistas-v2/docs/02-definicion-modulos/MAI-003-ordenes-transporte/historias-usuario/US-MAI003-006.md
Adrian Flores Cortes ec43d9c6cd docs: Add Phase 3 secondary modules specifications (P1/P2/P3) 
Modules documented:
- MAI-003 (OT): README, REQUERIMIENTOS, RESUMEN-EPICA, 10 US
- MAI-006 (Tracking): README, REQUERIMIENTOS, RESUMEN-EPICA
- MAI-008 (Incidencias): 3 US (18 SP)
- MAI-011 (Flota): README, REQUERIMIENTOS, RESUMEN-EPICA
- MAI-012 (Combustible): 3 US (18 SP)
- MAI-013 (Mantenimiento): 3 US (18 SP)
- MAI-014 (Carriers): 3 US (18 SP)
- MAI-015 (Portal): 3 US (18 SP)
- MAE-016 (Carta Porte): 10 US
- MAE-017 (HOS): 3 US (16 SP)
- MAE-018 (Reportes): 3 US (18 SP)

Phase 2+3 complete: 13 modules, 50+ User Stories

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-27 02:24:35 -06:00

4.9 KiB
Raw Blame History

US-MAI003-006: Modificar OT en borrador

Metadata

Campo Valor
ID US-MAI003-006
Epica EPIC-MAI-003 - Ordenes de Transporte
Modulo ordenes-transporte
Prioridad P1
Story Points 5
Sprint Por asignar
Estado Backlog

Historia de Usuario

Como despachador de una empresa transportista, quiero modificar los datos de una orden de transporte que se encuentra en estado BORRADOR, para corregir errores, completar informacion faltante o actualizar datos antes de confirmar la OT para planeacion.

Descripcion Detallada

Cuando una OT se crea en estado BORRADOR, es comun que el despachador necesite volver a editarla para completar datos que no estaban disponibles al momento de la creacion inicial, corregir errores de captura, o actualizar informacion proporcionada por el cliente. El sistema debe permitir la modificacion completa de todos los campos de la OT mientras se encuentre en estado BORRADOR.

Una vez que la OT cambia a estado CONFIRMADA o cualquier estado posterior, los datos se consideran bloqueados para edicion. Esta restriccion protege la integridad de la informacion operativa, ya que una OT confirmada puede estar siendo procesada por planeacion, asignada a un viaje, o en ejecucion.

La modificacion debe registrar el usuario que realiza el cambio (updated_by_id) y la fecha de actualizacion (updated_at), manteniendo la trazabilidad completa de cambios.

Criterios de Aceptacion

Escenario 1: Modificacion exitosa en estado BORRADOR

Dado que existe una OT en estado BORRADOR, Cuando el despachador modifica los datos de carga (peso_kg de 5000 a 7500, pallets de 10 a 15) y guarda los cambios, Entonces el sistema actualiza los campos modificados, recalcula tarifa/total si aplica, registra updated_by_id y updated_at, y muestra la OT actualizada.

Escenario 2: Rechazo de modificacion en estado CONFIRMADA

Dado que existe una OT en estado CONFIRMADA, Cuando el despachador intenta modificar cualquier campo de la OT, Entonces el sistema rechaza la operacion con error 422 y mensaje "Solo se pueden modificar ordenes de transporte en estado BORRADOR".

Escenario 3: Recalculo automatico de tarifas al modificar carga

Dado que una OT en BORRADOR tiene una tarifa asignada de tipo POR_TONELADA, Cuando el despachador modifica el peso_kg de la carga, Entonces el sistema recalcula automaticamente tarifa_base, subtotal, IVA y total basandose en el nuevo peso y la tarifa asociada.

Escenario 4: Modificacion parcial de datos

Dado que una OT en BORRADOR tiene datos completos, Cuando el despachador envia una actualizacion parcial (solo cambia destino_direccion y destino_ciudad), Entonces el sistema actualiza unicamente los campos enviados sin afectar los demas datos de la OT.

Tareas Tecnicas

  • Database: Utilizar la tabla transport.ordenes_transporte existente. Los campos updated_at y updated_by_id registran la ultima modificacion. Soft delete via deleted_at.
  • Backend: Agregar metodo update() en OrdenTransporteService con validacion de estado: solo permitir actualizacion si estado = BORRADOR. Implementar actualizacion parcial (PATCH semantics). Agregar logica de recalculo de tarifas cuando se modifican campos de carga y hay tarifa_id asignada. Configurar endpoint PATCH /api/v1/ordenes-transporte/:id. Crear UpdateOrdenTransporteDto con todos los campos opcionales y validaciones condicionales.
  • Frontend: Reutilizar el formulario de creacion de OT en modo edicion. Deshabilitar el boton de edicion si el estado no es BORRADOR. Mostrar mensaje informativo cuando la OT no es editable. Al guardar, mostrar resumen de campos modificados antes de confirmar.
  • Tests: Tests unitarios de validacion de estado para edicion. Tests de actualizacion parcial (solo campos enviados). Tests de recalculo de tarifas al modificar carga. Tests de rechazo en estados no editables.

Dependencias

  • Depende de: US-MAI003-001 (la OT debe existir en estado BORRADOR)
  • Bloquea: Ninguno directamente (mejora la experiencia de captura de datos)

Notas Tecnicas

  • Endpoint: PATCH /api/v1/ordenes-transporte/:id
  • Entity: OrdenTransporte -> transport.ordenes_transporte
  • Validacion de estado: En el servicio, antes de aplicar cambios, verificar que ot.estado === EstadoOrden.BORRADOR. Si no, lanzar excepcion UnprocessableEntityException
  • Actualizacion parcial: Utilizar PATCH semantics donde solo los campos presentes en el body se actualizan. El DTO debe tener todos los campos como opcionales con @IsOptional()
  • Recalculo de tarifa: Si se modifica peso_kg, volumen_m3, piezas o pallets y existe tarifa_id, ejecutar el calculo de tarifa del servicio de MAI-002
  • Auditoria: Siempre actualizar updated_at = NOW() y updated_by_id = currentUserId en cada operacion de update

US-MAI003-006 - ERP Transportistas v1.0.0