Los estatus del producto en el TO-BE, a detalle

Qué responde

Por qué hoy hay tantos estatus, cuáles quedan en el TO-BE y cómo se ve cada uno desde el portal del proveedor, desde la API de catalogación y desde los sistemas que todavía leen el código de P360.

Para quién

Producto, Negocio y Arquitectura, y los equipos de Entrada Única, Foro, Marketplace e integraciones.

Estado

Propuesta. El modelo de tres capas se eligió el 16-oct como propuesta para validar (PD-29), y la API de catalogación es una propuesta del mismo día. Lo de hoy sale del código, de la base de P360 y de los talleres.

Marcas

Hoy lo que hace hoy el sistema · Propuesta no está acordado · Por decidir sigue abierto · Inferido lo deduje al armar esta página; ninguna fuente lo dice así.

1. En 30 segundos

• Hoy hay muchos porque todo vive en un solo campo. P360 tiene 28 códigos de estatus y 239 transiciones, y cada producto lleva tres estatus a la vez: el interno, el que ve el proveedor y el previo. Entrada Única suma 10 estados propios y 6 pasos de Foro por variante. P360 copió como estatus los pasos de STEP y les sumó uno por cada tipo de rechazo.
• En el TO-BE se separan en tres capas Propuesta: un ciclo de vida de 7 estados; 14 tipos de tarea por área, que dicen quién tiene el producto y por qué; y un estado por canal (Pendiente, Enviado, Publicado, Error y Retirado) en cada uno de los 5 destinos.
• Cada quien ve una vista de esas capas, sacada de una sola tabla. El proveedor o seller ve 10 etiquetas en el portal. El sistema de un tercero recibe 14 códigos por la API y 17 tipos de aviso. Mientras convivan los sistemas, Entrada Única, Foro y los reportes reciben el código de P360 equivalente.
• No se pierde nada. Cada uno de los 28 códigos tiene a dónde ir. Un rechazo deja de ser un estatus y abre una tarea de corrección, con origen, motivo por campo y plazo. El área queda en la tarea, y la entrega a cada destino, en el estado del canal. Los códigos que nadie escribe hoy no se emiten.
• Sigue abierto: validar el modelo (PD-29), cuándo queda «Aprobado», si Category se conserva, el plazo para cancelar un rechazo, qué frena el score de Marketplace y quién lee hoy 1007 como «ya publicado».

2. Cómo leer esta página: tres capas y cuatro vistas

Hoy un solo campo, el estatus, tiene que decir a la vez en qué momento va el producto, quién debe actuar, por qué se lo regresaron y si ya llegó a la tienda. Por eso se multiplican los códigos. La propuesta separa esas preguntas.

Las cuatro vistas salen de esas capas: el portal (§7), la API (§8), el código de P360 equivalente (§9) y la bandeja de cada perfil (§5). Aparte quedan los datos de cada variante (§10) y otros objetos que no son el producto pero también tienen estado, como el lote o el aviso (§11).

El estado previo de P360 desaparece como parte de la llave. Lo que hoy se deduce de él, como quién rechazó o de dónde viene el producto, viaja como dato dentro de la tarea.

3. Hoy: por qué hay tantos estatus Hoy

3.1 Los 28 códigos de P360

3.2 Tres estatus a la vez: interno, externo y previo

• Interno es el real; externo, lo que ve el proveedor; previo, el anterior. P360 los escribe en el producto y en cada variante, y Entrada Única los guarda aparte.
• El externo sale de un diccionario, ExternalStatus, que tiene 22 renglones: uno por código interno. Nunca se ha volcado completo; sólo se conocen 5 renglones: 1002 y 1021 se ven como «En proceso Liverpool», 1003 como «En revisión», 1006 como «Por actualizar» y 10031 como «Borrador». Si un código no tiene renglón, se ve «Borrador».
• Entrada Única corrige el externo por su cuenta. Con el interno 1002 lo fuerza a «Pendiente Inicio Liverpool» (RC-EUP-027). En Rechazo QA y Revisión QA, si el producto lo enriqueció Foro, el proveedor ve «En proceso Liverpool»; si no, Rechazo QA se ve «Rechazada». Lo que no reconoce lo guarda como «Status Desconocido» (RC-EUP-026).

