FT-PRD-04 · Propuesta del proveedor de Mercaderías

En 30 segundos

Cuando un proveedor de Mercaderías envía una propuesta, Compras tiene que aceptarla, rechazarla o cancelarla antes de que se pida el SKU a SAP. Esta épica cuida ese tramo: la bandeja de Compras, el rechazo con motivo por campo, los avisos al proveedor, los plazos que vencen solos y el historial de lo que se canceló, para que ninguna propuesta se pierda sin explicación.

• Módulo dueño: MS-02 Producto. También participan: MS-14 Avisos y ayuda, MS-07 Ingesta de archivos, MS-08 Adaptadores de salida, MS-13 Identidad y acceso.
• Etapa 4 · Visto bueno. Recibe «PE-4 · Propuesta enviada» y entrega «PE-5 · Visto bueno dado».
• APIs: construye 2 y usa 9 que construyen otras épicas.
• Eventos: publica 6 y consume 4.

1. Dónde encaja

Recibe

Entrega

Cambios de estado que hace

Tareas que abre o cierra: Visto bueno de Compras, Corrección.

2. Diagrama de contexto

Quién participa y cómo se conecta. Las pantallas llegan por el BFF del portal, que valida el token y compone; cada módulo vuelve a validar el token y decide sus permisos con los roles de MS-13.

🟩 Verde: nuevo, se construye · 🟦 Azul: ya existe y se queda, se reutiliza su código · 🟧 Naranja: temporal o se retira (se apaga en R3) · ⬜ Gris: sistema externo · ★ módulo dueño

3. Diagrama de flujo

El camino principal, paso por paso. Cuando una pantalla llama a un módulo se ven dos flechas: la pantalla al BFF y el BFF al módulo. Los eventos salen del outbox del módulo después de guardar; quien los consume ignora los repetidos.

3.1 Si Compras rechaza y nadie corrige

3.2 Placeholders de pre-compra con o9

4. Si algo sale mal

• Compras rechaza. La propuesta regresa a Borrador con una tarea de Corrección. El proveedor ve «Rechazada» con el motivo de cada campo y recibe un aviso; al reenviar, vuelve a la bandeja de Compras.
• El proveedor no corrige a tiempo. El reloj de plazos de MS-02 le recuerda cada semana. Al vencer el plazo de corrección, la propuesta pasa a Cancelado, sus EAN quedan libres y el proveedor la ve en su historial con el motivo «Venció el plazo de corrección».
• Compras no responde a tiempo. La propuesta no se cancela. A los 15 días se le recuerda a Compras y a los 30 la tarea pasa a la cola del área de Gobierno de Producto para reasignarla; el proveedor ve «Revisión de compras» con la fecha en que entró.
• Otra persona cambió la propuesta mientras Compras la revisaba. La confirmación responde 409 VERSION_CONFLICT; el portal recarga la propuesta y Compras vuelve a decidir sobre la versión nueva.
• El archivo de o9 trae renglones en otro orden o desconocidos. Cada renglón se aplica por su placeholderId, nunca por posición; los desconocidos quedan en el recibo del archivo como rechazados y no se tocan otros productos.

5. APIs

Las que construye esta épica (2)

null

{
  "success": true,
  "data": {
    "items": [
      {
        "productId": "PRD-0004812",
        "rejectedAt": "2026-10-18T15:04:07Z",
        "rejectedBy": {
          "area": "COMPRAS-HOGAR",
          "role": "COMPRAS"
        },
        "target": "PROVEEDOR",
        "reason": {
          "code": "DATOS_INCOMPLETOS",
          "comment": "Faltan medidas del empaque"
        },
        "fields": [
          {
            "attribute": "ALTO_EMPAQUE",
            "label": "Alto del empaque",
            "code": "REQUIRED",
            "comment": "Captura el alto en centímetros"
          }
        ],
        "correctionDueAt": "2026-12-17T15:04:05Z"
      }
    ]
  }
}

{
  "fileId": "o9-resp-20261018-01",
  "records": [
    {
      "placeholderId": "PRD-0007710",
      "status": "ACCEPTED"
    },
    {
      "placeholderId": "PRD-0007711",
      "status": "NOT_RECOMMENDED"
    }
  ]
}

