FT-INT-05 · Multioferta y stock out

En 30 segundos

Si un seller de Marketplace da de alta algo que ya existe, no se vuelve a catalogar: oferta sobre el SKU existente y sólo captura precio e inventario en el portal de ofertas (Mirakl). Esta épica revisa que ese SKU exista con sus datos base y que ya esté en el portal de ofertas (si no, lo manda), cierra la propuesta como oferta y avisa al portal y al seller. Lo mismo vale para el stock out sobre un producto de Liverpool.

• Módulo dueño: MS-02 Producto. También participan: MS-06 Evaluación, MS-08 Adaptadores de salida, MS-14 Avisos y ayuda.
• Etapa 1 · ¿Ya existe?. Recibe «PE-1 · Propuesta en Borrador» y entrega «PE-9 · Publicado por canal».
• APIs: construye 1 y usa 6 que construyen otras épicas.
• Eventos: publica 4 y consume 4.

1. Dónde encaja

Recibe

Entrega

Cambios de estado que hace

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 Existe catalogado pero no está en el portal de ofertas

3.2 Stock out sobre un producto de Liverpool

3.3 El producto existente todavía no tiene SKU

4. Si algo sale mal

• La coincidencia es con un producto de Suburbia. No se oferta ni se recataloga, porque Marketplace no vende en Suburbia: la propuesta queda en revisión manual de Marketplace y el seller lo ve en su propuesta.
• El portal de ofertas rechaza el documento o no contesta. El canal Marketplace queda en Error con la respuesta; el seller sigue viendo «existe catalogado, en sincronización» y la oferta no se habilita. Operación republica sólo ese canal (FT-CAT-05); nadie lo reenvía a mano desde Entrada Única.
• El SKU existe pero le faltan título o marca. La oferta no se habilita y se abre Gobierno de Datos sobre el producto existente; el seller ve que su oferta está en espera.
• El seller abandona sin elegir. La propuesta sigue en Borrador y vence como cualquier borrador (FT-PRD-04); nunca crea SKU.
• La marca está en la lista negra. No llega aquí: MS-06 la bloquea antes (FT-REF-02) y el seller ve el motivo.

5. APIs

Las que construye esta épica (1)

null

{
  "success": true,
  "data": {
    "sku": "1000007301",
    "productId": "PRD-0007301",
    "business": "MKP",
    "decision": "MULTI_OFFER",
    "title": "Audífonos inalámbricos con cancelación de ruido",
    "brand": "MARCA01",
    "offerable": true,
    "marketplace": {
      "state": "PUBLICADO",
      "document": "MKT",
      "lastAckAt": "2026-10-17T22:10:00Z"
    },
    "nextStep": "CREAR_OFERTA_EN_MARKETPLACE"
  }
}

Las que usa y construye otra épica (6)

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-05-1. La oferta nace y vive en el portal de ofertas; el PIM no guarda precio ni inventario. El PIM garantiza que el SKU existe con sus datos base y que ya está en el portal, y avisa al portal y al seller. Por qué: Orquestar ofertas en el PIM sería construir lo que el portal ya hace; precio e inventario viven en la oferta. Se apoya en PEN-23, DEC-38, RN-ALT-13.
• D-INT-05-2. OFFER_CREATED quiere decir «el seller quedó ligado a un SKU sobre el que ya puede ofertar». Sale sólo cuando el SKU tiene título y marca y su canal Marketplace está Publicado; antes, el seller ve «existe catalogado, en sincronización». Por qué: La oferta sólo existe si el SKU existe, y redirigir a un SKU que el portal no tiene es el error de hoy. Se apoya en RN-ALT-13, RN-INT-05.
• D-INT-05-3. La propuesta que se vuelve oferta pasa a Cancelado con el motivo «Convertida en oferta» y queda ligada al SKU (T11): no crea SKU, no se enriquece y no reserva sus EAN. Se convierte con una acción del motor (CONVERT_TO_OFFER en API-02-028). Por qué: Con coincidencia no se crea SKU ni se enriquece; el registro se conserva para que el seller y el reporte sepan qué pasó. Se apoya en RN-MAT-18, RN-MAT-13.
• D-INT-05-4. «Existe catalogado»: si el canal Marketplace del producto no está Publicado, MS-02 pide publicarlo sólo en ese canal y avisa al seller cuando llega el acuse. Por qué: Hoy Operación reenvía a mano desde Entrada Única los SKU que no llegan; así se reenvía solo y con estado. Se apoya en RN-INT-05, PEN-24.
• D-INT-05-5. Un solo canal (MARKETPLACE) con dos documentos: MKT para productos de Marketplace al destino de Marketplace y LVP para el stock out de Liverpool al destino de Stock Out. Suburbia nunca va al portal de ofertas. Por qué: Es lo que hace el código de hoy y deja un solo estado por canal. Se apoya en RN-MAT-15, PEN-133.
• D-INT-05-6. Datos base para ofertar: SKU, título y marca; para mandar el documento, además, el grupo de artículo y la imagen principal que pide el portal. Por qué: Nadie oferta sobre un producto incompleto; la lista completa queda por confirmar con Marketplace. Se apoya en RN-ALT-13.
• D-INT-05-7. La misma regla sirve al portal y a la API: el gateway responde «ya existe» con el SKU (API-GW-003) leyendo lo mismo que API-02-404. Por qué: Un solo lugar para la regla, sin importar por dónde llegó el seller. Se apoya en PD-02, PEN-23.

Qué falta decidir

También siguen abiertos: PEN-23, Mecanismo y destino de la redirección: aquí, el portal de ofertas y el PIM sólo avisa. Lo valida Marketplace con Arquitectura en ADR-02; PEN-24, Llevar a cero los SKU que no llegan al portal de ofertas antes de automatizar.

Fuentes

1. [D] trazabilidad/features/FT-INT-05-multioferta-stock-out-mirakl.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.