Hallazgos verificados — Edición (PATCH) de pedidos con combos¶
Fecha: 2026-07-17. Verificado contra SAP dev ZZ_COMPU_3 vía sl-helper.js, pedidos de
prueba 33276 (TESTBOM-PC + línea normal), 33279 (combo 01157) y 33281 (combo 06565, componente
serializado 01892). Los tres cancelados al terminar.
Contexto: revierte la decisión del 2026-07-16 ("los pedidos con combos no se editan"). Requerimiento nuevo: el pedido con combos sí se edita — líneas normales, línea padre (cantidad, precio, descuento) y seriales de los componentes; lo inmutable es la receta (qué componentes y cuántos por combo). Esto reabre la incógnita de 03 §6 (PATCH con líneas explotadas), que acá queda resuelta empíricamente.
Todos los PATCH con B1S-ReplaceCollectionsOnPatch: true (como usa updateOrder).
1. Matriz de resultados¶
| # | Prueba | Resultado | Implicancia |
|---|---|---|---|
| B | Reenviar TODAS las líneas idénticas (padre + iIngredient + normal) | 204 — sin duplicados, TreeType intacto |
El PATCH de reemplazo actual es seguro en el caso neutro |
| D | Cantidad del padre 1→2, hijos reenviados con qty vieja | 204 — SAP re-escala los hijos solo (RAM 2→4, resto 1→2) desde la receta; ignora las qty enviadas | La cantidad del padre es editable; los hijos se mantienen consistentes siempre |
| H | Cantidad de un ingrediente 4→99 | 204 pero SIN efecto — SAP la ignora en silencio | La receta es inviolable a nivel SAP; no hace falta bloquear en el OMS por integridad (sí por UX) |
| I | Precio de un ingrediente 0→500 | 204 — PriceAfterVAT queda 500 pero Price/LineTotal siguen 0 y DocTotal no cambia |
Cosmético pero sucio (aparecería en impresiones): NO enviar precios ≠ 0 en ingredientes |
| E | Cantidad de la línea normal 1→3 | 204 — DocTotal correcto | Las líneas normales se editan igual que siempre |
| F | Omitir las líneas iIngredient del PATCH (solo padre + normal) | 204 — SAP conserva/regenera los ingredientes correctamente | El backend podría mandar solo padre+normales… pero perdería los seriales (ver §2) |
| G | Depósito de un ingrediente CEN→MUL | 400 "Enter a valid value in Whse field" — pero la línea normal dio el mismo 400: los TESTBOM-* solo tienen CEN en ItemWarehouseInfoCollection |
No concluyente — el 400 es por ítem sin ese depósito, no por ser ingrediente. Reprobar con ítem real si el caso importa |
| S1 | Serial en línea ingrediente (01892, serial disponible en CEN) reenviando todas las líneas | 204 y persistido | ✅ El requerimiento clave es viable: los seriales de componentes se cargan por PATCH |
| S2 | PATCH "mínimo" de una sola línea ({LineNum, ItemCode, SerialNumbers}) |
400 "On Contents tab, enter item or items" |
Con el header de replace hay que reenviar todas las líneas; no hay patch parcial de una línea |
| S3 | Reenviar líneas sin el campo SerialNumbers |
204 — el serial se conserva | Omitir el campo no borra seriales |
| S4 | Reenviar con SerialNumbers: [] explícito |
204 — el serial NO se borra (queda igual) | ⚠ Quitar un serial vía PATCH no funciona por esta vía — punto abierto si la UX lo necesita |
Validación de seriales: S1 con un serial no disponible en el depósito falla con
1320000147 - Item ... with serial number ... does not exist in warehouse — SL valida
disponibilidad contra el depósito de la línea.
2. Diseño que habilitan los hallazgos¶
- Quitar el guard 409 de
updateOrder(orders.service.ts:445-453). - Reenviar todas las líneas (como hoy), con una regla para las
iIngredient: mandarLineNum, ItemCode, Quantity (la actual), WarehouseCode (el actual), SerialNumbersy precio 0 / sin precio (evita el sucio cosmético de I). Cantidades de ingredientes: da igual lo que se mande (SAP las recalcula), pero mandar la actual es lo honesto. processOrderLinesen update no debe aplicar el fallback de creación de ítems a líneas que vienen de SAP con LineNum (ya existen) — revisar que no ensucie ingredientes.- Tras el PATCH, refrescar el pedido desde SAP: si cambió la cantidad del padre, los hijos re-escalados los conoce SAP, no el cliente.
- UI: componentes como filas normales indentadas bajo su padre — serial editable; cantidad/precio de ingrediente no editables (SAP los ignora/recalcula — deshabilitar para no mentir); depósito de ingrediente: pendiente de reprobar (G).
✅ Implementado en el backend (2026-07-17, commit posterior a 04c29f5)¶
OrdersService.updateOrder (orders.service.ts):
- Se quitó el guard 409. Los pedidos con combos se editan.
- Las líneas del PATCH se separan por
LineNum: las que ya existen en SAP se reenvían sin pasar porprocessOrderLines(el fallback de creación solo corre para líneas nuevas sin LineNum) — implementa §2.3. - Para las líneas cuyo
TreeTypeen SAP esiIngredient: se envíaItemCode,QuantityyWarehouseCodeactuales de SAP (no lo que mande el cliente), sin precio, y losSerialNumbersdel DTO — implementa §2.2 y §2.5. - Tras el PATCH se hace un
GET Orders(n)completo y se devuelve eso (no la respuesta del PATCH) — implementa §2.4 y evita la trampa de seriales de §3. - Verificado E2E en dev (pedido 33285, TESTBOM-PC): padre 1→2 → 204, SAP
re-escaló RAM 2→4 y el resto 1→2, ingredientes en total 0,
TreeTypeintacto.
Cubierto por unit tests en orders.service.spec.ts (protección de receta del
ingrediente + serial que sí viaja; padre con cantidad/precio editados).
Pendiente: quitar un serial vía PATCH no funciona (S4) — punto abierto si la UX lo necesita; y reprobar el cambio de depósito de ingrediente con ítem real (G).
3. Trampa de medición (para futuras verificaciones)¶
GET Orders(n)?$select=DocumentLines devuelve SerialNumbers vacío aunque haya seriales
grabados; el GET completo sí los trae. Dos hallazgos falsos de esta sesión salieron de ahí.
4. Efecto sobre decisiones anteriores¶
- 01 §2 y 04 §1: la fila "¿Se pueden editar pedidos que contienen combos?" queda revertida (2026-07-17): sí se editan; la receta sigue siendo inmutable (y SAP la protege solo, ver H y D).
- 03 §6: la incógnita del PATCH queda verificada — este documento la reemplaza.
- RF-5 de 06 y el bloqueo implementado en el frontend (2026-07-17) quedan a revertir cuando se implemente este diseño.