Por qué los datos de ventas del retailer no coinciden con el ERP

Los datos de ventas del retailer no coinciden con el ERP, pero nadie puede decir exactamente por qué. La diferencia se cita en las reuniones como un número, se ajusta en un libro y nunca se resuelve. Antes de que alguien cambie el número, la diferencia necesita un árbol de causas: un conjunto controlado de explicaciones posibles y un método para probar cada una.

Una discrepancia entre el retailer y el ERP no es un error hasta que se conoce la causa. Puede venir del evento de negocio registrado, del identificador de producto o ubicación, del período de reporte, de las devoluciones y créditos, de los tamaños de pack, de los archivos corregidos o de las exportaciones del sistema. Esta guía convierte esas posibilidades en un diagnóstico que puede ejecutar antes de ajustar nada.

Defina la comparación antes de enumerar las causas

El primer paso es precisar qué registra exactamente cada número. Los datos de ventas del retailer suelen significar datos de POS o sell-out: unidades o valor vendidas a consumidores, informados por tienda y período comercial. El ERP suele registrar documentos comerciales: pedidos, envíos, facturas, notas de crédito y devoluciones, fechados por documento o por fecha de contabilización. La misma palabra, como ventas, puede referirse a eventos distintos en los dos sistemas.

Anote cuatro cosas de cada fuente antes de investigar la diferencia: el evento de negocio, el identificador de producto y su ruta de mapeo, el grano de ubicación, y el período o la fecha de corte. Si las fuentes no pueden compararse al mismo grano y período, la primera diferencia es estructural y no un error de datos.

Decida también si compara unidades, valor o ambos. Una brecha en unidades y una brecha en valor pueden tener causas distintas, así que separe las dos comparaciones en lugar de mezclarlas en una sola variación.

Diez causas de discrepancia entre el retailer y el ERP

1. Las fuentes registran eventos de negocio distintos

El sell-out del retailer registra demanda del consumidor. Un envío del ERP registra producto que sale de su control; una factura registra la obligación comercial. Si la comparación mezcla sell-out con envíos, el stock que sigue en la red del retailer y el stock en tránsito aparecen como una diferencia. Confirme que ambos archivos describen el mismo evento o acepte la diferencia de evento como un puente conocido.

2. Los identificadores de producto no están mapeados

El retailer puede informar un EAN o su propio código de producto, mientras que el ERP almacena un SKU interno. Un mapeo faltante, retirado o duplicado deja ventas válidas sin emparejar. Cuente las filas sin mapear e inspecciónelas por producto: un puñado de códigos sin mapear puede concentrar toda la brecha.

3. El grano de ubicación no coincide

Los documentos del ERP pueden ir a una cuenta de cliente o a un centro de distribución, mientras que el sell-out se informa por tienda individual. Un cliente puede mapearse a muchas tiendas. Comparar en el grano equivocado convierte una relación legítima de uno a muchos en una discrepancia falsa.

4. Los períodos de reporte y las fechas de corte difieren

Una semana comercial puede ir de lunes a domingo, mientras que el mes del ERP cierra el último día natural y las facturas se contabilizan días después de la entrega. Una transacción cercana al límite puede aparecer en un período distinto en cada sistema sin que ninguno esté equivocado. Estas diferencias deberían compensarse en un período posterior cuando el calendario se puentea correctamente.

5. Las devoluciones y los créditos se mueven entre períodos

Los datos del retailer pueden ser netos de devoluciones de consumidores. El ERP puede emitir una nota de crédito solo cuando el stock se devuelve físicamente, a veces semanas después. Algunos socios reexpresan períodos de sell-out anteriores; otros incluyen ajustes en el archivo actual. Tratar toda cantidad negativa como una devolución puede mover la discrepancia en lugar de resolverla.

6. Los tamaños de pack y las unidades de medida difieren

Una fuente puede informar packs de seis, otra unidades individuales y una tercera cajas. Una caja de cuatro packs de seis puede aparecer como 4, 24 o 1 según la fuente. Las reglas de conversión deben tener fecha de vigencia porque las configuraciones de pack cambian con el tiempo.

7. Los archivos corregidos crean duplicados u omisiones

Un retailer que reenvía un archivo corregido sin versionado puede duplicar filas o dejar versiones antiguas activas. Una extracción del ERP que incluye documentos cancelados o revertidos puede añadir cantidades fantasma. Los controles de unicidad de claves y el versionado de archivos detectan esto antes de la comparación.

8. Faltan tiendas o períodos, o llegan tarde

Una tienda que no ha informado, un período que no ha cerrado o un archivo recibido después de la fecha de corte reduce un lado de la ecuación. La brecha entonces parece una variación cuando en realidad es un problema de cobertura. Mida la cobertura por tienda, producto y período antes de confiar en cualquier total.

9. Las reglas de valor, precio y moneda difieren

