FT-INT-06 · Avisos de cambios a Entrada Única y consumidores

En 30 segundos

Mientras sigan vivos los backends de Entrada Única y de Foro, tienen que enterarse de cada cambio de estatus, del SKU y el EAN que da SAP, de los precios y de los looks, con los mismos mensajes que hoy les manda P360. Esta épica hace que el PIM publique esos avisos temporales (tópicos idmc_*) desde su outbox y los apague con tráfico cero en R3. Las pantallas nuevas no los usan: leen el estado por el BFF.

• Módulo dueño: MS-02 Producto. También participan: MS-07 Ingesta de archivos.
• Etapa 8 · Publicación. Recibe de otras épicas y entrega a otras épicas.
• APIs: construye 4 y usa 5 que construyen otras épicas.
• Eventos: publica 7 y consume 4.

1. Dónde encaja

Recibe

Entrega

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 SAP crea el artículo: SKU y EAN a Entrada Única

3.2 Precio, costo y EAN que cambia SAP

3.3 Conjunto Look creado en SAP

4. Si algo sale mal

• Entrada Única o Foro muestran un estatus viejo. Gobierno de Datos reemite el aviso de esos productos sin tocarlos (API-02-405); los backends ignoran lo repetido por eventId y versión.
• el bus de eventos no confirma un lote. El outbox lo reintenta con el mismo messageId, en lotes de hasta 100 como hoy; nada se pierde porque el aviso se escribió en la misma transacción que el cambio.
• Quedan dos emisores a la vez (P360 y el PIM). No debe pasar: el interruptor por tópico enciende el del PIM en la misma ventana en que se apaga el de P360 (FT-MIG-04). Si la medición encuentra avisos duplicados, se apaga el del PIM y se repite la ventana.
• Un estado no tiene renglón en la tabla de estatus de hoy. El aviso sale con la etiqueta «Borrador», como hoy, porque el listener de Entrada Única la espera; el caso queda en el reporte de la tabla para completarla y nunca se inventa un código.
• Un tópico ya no tiene consumidores. Con tráfico cero medido en su suscripción, se apaga su interruptor y el tópico se borra en R3, junto con API-02-405.

5. APIs

Las que construye esta épica (4)

{
  "fileId": "ECC-E14-20261018-160000-01",
  "looks": [
    {
      "recordKey": "ECC-E14-20261018-160000-01#1",
      "lookId": "700000004812",
      "name": "LOOK COCINA ROJA",
      "mainSku": "1000004812",
      "skus": [
        "1000004812",
        "1000004820",
        "1000004831"
      ]
    }
  ]
}

{
  "success": true,
  "data": {
    "fileId": "ECC-E14-20261018-160000-01",
    "applied": 1,
    "rejected": 0,
    "items": [
      {
        "recordKey": "ECC-E14-20261018-160000-01#1",
        "result": "CREATED",
        "lookId": "700000004812",
        "productId": "PRD-0009120",
        "type": "LOOK",
        "members": 3,
        "unknownSkus": []
      }
    ]
  }
}

{
  "fileId": "ECC142-20261019-013000-STCTS",
  "kind": "STCTS",
  "records": [
    {
      "recordKey": "ECC142-20261019-013000-STCTS#1",
      "sku": "1000004812",
      "value": 820.0
    },
    {
      "recordKey": "ECC142-20261019-013000-STCTS#2",
      "sku": "1000004899",
      "value": 455.5
    }
  ]
}

{
  "success": true,
  "data": {
    "fileId": "ECC142-20261019-013000-STCTS",
    "kind": "STCTS",
    "applied": 1,
    "rejected": 1,
    "items": [
      {
        "recordKey": "ECC142-20261019-013000-STCTS#1",
        "result": "APPLIED",
        "sku": "1000004812",
        "productId": "PRD-0004812",
        "variantId": "VAR-0004812-01",
        "field": "CostobrutoSinIVA"
      },
      {
        "recordKey": "ECC142-20261019-013000-STCTS#2",
        "result": "REJECTED",
        "sku": "1000004899",
        "reason": "SKU_NOT_FOUND"
      }
    ]
  }
}

{
  "fileId": "EAN_delta-20261018-160010",
  "kind": "DELTA",
  "records": [
    {
      "recordKey": "EAN_delta-20261018-160010#1",
      "sku": "1000004812",
      "ean": "7501234567916",
      "business": "MER",
      "itemGroup": "GA-0412",
      "action": "ADD"
    },
    {
      "recordKey": "EAN_delta-20261018-160010#2",
      "sku": "1000004813",
      "ean": "7501234567923",
      "business": "MER",
      "itemGroup": "GA-0412",
      "action": "REMOVE"
    }
  ]
}

{
  "success": true,
  "data": {
    "fileId": "EAN_delta-20261018-160010",
    "applied": 1,
    "ignored": 1,
    "rejected": 0,
    "items": [
      {
        "recordKey": "EAN_delta-20261018-160010#1",
        "result": "APPLIED",
        "productId": "PRD-0004812",
        "variantId": "VAR-0004812-01"
      },
      {
        "recordKey": "EAN_delta-20261018-160010#2",
        "result": "IGNORED",
        "reason": "La variante ya no tiene ese EAN"
      }
    ]
  }
}

