Cómo migrar catálogo, tarifas y precios especiales al automatizar pedidos

El ERP debe seguir siendo la fuente única

En una distribuidora, el ERP suele ser el sistema donde viven los datos críticos de negocio: clientes, productos, códigos internos, tarifas, stock, condiciones comerciales, pedidos, albaranes y facturación.

Por eso, al automatizar pedidos, el objetivo no debería ser crear otro catálogo paralelo. El objetivo debería ser que el sistema de automatización pueda consultar, interpretar y validar contra los datos del ERP.

Esto evita que existan dos versiones de la verdad:

• Un producto activo en el ERP, pero inactivo en el sistema nuevo.
• Una tarifa actualizada en el ERP, pero antigua en la automatización.
• Un descuento especial aplicado en facturación, pero no en el pedido automático.
• Un formato de venta cambiado en el ERP, pero no sincronizado en el nuevo sistema.
• Un cliente bloqueado en el ERP, pero aceptado por error en otro canal.

Si el ERP es la fuente única, la automatización no inventa ni decide datos comerciales. Lee el pedido, lo estructura y lo valida contra la información oficial.

Migrar no siempre significa copiar datos

Cuando se habla de migrar catálogo al nuevo sistema, muchas empresas imaginan una exportación completa: productos, precios, clientes y descuentos copiados a otra base de datos.

Pero hay varias formas de trabajar:

• Consulta directa al ERP: el sistema consulta productos, clientes, tarifas o stock cuando los necesita.
• Sincronización periódica: se actualizan datos cada cierto tiempo desde el ERP.
• Exportación controlada: se trabaja con ficheros CSV, XML o tablas generadas por el ERP.
• Catálogo auxiliar: se mantiene una tabla de equivalencias, sin duplicar toda la lógica comercial.
• Borradores revisables: el sistema sugiere productos y precios, pero administración valida antes de enviar al ERP.

La decisión depende del ERP, de sus vías de integración y de la calidad de los datos actuales.

Qué datos del catálogo necesita la automatización

Para automatizar pedidos correctamente, el sistema necesita acceder a los datos que permiten relacionar lo que pide el cliente con el producto real de la distribuidora.

Los campos más importantes suelen ser:

• Código interno del producto.
• Nombre oficial.
• Nombre comercial.
• Marca.
• Familia o categoría.
• Formato de venta.
• Unidad de medida.
• Equivalencias.
• Productos activos o descatalogados.
• Productos sustitutos.
• Stock disponible, si aplica.
• Histórico de compra por cliente.

El catálogo no sirve solo para mostrar nombres. Sirve para validar que una línea de pedido puede convertirse en una línea real del ERP.

El problema de los nombres informales

En distribución, los clientes no siempre piden usando el nombre exacto del ERP.

Pueden escribir:

• "el queso de siempre".
• "agua pequeña".
• "la cerveza del barril azul".
• "tomate grande".
• "2 cajas de leche".
• "lo mismo que el martes".

El sistema debe relacionar esas expresiones con el catálogo real. Para eso, puede apoyarse en:

• Histórico de pedidos del cliente.
• Sinónimos habituales.
• Marcas.
• Formatos.
• Familias de producto.
• Productos más comprados por ese cliente.
• Equivalencias definidas por administración.

Pero si no hay suficiente confianza, la línea debe quedar como dudosa. La automatización no debe inventar el producto.

Formatos y unidades: donde más errores aparecen

Migrar o sincronizar catálogo no sirve de mucho si no se controlan formatos y unidades de venta.

En alimentación y bebidas, un producto puede venderse por:

• Unidad.
• Caja.
• Pack.
• Kilo.
• Litro.
• Bandeja.
• Saco.
• Botella.
• Bidón.
• Barril.

Si el cliente escribe "3 de agua", el sistema debe saber si puede resolverlo con seguridad. Si no sabe si son cajas, packs o unidades, debe marcarlo para revisión.

El formato no es un detalle menor. Es una de las diferencias entre un pedido correcto y una incidencia de almacén.