Si compara valor, la base de precio puede diferir: precio de venta, precio neto, costo, IVA incluido o excluido. La moneda, las fechas de cambio y las reglas de redondeo también pueden divergir. Declare la definición de valor de cada fuente y convierta ambas a la misma base antes de comparar.

10. Las exportaciones del sistema filtran u omiten registros

Un informe del ERP puede excluir ciertos estados de documento, pedidos cancelados o movimientos intercompañía. Un archivo del retailer puede excluir categorías de autoscaneo o determinadas banderas. Documente el filtro de cada exportación para que la comparación cubra la misma población.

Cómo aislar cada causa

Ejecute los pasos de diagnóstico en orden. Cada paso elimina una familia de causas o aporta evidencia para probarla. Deténgase en el primer paso que explique la brecha y confírmelo con el siguiente ciclo.

1. Confirme el evento. Revise la cabecera del archivo y las definiciones. Si compara sell-out con envíos, construya el puente de stock en lugar de esperar un emparejamiento directo.
2. Mapee los identificadores de producto. Una ambos archivos al mapeo de producto y cuente los códigos y EAN del retailer sin mapear. Revise los valores sin mapear para buscar listados nuevos, códigos retirados y errores de mapeo.
3. Alinee el grano de ubicación. Agregue al nivel que soporten ambas fuentes, como tienda, bandera o cliente. Documente cualquier lógica de ubicación uno a muchos.
4. Construya un puente de calendario. Mapee las semanas comerciales a los períodos financieros y liste los documentos cercanos a la fecha de corte. Las diferencias de calendario deberían trasladarse y compensarse.
5. Separe devoluciones y créditos. Liste las cantidades negativas y las notas de crédito por tipo y período. Aplique la regla de devoluciones acordada en lugar de tratar todos los negativos igual.
6. Aplique conversiones de unidades. Convierta ambas fuentes a una sola unidad de medida con reglas de pack con fecha de vigencia y recalcule la comparación.
7. Compruebe duplicados. Pruebe la unicidad de la clave en el grano producto-ubicación-período en ambos archivos e identifique los reenvíos corregidos.
8. Mida la cobertura. Compare tiendas, productos y períodos esperados frente a recibidos. Cuantifique los datos faltantes y tardíos antes de interpretar la brecha.
9. Compare las reglas de valor. Si la brecha está en el valor, verifique la base de precio, la moneda y el redondeo en ambos lados.
10. Revise los filtros de exportación. Confirme que ambas extracciones incluyen los mismos estados de documento, banderas y canales.

Tabla de diagnóstico

Qué no debe ajustarse

• Cambiar el número del retailer para que coincida con el ERP sin evidencia. Esto oculta la causa y hace más difícil explicar el siguiente ciclo.
• Descartar en silencio filas sin mapear. El conjunto emparejado parece preciso mientras desaparecen los registros más difíciles.
• Contabilizar ajustes manuales para diferencias de calendario que deberían compensarse. Si la cantidad es correcta en ambos lados, una entrada manual crea un doble conteo.
• Sobrescribir un mapeo para corregir una línea. Un cambio de mapeo afecta a todo el histórico de ese producto.
• Cerrar una excepción como “ajustado manualmente”. Eso describe la acción, no la causa, y la variación volverá.
• Confiar en un total limpio sin comprobar la cobertura. Las tiendas faltantes y los productos que se compensan pueden esconderse detrás de una cifra ordenada.

Vía de escalado

Cuando los pasos de diagnóstico no aíslan la causa, escale con evidencia y no con un número. Empiece por el equipo de datos, que es dueño de los mapeos, la calidad de origen, los duplicados y la cobertura. Después involucre a finanzas o al dueño del control para devoluciones, notas de crédito, fechas de corte y materialidad. Si la evidencia apunta a la fuente, lleve los hallazgos al responsable de la relación con el retailer o distribuidor con una petición concreta de archivo corregido o aclaración.

Documente cada decisión, incluida la evidencia, el responsable, el estado y el ciclo de seguimiento. Si la causa se confirma y se compensa, conserve el registro para que el equipo no investigue el mismo problema otra vez.

Conclusión práctica

Para diagnosticar por qué los datos de ventas del retailer no coinciden con el ERP, empiece por definir el evento, el grano, el período y la regla de valor de cada fuente. Después recorra las diez causas en orden, aislando cada familia con la evidencia que necesita. No ajuste un número hasta que la causa esté confirmada y documentada. Escale con evidencia y traslade los elementos sin resolver al siguiente ciclo con un responsable y un estado.

Si su equipo explica las mismas diferencias entre el retailer y el ERP de forma distinta cada mes, el servicio de conciliación de datos y controles de Marksyte puede revisar la comparación, las causas y la pista de evidencia. El trabajo relacionado puede incluir mapear identificadores de producto, cliente y tienda o estandarizar archivos de socios y reglas de calidad de datos.

Preguntas frecuentes