{
  "success": true,
  "data": {
    "fileId": "o9-resp-20261018-01",
    "applied": 2,
    "rejected": 0,
    "items": [
      {
        "placeholderId": "PRD-0007710",
        "result": "APPLIED",
        "nowStatus": "BORRADOR"
      },
      {
        "placeholderId": "PRD-0007711",
        "result": "APPLIED",
        "nowStatus": "PLACEHOLDER_NO_RECOMENDADO"
      }
    ]
  }
}

Las que usa y construye otra épica (9)

Su request y su response están en la página de la épica que la construye.

6. Eventos

Publica

Consume

7. Datos

Cada colección tiene un solo dueño, el único que escribe en ella.

8. Historias que cubre

9. Decisiones de esta épica

Las tomó el TL como arquitecto; quedan como [Propuesta] hasta que el equipo de la épica las revise.

• D-PRD-04-1. La propuesta vive en el PIM (colección products de MS-02) desde que se guarda; el portal de catalogación sólo la muestra y la edita por la API v2. Por qué: Un solo sistema y un solo dueño del dato: si la propuesta se quedara en Entrada Única habría dos copias que reconciliar y dos máquinas de estados. Se apoya en ADR-12, PD-06.
• D-PRD-04-2. Plazo de corrección de 60 días por omisión, configurable por negocio en el motor (workflow/config tipo DEADLINES), con recordatorio semanal. Al vencer, se cancela sola y libera sus EAN. Por qué: Hoy ningún sistema cancela solo y las propuestas muertas se acumulan; 60 días es el arranque que propone backend compartido y deja margen al proveedor. El valor final lo ratifica el negocio. Se apoya en PEN-211, DUD-24.
• D-PRD-04-3. La revisión de Compras no cancela nunca: recuerda a los 15 días y a los 30 pasa la tarea a la cola de Gobierno de Producto para reasignarla. Por qué: Cancelar por inacción de Liverpool castigaría al proveedor; escalar hace visible el atraso sin perder la propuesta. Se apoya en DEC-24.
• D-PRD-04-4. Todos los plazos los vigila un solo reloj en MS-02 que revisa las tareas abiertas y su vencimiento; los avisos los manda MS-14 por pantalla y correo. Por qué: Un solo lugar para plazos evita crons sueltos por sistema, como hoy en Entrada Única y P360. Se apoya en PEN-12, PD-29.
• D-PRD-04-5. Al cancelar, los EAN se liberan en la misma transacción que el cambio de estado (identifier_registry es de MS-02). Por qué: Si la liberación fuera por evento, un fallo dejaría EAN bloqueados sin propuesta viva. Se apoya en ADR-12.
• D-PRD-04-6. Un borrador vence a los 90 días sin actividad y el de pre-compra a los 300, con aviso 7 días antes; la depuración la hace FT-PRD-06. Por qué: Concilia la depuración de 30 días de hoy con la pre-compra de unos 9 meses que pidió el taller. Se apoya en RF-ALT-08.

Qué falta decidir

También siguen abiertos: PEN-211, Ratificar con el negocio el plazo de corrección por negocio (aquí arranca en 60 días); PEN-12, Confirmar el canal y la frecuencia de los avisos al proveedor.

Fuentes

1. [D] trazabilidad/features/FT-PRD-04-ciclo-de-vida-propuesta-proveedor.md: la ficha de la épica, con sus historias, reglas y bloqueos.
2. [D] ADR-12 · Un solo sistema: backend compartido y una sola base (sección 3.4).
3. [D] docs/arquitectura/por-epica/base/: piezas, colecciones, eventos y el hilo de punta a punta.
4. [D] docs/arquitectura/omega-a-pim-headless/contratos-api.md: convenciones y endpoints de partida.
5. [D] docs/arquitectura/maquina-de-estados-to-be/propuesta-maquina-de-estados.md §7: estados, tareas y canales.
6. [I] Las decisiones de la sección 9 son del TL sobre esas fuentes.