FT-MIG-03 · Migración inicial de productos desde P360

En 30 segundos

Los cerca de 3.4 millones de productos vivos de P360 tienen que pasar al Nuevo PIM sin perder nada y sin bloquear lo que hoy se vende. Esta épica los extrae de P360, arma cada familia con sus variantes, valores, imágenes y clasificaciones, la carga en Producto con su estado y su estado por canal, manda a cuarentena lo dudoso y concilia todo contra P360 antes de firmar.

• Módulo dueño: MS-03 Migración y convivencia. También participan: MS-02 Producto, MS-05 Auditoría, MS-08 Adaptadores de salida, MS-11 Activos digitales, MS-12 Estudio fotográfico.
• Etapa M · Migración. Recibe «PE-C · Catálogo vigente» y entrega «PE-M · Producto migrado».
• APIs: construye 3 y usa 11 que construyen otras épicas.
• Eventos: publica 0 y consume 0.

1. Dónde encaja

Recibe

Entrega

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 Piloto de 10,000 familias

3.2 Cuarentena y liberación

3.3 Lo publicable igual que en la tienda

4. Si algo sale mal

• Dos productos del mismo negocio tienen el mismo EAN. El segundo no se carga como vivo: entra en cuarentena por choque de EAN junto con el primero y Gobierno de Producto decide quién conserva el código; al corregirlo en P360 se libera.
• Un genérico no tiene plantilla. Se carga con la marca de cuarentena: no se publica ni se ofrece como aprobable hasta que Gobierno de Producto le asigne plantilla.
• Un artículo no tiene padre o tiene varios. No forma un documento válido: va completo a las incidencias con sus filas de origen y el equipo de migración corrige el mapeo y lo vuelve a cargar.
• La extracción mide menos de 30 millones de filas por hora. Se pide al DBA una tabla plana nocturna o más lectores en paralelo, y la carga se parte en dos noches por rangos de ID.
• Una familia que hoy sale quedaría bloqueada por una regla. La conciliación de salida lista la regla que la bloquea; ninguna familia con envíos registrados puede quedar en cuarentena sin decisión antes de firmar.

5. APIs

Las que construye esta épica (3)

null

{
  "success": true,
  "data": {
    "items": [
      {
        "id": "qr-1033301-EAN_COLLISION",
        "productId": "PRD-0004812",
        "legacy": {
          "system": "P360",
          "identifier": "1033301"
        },
        "code": "EAN_COLLISION",
        "detail": "El EAN 7501234567909 también lo tiene la familia 1033412 en MER",
        "releasedBy": "GOBIERNO_DE_PRODUCTO",
        "hasDeliveries": true,
        "runId": "run-prd-e1-0003",
        "detectedAt": "2026-11-28T03:22:15Z",
        "status": "OPEN"
      }
    ],
    "page": 1,
    "size": 50,
    "total": 1
  }
}

{
  "action": "REVALIDATE",
  "reason": "Gobierno de Producto dejó el EAN en la familia 1033301 y lo quitó de la 1033412 en P360",
  "approvalRef": "TCK-0421"
}

{
  "success": true,
  "data": {
    "requestId": "req-qr-0071",
    "status": "ACCEPTED",
    "receiptUrl": "/api/v2/migration/quarantine?id=qr-1033301-EAN_COLLISION"
  }
}

null

{
  "success": true,
  "data": {
    "legacyId": "-4471",
    "system": "OMEGA",
    "table": "PRODUCTO",
    "identifier": "1033301",
    "productId": "PRD-0004812",
    "resolution": "P360_WINS",
    "owner": "P360",
    "firstSeenRun": "run-prd-e1-0003",
    "lastSeenRun": "run-prd-e3-0001"
  }
}

Las que usa y construye otra épica (11)

Su request y su response están en la página de la épica que la construye.

6. Eventos

