Quién manda en el stock y en el precio cuando conectas la tienda online con el ERP

En una integración entre ERP y tienda online, el stock y los precios son los dos campos donde antes se nota que algo no cuadra: se vende la última unidad de una referencia agotada ayer, sale una factura con un importe distinto al que vio el comprador y nadie sabe dónde se edita la descripción de un artículo.

Antes de mirar la API conviene comprobar otra cosa: si alguien decidió, campo a campo, qué sistema es dueño del dato, quién recibe copia y qué ocurre cuando los dos escriben. Ese reparto determina qué hay que desarrollar y debería estar cerrado antes de pedir presupuesto de ningún conector.

Dato maestro: un campo, un dueño

El dueño de un campo es el sistema donde ese campo se crea y se modifica. El resto lo recibe como copia, en modo lectura: una copia se muestra, se cachea, se indexa y se usa para vender; no se edita.

Cuando dos sistemas escriben el mismo campo sin una regla clara, el valor que queda depende del orden de llegada de los mensajes: el almacén ajusta a 9 unidades, la web había escrito 12, el mensaje de la web llega con retraso y queda 12. Nadie ha hecho nada mal y el stock está mal.

La sincronización bidireccional tiene sentido entre campos distintos —el ERP manda el stock hacia la web y la web manda los pedidos hacia el ERP—, pero sobre el mismo campo crea dos fuentes de verdad. Y el ERP no es dueño de todo por defecto: pesa más en una empresa con almacén propio y facturación consolidada que en un negocio nativo digital cuyo catálogo y promociones se construyen en la web.

Propiedad por campo, no por sistema

«¿Quién gestiona el stock, el ERP o la tienda online?» no tiene respuesta útil en abstracto. «¿Quién escribe el número de stock que ve el comprador?», sí. El mismo producto puede tener el precio en el ERP y el texto en la web; el problema aparece cuando los dos sistemas creen que mandan en el mismo atributo. En un proyecto de tienda online que arranca de cero, esa decisión se toma antes de elegir plataforma; en una tienda en marcha, antes de contratar el conector.

Matriz de propiedad del dato entre ERP y tienda online

Una línea por dato, con sistema dueño, quién recibe copia, cada cuánto se actualiza y qué gana si hay conflicto. Cópiala en un documento, rellena «Tu decisión» con operaciones y con quien lleva la web, y entrégala al proveedor antes de que escriba una línea de código.

1. SKU y catálogo base · Dueño: ERP · Copia: web · Frecuencia: por evento al crear o modificar · Conflicto: gana el ERP; la web no crea referencias · Tu decisión: __
2. Descripción, imágenes y contenido SEO · Dueño: web · Copia: ERP (solo la descripción corta) · Frecuencia: al publicar · Conflicto: gana la web · Tu decisión: __
3. Precio base · Dueño: ERP · Copia: web · Frecuencia: por evento · Conflicto: gana el ERP · Tu decisión: __
4. Tarifas y descuentos por cliente · Dueño: ERP · Copia: web (ya resuelta para el cliente identificado) · Frecuencia: por evento y al iniciar sesión · Conflicto: gana el ERP · Tu decisión: __
5. Promociones y cupones · Dueño: web · Copia: ERP (como descuento identificado en la línea) · Frecuencia: viaja con el pedido · Conflicto: gana la web; el ERP contabiliza el descuento con su código · Tu decisión: __
6. Stock físico por almacén · Dueño: ERP · Copia: web · Frecuencia: por evento en referencias críticas, programada en el resto · Conflicto: gana el ERP · Tu decisión: __
7. Stock publicable · Dueño: ERP (o la capa de integración, si el cálculo se hace fuera) · Copia: web · Frecuencia: recálculo al cambiar cualquiera de sus componentes · Conflicto: gana el recálculo, sin edición manual · Tu decisión: __
8. Stock reservado en checkout · Dueño: web · Copia: ERP (si la reserva debe respetarse en almacén) · Frecuencia: tiempo real, con caducidad · Conflicto: gana la web hasta que la reserva caduca · Tu decisión: __ (reservar también en el carrito es una decisión aparte: baja la sobreventa y baja la disponibilidad publicada)
9. Ficha de cliente · Dueño: ERP · Copia: web · Frecuencia: por evento · Conflicto: gana el ERP, con cola de revisión manual para duplicados · Tu decisión: __
10. Pedido · Dueño: ERP (la web lo crea y lo entrega) · Copia: web, que recibe estado y seguimiento · Frecuencia: por evento en los dos sentidos · Conflicto: gana el ERP · Tu decisión: __
11. Factura · Dueño: ERP · Copia: web (solo para descarga) · Frecuencia: por evento al emitirse · Conflicto: gana el ERP; la web no emite ni numera · Tu decisión: __
12. Devolución y abono · Dueño: ERP · Copia: web, para mostrar el estado · Frecuencia: por evento · Conflicto: gana el ERP · Tu decisión: __

