FT-PLT-04 · Grupos de atributos y mínimos de información por sistema…

En 30 segundos

Cada sistema que recibe productos (SAP, la tienda, OMS, Marketplace, Señalización, el almacén de datos) necesita un juego distinto de atributos, y hoy esas listas viven escondidas en código y en siete tipos de «grupo» que no se hablan. Esta épica junta los atributos en grupos con tipo: por destino, por sección, por permiso o para la etapa de placeholder. Así se sabe qué viaja a cada sistema, cuál es su mínimo y qué negocios lo exigen, sin listas fijas en ningún adaptador.

• Módulo dueño: MS-01 Catálogo. También participan: MS-08 Adaptadores de salida.
• Etapa C · Configura el catálogo. Recibe «PE-T · Usuario con permisos y bitácora» y entrega «PE-C · Catálogo vigente».
• APIs: construye 4 y usa 3 que construyen otras épicas.
• Eventos: publica 3 y consume 3.

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 Matriz de mínimos de una plantilla

3.2 Grupo con comportamiento heredado

3.3 Campos de la etapa placeholder

4. Si algo sale mal

• Un destino exige un atributo que un negocio tiene opcional. La matriz lo marca como hueco; el atributo no frena el envío de la propuesta, pero la vista lo marca requerido para publicar en ese canal y la compuerta de publicación de MS-02 lo cobra.
• Se agrega a un grupo un atributo inactivo o que no existe. El plan responde 422 VALIDATION_ERROR y no se abre ninguna solicitud.
• Dos grupos de un atributo se contradicen (uno lo manda a Marketplace y otro lo excluye). Gana la exclusión explícita y el plan lo dice antes de confirmar; nada viaja por accidente.
• El adaptador no alcanzó a leer la salida nueva. MS-08 aplica los avisos en orden por versión y, al arrancar, relee la salida de cada destino; nunca usa una lista propia.

5. APIs

Las que construye esta épica (4)

null

{
  "success": true,
  "data": {
    "items": [
      {
        "groupId": "DESTINO:OMS",
        "type": "DESTINO",
        "name": {
          "es": "Lo que viaja a OMS"
        },
        "exportTo": [
          "OMS"
        ],
        "memberCount": 3,
        "minimumCount": 2,
        "order": 4,
        "parentGroupId": null,
        "status": "ACTIVE",
        "version": 5
      }
    ],
    "page": 1,
    "size": 50,
    "total": 1
  }
}

{
  "operation": "ADD_MEMBERS",
  "groupId": "DESTINO:OMS",
  "version": 5,
  "members": [
    {
      "attributeId": "ATR-0000002",
      "minimum": true
    },
    {
      "attributeId": "ATR-0000006",
      "minimum": true
    },
    {
      "attributeId": "ATR-0000008",
      "minimum": false
    }
  ]
}

{
  "success": true,
  "data": {
    "planId": "pln-9e2b40",
    "expiresAt": "2027-01-13T15:10:00Z",
    "requiresApproval": true,
    "items": [
      {
        "attributeId": "ATR-0000002",
        "outputs": {
          "before": [
            "TIENDA"
          ],
          "after": [
            "TIENDA",
            "OMS"
          ]
        },
        "minimumFor": {
          "after": [
            "OMS"
          ]
        }
      },
      {
        "attributeId": "ATR-0000006",
        "outputs": {
          "before": [
            "SAP"
          ],
          "after": [
            "SAP",
            "OMS"
          ]
        },
        "minimumFor": {
          "after": [
            "OMS"
          ]
        }
      },
      {
        "attributeId": "ATR-0000008",
        "outputs": {
          "before": [],
          "after": [
            "OMS"
          ]
        },
        "minimumFor": {
          "after": []
        }
      }
    ],
    "impact": {
      "views": 0,
      "destinations": [
        "OMS"
      ]
    },
    "applyUrl": "/api/v2/catalog-plans/pln-9e2b40/apply"
  }
}

null

{
  "success": true,
  "data": {
    "destination": "OMS",
    "version": 12,
    "computedAt": "2027-01-13T15:20:02Z",
    "attributes": [
      {
        "attributeId": "ATR-0000002",
        "minimum": true,
        "because": "GRUPO DESTINO:OMS"
      },
      {
        "attributeId": "ATR-0000006",
        "minimum": true,
        "because": "GRUPO DESTINO:OMS"
      },
      {
        "attributeId": "ATR-0000008",
        "minimum": false,
        "because": "GRUPO DESTINO:OMS"
      }
    ],
    "excluded": []
  }
}

null

