FT-PRD-05 · Edición y aprobación por campo según el dueño del dato

En 30 segundos

Cuando alguien cambia un producto que ya está publicado, esta épica decide qué pasa con cada campo según quién es su dueño. Si quien cambia es el dueño, como el comprador con el envase, se aplica y se republica al momento. Si no, el dueño revisa el cambio mientras la tienda sigue mostrando lo publicado; al aprobarse, sólo se republican los canales afectados. También cubre los cambios de sellers, las variantes nuevas, el repoblamiento y la inactivación mientras se corrige.

• Módulo dueño: MS-02 Producto. También participan: MS-15 IA y enriquecimiento, MS-14 Avisos y ayuda, MS-08 Adaptadores de salida, MS-05 Auditoría.
• Etapa 9 · Modificación. Recibe «PE-9 · Publicado por canal» y entrega «PE-10 · Cambio aprobado».
• APIs: construye 2 y usa 16 que construyen otras épicas.
• Eventos: publica 6 y consume 4.

1. Dónde encaja

Recibe

Entrega

Cambios de estado que hace

Tareas que abre o cierra: Revisión del cambio, Repoblamiento, Corrección.

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 Un seller cambia su producto publicado: revisión con IA sin detener la venta

3.2 Si el revisor rechaza el cambio

3.3 Inactivar y repoblar un producto publicado

4. Si algo sale mal

• Dos personas proponen cambios al mismo campo. La segunda solicitud se junta con la primera en la misma Revisión del cambio y el revisor ve las dos; quien confirma sobre una versión vieja del mismo grupo de campos recibe 409 VERSION_CONFLICT y vuelve a ver lo vigente.
• La IA no responde o duda al revisar un cambio. El cambio no se aplica sin dato: la revisión pasa a QA manual con el motivo «Sin dato» y la tienda conserva lo publicado.
• Alguien intenta cambiar el EAN o el SKU. La solicitud responde 422 BUSINESS_ERROR: el EAN va por la liberación de EAN (FT-PRD-03) o por Gobierno de Datos, y el SKU no cambia nunca.
• El cambio aprobado toca un dato que usa SAP. Además de republicar, se pide a SAP con SAP_CREATION_REQUESTED de tipo MODIFY. Si SAP lo rechaza, se abre Gobierno de Datos con el mensaje de SAP y el proveedor ve «En proceso Liverpool».
• Un seller intenta cambiar el contenido de un producto ajeno. Responde 403: sólo puede agregar variantes. La pantalla ya lo muestra, porque la matriz deja ese grupo de campos en sólo lectura para él.

5. APIs

Las que construye esta épica (2)

{
  "version": 12,
  "comment": "El proveedor actualizó la ficha técnica del empaque",
  "changes": [
    {
      "attribute": "PESO_EMPAQUE",
      "value": "1.4",
      "unit": "kg"
    }
  ]
}

{
  "success": true,
  "data": {
    "planId": "pln-5d21f0",
    "expiresAt": "2026-10-18T15:14:05Z",
    "productId": "PRD-0004812",
    "from": "APROBADO",
    "to": "EN_MODIFICACION",
    "fields": [
      {
        "attribute": "PESO_EMPAQUE",
        "published": "1.2 kg",
        "proposed": "1.4 kg",
        "reviewer": {
          "kind": "AREA",
          "area": "LOGISTICA"
        },
        "route": "OWNER_REVIEW"
      }
    ],
    "opensTasks": [
      "REVISION_DEL_CAMBIO"
    ],
    "storeKeepsVersion": 12,
    "needsSap": false,
    "applyUrl": "/api/v2/product-plans/pln-5d21f0/apply"
  }
}

null