Por eso lo que se ve no siempre coincide con el interno. Las combinaciones reales, contadas en agosto de 2026 sobre unos 1.7 millones de productos de P360, fueron estas:

3.3 Lo que sólo existe en Entrada Única

3.4 Cómo se llegó a tantos

• P360 copió los pasos de STEP como estatus. STEP, el PIM anterior, tenía 19 pasos en el alta y 12 en la modificación, en dos flujos, y uno más de Foro. Cada paso era la bandeja de un equipo. La migración tradujo cada paso a un estatus (RC-P3A-036), y quien trabajó en STEP lo confirma: P360 «conserva el orden, pero como estados».
• Le sumó un estatus por cada rechazo: 1005, 1027, 1028, 1029 y 1030, aunque quién corrige ya lo dice el rol al que se manda.
• Una llave de cuatro partes (estado previo, actual, acción y rol) que da 239 renglones, y tres mecanismos que se pisan: la tabla, las rutas fijas del cliente de P360 y los movimientos automáticos.
• Alta, Foro, publicación y modificación en el mismo campo. STEP los tenía en flujos distintos.
• Estados muertos: 1010, 1011, 1024, 1025 y 1032, y los de prepropuestas mezclados en el alta.
• Dos revisiones humanas en serie al final: QA y Category concentran el 94 % de los movimientos.
• La API de hoy, el XML de Marketplace, responde «received» antes de cargar y crea el producto directo en 1020, sin borrador (RC-P3A-044 a RC-P3A-047). No se sabe quién la usa.

3.5 Lo que piden los talleres

• «Soportar los estados del producto que hoy existen, al menos Inicio, Borrador, En revisión (en proceso de envío), Revisión de compras y Cancelada» (S26-RF-14).
• Los perfiles proveedor, compras, PLM, Foro Fotográfico y gobierno de datos (S26-RF-13).
• «Enviado» cuando el PIM publica el mensaje y «Publicado» cuando llega el acuse; el publicador no espera a que el destino termine (S26-RF-02, S26-RF-03 y RN-PUB-09, acordado).
• Colas de trabajo por etapa, con asignación a persona (RF-CAL-15).
• Pedir el SKU sólo desde los estados autorizados y guardar el estado de cada SKU (RF-ALT-11).
• «Procede / no procede» por variante, según tenga imagen principal (RF-PUB-12).
• El estatus «en Foro» visible, para bloquear la edición (RF-INT-08).
• Rechazo con motivo por campo, avisos y vencimiento (RF-ALT-06).
• Una vista amigable del avance para el proveedor: en qué paso está, qué le falta y por qué lo rechazaron (RF-REP-01).

4. Capa 1 · El ciclo de vida: 7 estados Propuesta

Las 14 transiciones

• Un producto aprobado no se cancela: se retira de cada canal (§6). Hoy se puede cancelar desde cualquier estado (RC-P3B-043).
• Por API no hay borradores Propuesta: la validación previa ocupa su lugar y lo que se manda entra como enviado. Así no se acumulan borradores que nadie depura.

5. Capa 2 · Las tareas por área: 14 tipos Propuesta

Cada tarea es la bandeja de un perfil y la cola con asignación que piden los talleres (RF-CAL-15). Guarda quién la abrió, por qué (motivo tipificado y observaciones por campo), a quién está asignada, cuándo vence y a qué tarea regresa el producto cuando se cierra. La propuesta no les pone nombre de estado a las tareas: guarda esos datos.

Después del SKU, varias tareas a la vez

Los pasos de Foro, por variante

