FT-RAC-01 · Motor de validación en línea y candados de datos…

En 30 segundos

Hoy las validaciones se concentran al final y SAP es el último en decir que falta algo, así que el proveedor retrabaja todo. Esta épica valida cada dato en el momento en que se captura, con el error en el mismo campo, y pone candados que impiden enviar, pedir el SKU o mandar a SAP un producto incompleto. Al enviar, una Validación automática revisa la versión enviada y la deja lista para el visto bueno.

• Módulo dueño: MS-02 Producto. También participan: MS-01 Catálogo, MS-06 Evaluación, MS-08 Adaptadores de salida, MS-14 Avisos y ayuda.
• Etapa 3 · Captura. Recibe «PE-3 · Plantilla asignada» y entrega «PE-4 · Propuesta enviada».
• APIs: construye 3 y usa 10 que construyen otras épicas.
• Eventos: publica 4 y consume 3.

1. Dónde encaja

Recibe

Entrega

Cambios de estado que hace

Tareas que abre o cierra: Validación automática, Corrección, 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 Si las reglas rechazan la propuesta enviada

3.2 Candado antes del SKU y antes de SAP

3.3 Carga masiva con las mismas reglas

4. Si algo sale mal

• Catálogo (MS-01) no responde al validar. MS-02 valida con la vista efectiva y las reglas que tiene en caché, con su versión; si no tiene caché responde 503 DEPENDENCY_UNAVAILABLE y no guarda nada. El autoguardado conserva lo tecleado (FT-PRD-07).
• La plantilla o una regla cambió entre la vista previa y la confirmación. La confirmación responde 409 VERSION_CONFLICT porque las versiones de origen del plan ya no coinciden; el portal vuelve a revisar y el proveedor ve los campos nuevos.
• Una regla falla en la Validación automática después de enviar. La propuesta regresa a Borrador (T04) con una tarea de Corrección y el motivo por campo; el proveedor recibe un aviso y, al reenviar, la validación corre otra vez.
• Evaluación (MS-06) no responde durante la Validación automática. La tarea sigue abierta y MS-02 reintenta con espera creciente; el proveedor ve «Enviada, en validación». A las 4 horas sin respuesta, la tarea pasa a la cola de Gobierno de Datos para revisarla a mano.
• A una propuesta aceptada le falta un dato del candado del SKU. El plan de aceptar sale bloqueado con «te hacen falta estos datos»; no se pide el artículo a SAP. Si la descripción está vacía se recalcula; si aun así falta un dato maestro se abre Gobierno de Datos.

5. APIs

Las que construye esta épica (3)

{
  "step": "DATOS_BASICOS",
  "values": [
    {
      "attributeId": "MARCA",
      "code": "MARCA01"
    },
    {
      "attributeId": "TIPO_PRODUCTO_SAP",
      "code": "LICUADORA"
    },
    {
      "attributeId": "MODELO_COMERCIAL",
      "text": "LX-200"
    },
    {
      "attributeId": "ANCHO_SIN_EMPAQUE",
      "value": "21",
      "unit": "cm"
    },
    {
      "attributeId": "ANCHO_CON_EMPAQUE",
      "value": "19",
      "unit": "cm"
    },
    {
      "attributeId": "POTENCIA_W",
      "value": "6OO"
    },
    {
      "attributeId": "PRECIO_VENTA",
      "value": "899.00"
    },
    {
      "attributeId": "PRECIO_COMPRA",
      "value": "540.00"
    },
    {
      "attributeId": "INDICADOR_IMPUESTO",
      "code": "G5"
    }
  ]
}