{
  "success": true,
  "data": {
    "productId": "PRD-0004812",
    "status": "EN_MODIFICACION",
    "publishedVersion": 12,
    "items": [
      {
        "changeId": "chg-7a10",
        "taskId": "tsk-52108",
        "kind": "VALUES",
        "requestedBy": {
          "area": "COMPRAS-HOGAR",
          "role": "COMPRAS"
        },
        "requestedAt": "2026-10-18T15:04:07Z",
        "reviewer": {
          "kind": "AREA",
          "area": "LOGISTICA"
        },
        "state": "IN_REVIEW",
        "fields": [
          {
            "attribute": "PESO_EMPAQUE",
            "label": "Peso del empaque",
            "published": "1.2 kg",
            "proposed": "1.4 kg"
          }
        ],
        "republishChannels": [
          "TIENDA",
          "OMS"
        ]
      }
    ]
  }
}

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-PRD-05-1. Cada grupo de campos tiene un dueño por negocio en la tabla FIELD_OWNERS del motor, con dos modos: directo o con revisión. Si quien cambia es el dueño en modo directo (el envase para Compras), el cambio se aplica con el plan de valores, queda quién y cuándo, y se republica al momento (T09 y T10 en la misma transacción). Si no, se pide con una solicitud de cambio (API-02-310) que revisa el dueño. Por qué: El comprador corrige lo suyo sin ticket y nada de quien no es dueño se aplica sin aprobación. El «archivo de roles» del taller se vuelve una tabla que Gobierno de Producto cambia sin desplegar código. Se apoya en RF-ALT-05, RN-CAL-05, DMS-71, DUD-22.
• D-PRD-05-2. Lo publicado no se toca mientras se revisa: la propuesta vive en la tarea Revisión del cambio, el producto pasa a En modificación (T09) y la tienda conserva su versión. Al aprobar, se aplica en una transacción con versión nueva, vuelve a Aprobado (T10) y sólo los canales afectados pasan de Publicado a Enviado (C06). Por qué: Así se revisa el cambio sin detener la venta, como pidió Marketplace: se detiene la tarea, no el SKU. Se apoya en S30-RF-09, PD-29.
• D-PRD-05-3. Quién revisa sale de la tabla CHANGE_ROUTES: un dato puntual del contenido lo revisa la QA con IA; un dato maestro o una variante nueva, Compras en Mercaderías y Suburbia o la calificación en Marketplace. El EAN no se cambia por aquí: va por la liberación de EAN (FT-PRD-03) o por Gobierno de Datos. Por qué: Es la regla del taller: el dato puntual sólo vuelve a la revisión con IA y el dato maestro o la variante regresan a Compras, que cuida lo que va a SAP. Se apoya en S34-RF-07, P-41, DEC-PRD-04.
• D-PRD-05-4. Si el revisor rechaza, se abre una Corrección para quien pidió el cambio, con el motivo por campo y su destino, y el proveedor ve «Por actualizar». Si la corrección vence, se descarta el cambio, nunca el producto, y vuelve a Aprobado (T10). Por qué: Un producto aprobado no se cancela; rechazar un cambio sólo debe deshacer el cambio. Se apoya en PD-29, P-01.
• D-PRD-05-5. Una variante nueva sobre un producto aprobado, propia o de un seller sobre un genérico ajeno, entra por la misma solicitud. Al aprobarse, la familia vuelve a Aprobado y la variante lleva su propio estado: pide su SKU con SAP_CREATION_REQUESTED de tipo MODIFY y entra a sus canales cuando esté lista. Las variantes publicadas y los datos del genérico no se tocan, y la variante queda con su seller como dueño. Por qué: Vender un color o una talla nueva sin duplicar el producto ni tocar la ficha ajena; el producto es un documento por familia con estado de familia y de variante. Se apoya en S30-RF-01, DEC-PRD-02.
• D-PRD-05-6. El seller dueño del contenido puede proponer cambios a todo su producto, que vuelven a la revisión con IA; si el producto es de otro seller o de Liverpool, sólo puede agregar variantes. La modificación masiva usa la carga masiva de FT-FLU-04 con la columna índice del papá o del SKU, y cada renglón se vuelve una solicitud de cambio, sin pedir SKU nuevo. Por qué: «Sólo puedes solicitar en tu catálogo»: nadie cambia fichas ajenas, y la plantilla de modificación no repite el alta. Se apoya en S30-RF-07, PD-02.
• D-PRD-05-7. Dos áreas pueden trabajar a la vez en un producto: ninguna tarea bloquea la edición (salvo Foro, que lo deja sólo para consulta) y el conflicto de versión se revisa por grupo de campos, así que Publicación edita lo suyo mientras Categoría trabaja en lo suyo. Por qué: Hoy un área le quita la propuesta a la otra; con un dueño por grupo, los cambios de áreas distintas no chocan. Se apoya en RF-INT-08, PD-29.
• D-PRD-05-8. Inactivar un producto publicado es una acción del motor (INACTIVATE): pasa a En modificación con una tarea de Repoblamiento y pide retirarlo de todos sus canales con la misma operación de retiro de la publicación (FT-CAT-05). Al reactivar (REACTIVATE) vuelve a Aprobado y se republica en los mismos canales, sin SKU nuevo. Por qué: Un producto aprobado no se cancela: se retira de cada canal, como pide el servicio para inactivar mientras se corrige. Se apoya en S34-RF-02, PD-29.

Qué falta decidir

También siguen abiertos: PEN-167, La precedencia de lo que manda el proveedor frente a lo que propone la IA o Foro en un producto publicado.

Fuentes

1. [D] trazabilidad/features/FT-PRD-05-edicion-aprobacion-por-campo.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.