{
  "topic": "idmc_put_products",
  "productIds": [
    "PRD-0004812",
    "PRD-0004813"
  ],
  "reason": "Entrada Única muestra un estatus viejo"
}

{
  "success": true,
  "data": {
    "requestId": "req-idmc-0412",
    "status": "ACCEPTED",
    "receiptUrl": "/api/v2/product-receipts/req-idmc-0412",
    "products": 2
  }
}

Las que usa y construye otra épica (5)

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-INT-06-1. Los idmc_ son sólo para los backends viejos: existen mientras vivan los backends de Entrada Única y de Foro. Las pantallas nuevas leen el estado por el BFF desde MS-02 y no se construyen rutas /public/rt para ellas (ni GetProposals ni AutForoWrite). Con tráfico cero cada tópico se apaga y se borra en R3. Por qué:* ADR-12 adopta las decisiones 19 y 20 del backend compartido: un solo BFF y sin capa de compatibilidad para los fronts. Se apoya en ADR-12, PD-06, DUD-06.
• D-INT-06-2. Un solo emisor por tópico: el del PIM se enciende con un interruptor por tópico en la tabla SWITCHES del motor, en la misma ventana en que se apaga el de P360, en el corte de productos (FT-MIG-04); antes del corte, P360 sigue publicando. Por qué: Dos emisores duplican avisos y uno apagado deja a Entrada Única en silencio sin error visible. Se apoya en PD-06, PD-11, DEC-ARQ-10.
• D-INT-06-3. El aviso de hoy se escribe en el outbox de MS-02 en la misma transacción del cambio, como una proyección del evento nuevo; no hay un servicio aparte ni una tarea programada. Si el interruptor está apagado, no se escribe. Por qué: Así ningún cambio confirmado queda sin aviso y no se mantiene otra pieza para algo temporal. Se apoya en ADR-12, DMS-67.
• D-INT-06-4. La etiqueta sale de SUPPLIER_LABELS (FT-RAC-05) y el código de hoy de P360_CODES (FT-FLU-01), las mismas tablas versionadas de MS-02 que usan el portal, MS-03 y los reportes: estado, tarea abierta y origen dan etiqueta y código, con el orden de §7.5 de la máquina de estados. El aviso no calcula nada por su cuenta. Por qué: Un solo lugar para traducir el modelo nuevo al de hoy, para que Entrada Única diga lo mismo que el portal; Entrada Única lee etiquetas, no códigos. Se apoya en PD-29, PD-06.
• D-INT-06-5. El aviso del 122 conserva la regla de hoy por negocio de SAP: SFERA 1021; REGULAR, MARCAS PROPIAS y SERVICIOS 1002; DUTY FREE y otros 1001, con estatus previo «SKU Creation» y las variantes con SKU y MainBarCode. ECC y S4H mandan el mismo cuerpo: se corrige el defecto de S4H (sin variantes y con previo 1020), probado antes contra el listener de Entrada Única en QA. Por qué: Paridad en lo que Entrada Única espera y una sola lógica para los dos SAP, como pide FT-PRD-02. Se apoya en PD-06, DEC-ARQ-12, RN-ALT-12.
• D-INT-06-6. Por suscripción: el PIM emite los 3 tópicos de producto que hoy tienen emisor en el código (idmc_post_products, idmc_put_products e idmc_post_look; los 2 de catálogo los emite MS-01). Los 12 que tienen suscripción en Entrada Única pero ningún emisor en el código no se emiten, después de confirmar tráfico cero. Los que sólo salen de scripts temporales se retiran. Por qué: Cada una de las 19 suscripciones de Entrada Única y la de Foro queda con decisión antes del corte, sin construir emisores que nadie usa. Se apoya en DUD-06, PD-06.
• D-INT-06-7. El campo owner del aviso se calcula con la regla de hoy (ID de 15 caracteres o más, o proveedor migrado: P360; si no, STEP) sólo para el aviso. No se agrega un valor nuevo para no romper el listener; se retira con el tópico. Por qué: Para Entrada Única «P360» significa «el sistema dueño», que ahora es el PIM; cambiar el valor obliga a cambiar un backend que se va a apagar. Se apoya en DUD-11.
• D-INT-06-8. El Conjunto Look que crea SAP se guarda como producto de tipo LOOK con referencias a sus productos y se avisa con idmc_post_look; el PIM es su fuente de verdad desde el corte. Por qué: Es la propuesta vigente para PD-15: el look no es un árbol, es un producto con referencias. Se apoya en PD-15.
• D-INT-06-9. Para corregir desfases, Gobierno de Datos reemite el aviso de una lista de productos sin tocarlos (API-02-405), con recibo; el comando se borra con los tópicos. Por qué: Hoy hubo que republicar a mano estatus desfasados; sin un comando, el riesgo de que Entrada Única deje de enterarse no tiene remedio. Se apoya en RSG-26.

Qué falta decidir

Fuentes

1. [D] trazabilidad/features/FT-INT-06-avisos-idmc-entrada-unica.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.