La mayoría de los proyectos de conciliación empiezan con una diferencia sin explicar: el sell-out del retailer es inferior a los envíos del ERP, y la brecha es mayor en unos productos que en otros. Los equipos responden revisando los candidatos obvios y, en algún momento, alguien dice «también descartamos las filas cuyo SKU no reconocemos». Esa frase es donde vive el problema real, y normalmente termina ahí, porque un join interno ya ha hecho invisibles las filas descartadas.
Esta guía separa las dos cosas que se llaman «SKU que falta», muestra por qué un join interno oculta silenciosamente ventas válidas y monta las tres piezas de una solución que funciona: un control de detección que se ejecuta antes del join, un cascada de mapeo que resuelve los identificadores por orden de fiabilidad y una cola que da a cada producto sin resolver un responsable y una antigüedad.
Faltante y sin mapear son dos problemas
Un archivo de sell-out del retailer lleva un identificador de producto en cada fila. Cuando concilia ese archivo contra su ERP o su conjunto de datos de sell-out, el join se ejecuta sobre ese identificador, a través de una tabla de mapeo que conecta los códigos del retailer con los SKU internos. Las filas que no coinciden son «faltantes». La palabra oculta la distinción que decide la solución.
Un SKU faltante nunca aparece en el archivo. Una tienda no reportó, una categoría está ausente o falta una línea de producto en un periodo. Es un problema de cobertura: la población esperada está incompleta y ninguna lógica de join la recuperará, porque las filas nunca se entregaron. La solución está del lado del retailer o en la recepción del archivo, y se mide contra una población esperada, no contra su mapeo.
Un SKU sin mapear aparece en el archivo con un identificador que su maestro no puede interpretar. La fila está físicamente presente; el producto se vendió; solo que todavía no puede decir qué producto es. Es un problema de identidad y se arregla con la tabla de mapeo. Los dos se funden en un único recuento porque ambos aparecen en el mismo sitio —la salida del join—, pero fallan en etapas distintas. La cobertura falla en la recepción. La identidad falla en el mapeo.
Esto no es un ejercicio de terminología. Los dos problemas tienen evidencia, responsables y plazos distintos. La cobertura se arregla con el retailer o el proveedor de datos y puede llevar semanas. La identidad se arregla en su propio mapeo y puede llevar minutos. Si el informe dice «perdimos el 4% de las filas por SKU faltantes», nadie sabe de qué tipo se trata, así que nadie sabe quién debe actuar, y el número se repite cada mes con la misma ambigüedad.
Controles de detección antes del join
La razón por la que los SKU sin mapear sobreviven meses es que el join los borra. Un join interno devuelve solo las filas que coinciden, y la salida parece limpia: cada fila restante tiene un SKU, un valor y un nombre. Nadie puede saber por la salida que el 3% del valor del retailer desapareció en el join, y la conciliación «cuadra» contra un total que nunca fue el total real.
El control de detección es un recuento de filas y de valor que se ejecuta antes del join y escribe su resultado en el registro de la corrida. Divida el archivo entregado en tres estados: registros sin identificador de producto, registros cuyo identificador no está en el mapeo y registros que mapean correctamente. Cuente filas y valor en cada estado, por retailer y por periodo. Reporte el valor mapeado como proporción del valor entregado, no como proporción del valor esperado, para que la pérdida de cobertura y la de identidad se mantengan separadas.
| Estado | Qué significa | Dónde falla | Responsable |
|---|---|---|---|
| Sin identificador | Filas del archivo sin columna de producto o con el campo en blanco | Recepción y validación | Operaciones de datos |
| Sin mapear | Identificador presente pero ausente de la tabla de mapeo | Mapeo de producto | Datos maestros |
| Mapeado | El identificador resuelve a un SKU interno | Ninguno | Ninguno |
La salida del control es un número estable que se mueve. Cuando el valor mapeado como proporción del valor entregado sube de un mes a otro, el atraso se está reduciendo. Cuando se estanca, la cola no se está vaciando. Sin este número, «tenemos algunos SKU que faltan» es un estado de ánimo; con él, la conciliación tiene un control que cualquier regla del modelo operativo puede asumir. El control pertenece a la misma corrida que el resto de la conciliación, no a una investigación aparte que solo ocurre cuando alguien se queja.
La cascada de mapeo
Un identificador sin mapear se resuelve mediante una cascada, por orden de fiabilidad, y cada paso se registra para que la resolución pueda auditarse y reutilizarse. El primer intento es el código de artículo del retailer contra la tabla de mapeo. La mayoría de las filas se resuelve aquí, porque el mapeo ya existe. El segundo es el nombre del producto del retailer, la marca y la descripción de pack contra el maestro de producto, produciendo un candidato. El tercero es el EAN o GTIN impreso en la línea o resuelto mediante el catálogo de artículos del retailer. El último es la revisión humana, que o bien crea una entrada de mapeo nueva o clasifica el identificador como genuinamente desconocido.
Cada resultado recibe un estado, y el estado decide si la fila puede usarse. Mapeado significa que el identificador resuelve a un único SKU interno. Candidato significa una coincidencia probable que necesita confirmación humana antes de tratarse como ventas. Sin resolver significa que no se encontró nada plausible y la fila se envía a la cola. La distinción importa porque un candidato promovido a mapeado sin revisión es como una atribución de producto equivocada se vuelve permanente: las ventas caen sobre el SKU incorrecto y todas las tendencias posteriores quedan silenciosamente mal.
La cascada es la misma disciplina de emparejamiento que usa el resto de la conciliación, aplicada un nivel más abajo. También alimenta el propio mapeo: un código que resuelve al mismo SKU interno durante tres meses seguidos debería promoverse a entrada de mapeo permanente con una fecha de vigencia, para que el mes siguiente se resuelva en el paso uno en lugar del paso tres.
Los nuevos listados llegan antes que su maestro
La fuente más habitual de SKU sin mapear no es un error. Es un listado nuevo. Un producto nuevo, un pack exclusivo del retailer o una variante estacional entra en el surtido del retailer y empieza a venderse, y sus filas aparecen en el archivo de sell-out en el mismo periodo en que el producto se lanza. Su maestro de producto se construyó alrededor de su propio catálogo, y el mapeo entre un código nuevo del retailer y un SKU interno nuevo tiene que crearlo alguien. Hasta que lo hace, cada fila de ese producto está sin mapear.
El patrón es lo bastante predecible como para planificarlo. Los listados nuevos tienen una ventana conocida: la fecha de listado del retailer, el primer archivo de sell-out esperado y el día en que se crea la entrada del maestro o del mapeo. El hueco entre la primera y la última de esas fechas es donde desaparecen ventas válidas. La solución no es perseguir cada código nuevo después del hecho, sino tratar un listado nuevo como un evento con una fecha límite: la entrada de mapeo se crea antes del primer archivo que la contendrá, aunque el estado sea «pendiente de maestro» hasta que se confirme el dato de producto.
Aquí también entran en juego las reglas de identificación de GS1. Un producto nuevo recibe un GTIN nuevo, y un cambio de contenido neto, de configuración de pack o de marca principal también exige un GTIN nuevo. Esos son los cambios de producto que producen identificadores nuevos en los archivos del retailer. Son eventos comerciales normales, no anomalías de datos, y la tubería de conciliación debe absorberlos con un calendario en lugar de redescubrirlos cada mes.
Los productos discontinuados siguen vendiendo
La otra fuente recurrente es la contraria a un listado. Un SKU se discontinúa, se retira de su maestro o se filtra del reporting, pero el retailer sigue vendiendo las existencias que le quedan y el archivo sigue trayendo el código antiguo. Son ventas válidas que acabarán en el cubo de sin mapear si la entrada de mapeo se eliminó cuando el producto se retiró.
Los productos discontinuados deben retirarse, no borrarse. La entrada de mapeo conserva su identificador, el SKU interno y un estado de fin de vida, y sigue siendo válida mientras el retailer continúe reportándola. La capa de reporting decide si las ventas de un SKU retirado aparecen en el rendimiento actual o se marcan como venta de existencias; la capa de conciliación solo necesita que el mapeo siga funcionando para que las filas no se pierdan. La consecuencia de borrar la entrada es que las ventas residuales de un producto discontinuado se vuelven sin mapear, y el valor residual de una línea discontinuada es exactamente el valor que nadie está vigilando.
La misma regla aplica a un cambio de pack que reutiliza un nombre conocido. Cuando el código del retailer cambia porque cambió el tamaño del pack, el código antiguo y el nuevo son dos identificadores de productos adyacentes, no un producto con una errata. El mapeo a nivel de pack mantiene los dos separados para que el historial de ventas no se mezcle a través de un cambio que tiene una fecha real.
La cola es el proceso
Un identificador sin mapear es un elemento de cola, no un tema de reunión. La cola contiene una fila por identificador sin resolver, con el retailer fuente, el primer y último periodo vistos, el estado de resolución, el responsable y la antigüedad en periodos. Cada elemento se resuelve, se empareja con un SKU y una entrada de mapeo, o se clasifica explícitamente como irrecuperable con una razón documentada. Los elementos con más antigüedad que un umbral definido se escalan, y la cola se revisa con la misma cadencia que la corrida de conciliación.
La cola cambia cómo se discute el problema. En lugar de «tenemos otra vez códigos desconocidos», la corrida produce: diez identificadores nuevos este mes, tres resueltos por la cascada, seis son listados nuevos a la espera de confirmación del maestro y uno es genuinamente desconocido y se está escalando al retailer. Cada una de esas frases describe una acción y un responsable distintos. Esa es la diferencia entre un proceso de excepciones y una bandeja de entrada.
La cola también detecta regresiones. Si un identificador se resolvió y se mapeó hace tres meses y reaparece como sin mapear este mes, no es un problema nuevo; es un mapeo sobrescrito, una tabla de mapeo reconstruida o un archivo que cambió de campo de identificador. El ciclo de vida de excepciones que gestiona las diferencias de conciliación aplica aquí también, con los mismos requisitos de evidencia y la misma regla: un elemento resuelto que vuelve se trata como un defecto del proceso, no como mala suerte.
Por qué vuelven los mismos códigos
El lado de producto de la conciliación retail falla por razones estructurales, y ninguna es exótica. Proveedores y retailers mantienen los datos de producto por separado, y el registro de artículo del retailer cambia cuando cambia su propio catálogo. Los problemas de calidad del maestro de producto en FMCG están bien documentados en ambos lados de la relación: un estudio de dos empresas de distribución y retail FMCG encontró que la calidad del maestro de producto tenía un efecto significativo en el rendimiento de los procesos logísticos, y una encuesta sobre el mismo tema encontró que las empresas eran conscientes de la importancia de la calidad del dato de producto pero rara vez usaban los procedimientos estandarizados que existen para mantenerla.
La implicación es directa. Los SKU sin mapear no dejarán de aparecer, porque el mundo comercial sigue produciendo identificadores nuevos, listados nuevos, relanzamientos y cambios de pack. Lo que puede arreglarse es la respuesta: un control de detección que los cuenta, una cascada que los resuelve, una cola que mide su antigüedad y un mapeo que trata un código del retailer como un registro duradero y no como algo desechable. Cuando esas cuatro existen, el número de conciliación incluye todo lo que el retailer reportó, y la discusión sobre «SKU que faltan» deja de tratar de por qué el archivo está incompleto y empieza a tratar de qué cambio de producto necesita una entrada de mapeo esta semana.
Un límite aplica. Un mapeo bien gestionado no puede recuperar un archivo que nunca se entregó, y no puede inventar productos que nunca se enviaron. La solución de identidad protege las filas que llegaron; la solución de cobertura protege las filas que deberían haber llegado. Ejecutar solo una deja el mismo agujero, solo que en el otro lado del join.
Dónde suelen desaparecer los SKU sin mapearLas filas las descarta un join interno antes de que nadie las cuente, así que la diferencia se atribuye a «productos desconocidos» y nunca se descompone. El primer paso es un registro de corrida que cuente el valor mapeado frente al valor entregado antes de que corra el join, separando la pérdida de cobertura de la de identidad.
- Mapeo SKU-EAN y GTIN para equipos FMCG
- Cómo conciliar los datos de sell-out del retailer con el ERP
- Cómo crear un conjunto de datos de sell-out FMCG fiable
- Cómo diseñar reglas de conciliación de datos reutilizables
- Vea un caso ilustrativo de conciliación de datos FMCG
- Explore el mapeo e integración de datos
- Explore la auditoría y estandarización de datos
Preguntas frecuentes
¿Cuál es la diferencia entre un SKU faltante y un SKU sin mapear?
Un SKU faltante nunca aparece en el archivo del retailer, por lo que el problema es de cobertura: falta una tienda, un periodo o una línea de producto. Un SKU sin mapear aparece en el archivo pero su identificador no puede vincularse con su maestro de producto, por lo que el problema es de identidad. Los dos tienen causas, soluciones y responsables distintos, y nunca deberían reportarse como un único número.
¿Cómo detecto los SKU sin mapear antes de que un join los descarte?
Cuente filas y valor en tres estados antes del join: registros sin identificador de producto, registros cuyo identificador no está en el mapeo y registros que mapean correctamente. Reporte el valor mapeado como proporción del valor entregado por retailer y periodo. Un join interno que descarta filas sin coincidencia hace invisible el problema; el control de detección tiene que ejecutarse antes del join.
¿Por qué los SKU sin mapear vuelven a aparecer cada mes?
Porque las causas son eventos, no errores: los nuevos listados llegan al archivo del retailer antes de que se actualicen su maestro y su mapeo, los cambios de pack y de contenido neto crean identificadores nuevos, y los productos discontinuados siguen vendiendo existencias antiguas. Cada uno es un evento previsto con una ventana conocida. La cola debe esperarlos y medir su antigüedad, en lugar de tratar cada reaparición como un problema nuevo.
Fuentes
- GS1, Número Global de Artículo Comercial (GTIN).
- SPS Commerce, Why Supplier Item Data Failures Cascade and What They Cost Retailers.
- MDPI, Impact of the Product Master Data Quality on the Logistics Process Performance.
Las reglas de identificación de GS1 se citan para indicar cuándo los productos nuevos o modificados reciben identificadores nuevos. El material de SPS Commerce y MDPI se cita por los efectos documentados del dato de producto incompleto en las cadenas de suministro de retail y FMCG. Esta guía no afirma un porcentaje concreto de archivos de retailer afectados por SKU sin mapear, porque las fuentes no ofrecen una base verificable para esa cifra.