FT-FLU-03 · Decisión por negocio ante coincidencia

En 30 segundos

Si el producto del seller ya existe no se vuelve a catalogar, y lo que toca depende del negocio donde existe, de la marca y del tipo de artículo. Esta épica es la tabla de decisión de Evaluación: si existe en Marketplace, multioferta; si es de Liverpool y está permitido, stock out (ofertar sobre su SKU sin cambiar su contenido); si está vetado o es de Suburbia, no se puede. Cada caso lleva su mensaje, igual en pantalla, archivo y API.

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

1. Dónde encaja

Recibe

Entrega

Tareas que abre o cierra: Gobierno de Datos.

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 en Liverpool

3.2 Con permiso, descontinuado o Suburbia

3.3 Configurar la tabla de decisión

4. Si algo sale mal

• El producto existe pero todavía no está en el portal de ofertas. La decisión sigue siendo ofertar; FT-INT-05 lo manda al portal y el seller ve «existe catalogado, en sincronización» hasta que llega el acuse.
• Coincide sólo con un producto de Suburbia. Por ahora no se puede catalogar, con la explicación de que Marketplace sólo vende en Liverpool. Cada caso queda en la evaluación para medir cuántos son y decidir la regla de Suburbia sin tocar código.
• La marca pide permiso o el producto de Liverpool está descontinuado. Se abre una tarea de Gobierno de Datos y el seller ve «en revisión»; si la tarea vence, el motor la escala a su cola. La decisión de la persona queda en la evaluación.
• El seller cambia el EAN o la marca para que no coincida. MS-02 vuelve a pedir la evaluación en cada cambio y al enviar; con imagen o URL, la coincidencia visual también entra a la decisión.

5. APIs

Las que construye esta épica (1)

null

{
  "success": true,
  "data": {
    "evaluationId": "evl-0000740",
    "kind": "IDENTIFICATION",
    "status": "DONE",
    "subject": {
      "productId": "PRD-0004815",
      "version": 1,
      "business": "MKP",
      "origin": "PORTAL",
      "owner": {
        "type": "SELLER",
        "id": "SELLER-0002"
      }
    },
    "inputs": {
      "brandCode": "MARCA03",
      "model": "CG-25W",
      "ean": "7509876500018",
      "productType": "CARGADOR",
      "sources": [
        "SELLER"
      ]
    },
    "blacklist": {
      "blocked": false,
      "rulesVersion": 12
    },
    "candidates": [
      {
        "productId": "PRD-0002031",
        "business": "MKP",
        "sku": "1000002031",
        "productName": "Cargador de pared 25 W USB-C",
        "confidence": 0.78,
        "fields": [
          {
            "field": "EAN",
            "matched": false
          },
          {
            "field": "MARCA",
            "matched": true,
            "weight": 25
          },
          {
            "field": "MODELO",
            "matched": true,
            "weight": 25
          },
          {
            "field": "TIPO_PRODUCTO",
            "matched": true,
            "weight": 15
          },
          {
            "field": "COLOR",
            "matched": true,
            "weight": 10
          },
          {
            "field": "CONTENIDO",
            "matched": false,
            "weight": 5
          }
        ]
      }
    ],
    "decision": {
      "action": "REVIEW",
      "reasonCode": "MATCH_BETWEEN_BANDS",
      "message": "Encontramos un producto muy parecido; una persona lo revisa antes de seguir."
    },
    "bands": {
      "low": 0.7,
      "high": 0.9
    },
    "review": null,
    "thresholdsVersion": 4
  }
}

Las que usa y construye otra épica (11)

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-03-1. Una sola tabla de decisión por negocio, en validation_thresholds de MS-06, versionada y editable con plan (API-06-008): cada fila dice negocio de la coincidencia, regla de la marca, si es del mismo seller y estado del producto existente, y da la acción (CONTINUE, BLOCK, MULTI_OFFER, OWN_DUPLICATE, STOCK_OUT, DUPLICATE o REVIEW) con su mensaje. MS-02, la carga masiva y el gateway no copian la tabla: usan la respuesta. Por qué: Una regla, un dueño; cambia sin código y explica cada rama, que es lo que piden los talleres. Se apoya en RF-MAT-10, DEC-37, RN-MAT-07, FT-PRD-03.
• D-FLU-03-2. Orden: primero los vetos generales (FT-REF-02), luego la coincidencia (FT-REF-03) y al final la fila del negocio que coincide, con los vetos de ese negocio. Por qué: Es el orden vigente del taller: lista negra primero, negocio después, y un rombo por negocio. Se apoya en DEC-36, DEC-34, DEC-37.
• D-FLU-03-3. Arranque de las filas abiertas: coincidencia sólo con Suburbia, BLOCK con explicación; marca «con permiso», REVIEW con Gobierno de Datos; producto de Liverpool descontinuado, REVIEW. Cada una se cambia en la tabla cuando se decidan PEN-19, PEN-20 y PEN-131. Por qué: Marketplace sólo vende en Liverpool y los SKU de Suburbia no van al portal de ofertas, así que hoy no hay stock out sobre Suburbia; lo dudoso lo decide una persona hasta tener regla. Se apoya en PEN-19, PEN-20, PEN-131, RN-CAT-04.
• D-FLU-03-4. Con coincidencia nunca se crea SKU ni se enriquece. Si la propuesta ya existía, MS-02 la cierra como convertida en oferta (FT-INT-05). Si el producto es del mismo seller (OWN_DUPLICATE), se le manda a modificar el suyo. Por qué: El seller se cuelga del SKU existente; duplicar contenido es justo lo que se quiere evitar. Se apoya en DEC-38, DEC-39, RN-MAT-18.
• D-FLU-03-5. «Stock out» quiere decir ofertar sobre un SKU de Liverpool sin cambiar su contenido; no es un negocio ni un producto nuevo. La palabra se usa sólo así en mensajes y reportes, y el mensaje nunca dice qué otros sellers venden el producto. Por qué: Hoy la palabra tiene tres significados; fijarla evita que cada pantalla la use distinto. Se apoya en RN-MAT-15, PEN-132.

Qué falta decidir

También siguen abiertos: PEN-19, Regla de Suburbia: bloqueo, stock out o registro interno (Marketplace con el área comercial de Suburbia); PEN-20, Criterios de canibalización y quién autoriza el «con permiso»; PEN-131, Si se puede ofertar por stock out sobre artículos de Liverpool descontinuados; PEN-132, Ratificar la definición única de «stock out».

Fuentes

1. [D] trazabilidad/features/FT-FLU-03-decision-por-negocio-ante-coincidencia.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.