Cada mercado, retailer y distribuidor envía su sell-out de forma distinta: archivos, códigos de producto, calendarios, unidades y niveles de detalle diferentes. Combinarlos en una sola hoja de cálculo produce totales que parecen limpios pero no se pueden explicar. Un conjunto de datos fiable es lo contrario: cada fila se traza hasta su fuente, cada corrección conserva su historial y cada hueco es visible como bandera o excepción, no como una celda en blanco silenciosa.
Esta guía define las ocho capas de ese conjunto de datos: el contrato de fuentes, el modelo canónico, los mapeos, los calendarios y las medidas, las banderas de calidad, el versionado, las excepciones y las capas de salida.
El contrato de fuentes
Empieza con un contrato escrito para cada fuente: qué archivo o feed llega, con qué frecuencia, en qué formato, con qué nivel de detalle, con qué columnas y unidades, y quién lo gestiona. El contrato define la cobertura esperada, como las tiendas o canales que el archivo declara representar. Una fuente que entrega fuera de su contrato es un evento de calidad de datos, no una sorpresa inesperada.
El contrato hace posible auditar el conjunto de datos. Cuando un total cambia entre ciclos, el contrato identifica si el cambio es un movimiento real, una nueva versión de archivo o un cambio de cobertura.
El modelo canónico
Define una única estructura canónica a la que toda fuente se convierte en la ingesta. Un registro de sell-out debe incluir la fuente, el retailer o distribuidor, el identificador de producto, la ubicación, el periodo, las unidades y el valor, y la información que lo hace trazable. Cada fuente aterriza con la misma forma, así las comparaciones y agregaciones se ejecutan sobre un modelo coherente en lugar de copias rehechas.
El modelo canónico es el contrato entre las fuentes y todos los informes. Cuando se incorpora un socio nuevo, el modelo no cambia; su archivo se mapea a él.
Plantilla de fila canónica
La siguiente fila ilustrativa separa lo que llegó de la fuente de lo que el conjunto de datos estandarizó o decidió. Estos campos permiten rastrear una cifra publicada hasta un archivo, un mapeo, una regla de período y los controles que permitieron que avanzara.
| Campo | Valor ilustrativo | Función en el conjunto de datos |
|---|---|---|
| Sistema o archivo de origen | Retailer ES-042 / sellout_2026-05_v3.csv | Identidad conservada de la fuente |
| Versión del archivo de origen | v3 | Marcador de revisión de la fuente |
| Mercado | ES | Dimensión de reporting estandarizada |
| Distribuidor o retailer | Retailer ES-042 | Parte de origen mapeada a la jerarquía de reporting |
| Código de producto de origen | 883221 | Identificador del socio conservado |
| ID de producto canónico | MX-2041 | Referencia de producto estandarizada |
| Ubicación o cliente | Tienda ES-042 / cliente CUST-042 | Relación entre la ubicación de origen y la estandarizada |
| Período o fecha de origen | Semana retail W14 | Período de reporting conservado de la fuente |
| Período canónico | 2026-04-01 a 2026-04-07 | Período estandarizado según el puente de calendario controlado |
| Unidad de medida | Unidad | Medida estandarizada después de las reglas de conversión |
| Cantidad | 1.240 | Valor numérico estandarizado con la cantidad de origen conservada en el linaje |
| Valor y moneda | 8.928 EUR netos | Definición de medida y moneda para el reporting |
| Linaje de origen | Archivo v3, filas 182–183 | Evidencia para reconstruir el registro |
| Indicador de cobertura | Conjunto esperado de tiendas incluido | Si el alcance de la fuente está representado |
| Indicador de completitud | Período recibido; cobertura de producto parcial | Si están presentes las dimensiones esperadas |
| Estado de validación | Controles estructurales y de negocio superados | Puerta antes de que la fila entre en el reporting |
| Estado de conciliación | Comparado a nivel producto-tienda-semana | Si la fila ha entrado en la comparación correspondiente |
| Estado de excepción | Abierta: revisión de cobertura de producto | Decisión pendiente visible |
| Marca temporal de registro o versión | 2026-06-03T09:15Z | Cuándo entró esta versión en el conjunto de datos controlado |
Mapeos
Mapea cada identificador de fuente a las referencias compartidas: el código de producto al SKU y al EAN o GTIN, la tienda o punto de venta a un maestro de ubicaciones, y el mercado a una geografía. Mantén los mapeos como tablas versionadas con fechas de vigencia y responsables, y haz visible cada registro no mapeado en lugar de descartarlo. Un producto no mapeado no es una ausencia de ventas; es una excepción que espera una decisión.
La misma disciplina aplica al mapeo de tiendas y mercados. Si dos fuentes llaman a la misma tienda de forma distinta, la tabla de mapeo es el único lugar donde se registra esa relación.
Calendarios y medidas
Define el calendario de reporting y las definiciones de medida antes de agregar. Un retailer puede reportar por semana retail mientras un distribuidor lo hace por mes natural; el conjunto de datos necesita un puente de calendario que asigne cada periodo de fuente al periodo de reporting compartido sin duplicar días. Declara las unidades que reporta cada fuente y conviértelas explícitamente, incluyendo conversiones de pack, caja y unidades.
Documenta qué medida representa cada columna, como unidades de sell-out, valor neto de devoluciones o bruto. Dos fuentes que llaman valor a una columna pueden significar cosas distintas; la regla de medida decide el significado compartido y la conversión.
Banderas de calidad
Lleva una evaluación de calidad en cada registro o bloque de registros en lugar de conservar solo las filas que parecen correctas. Señala la cobertura, como qué tiendas o canales representa un archivo; la completitud, como productos o periodos ausentes; y la validez, como precios poco plausibles o claves duplicadas. Las banderas viajan con los datos para que un informe pueda mostrar totales y las salvedades que los matizan.
Un total sin sus banderas es engañoso. Los informes pueden elegir mostrar el total completo, el total totalmente verificado, o ambos, y decir cuál están usando.
| Dimensión de completitud | Registro de control ilustrativo | Qué indica al responsable |
|---|---|---|
| Archivos esperados | 5 esperados / 5 recibidos | Si llegó cada envío de fuente |
| Tiendas o ubicaciones esperadas | 420 esperadas / 408 recibidas | Si el alcance observado cubre la red prevista |
| Cobertura de producto esperada | 1.180 productos activos / 1.146 observados | Si las filas de producto ausentes pueden afectar al total |
| Períodos o fechas esperados | 4 semanas retail / 4 recibidas | Si la ventana de reporting está completa |
| Cobertura esperada de volumen o valor | Base del contrato de fuentes registrada, sin umbral universal aplicado | Si existe una base válida para interpretar el total |
Estos campos son un modelo de control, no umbrales universales de aceptación. El contrato de fuentes y el uso del reporting deciden si un conjunto parcial de tiendas, productos o valores puede publicarse, ponerse en cuarentena o mostrarse con una salvedad.
Versionado
Versiona cada envío y conserva cada versión. Cuando llega un archivo corregido, registra la nueva versión, qué cambió y por qué, y reprocesa solo los periodos afectados. El conjunto de datos mantiene la trazabilidad de lo que la fuente reportó originalmente y a qué fue corregido. Los informes indican qué versión generó sus cifras.
No sobrescribas el histórico. La diferencia entre la versión original y la corregida suele ser el diagnóstico más útil que puede ofrecer el conjunto de datos.
Envíos tardíos y corregidos
| Situación del envío | Aceptar y conservar | Etapas que hay que repetir | Salida posterior | Firma y evidencia |
|---|---|---|---|---|
| Archivo nuevo recibido a tiempo | Aceptarlo como versión actual de la fuente | Validar, mapear y publicar | Salida del período actual | Recepción, versión y resultado de validación |
| Archivo tardío de un período abierto | Aceptarlo si lo permite el contrato de fuentes y conservar la hora de recepción | Validar y repetir el período afectado | Publicar o retener según la regla de completitud | Motivo del retraso, impacto de cobertura y responsable |
| Archivo corregido antes de publicar | Sustituir la entrada anterior, pero conservar ambas versiones | Repetir la validación, el mapeo y las salidas afectadas | Publicar solo la versión corregida | Motivo de la corrección y comparación de versiones |
| Archivo duplicado | Ponerlo en cuarentena salvo que sea explícitamente una versión nueva | No repetir etapas posteriores hasta clasificarlo | No sumar una contribución duplicada a los totales | Clave duplicada, hash del archivo o referencia de la fuente |
| Archivo que sustituye a otro después de publicar | Conservar la versión publicada y la que la sustituye | Repetir las etapas afectadas y conciliar la diferencia | Reexpresión versionada o vista actual anotada | Decisión de reexpresión y registro de aprobación |
| Corrección de un período publicado | Conservar los registros original y corregido | Repetir el período afectado, las métricas posteriores y la conciliación cuando corresponda | Reexpresar solo si la política y el impacto lo exigen | Totales antes y después, alcance del impacto y firma reabierta |
Excepciones
Envía a una cola de excepciones visible todo lo que el conjunto de datos no pueda clasificar: productos no mapeados, periodos ausentes, registros poco plausibles, archivos tardíos y huecos de cobertura. Cada excepción lleva una categoría, un responsable, un estado y una regla de antigüedad. La cola hace honesto al conjunto de datos, porque cada hueco conocido se nombra y se gestiona en lugar de absorberse en una celda en blanco.
Las excepciones recurrentes se convierten en trabajo de mejora: un mapeo nuevo, una fuente corregida, un cambio de contrato o una regla de validación nueva.
Capas de salida
Separa el conjunto de datos en capas para que cada consumidor lea la correcta. La capa bruta conserva los archivos de fuente tal como se reciben. La capa estándar tiene el modelo canónico con las banderas de calidad y los mapeos aplicados. La capa conciliada contiene la versión que ha superado los controles y ha cerrado sus excepciones. Y la capa de reporting presenta los totales con sus banderas. Quienes necesitan cifras auditadas usan la capa conciliada; los analistas que necesitan el detalle bruto usan la capa estándar.
Mantener las capas separadas evita que los informes mezclen en silencio fuentes, versiones y niveles de calidad.
Resumen práctico
Construye el conjunto de datos de sell-out en torno a la trazabilidad, no a la limpieza. Aplica un contrato de fuentes, aterriza cada fuente en un modelo canónico, mapea los identificadores con tablas versionadas, define calendarios y medidas explícitamente, lleva banderas de calidad, versiona las correcciones, gestiona una cola de excepciones visible y separa las capas de salida. Así, tu equipo dispone de una sola versión de sell-out que se puede defender, auditar y mejorar.
La operación gestionada de datos de Marksyte puede construir y operar este conjunto de datos entre retailers y distribuidores, y su servicio de estandarización de datos puede diseñar la capa de ingesta y validación.
Preguntas frecuentes
¿Qué hace fiable un conjunto de datos de sell-out FMCG?
Tiene un modelo canónico, un contrato de fuentes documentado, mapeos explícitos, reglas de calendario y medida, banderas de calidad, versionado para archivos corregidos y una cola de excepciones. Conserva las diferencias de las fuentes en lugar de ocultarlas.
¿Cómo se combinan los datos de sell-out de retailers y distribuidores?
Estandariza cada fuente en un único esquema canónico en la ingesta, mapea productos, tiendas y periodos a referencias compartidas, aplica reglas de calendario y medida, y conserva el linaje y las banderas de calidad en cada fila.
¿Cómo se gestionan los archivos de sell-out corregidos?
Versiona cada envío, conserva las versiones anteriores, reprocesa solo los periodos afectados e indica qué versión generó cada salida. El conjunto de datos mantiene una trazabilidad completa en lugar de sobrescribir el histórico en silencio.