En B2C la lista queda más ligera: precio único, un almacén publicable y un alta de cliente que puede nacer en la web y consolidarse en el ERP con el primer pedido. En B2B se complican esas mismas líneas: el maestro de clientes y el de tarifas vive en el ERP, donde está la relación comercial completa, y el stock por almacén condiciona lo que ve cada cliente.

Stock: cuatro números y solo uno se publica

• Físico: lo que hay en la estantería.
• Comprometido: pedidos aceptados y todavía no servidos.
• Reservado: unidades bloqueadas por checkouts en curso; y por carritos solo si se decide reservar también ahí.
• Publicable: el número que se muestra en la ficha.

stock publicable = físico de los almacenes que publican − comprometido − reservado − stock de seguridad

Una referencia con 40 unidades en el almacén central y 6 en la tienda física, que no publica, con 5 comprometidas, 2 reservadas en checkout y un buffer de 3: publicable = 40 − 5 − 2 − 3 = 30. Las 6 de la tienda no entran en el cálculo.

Los kits obligan a un cálculo aparte: el que se ensambla al servirlo depende del componente que antes se agota; un pack premontado con referencia propia tiene stock propio. Lotes con caducidad, mercancía en tránsito, devoluciones pendientes de revisar y productos bajo pedido se deciden uno a uno. Publicar el número exacto del ERP tampoco es la opción neutra: cualquier desfase de sincronización expone unidades ya comprometidas.

Cómo evitar la sobreventa sin dejar de vender

Un buffer global generoso también cuesta dinero: deja de vender referencias que sí tenías.

1. Buffer por familia, no global: la rotación alta necesita colchón; la referencia que se mueve dos veces al mes, no.
2. Reserva al entrar en el checkout, con caducidad corta.
3. Rangos y avisos: «últimas unidades» aguanta un desfase que «quedan 3» no perdona.
4. Backorder explícito con fecha: vender sin stock funciona si el comprador lo sabe antes de pagar.
5. Bloqueo de venta solo en referencias críticas, las que no puedes reponer.

El número que ordena esas decisiones es el desfase que aguantas, y sale de tus datos: unidades que vende la referencia en su hora punta por las horas que tarda la sincronización. Cuatro por hora con una consulta programada cada tres horas dan del orden de doce unidades expuestas; compáralo con el buffer de esa familia y decide qué referencias piden sincronización por evento. Y ten escrito el protocolo de sobreventa: avisar antes de que lo descubra el cliente, ofrecer alternativa y reembolsar sin fricción.

Precio: qué versión gana cuando web y ERP no coinciden

El precio base es la parte fácil. La complicación son las capas: tarifa por cliente, por canal, por volumen, condiciones negociadas y descuentos en cascada. En B2B esa lógica ya vive en el ERP; duplicarla en la web crea dos versiones de la tarifa que hay que mantener a mano, así que lo razonable es que la web reciba la tarifa ya resuelta para el cliente identificado y no la recalcule. En B2C, con precio único y campañas que nacen en marketing, la parte promocional se reparte al revés.

Luego están los impuestos: precios con y sin IVA, redondeo por línea o sobre el total, importes que difieren en dos céntimos y cuadran mal en contabilidad. Si la web recalcula el impuesto con una regla distinta a la del ERP, el desajuste se repite en cada pedido. En ventas a otros países de la UE, la normativa aplicable fija las obligaciones y una asesoría fiscal puede determinar cómo se aplican a tu caso; para la integración lo relevante es que el importe final lo calcule un solo sistema. Las promociones nacidas en la web deben viajar al ERP como descuento identificado, con su código, y no escondidas en un precio unitario raro: es lo que permite analizar después el margen de la campaña.

Y el principio que ahorra media discusión: el pedido congela el precio en el momento de la compra. Si el ERP sube la tarifa un minuto después, la factura se emite con el precio del pedido. Si el importe final lo calcula el ERP, la web no inventa totales; y si la web muestra un total en el checkout, lo hace con las mismas reglas y el ERP lo acepta como dato del pedido.

Reglas de conflicto y permisos: la parte organizativa

