Conectar WooCommerce con Bsale o Defontana: qué se sincroniza y qué no

Casi toda integración entre WooCommerce y un ERP como Bsale o Defontana empieza con la misma frase: que todo se sincronice con todo. Suena razonable y es justamente ahí donde se rompe. Sincronizar es barato de prometer y caro de mantener: cada dato que viaja en las dos direcciones es un lugar donde dos sistemas pueden discrepar, y cuando discrepan, el que paga es el cliente que ve stock que no existe o un precio que no corresponde. Antes de conectar nada conviene responder una pregunta incómoda: para cada dato, ¿quién manda?

Qué se sincroniza y en qué dirección

No todos los datos son iguales. Algunos nacen en el ERP, otros nacen en la tienda, y muy pocos deberían ser editables en ambos lados. La regla simple es que cada dato tiene una sola fuente de verdad, y el otro sistema lo recibe en modo lectura. La dirección de la flecha no es un detalle técnico: es la decisión de negocio más importante de toda la integración.

Dato	Fuente de verdad	Dirección de sincronía
Stock disponible	ERP (Bsale / Defontana)	ERP → WooCommerce
Precio de lista y precios por cliente	ERP	ERP → WooCommerce
Ficha de producto (nombre, SKU, categoría)	ERP (catálogo maestro)	ERP → WooCommerce
Contenido de marketing (imágenes, descripción larga, SEO)	WooCommerce	Solo en WooCommerce
Pedidos / ventas web	WooCommerce	WooCommerce → ERP
Documento tributario (boleta / factura)	ERP	ERP → WooCommerce (número y PDF)
Cliente y su lista de precios asignada	ERP	ERP → WooCommerce

Lo que esta tabla deja en evidencia: casi todo viaja en un solo sentido. El único dato que sube de la tienda al ERP es el pedido. Cuando una integración intenta que el stock o el precio sean editables en ambos lados, no está agregando flexibilidad, está agregando un conflicto que tarde o temprano va a ocurrir.

El ERP manda en stock y precio. WooCommerce manda en pedidos

El stock y el precio son el inventario y la política comercial de la empresa. Esos números los decide quien controla bodega y facturación, no la web. Si un operador ajusta stock en el ERP por una merma y al mismo tiempo WooCommerce descontó por una venta, y ambos sistemas se creen dueños del número, el resultado es impredecible. Por eso el ERP escribe stock en WooCommerce y WooCommerce no escribe stock de vuelta jamás.

El pedido es lo contrario. Nace en la tienda, con todo su contexto: qué cliente, qué dirección de despacho, qué medio de pago, qué comuna. Ese pedido baja al ERP para que genere el documento y descuente inventario. La tienda no debería recibir de vuelta un pedido modificado por el ERP; recibe, a lo sumo, el número de documento y el cambio de estado. Mantener separadas estas dos autoridades es lo que evita el problema más caro de todos.

El doble descuento de stock

El error clásico: WooCommerce tiene activada la gestión de inventario nativa (manage_stock) y además el ERP descuenta al facturar. Una venta descuenta dos veces. En una tienda de bajo volumen pasa desapercibido; en una mayorista con cientos de líneas diarias, el catálogo se desangra hasta marcar agotado lo que sí hay. La regla: un solo sistema descuenta. Si el ERP es la fuente de verdad del stock, WooCommerce no debe descontar al confirmar el pedido, solo reflejar la cifra que el ERP le manda.

Los límites reales de las APIs

Las integraciones se diseñan en una pizarra como si los datos viajaran al instante. No viajan así. Tres realidades técnicas determinan qué es posible y qué no:

• Rate limits. Las APIs de Bsale y Defontana imponen un techo de llamadas por minuto. Un catálogo de 8.000 SKU no se puede consultar uno por uno cada cinco minutos sin chocar contra el límite. Hay que sincronizar por lotes y por diferencias, no por fuerza bruta.
• Paginación. Ninguna API entrega 8.000 productos en una sola respuesta. Vienen en páginas de 25, 50 o 100. Una sincronización que no maneja bien la paginación termina leyendo siempre la primera página y creyendo que el catálogo tiene 50 productos.
• Webhooks vs. polling. El webhook avisa cuando algo cambió y es eficiente, pero no todos los eventos tienen webhook confiable y un webhook perdido es un cambio que nunca llegó. El polling (preguntar cada X minutos) es robusto pero introduce latencia y consume rate limit. En la práctica se combinan: webhook para reaccionar rápido, polling de respaldo para reparar lo que el webhook no entregó.
• Latencia. Entre que el stock cambia en el ERP y se refleja en la web siempre hay una ventana. Puede ser de segundos o de minutos. Esa ventana existe; el diseño honesto la asume y la acota, no pretende que es cero.

Errores comunes que cuestan ventas

Además del doble descuento, hay un puñado de fallas que aparecen en casi toda integración mal planteada:

• SKU que no calzan. El identificador que une un producto del ERP con su par en WooCommerce es el SKU. Si el ERP usa PROD-001 y la web prod001, el match falla y se crean productos duplicados o se actualiza el equivocado. El SKU tiene que ser idéntico, único y estable de los dos lados antes de conectar nada.
• Pedidos duplicados. Si el reintento ante un error no es idempotente, un pedido que falló a medio camino se reenvía y el ERP genera dos documentos. Cada envío de pedido debe llevar una clave única para que el ERP reconozca un reintento y no lo procese dos veces.
• Desfase de stock en alta demanda. En una liquidación o un lanzamiento, varios clientes compran la misma unidad dentro de la ventana de latencia. La web mostraba 3 unidades, se vendieron 5. Esto no se resuelve con más sincronización, sino reservando stock al confirmar el carro y validando contra el ERP antes de cerrar la venta crítica.

Una arquitectura que aguanta

La arquitectura que se sostiene en el tiempo es de una sola dirección por dato, con el ERP como maestro de inventario, precios y catálogo, y WooCommerce como origen único de los pedidos. En el medio conviene una capa de integración que normalice formatos, respete los rate limits, registre cada operación y reintente de forma idempotente. No es la opción más rápida de demostrar, pero es la que no te despierta a las dos de la mañana con el catálogo en cero.

La sincronía "todo con todo" no es más completa, es más frágil. Cada dato bidireccional duplica los caminos por donde dos sistemas pueden contradecirse.

La decisión de fondo es anterior al código. No se trata de qué API soporta qué método, sino de definir, dato por dato, quién es la autoridad. El stock manda desde bodega. El precio manda desde la política comercial. El pedido nace en la tienda. Esa repartición de autoridad es la integración; el resto es cómo la implementas. Si esa pregunta queda sin responder antes de conectar Bsale o Defontana con WooCommerce, ningún conector la va a responder por ti, y el desfase entre lo que tu tienda dice y lo que tu empresa tiene será solo cuestión de tiempo.