En un proyecto de ecommerce, la integración ERP es lo que el cliente final nunca ve y siempre sufre. Un producto que aparece con stock y no lo tiene. Un precio en el carro distinto al de la factura. Un pedido que llega dos veces a bodega.
Ninguno de esos problemas es de la plataforma. Son de cómo se conectó con el ERP. Esta guía resume lo que hemos aprendido integrando tiendas, lo que dicen las guías oficiales de VTEX, Shopify y SAP, y lo que en Chile se suele subestimar: la boleta y la factura.
Antes de integrar: quién manda en cada dato
La primera decisión no es técnica. Es definir, dato por dato, qué sistema es el dueño. Sin esa tabla escrita, cada desarrollador la inventa a su manera y los sistemas terminan pisándose.
Esta es la forma que más se repite en las integraciones que salen bien:
| Dato | Dueño | Dirección | Cada cuánto |
|---|---|---|---|
| Productos y atributos | ERP o PIM | ERP → tienda | Por cambio o en lote diario |
| Precio de lista y por cliente | ERP | ERP → tienda | Por cambio |
| Promociones y cupones | Tienda | Se quedan en la tienda | No viajan |
| Stock | ERP o WMS | ERP → tienda | Casi en tiempo real |
| Pedidos | Tienda | Tienda → ERP | Por evento, con reintentos |
| Factura, despacho y seguimiento | ERP | ERP → tienda | Por evento o varias veces al día |
El stock casi nunca es bidireccional. Tiene un dueño y los demás lo leen.
Y el dueño se define por campo, no por objeto. Si el ERP manda en el nombre del producto y tu equipo de marketing en la descripción larga, la sincronización nocturna no puede pisar la descripción que alguien corrigió en la tarde. Este error es más común de lo que parece y genera una desconfianza en el sistema que después cuesta revertir.
La frecuencia sigue al costo de equivocarse. Un stock desfasado de un producto que se vende rápido es una venta que no vas a poder cumplir. Un precio de lista desfasado por una noche, en general, no le hace daño a nadie.
Cómo integra VTEX con un ERP
VTEX tiene una guía oficial de integración con back office que separa el trabajo en dos fases: la carga inicial y el flujo continuo. El orden importa.
Primero va el catálogo: categorías, marcas y especificaciones, y después productos, SKUs e imágenes. Un producto que sale de la tienda se desactiva, no se borra. Luego el ERP envía un precio base por SKU y, si tu operación lo necesita, precios fijos por política comercial (por ejemplo, una para venta al detalle y otra para mayoristas). Al final se crean las bodegas y el ERP informa el stock por SKU y por bodega.
Con eso en pie, empieza el flujo de pedidos. El ERP escucha los pedidos que llegan al estado «listo para preparar», que en VTEX significa pagado y fuera del plazo de cancelación. Lee el detalle, lo registra y le avisa a VTEX que empezó a prepararlo. Cuando factura, informa el número de factura y el pedido pasa a facturado. El código de seguimiento puede ir con la factura o después.
La documentación trae advertencias que conviene leer antes de cotizar, no después:
- Feed o Hook: VTEX tiene dos formas de avisar los pedidos y recomienda el Feed en la mayoría de los casos, porque es el ERP el que pide los pedidos a su ritmo. El Hook los empuja apenas ocurren; en un Cyber, sin un middleware que amortigüe, puede ahogar a un ERP lento.
- Los avisos se repiten: VTEX no garantiza eventos únicos, así que tu integración tiene que reconocer un pedido que ya procesó.
- Los avisos vencen: hay que confirmar cada evento, incluso los que no requieren acción, y el proceso tiene que estar siempre corriendo, porque los eventos se eliminan solos a los cuatro días.
- La factura cierra el pedido: el número de factura tiene que ser único y el pedido solo queda facturado cuando el monto facturado iguala el total. Después de eso ya no se puede cancelar.
Shopify y SAP Business One
En Shopify la lógica es parecida con otro vocabulario. Los pedidos se avisan por webhooks, que no garantizan el orden y pueden repetirse. Shopify recomienda deduplicarlos y correr una conciliación periódica, y para cargas grandes de productos o inventario, usar sus operaciones masivas en vez de miles de consultas sueltas.
Del lado del ERP, si trabajas con SAP Business One, la puerta de entrada es su Service Layer, la API que expone artículos, socios de negocio, listas de precios, stock por bodega, pedidos y facturas.
Dos cosas de SAP que conviene tener claras desde el diseño. El stock de una bodega no es un solo número: está lo físico, lo comprometido y lo pedido, y en la tienda se publica lo disponible, de las bodegas que tú decidas que cuentan. Y el precio de un cliente se arma por capas (lista de precios, precio especial del cliente, descuentos por volumen). La tienda tiene que llegar al mismo número, o la factura no va a calzar con el carro.
Conector, middleware o integración propia
Un conector existente es lo más rápido si hay uno para tu par exacto de plataforma y ERP. Su límite es lo que sabe mapear: cuando tu lógica comercial se sale de ahí, empiezan los parches.
Un middleware o iPaaS, como Celigo, Boomi o Workato, te da monitoreo, reintentos y facilidad para sumar canales, a cambio de un costo mensual o por transacción. Se justifica cuando conectas varios sistemas, no uno.
La integración propia da control total y no paga licencias por transacción, pero alguien tiene que mantenerla cada vez que cambia una API. Compara el costo a tres años, no solo el de construirla, y exige que tenga un responsable con nombre y apellido.
En Chile: la boleta y la factura
Lo que más se subestima al integrar en Chile es el documento tributario. El flujo habitual: el pedido se paga, la tienda avisa, un proveedor de facturación emite el documento ante el SII, vuelve el folio y el PDF llega al cliente y al ERP.
Tres aprendizajes que nos han costado. Nunca emitas el documento dentro del checkout: si el SII o el proveedor tardan, el cliente queda mirando una rueda girando; va a una cola, con reintentos. Cuidado con esos reintentos, porque repetir a ciegas una emisión que sí se hizo puede generar un documento duplicado con un folio real. Y pide los datos tributarios en el carro: sin RUT, razón social y giro no hay factura, y muchas plataformas no los piden por defecto.
Los errores que más vemos
El clásico es el pedido duplicado. El ERP registra el pedido, la red se corta antes de que llegue la respuesta y la integración reintenta. Se evita usando el número de pedido como llave y preguntando si ya existe antes de crearlo.
Le sigue la sobreventa, que casi siempre es publicar el stock físico en vez del disponible. La fórmula sana es físico menos reservado menos un stock de seguridad, y ese stock de seguridad crece con la velocidad de venta del producto.
Hay uno más silencioso: enviar el stock como diferencia («restar 3») en vez de como nivel («quedan 12»). Parece eficiente hasta que un reintento resta dos veces.
Y el último no es técnico. Los datos del ERP rara vez sirven para vender: descripciones de 30 caracteres, sin imágenes ni atributos. Un producto se publica cuando está completo, no cuando existe en el ERP.
Salir por etapas cuando el ERP viene atrasado
Pasa seguido que el ecommerce y el ERP nuevo se cambian en el mismo año, y que el ecommerce sea la prioridad porque es el que vende. Si el ERP se atrasa, hay una salida: lanzar la tienda conectada a lo que usas hoy y cambiar la integración al ERP nuevo después.
Funciona, pero tiene costo. Se integra dos veces y, durante el cruce, hay que monitorear dos flujos. Para que el puente no se vuelva permanente necesita fecha de término y un responsable.
Lo que hace que el segundo cambio sea un trámite y no otro proyecto es la tabla de dueños de cada dato, escrita antes de construir cualquiera de las dos integraciones. Y un consejo que vale para cualquier plataforma: no elijas la tienda pensando en el puente. El puente dura meses; la integración definitiva, años.
Cómo lo abordamos en Canal Cero
Empezamos por la tabla de dueños de cada dato, con tu equipo y el de tu ERP en la misma reunión. Con eso definimos si conviene un conector, un middleware o una integración propia, y en qué orden se construye.
Si todavía estás eligiendo plataforma, parte por cómo elegir plataforma ecommerce. Y si estás pensando en pasar de PrestaShop a VTEX, aquí está cómo hacemos esa migración sin perder SEO ni ventas.
La plataforma se elige en semanas. La integración la vas a vivir todos los días.
¿Quieres que revisemos la tuya? Agenda un diagnóstico gratuito.