Entre las estrategias posibles, estas tres son fáciles de explicar y de auditar:

• Gana el dueño del campo: predecible, la recomendable para stock y precio; no resuelve los pocos campos que de verdad necesitan dos orígenes.
• Gana la última escritura con marca de tiempo: aceptable en contenido de bajo riesgo; arriesgada en todo lo que afecta a lo que se cobra.
• Cola de revisión manual: encaja en fichas de cliente, donde un duplicado con el mismo CIF necesita ojos humanos; inviable en stock por volumen.

La parte organizativa es una partida del alcance y hay que pedirla explícitamente: campos en modo lectura en el sistema que no los posee, permisos por rol —contenidos no debería ver la casilla de precio— y un procedimiento escrito para las ediciones de urgencia, que las va a haber. Antes de buscar el fallo en el código, descarta el uso: una edición hecha fuera del sistema dueño produce un descuadre idéntico al de un error técnico.

Cómo viajan los datos y hasta dónde llega un conector estándar

El stock y los precios no tienen por qué viajar por el mismo camino. El sistema dueño puede avisar en cuanto algo cambia, con eventos o webhooks: interesa en las referencias críticas y en el precio, y exige colas, reintentos idempotentes y control del orden de los mensajes. La consulta programada es más simple, tolera sistemas que no emiten eventos y, a cambio, añade latencia. Se pueden combinar, guardando en cada sistema la clave del otro para emparejar registros. Pide por escrito un contraste completo periódico —nocturno, por ejemplo— que compare campo a campo, con un umbral y un destinatario del aviso: si no está en el alcance, el descuadre lo encontrará un cliente.

Un conector de mercado resuelve bien lo que resuelve: campos habituales, ERPs extendidos con módulo mantenido, un almacén, precio único y volúmenes moderados. En una integración con WooCommerce, el catálogo y el stock viven en la base de datos de WordPress y el plugin escribe ahí; con la matriz decidida, en muchos casos basta, y sin esa decisión el mismo conector reproduce el descuadre. El desarrollo específico se justifica cuando aparecen tarifas por cliente con reglas propias, kits con stock calculado, reservas y backorder, multialmacén con lógica de publicación o casuística fiscal particular: ahí ya no se instala un plugin, se desarrolla una integración a medida. Y si el sistema de gestión es propio o muy personalizado, la conversación se acerca a un desarrollo de ERP a medida. Vigila el caso intermedio: el conector funciona, pero para funcionar obliga a que la web mande en un campo que debía mandar el ERP.

Checklist de ocho preguntas antes de firmar la integración

Una oferta se reconoce por si responde a estas ocho preguntas por escrito, en vez de resolverlas de palabra en una llamada.

1. ¿Está cerrada la lista de campos, con dueño y dirección de cada uno?
2. ¿Qué frecuencia tiene cada flujo y qué desfase máximo se acepta en cada campo?
3. ¿Qué ocurre si el ERP está caído? ¿Y si lo está la web? ¿Se encola, se bloquea la venta, se sirve la última copia conocida?
4. ¿Hay entorno de pruebas con datos anonimizados?
5. Cuando aparezca un descuadre, ¿quién lo diagnostica, quién lo corrige y cómo se comunica?
6. ¿El registro de errores es accesible para tu equipo o solo para el proveedor?
7. ¿Quedan definidas la documentación y la propiedad del código?
8. ¿Está el alcance escrito campo a campo, y no como «integración con ERP»?

El octavo punto es el que permite comparar dos ofertas: el presupuesto detalla el alcance del trabajo, y con la matriz rellenada encima de la mesa la conversación con cualquier proveedor cambia de tema, de «cuánto cuesta un conector» a «cuánto cuesta esto, campo a campo».

Cómo trabajamos en Bolmia

Habitualmente empezamos con una primera conversación para conocer la situación del proyecto y el punto en el que se encuentra el cliente; si procede, damos alguna recomendación puntual. Cuando hay que entrar a fondo en los datos, la auditoría es un servicio de pago. Hemos desarrollado una tienda online en WordPress con una plantilla a medida; su responsable contrató después SEO y publicidad online y sigue trabajando con nosotros. Cómo planteamos los proyectos está explicado en nuestro enfoque de trabajo, y hay trabajos publicados en casos de clientes.

Si la web y el ERP ya no dicen lo mismo, el primer paso no es contratar un conector: es decidir quién manda en cada campo. Cuéntanos en qué punto está tu integración y vemos la situación del proyecto.