Actualizado el 18-oct-2026. Primera versión de la arquitectura de esta épica.
Qué responde. Cómo funciona por dentro FT-PLT-03: qué piezas participan, en qué orden hablan, qué APIs hay que construir con su request y su response, y qué le entrega a la épica siguiente.
Para quién. Los equipos que van a construir la épica, QA y arquitectura.
Estado. [Propuesta] del TL del Nuevo PIM, 18-oct-2026, construida sobre ADR-12. La spec de cada épica dice el qué; estas páginas, el cómo.
Fuente. docs/arquitectura/por-epica/epicas/FT-PLT-03.json, generada con generar.py; la ficha de la épica es trazabilidad/features/FT-PLT-03-listas-de-valores-y-modelo-canonico.md.
En 30 segundos
Muchos atributos se llenan eligiendo de una lista (colores, materiales, marcas). Esta épica gobierna esas listas: cada valor tiene un código único que es lo que guarda el producto, una etiqueta que se puede corregir sin tocar productos y la forma en que lo recibe cada sistema (la tienda, SAP, Marketplace). También resuelve qué pasa cuando el proveedor no encuentra su valor, cómo se retira un valor sin perder lo histórico y cómo se fusionan dos valores moviendo los productos.
- Módulo dueño: MS-01 Catálogo. También participan: MS-02 Producto, MS-07 Ingesta de archivos, MS-14 Avisos y ayuda.
- Etapa C · Configura el catálogo. Recibe «PE-T · Usuario con permisos y bitácora» y entrega «PE-C · Catálogo vigente».
- APIs: construye 9 y usa 10 que construyen otras épicas.
- Eventos: publica 2 y consume 4.
1. Dónde encaja
Recibe
| De | Qué |
|---|---|
| PE-T · Usuario con permisos y bitácora | El administrador de Gobierno de Producto o el proveedor ya identificados, con sus roles del directorio de MS-13. |
| FT-PLT-02 · Catálogo de atributos | Los atributos de tipo lista, cada uno con su lista y la que usa cada negocio. |
| FT-INT-04 · Catálogos maestros, precios y costos desde SAP/S4H | Las listas que manda SAP (marcas, grupos de artículo, impuestos y listas de atributos de SAP) ya leídas del archivo por MS-07. |
Entrega
| A | Qué |
|---|---|
| PE-C · Catálogo vigente | Las listas y valores vigentes por código, con su etiqueta, su forma por destino y su política de valores nuevos; los cambios salen en LOV_CHANGED y LOV_VALUE_CHANGED. |
| FT-PLT-06 · Configuración de atributos por plantilla y por negocio… | Los valores activos que la configuración de cada plantilla puede filtrar, y el fuera de alcance que los quita de toda captura. |
| FT-PLT-10 · Fachada v1 compatible con P360 para Entrada Única y Foro | Los valores por código con su etiqueta y sinónimos (API-01-007) que el BFF muestra en las listas de la captura. |
| FT-PRD-07 · Captura guiada por pasos con los mínimos primero | La solicitud de valor nuevo (API-01-104) y el aviso LOV_VALUE_CHANGED que dice cuándo se aprobó, para que la captura deje el campo como «valor solicitado» y lo llene al aprobarse. |
| FT-INT-07 · Repoblamiento masivo de productos hacia la tienda | El código con su etiqueta o salida nueva (LOV_VALUE_CHANGED), para republicar con su vista previa (API-02-039, REPUBLISH) los productos publicados que lo usan. |
| FT-INT-04 · Catálogos maestros, precios y costos desde SAP/S4H | Las listas de valores por código, separadas por ECC y S4H, que reciben los valores de SAP por API-01-050. |
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.
Los pasos en texto
| Paso | De | A | Qué hace | API o evento |
|---|---|---|---|---|
| 1 | Administración del catálogo | Entrada Única · Vendor Center | Abre la lista de colores y sus valores | — |
| 2 | Entrada Única · Vendor Center | MS-01 Catálogo (por el BFF) | Pide la lista con sus destinos declarados | API-01-006 |
| 3 | Entrada Única · Vendor Center | MS-01 Catálogo (por el BFF) | Pide los valores con su forma por destino | API-01-007 |
| 4 | Administración del catálogo | Entrada Única · Vendor Center | Renombra «Azul» a «AZUL» y fija su salida a la tienda | — |
| 5 | Entrada Única · Vendor Center | MS-01 Catálogo (por el BFF) | Pide el plan del cambio de valores | API-01-010 |
| 6 | MS-01 Catálogo | MS-02 Producto | Cuenta los productos que usan ese código | API-02-113 |
| 7 | Entrada Única · Vendor Center | MS-01 Catálogo (por el BFF) | Confirma y abre la solicitud de cambio | API-01-004 |
| 8 | Entrada Única · Vendor Center | MS-01 Catálogo (por el BFF) | Otro administrador aprueba la solicitud | API-01-103 |
| 9 | MS-01 Catálogo | Base pim | Cambia etiqueta y salida sin tocar ningún producto | — |
| 10 | MS-01 Catálogo | Eventos | Avisa el cambio del valor | catalog.governance.changed/LOV_VALUE_CHANGED |
| 11 | Eventos | MS-02 Producto | Entrega el cambio: el producto muestra «AZUL» sin reescribirse | catalog.governance.changed/LOV_VALUE_CHANGED |
| 12 | Entrada Única · Vendor Center | MS-02 Producto (por el BFF) | Busca los productos publicados que usan ese código | API-02-001 |
| 13 | Entrada Única · Vendor Center | MS-02 Producto (por el BFF) | Pide el plan de republicarlos en sus canales | API-02-039 |
| 14 | Entrada Única · Vendor Center | MS-02 Producto (por el BFF) | Confirma la republicación con su vista previa | API-02-057 |
3.1 El proveedor pide un valor que no está en la lista
3.2 Fusionar valores y mover los productos
3.3 Listas que manda SAP
4. Si algo sale mal
- Se da de alta un código que ya existe en la misma lista. El plan responde 409 ID_ALREADY_EXISTS; el mismo código en otra lista sí se admite, porque la llave es lista más código.
- La lista no acepta valores nuevos (es de SAP o su política es rechazar). La solicitud responde 422 BUSINESS_ERROR con el motivo y los valores parecidos; el proveedor elige uno de ellos o pide el alta del valor a SAP por su área.
- Gobierno de Producto rechaza el valor que pidió el proveedor. MS-14 avisa al proveedor con el motivo y MS-02 deja el campo vacío para que elija otro valor; la propuesta no se pierde.
- Se pide borrar o fusionar un valor que usan productos. El plan muestra cuántos productos y cuántos publicados lo usan y exige confirmar el impacto; si Producto no responde el conteo, el plan no se arma (503 DEPENDENCY_UNAVAILABLE).
- El trabajo de reescritura falla con algunos productos. El recibo de MS-02 dice cuáles quedaron con el código viejo y por qué; el valor fusionado sigue inactivo y apunta al nuevo, así que se reintenta sólo lo pendiente.
5. APIs
Las que construye esta épica (9)
GET /api/v2/lovs · Buscar listas de valores
| Campo | Valor |
|---|---|
| API | API-01-005 · MS-01 Catálogo |
| Para qué | Busca listas de valores por nombre y uso, y dice de cada una quién manda (SAP o el PIM), si acepta valores nuevos, qué atributos la usan y cuántos valores tiene. |
| En esta épica | Buscar listas por nombre, uso y dueño |
| Quién la llama | BFF del portal, MS-02 Producto |
| Permiso | CAT-L; los módulos, con su cuenta de servicio |
| Cabeceras | Authorization, X-Request-Id |
| Parámetros | q = color, status = ACTIVE, masterSystem = PIM, usage = BUSINESS, page = 1, size = 50 |
Request
null
Response · 200
{
"success": true,
"data": {
"items": [
{
"lovId": "COLORES_LOV",
"name": {
"es": "Colores"
},
"valueType": "TEXT",
"masterSystem": "PIM",
"newValuePolicy": "REQUEST",
"usedByAttributes": [
"COLOR_PRINCIPAL"
],
"valueCount": 412,
"status": "ACTIVE",
"version": 7
}
],
"page": 1,
"size": 50,
"total": 1
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 400 | VALIDATION_ERROR | Un filtro trae un valor que no existe |
GET /api/v2/lovs/{id} · Detalle de una lista
| Campo | Valor |
|---|---|
| API | API-01-006 · MS-01 Catálogo |
| Para qué | Muestra la cabecera de una lista: quién manda, su política de valores nuevos, los destinos para los que declara una forma propia del valor y la lista paralela que usa otro negocio. |
| En esta épica | La cabecera de una lista con sus destinos y su política |
| Quién la llama | BFF del portal, MS-02 Producto |
| Permiso | CAT-L; los módulos, con su cuenta de servicio |
| Cabeceras | Authorization, X-Request-Id |
| Parámetros | id = COLORES_LOV |
Request
null
Response · 200
{
"success": true,
"data": {
"lovId": "COLORES_LOV",
"name": {
"es": "Colores",
"en": "Colors"
},
"valueType": "TEXT",
"masterSystem": "PIM",
"newValuePolicy": "REQUEST",
"outputsDeclared": [
"TIENDA",
"SAP",
"MARKETPLACE"
],
"parallelByBusiness": {
"SUB": "COLORES_LOV"
},
"transformedByDictionary": [],
"status": "ACTIVE",
"version": 7
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 404 | NOT_FOUND | La lista no existe |
GET /api/v2/lovs/{id}/values · Valores de una lista
| Campo | Valor |
|---|---|
| API | API-01-007 · MS-01 Catálogo |
| Para qué | Devuelve los valores de una lista por código, con su etiqueta por idioma, orden, sinónimos y su forma para cada destino. Con q autocompleta por etiqueta y sinónimo, como lo usa la captura. |
| En esta épica | Valores por código, con autocompletado y forma por destino |
| Quién la llama | BFF del portal, Gateway de terceros /partner/v1, MS-02 Producto |
| Permiso | CAT-L; quien captura una propuesta; los módulos, con su cuenta de servicio |
| Cabeceras | Authorization, X-Request-Id |
| Parámetros | id = COLORES_LOV, q = azu, status = ACTIVE, page = 1, size = 20 |
| También la usan | FT-FLU-06, FT-PLT-10, FT-RAC-07, FT-REF-01, FT-REF-04 |
Request
null
Response · 200
{
"success": true,
"data": {
"items": [
{
"code": "0700",
"label": {
"es": "Azul",
"en": "Blue"
},
"order": 70,
"synonyms": [
"azul rey"
],
"status": "ACTIVE",
"outputs": {
"TIENDA": "AZUL",
"SAP": "AZUL",
"MARKETPLACE": "Azul"
},
"externalIds": {
"ECC": "0700"
},
"version": 3
},
{
"code": "0705",
"label": {
"es": "Azul marino",
"en": "Navy blue"
},
"order": 71,
"synonyms": [
"marino"
],
"status": "ACTIVE",
"outputs": {
"TIENDA": "AZUL",
"SAP": "AZUL MARINO"
},
"externalIds": {
"ECC": "0705"
},
"version": 1
}
],
"page": 1,
"size": 20,
"total": 2
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 404 | NOT_FOUND | La lista no existe |
GET /api/v2/lovs/{id}/values/{code}/usage · Dónde se usa un valor en el catálogo
| Campo | Valor |
|---|---|
| API | API-01-008 · MS-01 Catálogo |
| Para qué | Dice dónde se usa un valor dentro del catálogo antes de borrarlo o fusionarlo: plantillas que lo filtran, reglas que lo citan y atributos que lo tienen por omisión. El conteo de productos no va aquí: lo da el plan de borrado o de fusión, que se lo pide a Producto. |
| En esta épica | Dónde se usa un valor dentro del catálogo antes de borrarlo |
| Quién la llama | BFF del portal |
| Permiso | CAT-L |
| Cabeceras | Authorization, X-Request-Id |
| Parámetros | id = GENERO_LOV, code = 0031 |
Request
null
Response · 200
{
"success": true,
"data": {
"lovId": "GENERO_LOV",
"code": "0031",
"label": "Infantiles",
"templates": {
"count": 12,
"sample": [
"EU4-0512",
"EU4-0518"
]
},
"rules": {
"count": 3,
"types": [
"ALLOWED_VALUES_BY_ITEM_GROUP"
]
},
"attributeDefaults": [
"GENERO"
]
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 404 | NOT_FOUND | La lista o el código no existen |
POST /api/v2/lovs/plans · Plan de alta o cambio de listas
| Campo | Valor |
|---|---|
| API | API-01-009 · MS-01 Catálogo |
| Para qué | Revisa sin escribir el alta o el cambio de una lista: su nombre, su política de valores nuevos, los destinos con forma propia y su lista paralela por negocio. Las listas cuyo dueño es SAP no se cambian aquí. |
| En esta épica | Cambiar una lista: su política de valores nuevos y sus destinos |
| Quién la llama | BFF del portal |
| Permiso | CAT-E |
| Cabeceras | Authorization, X-Request-Id, Idempotency-Key |
Request
{
"operation": "UPDATE",
"items": [
{
"lovId": "COLORES_LOV",
"version": 7,
"newValuePolicy": "REQUEST",
"outputsDeclared": [
"TIENDA",
"SAP",
"MARKETPLACE"
]
}
]
}
Response · 200
{
"success": true,
"data": {
"planId": "pln-3b7e22",
"expiresAt": "2027-01-12T16:20:00Z",
"requiresApproval": true,
"items": [
{
"lovId": "COLORES_LOV",
"action": "UPDATE",
"changes": [
{
"path": "outputsDeclared",
"before": [
"TIENDA",
"SAP"
],
"after": [
"TIENDA",
"SAP",
"MARKETPLACE"
]
}
]
}
],
"applyUrl": "/api/v2/catalog-plans/pln-3b7e22/apply"
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 409 | IMMUTABLE_ID | Intenta cambiar el identificador de la lista |
| 422 | BUSINESS_ERROR | La lista es de SAP: sólo la escribe la ingesta de MS-07 |
| 409 | VERSION_CONFLICT | La lista cambió desde que se leyó |
POST /api/v2/lovs/{id}/values/plans · Plan de alta o cambio de valores
| Campo | Valor |
|---|---|
| API | API-01-010 · MS-01 Catálogo |
| Para qué | Revisa sin escribir altas, cambios de etiqueta, orden o forma por destino, fuera de alcance, bajas y fusiones de valores. Pide a Producto cuántos productos usan cada código; si hay productos, el borrado o la fusión exigen confirmar el impacto. |
| En esta épica | Altas, cambios, fuera de alcance, bajas y fusiones de valores |
| Quién la llama | BFF del portal |
| Permiso | CAT-E |
| Cabeceras | Authorization, X-Request-Id, Idempotency-Key |
| Parámetros | id = COLORES_LOV |
Request
{
"operation": "UPDATE",
"items": [
{
"code": "0700",
"version": 3,
"label": {
"es": "AZUL"
},
"outputs": {
"TIENDA": "AZUL"
}
}
]
}
Response · 200
{
"success": true,
"data": {
"planId": "pln-61d0f8",
"expiresAt": "2027-01-12T16:31:00Z",
"requiresApproval": true,
"items": [
{
"code": "0700",
"action": "UPDATE",
"changes": [
{
"path": "label.es",
"before": "Azul",
"after": "AZUL"
}
],
"impact": {
"products": 1840,
"publishedProducts": 1210,
"productsRewritten": 0,
"republish": true
}
}
],
"applyUrl": "/api/v2/catalog-plans/pln-61d0f8/apply"
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 409 | ID_ALREADY_EXISTS | El código nuevo ya existe en esa lista (en otra lista sí se admite) |
| 409 | IMMUTABLE_ID | Intenta cambiar el código de un valor |
| 422 | BUSINESS_ERROR | La lista es de SAP, o borra o fusiona un valor con productos sin confirmar el impacto |
| 503 | DEPENDENCY_UNAVAILABLE | Producto no respondió el conteo: el plan no se arma a medias |
POST /api/v2/lovs/{id}/value-requests · Pedir un valor que no está en la lista
| Campo | Valor |
|---|---|
| API | API-01-104 · MS-01 Catálogo |
| Para qué | El proveedor o el seller pide, desde su propuesta, un valor que no encontró. Si la lista acepta solicitudes, queda una solicitud pendiente para Gobierno de Producto y el campo espera el valor; si no, responde con el motivo y con los valores parecidos. |
| En esta épica | El proveedor o el seller pide un valor que falta |
| Quién la llama | BFF del portal, Gateway de terceros /partner/v1 |
| Permiso | El proveedor o el seller dueño de la propuesta que tiene un atributo con esa lista |
| Cabeceras | Authorization, X-Request-Id, Idempotency-Key |
| Parámetros | id = COLORES_LOV |
| Escribe en | governance_receipts |
Request
{
"label": "Azul petróleo",
"attributeId": "COLOR_PRINCIPAL",
"productId": "PRD-0004812",
"templateId": "EU4-0412",
"business": "MER",
"comment": "Color del catálogo de la marca"
}
Response · 202
{
"success": true,
"data": {
"requestId": "req-71ab35",
"status": "PENDING_APPROVAL",
"changeRequestId": "chg-5d10e2",
"similarValues": [
{
"code": "0705",
"label": "Azul marino"
}
],
"receiptUrl": "/api/v2/catalog-receipts/req-71ab35"
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 422 | BUSINESS_ERROR | La lista no acepta valores nuevos (política REJECT o lista de SAP): se explica y se ofrecen los parecidos |
| 409 | ID_ALREADY_EXISTS | Ya hay un valor con esa etiqueta o sinónimo: se devuelve su código |
| 403 | AUTHORIZATION_ERROR | Quien llama no es dueño de esa propuesta |
POST /internal/governance/sap/lov · Listas que manda SAP
| Campo | Valor |
|---|---|
| API | API-01-050 · MS-01 Catálogo |
| Para qué | MS-07 entrega, ya leído del archivo, un lote de valores de una lista cuyo dueño es SAP (marcas, grupos de artículo, impuestos, listas de atributos de SAP). Se aplica sin aprobación porque SAP decide esos valores, con recibo por archivo y por registro. |
| En esta épica | Recibir las listas que manda SAP |
| Quién la llama | MS-07 Ingesta de archivos |
| Permiso | Sólo MS-07 (cuenta de servicio) |
| Cabeceras | Authorization, X-Request-Id, Idempotency-Key |
| Escribe en | lovs, lov_values, governance_receipts, governance_outbox |
| Publica | catalog.governance.changed/LOV_CHANGED, catalog.governance.changed/LOV_VALUE_CHANGED |
| También la usan | FT-INT-04, FT-REF-01 |
Request
{
"fileId": "lov-ecc-20270112-01",
"system": "ECC",
"lovId": "MARCAS_ECC_LOV",
"records": [
{
"recordNo": 1,
"code": "MARCA01",
"label": "Marca uno",
"active": true
},
{
"recordNo": 2,
"code": "MARCA02",
"label": "Marca dos",
"active": false
}
]
}
Response · 200
{
"success": true,
"data": {
"fileId": "lov-ecc-20270112-01",
"applied": 2,
"rejected": 0,
"items": [
{
"recordNo": 1,
"result": "CREATED"
},
{
"recordNo": 2,
"result": "DEACTIVATED"
}
]
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 409 | IDEMPOTENCY_MISMATCH | El mismo archivo llega otra vez con contenido distinto |
| 422 | BUSINESS_ERROR | La lista no tiene a SAP como dueño: no se escribe desde la ingesta |
POST /internal/product/value-remaps · Cuando el catálogo aprueba fusionar dos valores o mover valo
| Campo | Valor |
|---|---|
| API | API-02-120 · MS-02 Producto |
| Para qué | Cuando el catálogo aprueba fusionar dos valores o mover valores a otro atributo, Producto reescribe esos códigos en sus productos en un trabajo asíncrono, avisa cada producto cambiado (PRODUCT_UPDATED) y deja un recibo con el resultado de cada uno. |
| En esta épica | Reescribir en los productos el código fusionado |
Request
{
"changeRequestId": "chg-91b3e0",
"remaps": [
{
"attributeId": "GENERO",
"fromCode": "GENERO_LOV::0031",
"toCode": "GENERO_LOV::0030"
}
]
}
Response · 202
{
"success": true,
"data": {
"requestId": "req-6d22f1",
"status": "ACCEPTED",
"productsToChange": 2311,
"receiptUrl": "/api/v2/product-receipts/req-6d22f1"
}
}
Errores
| HTTP | Código | Cuándo |
|---|---|---|
| 403 | AUTHORIZATION_ERROR | Quien llama no tiene el permiso o no es el módulo autorizado |
| 422 | VALIDATION_ERROR | Falta un dato o viene con un formato inválido; el detalle dice qué campo |
| 409 | IDEMPOTENCY_MISMATCH | Se repite la llave de idempotencia con otro cuerpo |
Las que usa y construye otra épica (10)
Su request y su response están en la página de la épica que la construye.
| API | Método y ruta | Para qué, aquí | La construye |
|---|---|---|---|
| API-01-004 | POST /api/v2/catalog-plans/{planId}/apply | Confirmar el plan y abrir la solicitud | FT-PLT-01 · Fundamentos de gobierno de plantillas |
| API-01-103 | POST /api/v2/catalog-change-requests/{changeRequestId}/decision | Aprobar la solicitud del valor | FT-PLT-01 · Fundamentos de gobierno de plantillas |
| API-01-028 | GET /api/v2/taxonomies/PRODUCT/nodes/{id}/effective | La vista efectiva ya aplica el fuera de alcance y el filtro de cada plantilla | FT-PLT-06 · Configuración de atributos por plantilla y por negocio… |
| API-01-053 | POST /internal/governance/bulk-load/{coleccion} | Migrar los valores inactivos de P360 como fuera de alcance | FT-PLT-01 · Fundamentos de gobierno de plantillas |
| API-14-005 | POST /internal/notifications/messages | Avisar a Gobierno de Producto y al proveedor | FT-RAC-05 · Estatus del producto y motivos visibles para seller y… |
| API-02-025 | GET /api/v2/product-receipts/{requestId} | El recibo del trabajo que reescribe los productos | FT-FLU-01 · Motor de estados configurable con dos carreteras y reglas… |
| API-02-001 | POST /api/v2/products/search | Encontrar los productos publicados que usan el código renombrado | FT-PRD-01 · Modelo canónico de producto |
| API-02-039 | POST /api/v2/publications/plans | La vista previa de republicar esos productos en sus canales | FT-INT-07 · Repoblamiento masivo de productos hacia la tienda |
| API-02-057 | POST /api/v2/product-plans/{planId}/apply | Confirmar la republicación en Producto | FT-FLU-01 · Motor de estados configurable con dos carreteras y reglas… |
| API-02-113 | POST /internal/product/catalog-usage | Cuántos productos usan un código, por estado | FT-PLT-02 · Catálogo de atributos |
6. Eventos
Publica
| Evento | Cuándo | Quién lo consume |
|---|---|---|
catalog.governance.changed/LOV_VALUE_CHANGED | Se aprueba un alta, un cambio de etiqueta o de salida, un fuera de alcance, una baja o una fusión, o llega un valor de SAP | FT-ARQ-02, FT-PLT-06, FT-RAC-07 |
catalog.governance.changed/LOV_CHANGED | Cambia una lista: su política de valores nuevos, sus destinos o lo que manda SAP | MS-05 (bitácora) |
Consume
| Evento | Para qué | Quién lo publica |
|---|---|---|
catalog.governance.changed/LOV_VALUE_CHANGED | MS-02 resuelve la etiqueta y la salida nuevas, republica los publicados y llena los campos que esperaban un valor solicitado | esta misma épica |
catalog.governance.changed/LOV_VALUE_CHANGED | MS-01 recalcula las vistas efectivas que filtran ese valor | esta misma épica |
catalog.governance.changed/LOV_CHANGED | MS-02 refresca la política de valores nuevos y los destinos de la lista con que valida la captura y arma la foto de publicación | esta misma épica |
catalog.egress.files/OBJECT_FINALIZE | MS-07 lee el archivo de listas de SAP | D-ARCHIVOS |
7. Datos
Cada colección tiene un solo dueño, el único que escribe en ella.
| Colección | Dueño | Qué guarda | Esta épica |
|---|---|---|---|
lovs | MS-01 | Cabecera de cada lista de valores. | escribe |
lov_values | MS-01 | Cada valor de lista: código, etiqueta, orden y equivalencias por sistema. | escribe |
governance_receipts | MS-01 | El recibo de cada escritura confirmada en el catálogo (antes operation_receipts). | escribe |
governance_outbox | MS-01 | Los cambios del catálogo que esperan salir como evento (antes outbox). | escribe |
lovs | MS-01 | Cabecera de cada lista de valores. | lee |
lov_values | MS-01 | Cada valor de lista: código, etiqueta, orden y equivalencias por sistema. | lee |
attributes | MS-01 | Cada atributo: tipo, lista, restricciones, grupos e identificadores externos. | lee |
taxonomy_nodes | MS-01 | Plantillas y nodos de grupo de artículo, con la configuración de atributos de cada plantilla. | lee |
governance_rules | MS-01 | Reglas de captura y clasificación: marcas por plantilla, grupo de artículo a plantilla, alcance del proveedor y lista negra de Marketplace. | lee |
reference_table_defs | MS-01 | Definición de cada diccionario. | lee |
8. Historias que cubre
| Historia | Prioridad | Cómo la cubre |
|---|---|---|
| FT-PLT-03·H1 · Listas por código | P1 | pasos 1, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14; API-01-010, API-01-007, API-02-039 |
| FT-PLT-03·H2 · Fuera de alcance y filtro por plantilla | P1 | flujo «Listas que manda SAP»; API-01-010, API-01-053, API-01-028. Fuera: El filtro de valores de cada plantilla (que una blusa no ofrezca «55 L») se configura en FT-PLT-06 y lo aplica la vista efectiva; aquí vive el fuera de alcance de toda la lista. |
| FT-PLT-03·H3 · Valores que no están en la lista | P2 | flujo «El proveedor pide un valor que no está en la lista»; API-01-104, API-01-007 |
| FT-PLT-03·H4 · Valor canónico con salida por sistema | P2 | pasos 2, 3, 4, 9, 11; API-01-006, API-01-007, API-01-009 |
| FT-PLT-03·H5 · Limpiar listas | P3 | flujo «Fusionar valores y mover los productos»; API-01-008, API-02-113, API-02-120, API-02-025 |
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-03-1. El producto guarda el código, nunca la etiqueta. Renombrar cambia sólo el valor en MS-01 y avisa LOV_VALUE_CHANGED; MS-02 muestra la etiqueta nueva sin reescribir el producto. Los publicados se republican de forma explícita, con la vista previa de Producto (API-02-039), que la misma pantalla ofrece al aplicarse el cambio. Por qué: Corregir «Azul» a «AZUL» no debe tocar 1,840 productos ni sus versiones. Republicar con vista previa evita mandar miles de productos a los canales sin que nadie lo vea, como ya se decidió para los demás cambios del catálogo (FT-CAT-05). Se apoya en DEC-PLT-03, DMS-04.
- D-PLT-03-2. Las equivalencias por destino viven en el valor: cada valor declara su forma para la tienda, SAP, Marketplace y los demás (con valor y unidad cuando hace falta). MS-02 las resuelve al armar la foto de publicación y ningún adaptador guarda tablas propias. Los diccionarios de talla que ya transforman se migran tal cual y nunca hay dos fuentes para el mismo par lista y destino. Por qué: Capturar una vez y entregar a cada sistema su forma, sin romper SAP, con una sola fuente por transformación. Se apoya en RF-PLA-10, RN-PLA-13, DEC-PLT-08, DUD-34.
- D-PLT-03-3. Cada lista declara su política de valores nuevos. Las listas de SAP nunca aceptan valores del PIM (los crea SAP); las del PIM aceptan solicitudes que aprueba Gobierno de Producto. Nunca se acepta texto libre en un atributo de lista: mientras se decide, el campo queda como «valor solicitado» en el producto y MS-02 lo llena al aprobarse. Por qué: Equilibra no detener el alta con la meta de capturar en listas y no romper SAP con valores sin normalizar. Se apoya en PEN-31, RF-PLA-09.
- D-PLT-03-4. Fuera de alcance quita un valor de toda captura nueva y los productos que ya lo tienen lo conservan; lo inactivo de P360 migra así. El filtro de valores por plantilla vive en la configuración de la plantilla (FT-PLT-06), no en la lista. Por qué: Retirar un valor no debe reescribir lo histórico, y un solo lugar decide qué valores ve cada plantilla. Se apoya en DEC-ARQ-12, DEC-PLT-03.
- D-PLT-03-5. Fusionar valores o moverlos a otro atributo es una solicitud con impacto. Al aprobarse, MS-01 deja el valor fusionado inactivo y apuntando al que lo sustituye, y le pide a MS-02 reescribir los productos en un trabajo asíncrono con recibo (PEDIDA-PLT-03-1). Por qué: El dueño de los productos es MS-02: el catálogo decide la fusión y Producto cambia sus datos, con un reporte de lo que quedó. Se apoya en DEC-ARQ-12, ADR-12.
- D-PLT-03-6. El conteo de productos que usan un valor lo da el plan de borrado o de fusión, que lo pide a MS-02. La consulta de uso de MS-01 (API-01-008) sólo responde lo que está en el catálogo: plantillas, reglas y atributos. Por qué: Un endpoint de MS-01 no compone datos de otro módulo para una pantalla (decisión 19); el conteo sí es necesario para la regla de confirmar el impacto. Se apoya en ADR-12.
Qué falta decidir
| ID | Qué falta |
|---|---|
| DUD-34 | Decidir tabla por tabla dónde vive cada transformación por destino que hoy está en diccionarios. |
| DUD-23 | SAP confirma el contrato de las listas sin broker (los XML nuevos de E27 y X01) que lee MS-07. |
También siguen abiertos: PEN-31, Gobierno de Producto confirma la libertad del proveedor: aquí se propone solicitud con aprobación, nunca texto libre; PEN-88, Sesión de detalle del modelo canónico: cómo viaja a SAP un valor con unidad («22 centímetros»).
Fuentes
- [D]
trazabilidad/features/FT-PLT-03-listas-de-valores-y-modelo-canonico.md: la ficha de la épica, con sus historias, reglas y bloqueos. - [D] ADR-12 · Un solo sistema: backend compartido y una sola base (sección 3.4).
- [D]
docs/arquitectura/por-epica/base/: piezas, colecciones, eventos y el hilo de punta a punta. - [D]
docs/arquitectura/omega-a-pim-headless/contratos-api.md: convenciones y endpoints de partida. - [D]
docs/arquitectura/maquina-de-estados-to-be/propuesta-maquina-de-estados.md§7: estados, tareas y canales. - [I] Las decisiones de la sección 9 son del TL sobre esas fuentes.