FT-FLU-07 · Excepciones de catalogación y preventas con publicación…

En 30 segundos

Algunos productos se crean en SAP pero no deben llegar a la tienda en línea: los de ciertas secciones, marcas o proveedores, por negocio. Esta épica conserva esas excepciones como una tabla que Gobierno de Producto administra, las evalúa en cascada al crearse el SKU y le avisa al estudio que no les tome foto. También deja marcar una preventa desde el alta para publicarla pronto con imagen genérica, sin avisos por correo.

• Módulo dueño: MS-02 Producto. También participan: MS-07 Ingesta de archivos, MS-11 Activos digitales, MS-12 Estudio fotográfico, MS-05 Auditoría.
• Etapa 4 · Visto bueno. Recibe «PE-5 · Visto bueno dado» y entrega «PE-6 · SKU asignado».
• APIs: construye 3 y usa 5 que construyen otras épicas.
• Eventos: publica 4 y consume 2.

1. Dónde encaja

Recibe

Entrega

Cambios de estado que hace

Tareas que abre o cierra: Foro: muestra, foto y enriquecimiento, Carga de imagen.

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 Gobierno de Producto mantiene las excepciones

3.2 Preventa marcada desde el alta y publicada pronto

4. Si algo sale mal

• Un SKU coincide con dos tipos de excepción. Gana el primero de la cascada (sección y negocio, luego sección y marca, sección y proveedor, grupo de artículo y SKU) y se guarda su código; el resultado es el mismo que da hoy P360.
• El SKU está en las excepciones anuladas. Se le quita la excepción (código 6) y sigue el camino normal: se abre la foto y, al aprobarse, sale a la tienda.
• Gobierno de Producto cambia una excepción que afecta SKU ya evaluados. La vista previa los cuenta. Los que siguen en Creación de SKU se reevalúan al confirmar; los ya aprobados se listan para retirarlos de la tienda con la baja por canal o abrirles un Repoblamiento (FT-PRD-05) si ahora sí deben venderse en línea.
• Termina la preventa y el producto sigue con imagen genérica. Siete días antes se avisa al proveedor y a E-commerce. Al terminar, la bandera se apaga y la tienda la recibe en la siguiente publicación; la imagen definitiva entra como un cambio a un producto aprobado (FT-PRD-05).
• Se pide una excepción por precio. El tipo existe pero no se puede dar de alta (422 BUSINESS_ERROR) hasta que se defina su criterio; nada se evalúa por precio mientras tanto.

5. APIs

Las que construye esta épica (3)

null

{
  "success": true,
  "data": {
    "items": [
      {
        "exceptionId": "exc-00153",
        "type": "SECTION_BRAND",
        "code": 2,
        "business": "SUB",
        "key": {
          "section": "S-118",
          "brand": "MARCA01"
        },
        "effect": "NO_ECOMMERCE",
        "active": true,
        "validFrom": "2026-11-01T06:00:00Z",
        "validTo": null,
        "version": 1,
        "changedAt": "2026-10-18T15:04:07Z",
        "changedBy": {
          "area": "GOBIERNO-PRODUCTO"
        },
        "legacy": "ExcepcionesPorSeccionYMarca"
      }
    ],
    "page": 1,
    "size": 50,
    "total": 1
  }
}

{
  "changes": [
    {
      "op": "ADD",
      "type": "SECTION_BRAND",
      "business": "SUB",
      "key": {
        "section": "S-118",
        "brand": "MARCA01"
      },
      "validFrom": "2026-11-01T06:00:00Z",
      "reason": "La marca sólo se vende en tienda física en Suburbia"
    },
    {
      "op": "CANCEL",
      "exceptionId": "exc-00087",
      "version": 2,
      "reason": "La sección ya se vende en línea"
    }
  ]
}