Esta épica no publica ni consume eventos.

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-MIG-03-1. La fuente es el la base de P360 de P360, revisión 1 o nula y fila viva. Se extrae por rangos de ID a archivos cifrados de retención corta y cada familia (genérico con sus variantes) se arma como un solo documento. Por qué: Entrada Única no guarda los valores y la copia de Omega no es confiable; leer por rangos permite paralelo y reintento por rango. Se apoya en DEC-ARQ-06, DEC-PRD-05, DEC-PRD-09, RSG-43.
• D-MIG-03-2. Cada familia se carga con API-02-056: SKU y EAN en el registro de identificadores en la misma transacción, versión 1 con razón MIGRATION, estado por canal sembrado «en sincronía con legado» y sin eventos. La historia de estados va a Auditoría (API-05-006) y la de valores arranca en cero. Por qué: Publicar millones de altas que no son altas saturaría a los consumidores; sembrar el estado por canal evita republicar en el corte. Se apoya en DEC-PRD-04, DEC-PRD-06, DEC-ARQ-09, FT-ARQ-01.
• D-MIG-03-3. El ID del producto sigue la política de PD-16 (prefijo de negocio más el Identifier de P360, propuesta del 17-oct). El Identifier, el proposalId de P360 y los ID técnicos de Omega quedan como alias en el producto y en el mapa de MS-03 (API-03-006), nunca como llave. Por qué: Un ID estable con la llave de P360 deja seguir cada producto entre sistemas durante la convivencia. Se apoya en PD-16, DUD-18, DEC-PRD-01.
• D-MIG-03-4. La cuarentena es una marca en el producto: sin plantilla, sin negocio, tipo no previsto, choque de SKU o EAN y etiqueta sin código. Lo marcado no se publica ni se ofrece como aprobable, y se libera corrigiendo el dato en la fuente y revalidando (API-03-005), nunca apagando la marca. Por qué: El dato corregido queda bien para siempre y con traza; liberar con una bandera publicaría datos rotos. Se apoya en DMS-86, PD-19.
• D-MIG-03-5. Sin bloqueos nuevos: lo migrado se valida para salir con las reglas de salida de hoy y no con los obligatorios TO-BE. La conciliación de salida lista la regla que bloquearía a cada familia que hoy sale, y ninguna familia con envíos registrados queda en cuarentena sin decisión. Por qué: Lo que hoy se vende no puede dejar de venderse por migrarlo. Se apoya en RF-MIG-02, DEC-ARQ-12.
• D-MIG-03-6. Lo publicable igual: antes del corte, MS-08 arma sin mandar (API-08-005) el mensaje de un juego de referencia y MS-03 lo compara campo por campo con products y skus de la tienda; cada diferencia se atribuye al broker, al procesador o al PIM. Las fechas centinela no se propagan. Por qué: Es la única forma de saber que la tienda recibirá lo mismo sin el broker. Se apoya en PD-23, FT-INT-01.
• D-MIG-03-7. La carga completa de productos se hace antes de R2, cuando las pantallas de producto pasan al BFF. Desde ahí la convivencia (FT-MIG-04) mantiene la copia al día y las pantallas escriben en P360 por MS-03 hasta el corte de R3. Por qué: Las pantallas de R2 necesitan la copia completa desde su primer día, y P360 sigue siendo la fuente hasta R3. Se apoya en ADR-12, FT-MIG-04.
• D-MIG-03-8. Cada dato migrado va a su dueño: la familia a Producto, sus imágenes a Activos (API-11-016) sin copiar archivos ni cambiar URL, la decisión de tomar o no tomar al Estudio (API-12-013) como valor de su lista, y la historia de estados a Auditoría. Lo que un dueño no puede aparear o traducir queda como incidencia de la corrida. Por qué: Una sola base con un dueño por colección: MS-03 no escribe datos de negocio, sólo los entrega a quien los guarda. Se apoya en ADR-12, FT-ACT-02, FT-ACT-05.

Qué falta decidir

También siguen abiertos: RSG-09, Conteo exacto del universo: las cifras de P360, del modelo y de la PAC no coinciden.

Fuentes

1. [D] trazabilidad/features/FT-MIG-03-migracion-inicial-de-productos.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.