{
  "success": true,
  "data": {
    "templateId": "EU4-0412",
    "rows": [
      {
        "attributeId": "NOMBRE_COMERCIAL",
        "byBusiness": {
          "MER": "REQUIRED",
          "SUB": "REQUIRED",
          "MKP": "REQUIRED"
        },
        "requiredByDestination": [
          "TIENDA",
          "MARKETPLACE"
        ]
      },
      {
        "attributeId": "ATR-0000006",
        "byBusiness": {
          "MER": "REQUIRED",
          "SUB": "REQUIRED",
          "MKP": "OPTIONAL"
        },
        "requiredByDestination": [
          "OMS"
        ]
      }
    ],
    "gaps": [
      {
        "attributeId": "ATR-0000006",
        "business": "MKP",
        "issue": "OMS lo exige y Marketplace lo tiene opcional"
      }
    ]
  }
}

Las que usa y construye otra épica (3)

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-PLT-04-1. Un solo modelo de grupo con tipo. Los siete mecanismos de hoy migran como tipos (sección del portal, despliegue, categoría de característica, permiso, ATG, SAP y relevancia) con su orden de P360, y los de la ERF entran como tipos nuevos: destino y placeholder. No se consolidan al corte. Por qué: Cada mecanismo tiene consumidores distintos; consolidarlos en el corte rompería la ficha de la tienda y la captura. La forma del dato no cambia si después se consolidan. Se apoya en PD-14, DUD-16.
• D-PLT-04-2. La salida por destino es una sola cuenta: un atributo viaja a un destino si su relevancia lo dice o si pertenece a un grupo de ese destino, salvo una exclusión explícita, que siempre gana. El mínimo de atributos de cada destino es la marca «mínimo» en su grupo. MS-08, MS-10 y MS-02 la leen de API-01-105 y no guardan listas propias. Por qué: Que ningún sistema destino dependa de una lista escrita en código y que cambiar qué viaja sea una solicitud aprobada, no un despliegue. Se apoya en RF-PLA-07, RF-PLA-01, DEC-04.
• D-PLT-04-3. El mínimo para publicar en cada canal lo decide publication_rules de MS-02 y sólo cita el grupo de MS-01 para la parte de atributos. Precio, categoría web, imagen principal y el orden entre canales (OMS antes que la tienda) son condiciones de MS-02, no grupos de atributos. Por qué: Un dueño por dato: MS-01 sabe de atributos y MS-02 de lo que tiene cada producto. Así el mínimo web «precio, nombre, categoría e imagen» se arma sin copiar ninguna lista. Se apoya en RN-PUB-05, ADR-12.
• D-PLT-04-4. Quién ve o edita un grupo de tipo permiso lo decide sólo la matriz de MS-13 (rol por grupo de atributos); MS-01 dice qué atributos van juntos. Los campos de roles que traía el modelo de datos en el grupo no se usan. Por qué: Los permisos tienen un dueño, el directorio, y la identidad dejó MS-01 (ADR-12 sobre DMS-71). Se apoya en DUD-22, DEC-PLT-09, ADR-12.
• D-PLT-04-5. Los mínimos por destino alimentan la vista efectiva: el mínimo de SAP es la capa 1 (datos maestros) en los tres negocios y frena el envío de la propuesta; el mínimo de cada canal no frena el envío: la vista lo marca requerido para publicar en ese canal. Por qué: Dos carreteras: antes del SKU frena lo indispensable para crear el artículo, y la calidad del contenido frena sólo la publicación por canal. Se apoya en PD-24, RF-PLA-05, RF-PLA-02.
• D-PLT-04-6. El grupo de placeholder dice qué atributos valen en esa etapa y viajan en el archivo de placeholders a o9. PLM no tiene contrato ni pieza en el sistema y queda fuera hasta que se defina; cuando llegue, usará el mismo grupo. Por qué: La etapa de placeholder ya existe con o9 (FT-PRD-04); no se inventa un contrato con PLM que nadie ha descrito. Se apoya en RF-PLA-19.

Qué falta decidir

También siguen abiertos: PEN-75, Los equipos de negocio entregan la lista real de obligatorios funcionales por negocio; PEN-76, El equipo del proyecto entrega el mínimo técnico de cada sistema destino; PEN-87, SAP confirma la lista completa de datos maestros que pide para crear el artículo (capa 1); PEN-02, Confirmar si se mantienen mínimos propios por sistema o un modelo único; aquí se propone mínimos por destino derivados de un solo catálogo.

Fuentes

1. [D] trazabilidad/features/FT-PLT-04-grupos-de-atributos-y-minimos.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.