{
  "success": true,
  "data": {
    "planId": "pln-e5c021",
    "expiresAt": "2026-10-18T15:14:05Z",
    "summary": {
      "add": 1,
      "cancel": 1
    },
    "impact": {
      "skuStillInCreation": 12,
      "skuAlreadyApproved": 3,
      "approvedSample": [
        "1000004812",
        "1000004813",
        "1000005120"
      ]
    },
    "applyUrl": "/api/v2/product-plans/pln-e5c021/apply"
  }
}

{
  "skus": [
    "1000004812",
    "1000004813",
    "1000005120"
  ]
}

{
  "success": true,
  "data": {
    "items": [
      {
        "sku": "1000004812",
        "excepted": true,
        "type": "SECTION_BRAND",
        "code": 2,
        "business": "SUB",
        "reason": "El producto se encuentra bajo excepción de catalogación"
      },
      {
        "sku": "1000004813",
        "excepted": false,
        "code": 6,
        "reason": "Su excepción está anulada"
      },
      {
        "sku": "1000005120",
        "excepted": false
      }
    ]
  }
}

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-FLU-07-1. Las excepciones viven en catalog_exceptions de MS-02, no en los diccionarios de Catálogo: una tabla por tipo y por negocio con el mismo orden y códigos de hoy (1 a 5, y 6 para las anuladas), más precio, preventa y lanzamiento. Se leen en la misma base al evaluar, sin copias en caché. Por qué: Así lo decidió el diseño de plantillas para los diccionarios de excepciones y de flujo; leer sin caché evita el retraso de hoy, cuando un cambio no se ve hasta refrescar. Se apoya en DEC-PLT-08, RSG-52.
• D-FLU-07-2. Las excepciones se evalúan al salir de Creación de SKU (T06). Lo exceptuado conserva su estado real con una marca de excepción (no hay estado 1032), no abre Foro, Carga de imagen ni QA, y al aprobarse sale a OMS, Señalización y DWH, pero no a la tienda ni a Marketplace. Por qué: Es el mismo momento y el mismo efecto de P360 («no se publica al e-commerce»); el estado 1032 no lo asigna ningún código y en el modelo B la excepción es un dato, no un estado. Se apoya en PD-29, DUD-24.
• D-FLU-07-3. El estudio pregunta por lote a MS-02 (API-02-306) para marcar «NO TOMAR» en el producto y todas sus variantes; la regla vive en un solo lugar y MS-12 no copia las tablas. Por qué: Hoy el cálculo de tomar o no tomar lee seis diccionarios de excepción por su cuenta. Se apoya en ADR-12.
• D-FLU-07-4. Se separan dos sentidos: «excepción de catalogación» (no va a la tienda) y «vía rápida» (preventa o lanzamiento, se publica antes). La preventa la marca Compras con fechas en la propuesta: es la bandera de preventa del producto (valor, inicio y fin), deja cerrar la foto con una imagen genérica y sube la prioridad de sus tareas. No salta pasos. Por qué: Hoy las preventas se avisan por correo o chat aunque la bandera ya existe en P360; marcarla en el sistema la hace visible para Publicación y para la tienda. Se apoya en RN-PUB-04, PEN-09, PD-23.
• D-FLU-07-5. Un lanzamiento es prioridad, no otro camino: con una excepción de tipo lanzamiento, sus tareas van primero en cada cola, pero el motor no tiene una ruta distinta. Por qué: Un solo flujo con candados por negocio; un camino aparte sería otra máquina que mantener. Se apoya en P-38, RN-GEN-02.
• D-FLU-07-6. Los cuatro diccionarios que hoy no lee ningún código no se migran como reglas activas: entran como tablas inactivas hasta que Gobierno de Producto confirme si sirven. La excepción por precio se crea inactiva hasta definir su criterio. Por qué: Activar reglas que nadie aplica hoy cambiaría qué se publica sin que nadie lo haya pedido. Se apoya en DUD-34.

Qué falta decidir

También siguen abiertos: PEN-09, Quién marca exactamente la preventa en el alta: aquí la marca Compras y el proveedor sólo la propone.

Fuentes

1. [D] trazabilidad/features/FT-FLU-07-excepciones-catalogacion-preventas.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.