Hoy Entrada Única guarda un estado de Foro por variante, aparte del de P360: Recepción, Logística Entrada, Fotografía, Edición, Enriquecimiento y Validación. En la propuesta del backend compartido, ese avance pasa a ser el de la tarea del área Foro, y la operación física del estudio (entrada de muestras, toma y salida) vive en un servicio propio, Estudio. Ninguno de esos pasos es un estado del producto. Propuesta

Los perfiles son permisos, no estados

Un perfil no crea estatus: decide qué tareas ve en su bandeja, qué puede hacer en ellas y qué campos puede cambiar. La matriz firmada de quién ve y edita qué sigue pendiente con Negocio y Seguridad (DUD-22).

6. Capa 3 · La publicación por canal Propuesta

• «Publicado» no quiere decir que ya se vea en la tienda. El acuse sólo dice que el destino leyó el mensaje. Si Negocio necesita saber que ya se ve, hace falta un aviso del destino.
• Hoy el orden es el inverso: 1007 se marca sólo cuando los canales confirman (RC-P3P-025). En el TO-BE el producto queda Aprobado al cerrar calidad, y la entrega va aparte (decisión 14 del backend compartido).
• El resumen para el usuario puede ser, por ejemplo, «Aprobado · publicado en 4 de 5 destinos».
• Por dentro, el resultado de cada entrega llega como ACCEPTED, FAILED o UNCERTAIN.
• La API sólo muestra los canales de venta, la tienda y Mirakl, con PENDING, SENT, PUBLISHED, FAILED y RETIRED. OMS, Señalización y DWH son internos. Propuesta
• «Procede / no procede» sigue siendo un dato de cada variante: sin imagen principal, la variante no viaja (§10).

7. La tabla de traducción: lo que ve cada quien Propuesta

Con el estado del ciclo de vida y la tarea abierta, una sola tabla da la etiqueta del portal, el código de la API y el código de P360 equivalente. Si hay varias tareas abiertas, gana la que le pide algo al proveedor: primero Corrección, luego Carga de imagen, luego En proceso Liverpool y al final En revisión. Conviene que el portal y la API saquen su etiqueta de esta misma tabla.

Las 10 etiquetas del portal

Borrador · Rechazada · En revisión · Revisión de compras · En proceso Liverpool · Carga de imagen · Aprobada (con el detalle por canal) · Modificación · Por actualizar · Cancelada.

• Salen dos que hoy se ven: «Pendiente Inicio Liverpool» pasa a «En proceso Liverpool», y «Status Desconocido» desaparece.
• Entra una que hoy no se ve: «Revisión de compras», que piden los talleres (S26-RF-14); hoy ese momento se ve como «En revisión».
• Mientras Foro trabaja, el proveedor sólo consulta su producto (RF-INT-08).
• Lo que pide S26-RF-14 («Inicio, Borrador, En revisión, Revisión de compras y Cancelada») se lee aquí como nombres visibles que salen de la tabla, no como estados internos que haya que conservar. Falta validarlo con quien lo pidió. Por decidir

8. Lo que devuelve la API de catalogación Propuesta

Es para los sistemas de proveedores y sellers que catalogan por API. La API usa 14 códigos en inglés, cada uno con su etiqueta en español. Al visto bueno no lo llama «Aprobada», para no confundirlo con 1007, que hoy es el estado final. El estado para terceros se calcula en el motor de estados (MS-02): la tabla de estados suma una columna con el código para terceros, y cada cambio de estado lo trae junto con el plazo para corregir. Un estado interno sin renglón hace fallar las pruebas de contrato.

8.1 El envío

8.2 La propuesta y el producto

8.3 Los 14 códigos

• No se exponen 1010, 1011, 1024, 1032 ni las prepropuestas (2001 a 2003): casi no se usan o son de otro canal.
• Qué frena el score de Marketplace (PD-24): se propone que antes del SKU sólo frene lo mínimo y salga como CORRECTION_REQUIRED antes de ACCEPTED; la calidad del contenido saldría como CORRECTION_REQUIRED después de SKU_CREATED y frenaría sólo la publicación. El contrato no cambia si se decide otra cosa: sólo cambia en qué momento sale. Por decidir
• El plazo para corregir (correctionDueAt) vale vacío mientras el plazo del negocio no tenga valor (PEN-211).
• La respuesta en línea del envío individual depende de los tiempos de los servicios de producto y de evaluación, que no se han medido. Si la prueba de carga da tiempos altos, también pasa a procesarse en segundo plano. Por decidir

