FT-FLU-02 · Alta individual de Marketplace

En 30 segundos

Es la columna vertebral del alta de un seller de Marketplace en el portal: fija el orden de los pasos y a dónde va el producto en cada uno. Primero se revisa si la marca está vetada o si el producto ya existe; si ya existe, el seller va directo a ofertar sin catalogar. Si es nuevo, se elige o se sugiere la plantilla, la IA prellena, el seller completa lo mínimo y envía, sin que un score bajo cuente como rechazo.

• Módulo dueño: MS-02 Producto. También participan: MS-06 Evaluación, MS-15 IA y enriquecimiento, MS-01 Catálogo.
• Etapa 1 · ¿Ya existe?. Recibe «PE-1 · Propuesta en Borrador», «PE-C · Catálogo vigente» y entrega «PE-2 · Sin duplicado», «PE-4 · Propuesta enviada».
• APIs: construye 1 y usa 16 que construyen otras épicas.
• Eventos: publica 3 y consume 1.

1. Dónde encaja

Recibe

Entrega

Cambios de estado que hace

Tareas que abre o cierra: Validación automática, Calificación de IA.

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 Ya existe: directo a la oferta

3.2 Camino por características: elige la plantilla

3.3 No alcanza el mínimo: sigue en captura sin rechazo

4. Si algo sale mal

• La marca está en la lista negra de Marketplace. La identificación lo dice antes de crear nada: el seller ve la explicación y el alta termina sin propuesta; no llega a la plantilla.
• Al enviar, la Validación automática encuentra que el producto ya existe. Si otro seller lo catalogó entretanto, la propuesta se cierra como convertida en oferta (FT-INT-05) y el seller pasa a ofertar sobre el SKU existente; no se crea SKU ni se enriquece.
• La IA no sugiere ninguna plantilla con confianza suficiente. El seller elige en el árbol, como en el camino por características; si ninguna sirve, lo atiende Gobierno de Producto y el alta espera.
• No cumple lo mínimo de Marketplace. El plan de envío lo bloquea y dice qué falta por sección; la propuesta sigue en Borrador sin rechazo ni plazo de corrección.
• MS-06 no responde, o la evaluación por imagen o URL tarda. La identificación responde 503 y el alta no avanza; si la evaluación por imagen o URL tarda, MS-02 sigue cuando llega EVALUATION_DONE y la pantalla muestra «identificando».

5. APIs

Las que construye esta épica (1)

{
  "business": "MKP",
  "path": "CHARACTERISTICS",
  "brandCode": "MARCA01",
  "model": "PB-20",
  "eans": [
    "7501234567930"
  ],
  "imageAssetId": null,
  "sourceUrl": null,
  "supplierShopId": "SELLER-0001"
}

{
  "success": true,
  "data": {
    "evaluationId": "evl-5d21c8",
    "expiresAt": "2026-10-19T16:20:00Z",
    "outcome": "NEW",
    "allowedAction": "CREATE_PROPOSAL",
    "brand": {
      "code": "MARCA01",
      "blocked": false
    },
    "matches": [],
    "skuCatalog": "MARKETPLACE",
    "nextStep": "CHOOSE_TEMPLATE",
    "message": "Producto nuevo: elige o confirma su plantilla"
  }
}

Las que usa y construye otra épica (16)

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-FLU-02-1. La ruta de Marketplace (identificar, plantilla, prellenado, captura, imágenes y envío) es configuración del motor de MS-02, no código de pantalla: el portal pregunta en qué paso va la propuesta y qué puede hacer, y el BFF sólo compone. Por qué: Un flujo común con reglas por negocio (RN-GEN-02): el mismo producto puede llegar por archivo o API y seguir la misma ruta sin repetir lógica. Se apoya en RN-GEN-02, PD-29, ADR-12.
• D-FLU-02-2. La identificación va antes de crear (API-02-202): MS-02 pide la evaluación a MS-06 y devuelve la acción, el siguiente paso y un evaluationId que vale 24 horas. Si es producto nuevo, la propuesta nace en Borrador con esa evaluación y la plantilla confirmada (API-02-005); si ya existe o la marca está vetada, no nace nada. Por qué: Es la identificación previa que usa Evaluación (FT-REF-02, FT-FLU-03): el seller sabe al principio si debe catalogar u ofertar y no quedan propuestas muertas; la propuesta llega a PE-1 con lo de PE-2 ya guardado. Se apoya en RF-MAT-14, RF-MAT-15, DEC-62, ADR-12.
• D-FLU-02-3. Ruteo por camino: con imagen o URL, MS-15 sugiere de una a tres plantillas («¿es tu plantilla?») y prellena; con características, el seller elige en el árbol; si la coincidencia trajo datos aprovechables, se ofrecen como prellenado para validar. Por qué: Es la regla acordada (RF-ENR-03, DEC-51); lo prellenado queda con origen IA hasta que el seller lo confirma. Se apoya en RF-ENR-03, DEC-51, RN-ENR-13.
• D-FLU-02-4. «No avanza, pero no se rechaza»: lo mínimo para el SKU (obligatorios, plantilla, marca y coincidencia) se revisa en el plan de envío; si falta algo, la propuesta sigue en Borrador sin rechazo ni plazo. La Calificación de IA en En revisión sólo revisa lo que el SKU necesita; el score de calidad decide la publicación por rangos (FT-RAC-03). Por qué: Resuelve PD-24 como las propuestas del 16 y del 17-oct: cumple «dos carreteras» y la regla de que un score bajo no es rechazo (RN-CAL-06). Se apoya en PD-24, RN-CAL-06, RN-CAL-07.
• D-FLU-02-5. Si ya existe, el alta termina sin SKU ni enriquecimiento y entrega el SKU existente a «detalle oferta» (FT-INT-05). El PIM no crea la oferta: el seller la crea en Mirakl. Por qué: Con coincidencia no se crea SKU ni se enriquece (RF-MAT-15); producto y oferta van separados (PEN-23). Se apoya en RF-MAT-15, PEN-23, RN-MAT-18.
• D-FLU-02-6. Un producto nuevo que no existe en Liverpool nace como genérico de Marketplace y su SKU será de Marketplace; la oferta se habilita sólo con SKU y la publicación sigue los rangos de score de FT-RAC-03. Por qué: Es la «cuarta línea» acordada (RF-MAT-14, RN-MAT-19); lo de H5 queda en las épicas dueñas. Se apoya en RF-MAT-14, RN-MAT-19.

Qué falta decidir

También siguen abiertos: PEN-60, Definir el alcance de la tarea de Gobierno de Datos después del SKU.

Fuentes

1. [D] trazabilidad/features/FT-FLU-02-orquestacion-alta-individual-marketplace.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.