La mayoría de los equipos FMCG no descubren los datos malos de retailer porque los validen. Los descubren cuando la conciliación mensual produce una varianza que nadie puede explicar, y el analista dedica dos días a decidir si el error está en el archivo del retailer, en los datos del ERP o en el mapeo. La validación que habría identificado la causa en diez minutos nunca se ejecutó, porque nunca se separó de la conciliación misma. La validación no es un paso dentro de la conciliación; es la puerta que decide qué se permite entrar en ella.
Esta guía establece los controles que aplicar a los archivos de retailer y distribuidor antes de que lleguen a la comparación: controles estructurales que comparan el archivo con su propio formato, y controles de negocio que lo comparan con su dato maestro, su calendario y sus expectativas. Cada control nombra el modo de fallo que detecta, porque un control sin un modo de fallo nombrado es decoración.
Controles estructurales vs de negocio
Un control estructural compara el archivo con su propia definición: las columnas esperadas existen, los tipos de datos son correctos, el formato de fecha es consistente, las unidades están declaradas. Responde a una pregunta: ¿salió el archivo del sistema del socio con la forma que acordamos? Un control de negocio compara el archivo con algo que nosotros tenemos: el maestro de producto, la lista de tiendas, el calendario, los totales del período anterior. Responde a una pregunta distinta: ¿tiene sentido el dato contenido en un archivo con la forma correcta?
La distinción importa porque los dos controles fallan por razones distintas y exigen respuestas distintas. Un fallo estructural suele significar que el socio cambió una plantilla, exportó otra pestaña o cambió de herramienta de reporte. La solución pertenece al origen, y parchear el archivo a mano oculta el cambio. Un fallo de negocio suele significar que el dato cambió de un modo que el proceso debe gestionar: una tienda nueva, un producto discontinuado, una cantidad corregida. La solución pertenece al proceso de conciliación, y el fallo es información, no ruido.
Ejecute primero los controles estructurales, porque todo lo que viene después depende de que el archivo tenga la forma esperada. Un archivo al que le falta una columna no necesita veinte controles de negocio; necesita volver atrás o reexportarse. Aquí es donde el trabajo de estandarización se paga: la plantilla canónica acordada con el socio es exactamente la especificación contra la que un control estructural compara el archivo.
Campos obligatorios
Cada archivo de socio tiene un pequeño conjunto de campos sin los cuales una fila carece de sentido: el identificador de producto, el identificador de tienda o cliente, el período, la cantidad y la unidad. Un control de campos obligatorios marca las filas donde alguno de estos está vacío. El control es trivial de ejecutar y sorprendentemente se omite a menudo, porque los analistas ven unas pocas filas completas al inicio del archivo y asumen que el resto tiene el mismo aspecto.
Los códigos de producto vacíos y las tiendas vacías son los casos que causan el daño. Una fila con un código de producto en blanco no puede mapearse y cualquier join la descartará, eliminando ventas reales de forma silenciosa. Una fila con una tienda en blanco no puede atribuirse a una ubicación, lo que importa cuando la conciliación se hace a nivel de tienda. El control de campos obligatorios convierte estas pérdidas silenciosas en un recuento visible antes de que corra la comparación.
Hay un matiz que merece nombrarse: los campos obligatorios son por rol, no por archivo. Una cantidad es obligatoria en una línea de venta y no en una cabecera. Un código de cliente es obligatorio en el sell-out de distribuidor y no en una lista de precios. El control necesita definidos los roles de campo, que es el mismo trabajo de definición que construir el esquema canónico — y es por eso que el control pertenece a un conjunto de reglas documentado en lugar de a la cabeza de un analista.
Unicidad de clave
La clave de un archivo de sell-out o de ventas es la combinación de campos que debería aparecer una sola vez: producto por tienda por período por referencia de transacción. Un control de unicidad cuenta cuántas filas comparten la misma clave y marca los duplicados. Este es el control más valioso sobre un archivo de ventas, porque las filas duplicadas son el error que duplica un total en silencio sin parecer nunca incorrecto.
Las claves duplicadas provienen de eventos realistas: un archivo ensamblado a partir de dos extractos con un rango solapado, una corrección añadida en lugar de reemplazar las filas originales, una reejecución de una exportación parcial. Ninguno de estos se detecta mirando los números, porque un total de tienda duplicado es internamente consistente. Solo un control a nivel de clave los detecta. El control también debe definirse sobre la clave correcta: algunos archivos repiten legítimamente un código de producto entre tiendas, y tratar la combinación equivocada como clave produce fallos falsos que entrenan a la gente a ignorar el control.
Cuando la conciliación corre a nivel mapeado, la unicidad debe comprobarse tanto sobre la clave bruta como sobre la clave mapeada. Un archivo puede ser único por código de producto de retailer y duplicarse al mapearlo, si dos códigos de retailer apuntan al mismo SKU interno. Detectar eso en la validación es más rápido que explicar un volumen duplicado después del hecho.
Validez de referencia
Un control de referencia comprueba que cada valor de un campo identificador exista en la tabla de referencia correspondiente: códigos de producto contra el maestro de producto, códigos de tienda contra la lista de tiendas, códigos de cliente contra el archivo de clientes del distribuidor. Es el control que convierte los identificadores desconocidos en una excepción contable en lugar de un fallo de join silencioso.
En la práctica el control tiene dos capas. Primero, la búsqueda directa: ¿está este código de producto de retailer en la tabla de mapeo? Segundo, la validez: ¿está activo el destino mapeado — no discontinuado, no vencido, no a la espera de un sucesor por un relanzamiento? La primera capa detecta códigos desconocidos; la segunda detecta códigos conocidos pero obsoletos. Ambas pertenecen a la validación, porque una línea de producto sin mapear es exactamente el tipo de diferencia que la gestión de SKU faltantes debe resolver antes de la comparación, no después.
El control de referencia debe informar recuentos y filas de muestra, no solo un aprobado o un fallo. Saber que 47 de 12.000 códigos de producto no están mapeados es una cola de excepciones gestionable. Saber que un archivo "falló la validez de referencia" sin recuento no dice nada sobre si la corrida puede continuar. La salida de la validación solo es útil al nivel de detalle en el que alguien pueda actuar sobre ella.
Cobertura
Los controles de cobertura responden a una pregunta que los demás controles nunca tocan: no si las filas presentes son correctas, sino si faltan filas. Un archivo de retailer que cubre 41 de 45 tiendas, o un archivo de distribuidor que omite la última semana del período, puede pasar todos los controles estructurales y de negocio anteriores y seguir estando mal para el período en su conjunto.
Los controles de cobertura prácticos son: tiendas presentes frente a la lista de tiendas acordada, semanas o días presentes frente al calendario de reporte, y productos presentes frente al rango vendible esperado. Cada uno necesita una expectativa contra la que compararse, que es por lo que la cobertura es el control que los equipos omiten — requiere mantener una lista de tiendas y un calendario, y esos viven fuera del archivo mismo. Sin ellos, la cobertura no puede medirse, y el archivo se juzga solo por lo que contiene en lugar de por lo que omite.
La cobertura es donde la validación conecta con el esfuerzo más amplio de consolidación del sell-out — pero el punto práctico es más simple. Decida qué dimensión es crítica para el uso del archivo. Para un conjunto de datos de sell-out a nivel de mercado, la cobertura de tiendas es la que importa. Para una conciliación de cierre de período, la cobertura de períodos lo es. Construya primero las tablas de expectativa de la dimensión crítica; una cobertura perfecta en tres dimensiones que nadie lee sigue siendo un proceso razonable, pero no es el que detiene la conciliación mala.
Controles de total
Los controles de total comparan las cifras resumen del archivo contra una expectativa independiente: unidades totales contra el período anterior ajustado por calendario, valor total contra la cifra de factura o envío correspondiente, recuento de filas contra el recuento de recepción registrado el mes pasado. Son la forma más barata de detectar un problema que los controles estructurales y de negocio no ven — un problema repartido en muchas filas en lugar de concentrado en unas pocas.
Un control de total bien elegido tiene dos propiedades. Usa una fuente independiente; si no, solo está reverificando el archivo contra sí mismo. Y está definido a un nivel que significa algo: total por mercado, por categoría o por canal, no solo un gran total. Un gran total único puede ocultar dos errores compensados en categorías distintas; un control por categoría no puede.
Los controles de total son también el puente natural hacia la conciliación misma. Una varianza entre el total del archivo y el total del ERP es la misma comparación que la conciliación ejecutará en detalle. Ejecutar el control de total en la recepción le dice con antelación si el período va a conciliar limpio o si hay un hueco conocido que necesitará una explicación. No reemplaza la comparación detallada; le da primero la respuesta resumida.
Severidad
Un control que no clasifica sus fallos es un informe, no un control. Asignar severidad convierte la salida de la validación en decisiones: qué fallos detienen la corrida, cuáles se registran como excepciones y cuáles son informativos. El modelo de severidad debe ser fijo y simple — tres niveles bastan.
Los fallos de detención son estructurales: plantilla equivocada, columnas obligatorias ausentes, un archivo vacío, un total fuera de rango por un orden de magnitud. Significan que el archivo no es el que el proceso espera, y continuar produce una comparación sin sentido. Los fallos de advertencia son de negocio: duplicados, códigos sin mapear, huecos de cobertura. El archivo puede continuar, pero las excepciones deben ser visibles y tener responsable. Los ítems informativos son cambios: un código de tienda nuevo, un ajuste de plantilla, una gama de producto nueva — merece registrarse, no detenerse por ellos.
El sentido de la severidad es que alguien decida. Un archivo con una advertencia se convierte en una excepción con responsable y fecha límite, según el proceso de gestión de excepciones. Un archivo con un fallo de detención vuelve al origen con el motivo indicado. Lo que nunca debería pasar es que un archivo continúe en silencio tras un control fallido porque nadie definió qué significa el fallo.
Cuarentena
La cuarentena es lo que un fallo de detención parece operativamente. El archivo no se borra ni se fusiona; se retiene con su registro de fallo — nombre de archivo, fecha de llegada, controles fallidos, muestras de las filas ofensivas — mientras el origen lo corrige. La cuarentena hace visibles las entradas malas para el proceso en lugar de dejar que se evaporen, y le da a la conciliación una recepción limpia: la comparación solo corre sobre archivos que pasaron la puerta.
El área de cuarentena puede ser una carpeta de archivos brutos más un log, o una tabla de base de datos con un estado. El mecanismo importa menos que la disciplina: un archivo en cuarentena permanece fuera de la corrida hasta que lo reemplaza una versión corregida, y el log registra la llegada y la devolución para que el patrón de correcciones del socio sea medible. Si un distribuidor pone un archivo en cuarentena cada mes, eso es un problema del socio para plantear, no una sorpresa mensual.
La validación, la severidad y la cuarentena forman juntas la etapa de recepción del modelo operativo de conciliación. Una vez que la puerta de recepción es estable, los mismos controles que protegen una conciliación manual son la especificación de una automatizada: las reglas ya están escritas, probadas y con responsable. Por eso la validación merece construirse antes de la automatización, no después.
Dónde suele romperse la validaciónLos controles corren después de que la conciliación ya produjo una varianza, cuando la causa debe reconstruirse desde la salida. Mover los mismos controles a la recepción — antes de la comparación — convierte los datos malos de socio en una excepción controlada en lugar de una investigación de dos días.
Preguntas frecuentes
¿Qué diferencia hay entre un control estructural y uno de negocio en la validación de datos?
Un control estructural compara el archivo con su propio formato: columnas obligatorias, tipos de datos, formato de fechas, unidades. Detecta cambios de plantilla y errores de exportación. Un control de negocio compara el archivo con algo externo: que los identificadores existan en el maestro, que no haya duplicados, que los totales estén dentro de rangos esperados, que la cobertura coincida con la población acordada. Los controles estructurales prueban que el archivo tiene la forma correcta; los de negocio prueban que los datos que contiene son utilizables.
¿Qué controles de validación detectan los errores más graves en archivos de sell-out?
La unicidad de clave y la validez de referencia detectan los errores que corrompen totales de forma silenciosa. Una clave duplicada duplica una línea sin cambiar la completitud aparente del archivo, y un código de retailer sin mapear lo descarta un join salvo que se haga visible. Los controles de cobertura detectan el problema inverso: un archivo completo por fila pero que omite una tienda o una semana entera concilia bien y está mal. Ningún control basta por sí solo; cubren modos de fallo distintos.
¿Qué debería pasar con un archivo que falla la validación?
Depende de la severidad. Un fallo estructural debería detener la corrida y devolverse al origen, porque parchear un archivo malformado a mano destruye el rastro de auditoría. Un fallo de negocio debería registrarse como excepción con un responsable y una fecha límite, y el archivo puede continuar con el hueco conocido visible. El sentido de los niveles de severidad es que alguien decida deliberadamente en lugar de dejar que las filas fallidas desaparezcan dentro de la conciliación.
Fuentes
- Gartner, Data quality: best practices for accurate insights.
- TechTarget, Why businesses should know the importance of data quality.
Gartner se cita por el hallazgo de que la mala calidad de datos cuesta a las organizaciones un promedio de 12,9 millones de dólares al año (investigación de 2020), y TechTarget por la regla 1-10-100 de verificación y corrección de datos. Ambas apoyan el argumento de que validar en la recepción es materialmente más barato que corregir datos malos después de que llegan al reporte. Ninguna cifra de esta guía se presenta como aplicable a un encargo concreto de Marksyte.