8.4 Los 17 avisos

Cada cambio le llega al tercero por un aviso (webhook) firmado, y también lo puede consultar en un historial de los últimos 30 días.

Cómo se entregan: con firma, al menos una vez (el tercero descarta repetidos por su identificador y los ordena por versión), esperando respuesta en 10 segundos y reintentando con espera creciente de un minuto hasta 24 horas, unos diez intentos. Después, la entrega queda fallida y el aviso sigue en el historial.

9. Cada estatus de hoy y a dónde va

Sirve en los dos sentidos. Para migrar, cada producto entra con el estado y las tareas de su renglón. Para convivir, el nuevo PIM calcula el código de P360 equivalente mientras Entrada Única, Foro y los reportes lo sigan leyendo. Se propone guardarla como un dato versionado del motor de estados, con fecha de apagado cuando el último consumidor deje de leer el código (decisión 17 del backend compartido). Propuesta

10. Lo que va por variante

La propuesta de máquina de estados no le da a la variante un ciclo de vida propio. Pero hay datos de cada variante que funcionan como estatus y se conservan:

11. Otros objetos que también tienen estado

No son estados del producto, pero aparecen en las mismas pantallas, en la API o en las integraciones, y conviene no confundirlos.

12. Qué cambia frente a hoy

1. Un rechazo no crea un estatus: abre una Corrección con origen, motivo por campo y plazo. Antes del SKU, el producto vuelve a Borrador, como se decidió el 5-oct.
2. Al corregir, el producto regresa a la tarea que lo rechazó, no siempre a Compras como en STEP. Sólo pasa por Compras si cambiaron campos de los que Compras es dueño.
3. «Aprobado» no espera a los canales: cada canal lleva su estado. Hoy 1007 se marca sólo cuando los canales confirman.
4. Un producto aprobado no se cancela: se retira de cada canal. Hoy se puede cancelar desde cualquier estado.
5. La modificación no regresa el producto a revisión: la tienda conserva lo publicado hasta que se aprueba el cambio.
6. Category deja de ser un paso obligatorio, si así se decide en P-37.
7. Foro, las secciones con dueño y Gobierno de Datos trabajan al mismo tiempo después del SKU.
8. Nada llega como «desconocido»: un estado interno sin renglón en la tabla tiene que fallar en las pruebas de contrato.
9. Por API no hay borradores: la validación previa ocupa su lugar, y lo que pasó con cada producto de un lote queda en el resultado de su renglón.

13. Lo que falta decidir

Las propuestas de la columna del medio son del 16-oct y no están ratificadas.

14. Contradicciones entre fuentes

1. «En proceso de envío». S26-RF-14 y los diagramas TO-BE llaman así al momento de enviar (1001). Hoy «En proceso de envío» es el 1011, que la tabla pone después de Category y que ningún código escribe. Mismo nombre, otro momento.
2. ¿Se aprueba antes o después de publicar? El 5-oct se decidió «aprobar y luego publicar por evento». El código de hoy publica primero y marca 1007 cuando los canales confirman, y el orden depende de qué versión del plugin de P360 esté instalada, que no se ha medido (RC-P3P-025).
3. ¿A dónde va el rechazo? El 5-oct se decidió que vuelva a Borrador. El discovery TO-BE del 14-oct conserva 1027, 1028 y 1029 como estados de rechazo.
4. El plazo del rechazo: el taller dijo 30 días (y RF-ALT-06, 30 días desde la última notificación), una nota del tablero 60 y el diagrama 90. Hoy ningún sistema lo cancela solo.
5. PLM: es un perfil en S26-RF-13, pero en el discovery TO-BE es un alta directa sin portal, que entra a la creación del SKU.
6. La IA dudosa: hoy manda a Gobierno de Datos (1021); en el TO-BE, si el score no alcanza, el producto regresa al seller. Son dos cosas distintas, datos maestros para SAP y calidad del contenido, y se conservan las dos.
7. Corregir por API: la propuesta funcional dice que corregir una propuesta responde VALIDATING, pero la arquitectura dejó VALIDATING sólo para lotes. Falta alinear esa respuesta. Lo encontré al armar esta página.
8. Lo que ve el proveedor con Compras: el discovery TO-BE lo muestra como «En revisión», y la propuesta de máquina de estados como «Revisión de compras», que es lo que pide el taller. Esta página y la vista general usan «Revisión de compras».