{
  "success": true,
  "data": {
    "planId": null,
    "canApply": false,
    "sourceVersions": {
      "templateView": "EU4-0412@14",
      "rules": 31
    },
    "fieldErrors": [
      {
        "path": "/values/POTENCIA_W",
        "code": "NOT_A_NUMBER",
        "message": "Captura sólo números",
        "effect": "BLOCK"
      },
      {
        "path": "/values/ANCHO_CON_EMPAQUE",
        "code": "RULE_FAILED",
        "rule": "LOGISTICA-ANCHO",
        "message": "El ancho con empaque debe ser mayor que el ancho sin empaque",
        "fields": [
          "ANCHO_SIN_EMPAQUE",
          "ANCHO_CON_EMPAQUE"
        ],
        "effect": "BLOCK"
      }
    ],
    "missingInStep": [
      {
        "attributeId": "NUM_PROVEEDOR",
        "label": "Número de proveedor",
        "layer": "DATO_MAESTRO"
      }
    ],
    "warnings": [
      {
        "path": "/values/MODELO_COMERCIAL",
        "code": "TITLE_GENERIC",
        "message": "Tu título queda genérico: agrega la capacidad",
        "effect": "WARN"
      }
    ],
    "calculated": {
      "productName": "Licuadora MARCA01 LX-200",
      "titleWithoutBrand": "Licuadora LX-200",
      "MARGEN": {
        "value": "24.75",
        "unit": "%",
        "ruleId": "rul-000301"
      }
    },
    "stepComplete": false
  }
}

null

{
  "success": true,
  "data": {
    "productId": "PRD-0004812",
    "gate": "SUBMIT",
    "passes": false,
    "version": 9,
    "sections": [
      {
        "section": "DATOS_BASICOS",
        "step": 1,
        "ownerArea": "COMPRAS",
        "mandatory": {
          "present": 9,
          "total": 10
        },
        "missing": [
          {
            "attributeId": "NUM_PROVEEDOR",
            "label": "Número de proveedor",
            "layer": "DATO_MAESTRO"
          }
        ]
      },
      {
        "section": "VARIANTES_LOGISTICA",
        "step": 3,
        "ownerArea": "LOGISTICA",
        "mandatory": {
          "present": 12,
          "total": 12
        },
        "missing": []
      }
    ],
    "locks": [
      {
        "lock": "AL_MENOS_UNA_VARIANTE",
        "passes": true
      },
      {
        "lock": "IMAGEN_PRINCIPAL",
        "passes": false,
        "message": "Falta la imagen principal"
      }
    ],
    "message": "Te hacen falta estos datos: número de proveedor e imagen principal"
  }
}

{
  "items": [
    {
      "productId": "PRD-0004812",
      "version": 7
    },
    {
      "productId": "PRD-0004813",
      "version": 3
    }
  ],
  "attributeId": "GARANTIA_MESES",
  "op": "SET",
  "value": {
    "value": "12"
  },
  "onlyEmpty": true
}

