WooCommerce B2B: tarifas, precios por cliente y condiciones comerciales desde el ERP
Tu cliente profesional inicia sesión en WooCommerce B2B y espera encontrar su precio. Después añade más unidades y el carrito aplica otra condición. La oferta que parecía resuelta en la ficha acaba dependiendo de varios mecanismos.
El ERP puede mantener tarifas y acuerdos, mientras una extensión de WooCommerce representa las reglas B2B. Conectar ambos exige decidir qué se envía y qué parte calcula la tienda.
Seguiremos una caja de envases para comparar un precio final con una regla de descuento y comprobar qué debe conservar el pedido.
WooCommerce B2B: reconocer al cliente y sus condiciones
Imagina que distribuyes envases. Una tienda pequeña compra ocasionalmente; una cadena utiliza una tarifa profesional; otro cliente tiene un precio pactado para varios formatos.
Los tres pueden comprar el mismo producto, pero su contexto comercial es diferente.
El ERP puede mantener esa relación mediante tarifas, cuentas y condiciones. WooCommerce reconoce usuarios y la información que utilicen sus módulos.
La integración debe relacionar ambos modelos.
Si falta la correspondencia, el cliente puede ver un precio general aunque la tarifa profesional se haya sincronizado correctamente. Si la cuenta se asocia a otra relación comercial, el error afectará a toda la compra.
Por eso conviene comprobar primero quién compra. Los identificadores estables ayudan a conservar esa relación; los criterios alternativos deben responder a la forma en que la empresa organiza sus cuentas.
El precio estándar y la regla B2B cumplen funciones distintas
Una actualización del precio general del producto afecta a su oferta estándar. Para representar condiciones por rol o por cliente puede participar una extensión con su propio modelo de reglas. Antes de conectar datos del ERP necesitamos conocer la función de cada valor en esa tienda.
Como ejemplo de mecanismo, la documentación de Roles & Rules B2B describe ajustes por rol y reglas de producto. Es una extensión concreta; no se presenta como función nativa universal ni como integración ya verificada con Distillsync.
Pensemos ahora en una política hipotética: una caja tiene 20 € de precio base y el grupo profesional recibe el 10 % de reducción. El destino puede obtener 18 € al aplicar la regla sobre aquella base.
Si el ERP entrega directamente 18 € y se sustituye con ese importe la base sobre la que actúa la misma reducción, el carrito podría calcular 16,20 €. El problema estaría en haber enviado un resultado final a un lugar que el destino interpreta como base.
| Representación del ejemplo | Dato preparado | Interpretación necesaria en destino |
|---|---|---|
| Base más regla | 20 € y reducción profesional del 10 % | Resolver 18 € una sola vez |
| Precio final por contexto | 18 € para ese comprador y referencia | Utilizar ese resultado sin repetir la reducción |
Ambas representaciones necesitan un mecanismo compatible. Una API de productos no implica que cualquier campo privado de una extensión pueda mantenerse de la misma manera. La configuración debe utilizar la interfaz documentada de la solución instalada.
Distillsync permite preparar consultas y transformaciones en tareas. En este caso, la decisión clave es qué representa el importe antes de enviarlo. La guía WooCommerce–ERP aporta el contexto del intercambio.
Un precio por grupo y uno por cliente necesitan prioridades
Supongamos que un grupo profesional recibe un precio y una cuenta concreta tiene una excepción.
La integración necesita saber qué resultado espera el negocio. ¿La excepción sustituye al precio del grupo? ¿Solo afecta a ciertas referencias? ¿Tiene fecha de finalización?
También hay que distinguir datos y resultados. El ERP puede proporcionar un precio final o componentes que todavía deben combinarse. La tienda debe reconocer qué está recibiendo.
Si el valor ya incluye el descuento del cliente y WooCommerce vuelve a aplicar la misma reducción, el resultado cambiará.
Una prueba útil mantiene cliente y producto y modifica una sola condición: cantidad, fecha o pertenencia a grupo. Así es más fácil explicar por qué cambia el precio.
| Situación | Comprobación |
|---|---|
| Cliente sin condiciones específicas | Oferta general prevista |
| Usuario profesional relacionado | Tarifa o regla de su cuenta |
| Referencia con excepción | Prioridad y alcance |
| Cantidad distinta | Tramo o descuento que corresponda |
| Promoción activa | Combinación con otras condiciones |
El carrito debe conservar la oferta que acabas de comprobar
El comprador encuentra un precio en la ficha, añade unidades y continúa al carrito.
En ese recorrido pueden intervenir cantidades, promociones y otros elementos de la configuración de la tienda. Conviene comprobar la compra completa.
Si validamos únicamente la ficha del producto, quizá no veamos qué sucede al cambiar la cantidad o al confirmar. El precio que importa es el que corresponde a la operación aceptada bajo sus condiciones.
También hay que conservar claridad cuando el usuario cambia de contexto. Puede entrar como visitante y después iniciar sesión, o utilizar otra cuenta comercial si el modelo de la tienda lo permite.
Las condiciones deben aplicarse al comprador y al pedido adecuados. La experiencia visible y la información enviada al ERP tienen que poder relacionarse.
Esto permite atender una consulta posterior sin tener que adivinar qué vio el cliente.
Cambiar de usuario también cambia el contexto de precio
El comprador entra como visitante, añade una caja de envases a 20 € y después inicia sesión con su cuenta profesional. En el ejemplo, el precio aplicable pasa a 18 €. La tienda debe resolver el carrito con el contexto reconocido antes de confirmar la operación.
Después sale de esa cuenta. Un carrito o una respuesta conservada de la sesión anterior no debería mostrar el precio profesional a quien ya no compra con aquellas condiciones. El resultado depende también del tema, la extensión y los mecanismos de caché utilizados; por eso se recorre la experiencia completa, además de revisar el dato guardado.
La prueba utiliza un visitante, una cuenta profesional y la cuenta con acuerdo de 17,50 €. En cada caso seguimos ficha, carrito y confirmación. Mantenemos la misma caja y cantidad para que el cambio solo dependa del comprador.
Si la ficha tiene el precio correcto y el carrito conserva otro, la revisión se centra en la aplicación de la regla durante ese cambio de contexto. Si ambas pantallas utilizan un importe ajeno a la cuenta, revisamos primero la relación y el mecanismo que seleccionó la condición.
La información que llega al ERP debe corresponder a la compra confirmada. Volver a mirar el precio de la ficha más tarde puede mostrar una tarifa nueva o un contexto diferente. El pedido conserva la referencia que permite explicar aquella operación.
Esto ayuda a mantener una oferta consistente al cambiar la extensión o el tema. Las tres compras conocidas continúan siendo la referencia comercial, aunque la forma de representarlas en WooCommerce haya evolucionado.
El pedido necesita conservar las condiciones aplicadas
Cuando la compra llega al ERP, necesitamos reconocer cuenta, referencias, cantidades, importes y referencia de origen.
Si el circuito incluye una validación o un recálculo, conviene distinguir esa actuación de la oferta aceptada en WooCommerce. El negocio debe decidir cómo tratar cualquier discrepancia.
Supongamos que una tarifa cambia mientras hay Pedidos pendientes de incorporar. Mantener la información del pedido permite saber con qué condiciones se confirmó aquella compra, aunque la configuración comercial actual sea otra.
El mismo criterio ayuda con descuentos por cantidad y promociones que terminan. El estado actual de una campaña no debe borrar el contexto necesario para explicar una operación anterior.
Distillsync prepara intercambios mediante tareas configurables. Las decisiones sobre cómo conservar y revisar esa información deben reflejar el proceso comercial de la empresa.
Consulta el módulo de Precios y tarifas.
Mantener una responsabilidad evita cambios cruzados
Administración actualiza condiciones en el ERP. Marketing prepara campañas en la web. Ambos trabajos pueden convivir si sabemos qué mantiene cada equipo.
La dificultad aparece cuando una actualización sustituye una decisión que pertenecía al otro sistema y nadie puede explicar por qué.
Haz visible la distribución: dónde nace la tarifa, quién mantiene las excepciones y qué datos necesita WooCommerce para presentarlas. Añade cómo se tratan las promociones del canal.
Para una agencia, esta explicación suele ser más útil que enumerar todos los campos de la extensión. Permite hablar con el cliente sobre decisiones que conoce y después traducirlas a su configuración.
Si cambias de módulo o evolucionas la tienda, conservar esa descripción ayuda a comprobar qué comportamiento debe permanecer.
Una cuenta con excepción comprueba el recorrido completo
Añadimos un cliente que ha pactado 17,50 € por caja. El negocio decide que ese acuerdo sustituya a la condición profesional para esta referencia. El ejemplo no establece la prioridad de ninguna extensión: define el comportamiento que la tienda tiene que poder representar.
Con dos cajas, la compra de ese cliente suma 35 € antes de otros conceptos. Una cuenta profesional sin excepción obtiene dos cajas a 18 €, suma 36 €. Comparar ambas permite saber si se ha conservado la relación entre cuenta y acuerdo.
Después el comprador vuelve a la ficha, cambia la cantidad y confirma. Si el precio correcto solo aparece en la ficha y el carrito vuelve a 18 €, la condición no acompaña todo el recorrido. Si el pedido llega al ERP con 20 €, la representación de la compra se ha perdido al preparar el destino.
Esta muestra también sirve al actualizar o cambiar la extensión. Se revisan las mismas compras conocidas y sus resultados, aunque hayan cambiado las pantallas y campos que representan las reglas. La explicación de catálogo por cliente sitúa la personalización; aquí comprobamos la continuidad del precio hasta la operación aceptada.
Tu precio B2B debe poder explicarse de principio a fin
La oferta profesional incluye quién compra, qué cantidad pide y qué condiciones le corresponden. Mostrarla online exige mantener ese contexto durante toda la operación.
Distillsync utiliza un modelo semántico común y tareas configurables para coordinar información entre aplicaciones. Puedes probar una compra conocida y revisar cómo se representan sus decisiones.
El cliente encuentra una oferta reconocible. Tu equipo puede continuar el pedido con información suficiente para entenderla.
Descubre Distillsync para WooCommerce o crea tu cuenta y empieza a probarlo.