Cómo se sincronizan tarifas especiales y descuentos de cada cliente

Cómo se sincronizan tarifas especiales y descuentos de cada cliente es una de las preguntas más importantes del proyecto. En una distribuidora, dos clientes pueden pedir el mismo producto y tener precios distintos.

La automatización debe respetar:

• Tarifa asignada al cliente.
• Descuentos por familia.
• Condiciones especiales.
• Promociones vigentes.
• Acuerdos por volumen.
• Rappels o acuerdos comerciales.
• Bloqueos o restricciones.
• Pedidos mínimos, si existen.

Si el cliente escribe un precio en el mensaje, puede guardarse como observación, pero no debería aplicarse automáticamente sin validación.

Puedes ampliar esta parte en la guía sobre cómo automatizar pedidos con tarifas, descuentos y crédito por cliente.

Por qué no conviene duplicar tarifas en otro sistema

Duplicar tarifas suele generar problemas. Al principio puede parecer cómodo: se exportan precios y se cargan en la herramienta nueva. Pero si luego cambia una tarifa en el ERP y no se actualiza en el sistema auxiliar, aparece la incoherencia.

Los riesgos son:

• Precios distintos entre ERP y automatización.
• Descuentos no aplicados.
• Promociones caducadas que siguen activas.
• Condiciones especiales desactualizadas.
• Pedidos con importes incorrectos.
• Reclamaciones de clientes.
• Correcciones posteriores en facturación.

Por eso, siempre que sea posible, la automatización debe consultar tarifas en el ERP o sincronizarse de forma controlada desde el ERP, no mantener una lógica comercial independiente.

Qué pasa con los precios especiales

Los precios especiales suelen ser una de las partes más sensibles. Pueden depender del cliente, producto, familia, fecha, acuerdo comercial, campaña o volumen.

Antes de automatizar, conviene revisar:

• Dónde están guardados los precios especiales.
• Si están en el ERP o en hojas externas.
• Quién los actualiza.
• Cada cuánto cambian.
• Si tienen fecha de inicio y fin.
• Si se aplican por cliente, grupo o familia.
• Qué ocurre cuando un precio especial caduca.
• Cómo se resuelven conflictos entre tarifa y descuento.

Si estos precios viven fuera del ERP, el proyecto debe decidir si se integran, se migran, se limpian o se mantienen como excepción revisable.

Catálogo de productos: qué revisar antes de automatizar

Antes de automatizar pedidos, conviene analizar la calidad del catálogo de productos.

Hay que revisar:

• Productos duplicados.
• Productos descatalogados todavía activos.
• Nombres poco descriptivos.
• Formatos mal definidos.
• Unidades de venta inconsistentes.
• Familias incompletas.
• Marcas mal escritas.
• Códigos antiguos.
• Productos equivalentes no documentados.
• Histórico con referencias que ya no se venden.

Un catálogo desordenado no impide automatizar, pero sí obliga a definir una fase de limpieza, mapeo o control de excepciones.

Cuándo hace falta limpiar catálogo antes de automatizar

No siempre hace falta una limpieza completa del catálogo antes de empezar. Pero sí conviene limpiar o mapear cuando los errores pueden afectar al pedido.

Señales de que el catálogo necesita revisión:

• Administración duda a menudo entre varias referencias.
• Hay productos muy parecidos.
• Los clientes usan nombres distintos a los del ERP.
• Existen referencias antiguas activas.
• Hay formatos poco claros.
• Los comerciales usan abreviaturas no documentadas.
• El histórico contiene productos sustituidos.
• Hay errores frecuentes de preparación por producto o formato.

En estos casos, automatizar sin revisar catálogo puede acelerar errores. La solución no siempre es parar el proyecto, pero sí definir qué productos, familias o clientes se automatizan primero.

Qué hacer si el ERP no permite consulta directa

Si el ERP no permite consulta directa, todavía hay alternativas.

Se puede trabajar con:

• Exportaciones periódicas de catálogo.
• CSV de productos y tarifas.
• XML de datos maestros.
• Tablas intermedias.
• Conectores existentes.
• Ficheros generados por el ERP.
• Catálogos auxiliares sincronizados.
• Borradores revisables antes de enviar al ERP.

Sincronización periódica: cuándo puede ser suficiente

No todos los proyectos necesitan conexión en tiempo real desde el primer día.

Una sincronización periódica puede ser suficiente si:

• El catálogo no cambia constantemente.
• Las tarifas se actualizan con cierta estabilidad.
• Los productos activos están bien definidos.
• Los pedidos se revisan antes de entrar al ERP.
• El stock no se usa para prometer disponibilidad automática.
• La primera fase busca reducir trabajo manual, no automatizar decisiones críticas.

En cambio, puede no ser suficiente si la disponibilidad cambia rápido, las tarifas son muy dinámicas o el sistema tiene que confirmar stock y condiciones en tiempo real.

ERP como fuente única: qué significa en la práctica

Mantener el ERP como fuente única significa que los datos maestros importantes no se deciden en la automatización.

En la práctica:

• El catálogo oficial está en el ERP.
• Las tarifas oficiales están en el ERP.
• Los descuentos válidos están en el ERP.
• El stock fiable está en el ERP o en el sistema conectado a almacén.
• Los clientes activos se validan contra el ERP.
• Los pedidos finales deben coincidir con la lógica del ERP.

La automatización puede tener tablas auxiliares, reglas de interpretación o equivalencias, pero no debería convertirse en un segundo ERP.

Tablas auxiliares: cuándo sí tienen sentido

Aunque no conviene duplicar el catálogo, sí puede ser útil tener tablas auxiliares para mejorar la interpretación.

Por ejemplo:

• Sinónimos usados por clientes.
• Nombres informales de productos.
• Equivalencias entre formatos.
• Productos habituales por cliente.
• Abreviaturas de comerciales.
• Reglas para detectar pedidos duplicados.
• Casos que siempre deben ir a revisión.

La diferencia es importante: una tabla auxiliar ayuda a interpretar; no sustituye al catálogo oficial.

Pedidos históricos: una ayuda para interpretar

El histórico de pedidos puede ser muy útil para automatizar pedidos recurrentes.

Sirve para entender:

• Qué productos compra cada cliente.
• Qué formatos usa normalmente.
• Qué productos pide por nombre informal.
• Qué referencias suelen repetirse.
• Qué sustituciones se han usado antes.

Pero el histórico no debe usarse para inventar pedidos. Si el cliente escribe "lo mismo de siempre" y hay varios pedidos posibles, lo prudente es generar una sugerencia o dejar revisión humana.

Cómo validar productos antes de enviarlos al ERP

Antes de enviar un pedido al ERP, cada línea debería pasar por validaciones básicas.

Por ejemplo:

• Producto encontrado en catálogo.
• Código interno válido.
• Producto activo.
• Formato permitido.
• Cantidad compatible.
• Cliente autorizado a comprarlo, si aplica.
• Stock o incidencia identificada, si aplica.
• Tarifa o precio calculado desde fuente oficial.

Si una línea no supera validación, no debería entrar como pedido correcto. Debe apartarse para revisión.

Cómo gestionar productos no encontrados

Los productos no encontrados son normales durante las primeras fases.

Pueden deberse a:

• Nombre informal del cliente.
• Producto descatalogado.
• Error de escritura.
• Referencia antigua.
• Producto nuevo no actualizado.
• Abreviatura comercial.
• Formato no especificado.

Lo importante es definir un flujo claro:

Así, cada incidencia ayuda a mejorar el sistema sin enviar errores al ERP.

Cómo gestionar cambios de precio

Los cambios de precio deben gestionarse desde la fuente oficial. Si la distribuidora cambia tarifas, promociones o precios especiales, la automatización debe recibir ese dato de forma controlada.

Conviene definir:

• Quién actualiza precios.
• Dónde se actualizan.
• Cada cuánto se sincronizan.
• Cómo se detectan cambios.
• Qué pasa con pedidos ya recibidos.
• Qué precio se aplica si hay conflicto.
• Qué incidencias deben revisarse manualmente.

La automatización no debe convertirse en un lugar paralelo donde alguien cambia precios sin pasar por el ERP.

Cómo gestionar clientes con condiciones especiales

Muchas distribuidoras tienen clientes con condiciones particulares.

Por ejemplo:

• Descuentos propios.
• Tarifas distintas por centro.
• Productos autorizados o bloqueados.
• Pedidos mínimos.
• Condiciones de entrega.
• Crédito limitado.
• Revisión comercial obligatoria.
• Formatos preferidos.

Estas condiciones deben estar documentadas y, siempre que sea posible, reflejadas en el ERP. Si viven solo en la memoria del equipo, la automatización tendrá más dificultad para aplicarlas con seguridad.

Cómo empezar si los datos maestros no están perfectos

No hace falta tener todos los datos perfectos para empezar, pero sí hay que elegir bien el primer alcance.

Puede tener sentido empezar por:

• Clientes recurrentes.
• Productos de alta rotación.
• Familias con catálogo claro.
• Pedidos por PDF o email con estructura estable.
• Pedidos que administración ya resuelve de forma repetitiva.

Y dejar para una fase posterior:

• Clientes con condiciones muy especiales.
• Productos ambiguos.
• Tarifas poco documentadas.
• Catálogo con muchas referencias duplicadas.
• Casos que requieren criterio comercial frecuente.

Este enfoque permite avanzar sin esperar a que todo esté perfecto.

Qué debe revisar el proveedor antes de implantar

Antes de implantar una automatización de pedidos, el proveedor debería revisar el estado del catálogo, tarifas y datos maestros.

Preguntas importantes:

Si el proveedor no pregunta por catálogo y tarifas, probablemente está viendo solo una parte del proyecto.

Cómo encaja Mindai en esta parte del proyecto

En Mindai revisamos catálogo, tarifas y reglas de negocio antes de implantar automatización de pedidos.

El objetivo no es crear otro catálogo paralelo, sino trabajar con el ERP como fuente única siempre que sea posible. A partir de ahí, se pueden definir consultas, sincronizaciones, tablas auxiliares, equivalencias y revisión de excepciones.

Puedes ver el enfoque completo en nuestra página de implementación de automatización de pedidos.

La clave es que los pedidos claros avancen con datos oficiales y que los pedidos dudosos no entren al ERP como si fueran correctos.

Conclusión: automatizar pedidos exige cuidar los datos maestros

Migrar catálogo, tarifas y precios especiales al automatizar pedidos no debería significar duplicar datos sin control. En una distribuidora, el ERP debe seguir siendo la fuente única siempre que sea posible.

La automatización puede leer pedidos, interpretar productos, relacionarlos con catálogo, validar formatos, consultar tarifas y preparar borradores. Pero no debería inventar precios, duplicar reglas comerciales ni crear un segundo catálogo que acabe desactualizado.

Antes de implantar, conviene analizar la calidad del catálogo, cómo se gestionan tarifas por cliente, dónde viven los precios especiales, qué vías de integración permite el ERP y qué datos deben revisarse manualmente.

Si los datos maestros están bien planteados, la automatización será más fiable. Si están desordenados, el proyecto debe incluir una fase de limpieza, mapeo o control de excepciones.

Analizar calidad del catálogo en el ERP

Si quieres automatizar pedidos sin duplicar catálogo ni perder control sobre tarifas, descuentos y precios especiales, el primer paso es revisar la calidad de los datos maestros en el ERP.

En Mindai podemos ayudarte a analizar catálogo, formatos, tarifas por cliente, precios especiales y vías de integración para definir una automatización segura y conectada a la fuente correcta.

Analizar calidad del catálogo en el ERP →

Preguntas frecuentes sobre migrar catálogo, tarifas y precios especiales