{
  "success": true,
  "data": {
    "planId": "pln-0b3f55",
    "expiresAt": "2026-10-18T16:55:00Z",
    "summary": {
      "ok": 1,
      "skipped": 1,
      "blocked": 0
    },
    "items": [
      {
        "productId": "PRD-0004812",
        "result": "OK",
        "before": null,
        "after": "12"
      },
      {
        "productId": "PRD-0004813",
        "result": "SKIPPED",
        "reason": "Ya tiene valor y se pidió sólo vacíos"
      }
    ],
    "applyUrl": "/api/v2/product-plans/pln-0b3f55/apply"
  }
}

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.

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-RAC-01-1. Un solo motor de validación. Las reglas y la obligatoriedad las define Catálogo; las corre un mismo evaluador dentro de los planes de MS-02 en todas las puertas (captura, edición masiva, carga masiva y API de terceros), y Catálogo usa ese evaluador en su vista previa de calculados (API-01-203) cuando todavía no hay propuesta. No hay un servicio de validación aparte. Por qué: Las mismas reglas para todas las puertas, con un dueño por regla; ADR-12 responde PD-05 y DEC-PRD-08 ya ponía estas validaciones en catalog-product. MS-02 lee las reglas con caché, así que no depende de Catálogo en cada tecla. Se apoya en DEC-PRD-08, PD-05, ADR-12.
• D-RAC-01-2. La validación en el momento es el plan de valores (API-02-012): revisa sin escribir y responde errores por campo, lo que falta para cerrar el paso, avisos y calculados. Un valor inválido no se guarda; un obligatorio vacío sí deja guardar, pero no cerrar el paso ni enviar. Por qué: El error se ve en el campo donde se captura y no se acumula al final; guardar con faltantes permite saltar opcionales y regresar. Se apoya en RN-GEN-04, RF-CAL-03, RN-CAL-08.
• D-RAC-01-3. La Validación automática es una tarea real que atiende MS-02 al enviar: revalida la versión congelada, recalcula los calculados, pide al agente la categoría web y reevalúa en MS-06 si cambió el EAN, la marca o el modelo desde la identificación. Si pasa, abre Visto bueno de Compras (Mercaderías y Suburbia) o Calificación de IA (Marketplace); si falla, T04 con Corrección. Por qué: Lo que se capturó después de la identificación puede cambiar la identidad del producto, y el visto bueno sólo debe recibir propuestas completas. Se apoya en PD-29, RN-CAL-07, RN-CAT-08.
• D-RAC-01-4. Cuatro candados con nombre sobre el mismo motor: SUBMIT (enviar), SKU (pedir el artículo), SAP (armar los archivos) y PUBLISH (aprobar). El del SKU exige número de proveedor en Mercaderías, grupo de artículos, imagen principal, descripción y datos logísticos. Un dato de candado no se puede vaciar después de enviar por ninguna vía: plan, carga masiva o migración. Por qué: Hoy se pierden obligatorios entre la aprobación y el envío (los ~200 SKU de Esfera); el candado como red de seguridad en cada salida evita que vuelva a pasar. Se apoya en RF-CAL-05, RN-ALT-04, DEC-71.
• D-RAC-01-5. Cada regla trae su efecto por negocio (bloquea o avisa) en Catálogo. Lo que avisa se guarda con una nota y baja el score, sin cola manual de QA. Arranque: Mercaderías y Suburbia bloquean lo de creación; Marketplace bloquea lo que SAP exige y avisa lo demás. Por qué: La política por negocio sigue abierta; este arranque no frena al seller más de lo que SAP exige y conserva el control de Mercaderías. Se apoya en PEN-03, RF-CAL-04, RN-CAL-07.
• D-RAC-01-6. Las validaciones de CreateProposal (coherencia logística, proveedor válido para catalogar, avance de P1 a P2, campos de PP33) se reimplementan en código de MS-02 con parámetros de los diccionarios de Catálogo, y se prueban contra una muestra de 1,000 productos antes del corte. Por qué: Paridad con lo que hoy valida P360 mientras el lenguaje de reglas configurable llega después. Se apoya en DEC-PLT-08, DEC-PRD-08.
• D-RAC-01-7. Lo migrado no se bloquea por obligatorios nuevos: los candados aplican a lo que se crea o se edita. Un migrado que se edita ve los obligatorios nuevos como aviso hasta que Gobierno de Producto los vuelva bloqueo. Por qué: Endurecer la salida de golpe bloquearía productos que hoy se venden; la salida no debe exigir más que P360. Se apoya en RF-MIG-02, RSG-01.
• D-RAC-01-8. Los motivos que ve el seller después (por qué un SKU no se creó o no se ve, API-02-303 de FT-RAC-05) salen del mismo veredicto del motor: hay una sola lista de reglas. Por qué: Si el motivo visible y el candado se calcularan por separado, dirían cosas distintas. Se apoya en RF-PUB-09, FT-RAC-05.

Qué falta decidir

Nada propio de esta épica: lo que sigue abierto está en las decisiones del programa.

También siguen abiertos: PEN-01, Firmar con negocio y sistemas las listas de obligatorios por negocio y por destino que alimentan la vista efectiva; PEN-03, Ratificar la política por negocio (prevenir antes o corregir después); aquí arranca como en D-RAC-01-5; PEN-70, Encontrar la causa de la pérdida de obligatorios entre aprobación y envío, para probar que el candado la cubre; PEN-63, Depurar la matriz de validaciones de MM41 que se replica como candado de SAP.

Fuentes

1. [D] trazabilidad/features/FT-RAC-01-motor-de-validacion-en-linea.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.