Arquitectura de la etapa 3 · Captura

En 30 segundos

• Recibe «PE-3 · Plantilla asignada» y entrega «PE-4 · Propuesta enviada».
• 7 épicas, en el orden en que conviene construirlas: FT-PLT-07, FT-RAC-01, FT-PLT-08, FT-PRD-03, FT-PRD-07, FT-IA-01, FT-IA-03.
• Cambios de estado de esta etapa: T03.

Cómo se pasan el producto

Las épicas

FT-PLT-07 · Reglas de atributos

Muchas reglas de hoy están escondidas en el código de P360: la talla normalizada, el envase, el impuesto y los datos maestros que exige SAP. Esta épica las vuelve reglas explícitas de Catálogo, con versión, vigencia y prueba previa, para que el sistema calcule lo que el proveedor no debe capturar y bloquee lo incoherente al guardar, igual en pantalla, en archivo o por API.

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

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.

FT-PLT-08 · Títulos, nombres y descripciones de producto

El título del producto se arma solo con la regla de su plantilla, igual que en P360, para que el cambio de sistema no mueva los nombres publicados. Esta épica calcula el título, el título sin marca y la descripción en el mismo momento en que cambia un dato que los forma, los recalcula sin esperar en la cola general cuando cambia la regla, arma el nombre completo de los configurables y ofrece al seller sugerencias de título con IA.

FT-PRD-03 · EAN

Un EAN (el código de barras) no puede repetirse dentro de un negocio, y hoy el proveedor se entera tarde y libera un EAN ocupado con tickets y formularios. Esta épica revisa el EAN en cuanto se captura (formato, dígito verificador, tipo y si ya existe), dice qué hacer si ya está en otro negocio, lleva la liberación dentro del PIM con su estado a la vista y deja cambiar de negocio a un producto sin perder su historia.

FT-PRD-07 · Captura guiada por pasos con los mínimos primero

Capturar un producto hoy mezcla lo opcional con lo obligatorio y parte de la plantilla completa. Esta épica divide la captura en cinco pasos, cada uno con un área dueña: el primero pide sólo los obligatorios del negocio, los opcionales se saltan y se retoman, el avance se ve por sección y todo se guarda en la propuesta, nunca en la pantalla. Al final el proveedor o seller envía y la propuesta pasa a la Validación automática.

FT-IA-01 · Prellenado con IA y validación obligatoria del usuario

Capturar a mano una plantilla de hasta 50 atributos es lento, y lo que el seller ya publica en su página no debería recapturarse. Esta épica propone valores con IA a partir de la URL, la imagen o un producto del catálogo y los muestra aparte, como sugerencias. El usuario confirma, corrige o quita cada uno antes de avanzar: nada sugerido llega al SKU sin que una persona lo confirme, y queda registrado qué propuso la IA y qué se aceptó.

FT-IA-03 · Enriquecimiento de atributos opcionales con IA y política…

Liverpool quiere productos completos, pero al seller le interesan menos los atributos opcionales y correr la IA sobre millones de SKU cuesta. Esta épica deja que el seller pida a la IA valores para un bloque opcional (sólo con los obligatorios completos) y que Gobierno de Producto marque qué atributos puede llenar la IA, cuáles necesita como contexto y cuáles se persiguen. También fija hasta cuándo se enriquece en automático.

Fuentes

1. [D] docs/arquitectura/por-epica/base/hilo.json: las etapas y los puntos de encuentro.
2. [D] docs/arquitectura/por-epica/epicas/: la arquitectura de cada épica.