15. Glosario

Estatus interno

El real, con su código, que guarda P360.

Estatus externo

Lo que ve el proveedor; hoy sale del diccionario ExternalStatus.

Estatus previo

El anterior; hoy es parte de la llave que decide el siguiente.

Ciclo de vida

La capa 1: en qué momento de su vida está el producto.

Tarea

Un trabajo pendiente de un área, con responsable, motivo, plazo y a dónde regresa el producto al cerrarse.

Bandeja

La vista de las tareas que le tocan a un perfil.

Corrección

La tarea que abre cualquier rechazo; la atiende el proveedor o seller.

Acuse

La confirmación de que el destino leyó el mensaje. No dice que ya terminó su trabajo.

122, 141 y 142

Las respuestas de SAP a la creación del artículo: el 122 trae el SKU y el 141, el error.

Envío y propuesta

En la API, el envío es lo que manda el tercero; la propuesta existe sólo si el envío pasó la identificación.

Aviso (webhook)

El mensaje firmado que el PIM le manda al sistema del tercero cuando algo cambia.

Procede / no procede

Si una variante viaja a la tienda, según tenga imagen principal.

Convivencia

El tiempo en que el nuevo PIM, P360, Entrada Única y Foro funcionan juntos y hay que traducir los estatus.

16. Fuentes

• Propuesta de máquina de estados del producto en el TO-BE (16-oct): §5 a §11, y la equivalencia de los 28 estatus.
• Propuesta de catalogación por API (16-oct): §4 (estados), §5.5 a §5.11 (lotes, ofertas, imágenes, estado e historial, modificaciones y avisos) y §8 (contradicciones).
• Arquitectura de la catalogación por API (16-oct): los contratos que cambian y el modelo de datos.
• Decisiones propuestas del backend compartido (16-oct): 11 y 13 a 18.
• Discovery TO-BE del flujo unificado: §6 (los estados de los diagramas), §12 (pendientes) y §13.1 y §13.2 (participantes y estatus).
• Módulo de flujos y estados (§3.1 y §3.2) y la página «Los estados de un producto hoy» (14-oct).
• Base de P360: el conteo de diccionarios del 2-oct (22 renglones en ExternalStatus, 5 conocidos), la tabla de transiciones extraída el 12-oct (239) y las combinaciones de agosto de 2026.
• Reglas leídas en el código: RC-EUP-026, RC-EUP-027, RC-EUP-038, RC-P3P-025, RC-P3B-043, RC-P3A-036, RC-P3A-044 a RC-P3A-047, RC-OMG-064 y RC-BRK-051.
• Talleres: S26-RF-02, S26-RF-03, S26-RF-13, S26-RF-14, RN-PUB-08, RN-PUB-09, RF-ALT-06, RF-ALT-11, RF-PUB-12, RF-INT-08, RF-CAL-15, RF-REP-01, S34-RF-06, S34-RF-07, S34-PEN-04, S36-RN-04 y S36-PEN-03.
• Decisiones y dudas: PD-02, PD-24, PD-29, P-01, P-05, P-22, P-28, P-37, DUD-22, DUD-24, DUD-36 y PEN-211.