Para mantener consistentes los datos maestros de productos entre tu ERP y los marketplaces tenés que decidir qué sistema manda en cada campo, quién es responsable de actualizarlo, con qué frecuencia se sincroniza y qué regla resuelve los conflictos cuando dos sistemas dicen cosas distintas. Los datos maestros se mantienen consistentes cuando cada campo tiene un solo dueño. Sin esa definición, el mismo producto termina con tres precios, dos stocks y descripciones que nadie sabe de dónde salieron.
El problema aparece cuando la operación crece. Al principio, el ERP y la tienda se actualizan a mano y alcanza. Con cinco canales y miles de SKU, cada carga manual es una oportunidad de error que se traduce en ventas sin stock, precios equivocados o facturas que no coinciden con el pedido. Cada sistema que se actualiza a mano es una fuente posible de inconsistencias. En esta guía vas a ver cómo definir la fuente de verdad, asignar responsables, resolver duplicados y aplicar todo con un ejemplo real de integración.
Qué sistema debe ser fuente de verdad para SKU, EAN, precios y atributos
La fuente de verdad es el sistema donde un dato se crea y se modifica; el resto de los sistemas lo reciben y no lo editan. No hace falta que un solo sistema sea dueño de todo: lo habitual es que el ERP mande en los datos contables y logísticos, y que el hub de integración mande en los datos comerciales por canal. Definir la fuente de verdad campo por campo evita las sobrescrituras cruzadas. La tabla siguiente muestra una distribución frecuente en operaciones que trabajan con ERP y marketplaces.
| Campo | Fuente de verdad sugerida | Motivo |
|---|---|---|
| SKU | ERP | Es el identificador contable y de inventario |
| EAN | ERP | Identifica el producto ante proveedores y canales |
| Costo y precio base | ERP | Se vincula con compras, márgenes y facturación |
| Precio por canal | Hub de integración | Aplica reglas sobre el precio base del ERP |
| Stock físico | ERP o WMS | Refleja ingresos, egresos y ajustes de depósito |
| Peso y dimensiones | ERP o WMS | Se usan para logística y cálculo de envíos |
| Títulos, descripciones e imágenes | Hub de integración | Se adaptan a las reglas de cada marketplace |
La distribución es una referencia y cada empresa puede ajustarla según sus sistemas y procesos. Lo importante es que la decisión quede escrita y todos los equipos la conozcan. Si dos áreas creen que pueden editar el mismo campo en sistemas distintos, el conflicto es cuestión de tiempo.
El hub de integración cumple un rol de traductor. Recibe el dato maestro del ERP y lo adapta a lo que pide cada canal: categorías, atributos obligatorios, títulos con límite de caracteres o reglas de precio por canal. El hub adapta el dato maestro a cada canal sin modificar el original. Con las funcionalidades de Base podés centralizar productos, precios y publicaciones sin tocar la información que gestiona el ERP.
Cómo definir propiedad y frecuencia de actualización de cada campo
Saber qué sistema manda no alcanza: también necesitás saber qué persona o área es responsable de cada dato y cada cuánto tiene que llegar a los canales. Cada campo maestro necesita un responsable y una frecuencia de actualización acordada. Sin responsable, nadie corrige un error; sin frecuencia, nadie sabe si el dato está vigente. Una forma práctica de organizarlo es esta:
- Compras y administración: son responsables de SKU, EAN, costo y alta de productos nuevos en el ERP. Los cambios se sincronizan cuando ocurren, porque un producto sin alta no se puede vender.
- Área comercial: define precio base y reglas de precio por canal. La actualización puede ser diaria o ante cada cambio de lista, según la volatilidad de costos.
- Logística: controla stock físico, peso y dimensiones. El stock necesita sincronización lo más cercana posible al tiempo real, porque es el dato que más impacta en las ventas.
- E-commerce: gestiona títulos, descripciones, imágenes y atributos por marketplace. Se actualizan cuando cambian las reglas de un canal o cuando se optimiza una publicación.
La frecuencia también depende del costo de un dato desactualizado. Un título viejo se corrige sin consecuencias graves; un stock desactualizado durante una hora puede generar decenas de ventas que no podés cumplir. El stock es el dato maestro que exige la sincronización más frecuente. Por eso conviene priorizar su integración antes que la de cualquier atributo descriptivo.
Además de responsables y frecuencias, conviene registrar quién cambió cada dato y cuándo. Un historial de cambios permite reconstruir por qué un precio quedó mal o por qué un producto desapareció de un canal. Un registro de cambios convierte cada error en algo rastreable y corregible.
Cómo tratar duplicados y conflictos entre ERP, Base y marketplaces
Los duplicados aparecen por motivos conocidos: el mismo producto cargado con dos SKU distintos, variantes creadas como productos independientes, kits que no descuentan stock de sus componentes o publicaciones creadas directamente en el marketplace. La mayoría de los duplicados nace de cargas hechas fuera de la fuente de verdad. Para tratarlos, conviene aplicar reglas en este orden:
- Un identificador único: elegí el SKU del ERP como identificador principal y el EAN como secundario. Toda publicación en un canal tiene que poder vincularse a uno de esos códigos.
- Mapeo de equivalencias: si un marketplace o un socio usa sus propios códigos, mantené una tabla que los relacione con tu SKU. Así un pedido siempre descuenta el stock correcto.
- Regla de precedencia: definí qué sistema gana cuando dos datos difieren. Si el stock del marketplace no coincide con el del ERP, el ERP es el que corrige al canal, nunca al revés.
- Conciliación periódica: generá un reporte semanal de productos sin vincular, SKU duplicados y diferencias de stock. Corregir en lotes chicos es mucho más simple que limpiar el catálogo una vez por año.
Los conflictos de publicación merecen atención especial porque los marketplaces a veces modifican datos por su cuenta, como categorías o atributos. Revisar los cambios hechos por el canal evita que se pierdan en la próxima sincronización. Con la gestión de marketplaces en Base podés administrar publicaciones de varios canales desde un mismo panel y vincularlas a tu catálogo central.
Los kits y packs son otro foco de inconsistencias. Si vendés un pack de tres unidades como un producto independiente, su stock no se descuenta del producto individual y terminás vendiendo unidades que no tenés. Los kits tienen que descontar stock de sus componentes en forma automática. Con el administrador de productos de Base podés gestionar kits, variantes y múltiples depósitos sobre el mismo inventario.
Ejemplo de gobierno de datos maestros con SAP Business One y Base
Para ver cómo se aplican estas reglas en una integración real, tomemos el caso de SAP Business One. La integración de Base con SAP Business One se conecta a través del SAP Service Layer y define con claridad qué datos viajan en cada dirección. La integración documenta qué sistema manda en cada flujo de datos maestros. Eso la convierte en un buen ejemplo de gobierno de datos aplicado.
La tabla siguiente resume los flujos de datos que describe la integración, según su alcance documentado.
| Dato | Dirección | Cómo funciona |
|---|---|---|
| Productos | De SAP a Base | Se importan con stock, precios, grupo impositivo, peso, dimensiones y, opcionalmente, imágenes |
| Vinculación | Entre ambos | Los productos se vinculan por SKU o EAN |
| Stock | De SAP a Base | El stock disponible de un depósito de SAP se transfiere a un depósito externo en Base |
| Precios | De SAP a Base | Se sincronizan desde la lista de precios de SAP que elijas |
| Pedidos | De Base a SAP | Base crea una orden de venta en SAP |
| Facturas | De Base a SAP | Se exportan en forma automática o manual, y las anulaciones se reflejan en SAP |
| Clientes | De Base a SAP | Se identifican por código de cliente, CUIT o email, y se crean si no existen |
La información corresponde al alcance publicado de la integración y puede actualizarse con nuevas versiones. Antes de implementar, conviene validar el alcance vigente con el equipo de Base. También hay límites documentados: la integración no envía productos ni stock desde Base hacia SAP, no descarga pedidos desde SAP y cada conexión trabaja con una sola base de datos de empresa.
El esquema confirma el modelo de la primera sección: SAP es fuente de verdad para productos, stock y precios base, y Base es el punto de entrada de pedidos de todos los canales. El ERP manda en el producto y el hub manda en el pedido. Si tu operación además trabaja con un depósito gestionado en SAP, la integración de Base con SAP WMS se implementa en forma dedicada con especialistas de Base para conectar inventario, productos y estados de pedidos.
Los datos maestros consistentes son la base de cualquier operación multicanal que quiera crecer sin errores. Las empresas que definen fuente de verdad, responsables y reglas de conflicto antes de integrar sistemas evitan meses de limpieza posterior. Un dato con un solo dueño es un dato en el que todos pueden confiar.
Integrá tu ERP con todos tus canales desde Base
Si hoy actualizás productos, stock y precios a mano entre tu ERP y los marketplaces, cada canal nuevo multiplica las inconsistencias. En Base conectamos tu ERP con marketplaces, tiendas online y paqueteras, respetando la fuente de verdad de cada dato y centralizando los pedidos de todos tus canales. Tu catálogo se mantiene consistente y cada pedido llega al ERP sin carga manual. Así podés sumar canales sin perder control de tus datos maestros.
Ordená tus datos maestros. Conectá tu ERP con todos tus canales de venta. → Conocé el plan Business de Base
