Los precios B2B por cliente no deben modelarse como copias del catálogo ni como una cadena de descuentos acumulados. El modelo más fiable separa cuatro cosas: quién compra (cuenta, empresa o delegación), qué puede comprar (catálogo y surtido), qué precio contractual le corresponde (moneda, unidad, vigencia y escalados) y qué regla gana cuando coinciden varias condiciones. Esa precedencia debe calcularse igual en la ficha de producto, el carrito, el checkout, el pedido y el ERP.
Si una tarifa sólo es correcta en la pantalla pero cambia al enviar el pedido, el sistema no tiene un modelo de precios: tiene varias interpretaciones incompatibles. El objetivo operativo es que una misma entrada —cuenta, SKU, cantidad, fecha, mercado, moneda y unidad de venta— produzca siempre el mismo precio explicable.
El error de partida: confundir catálogo, tarifa y descuento
En B2B, el catálogo responde a la pregunta «¿este cliente puede ver y comprar este producto?». La tarifa responde a «¿cuál es el precio base autorizado para esta cuenta?». El descuento responde a «¿qué ajuste adicional es aplicable a esta operación?». Mezclarlos crea excepciones difíciles de auditar: productos duplicados, promociones que pisan contratos, importes públicos visibles a cuentas privadas o precios distintos entre ecommerce y ERP.
Una arquitectura mantenible conserva un único identificador de producto y relaciona el SKU con reglas de acceso y precio. Sólo conviene duplicar un producto cuando realmente cambia su identidad comercial o logística, no para representar cada contrato.
La clave de cálculo mínima
Antes de elegir plataforma, define la clave que identifica una decisión de precio. Como mínimo debería incluir:
- account_id o company_location_id: la entidad contractual que compra, no sólo el usuario conectado.
- sku o variant_id: la unidad comercial exacta.
- quantity: cantidad expresada en la unidad sobre la que se negoció el precio.
- unit_of_measure: unidad, caja, pallet, metro o kilogramo, con su factor de conversión.
- currency y market: moneda y ámbito fiscal o geográfico.
- effective_at: fecha y hora de validez del contrato.
- channel: ecommerce, comercial, EDI o portal si las condiciones autorizadas difieren.
El usuario es una credencial; la cuenta o delegación es la contraparte comercial. Si una persona compra para varias empresas, el sistema debe obligarla a seleccionar la cuenta activa y recalcular catálogo, crédito, impuestos y precios. Heredar la última cuenta sin mostrarla es una fuente clásica de pedidos mal valorados.
Una jerarquía de precios que se pueda explicar
No existe una jerarquía universal, pero sí una condición obligatoria: debe estar escrita, versionada y probada. Un ejemplo razonable es:
- Precio contractual por cuenta + SKU, vigente y en la moneda/unidad solicitadas.
- Precio contractual por grupo de cuentas + SKU, si no existe una excepción individual.
- Tarifa del catálogo asignado a la empresa o delegación.
- Precio B2B general del mercado, sólo si el contrato permite una alternativa general.
- Sin precio vendible: solicitud de cotización o bloqueo explícito.
Dentro del nivel ganador se aplican, en un orden definido, los escalados por cantidad y los descuentos permitidos. No hay que asumir que «el precio más bajo» es siempre la regla correcta: puede vulnerar un contrato, consumir margen o combinar dos incentivos incompatibles. Algunas plataformas eligen el menor importe entre catálogos elegibles; otras aplican una lógica de selección por ámbito. Por eso la regla de negocio debe ser propia y no una consecuencia accidental del motor.
Ejemplo de resolución
| Dato | Valor | Decisión |
|---|---|---|
| Cuenta | ACME Barcelona | Contrato C-2026-041 |
| SKU / unidad | VAL-80 / caja de 10 | No convertir desde precio unitario sin regla autorizada |
| Fecha | 15/10/2026 | Versión contractual vigente desde 01/10/2026 |
| Cantidad | 20 cajas | Tramo 20–49 |
| Precio resuelto | 184,00 EUR/caja | Contrato individual; promoción general excluida |
La respuesta del servicio de precios debería devolver no sólo 184.00, sino también moneda, unidad, precio neto o bruto, identificador y versión de la regla, fechas de validez y motivo de selección. Sin esa explicación, soporte no puede reconstruir una incidencia.
Contratos, volumen y promociones: decidir la acumulación
Cada regla necesita un atributo de compatibilidad. Para cada contrato define si el precio es:
- neto y final: excluye promociones y cupones;
- base negociada: admite determinados descuentos posteriores;
- por volumen: sustituye el precio al alcanzar un tramo;
- retroactivo: se liquida fuera del pedido mediante rappel o abono;
- cotizable: requiere aprobación antes de convertirse en pedido.
Los mínimos, máximos e incrementos de compra deben evaluarse sobre la misma variante y unidad que los escalados. Si el producto se vende en cajas de 10, un tramo de 100 unidades equivale a 10 cajas sólo cuando la conversión está gobernada y no cambia por mercado o presentación. Shopify documenta, por ejemplo, que sus reglas de cantidad y precios por volumen se aplican a variantes y que los tramos deben respetar mínimos e incrementos. Es una buena señal de diseño para cualquier implementación, aunque se utilice otra plataforma.
Qué sistema debe ser dueño de cada dato
| Dato | Fuente maestra habitual | Responsabilidad del ecommerce |
|---|---|---|
| SKU, unidad y conversión | ERP o PIM | Validar que la variante comprada coincide |
| Cuenta, grupo y delegación | ERP o CRM | Resolver la identidad activa de compra |
| Contrato y vigencia | ERP/CPQ | Consumir una versión publicada y trazable |
| Surtido visible | PIM/commerce | Aplicar catálogo por cuenta o ubicación |
| Precio mostrado | Servicio de precios | No recalcularlo con lógica divergente |
| Precio aceptado en pedido | Commerce + validación ERP | Guardar regla, versión y desglose |
Evita que ERP y ecommerce editen la misma regla. El patrón más estable es publicar una versión inmutable de la tarifa, activarla en una fecha y conservar la anterior para auditoría. Si llega una corrección, se publica una versión nueva; no se sobrescribe silenciosamente la que valoró pedidos existentes.
Sincronización y validación contra el ERP
La importación de precios no termina cuando el archivo o API responde «correcto». Debe haber reconciliación:
- contar reglas recibidas, aceptadas, rechazadas y caducadas;
- validar moneda, unidad, SKU, cuenta, fechas solapadas y tramos;
- comparar una muestra determinista de precios entre origen y destino;
- publicar la versión sólo si supera los umbrales;
- emitir una alerta con los identificadores rechazados;
- revalorar el pedido en ERP y bloquear la confirmación si la diferencia supera la tolerancia autorizada.
El ecommerce debe enviar al ERP el precio, el identificador de la regla y su versión. Si el ERP responde con otro importe, no conviene sustituirlo en silencio: el comprador necesita saber si el pedido queda retenido, requiere aprobación o debe recalcularse.
Caché y privacidad: un precio privado nunca puede cruzar cuentas
La caché de una ficha o API debe variar, como mínimo, por cuenta o catálogo efectivo, mercado, moneda, unidad y estado de autenticación. Una URL común con HTML cacheado sólo por ruta puede mostrar a un cliente el precio de otro. Para contenido público, separa el bloque cacheable del precio privado; para APIs, usa claves explícitas y evita cachear respuestas personalizadas en redes compartidas.
Los precios contractuales no deberían aparecer en datos estructurados públicos, feeds abiertos, buscadores internos anónimos ni fragmentos generados del lado del servidor antes de resolver la cuenta. Al cerrar sesión o cambiar de empresa, invalida carrito, precio y permisos asociados a la identidad anterior.
Qué hacer cuando falta un precio
Un cero, el precio público o el último valor cacheado no son alternativas seguras. Define por contrato uno de estos resultados: bloquear compra con explicación, permitir solicitud de cotización, recuperar el precio en tiempo real o usar una tarifa general expresamente autorizada. Registra el motivo y alerta si crece la tasa de productos sin precio.
Durante una caída del ERP, la continuidad puede apoyarse en la última versión publicada y aún vigente, nunca en una versión expirada sin señalización. La empresa debe fijar cuánto tiempo es aceptable operar así y qué pedidos requieren revisión posterior.
Pruebas antes de publicar
Una batería mínima debe incluir:
- dos usuarios de la misma cuenta obtienen el mismo resultado;
- un usuario con dos empresas cambia de contexto sin arrastrar precios ni carrito;
- dos cuentas con el mismo SKU ven sus tarifas correctas;
- el segundo exacto de inicio y fin de vigencia resuelve la versión esperada;
- mínimo, incremento y cada frontera de volumen (por debajo, exacta y por encima);
- cambio de moneda, mercado y unidad sin conversiones implícitas;
- contrato incompatible con promoción o cupón;
- producto sin tarifa, tarifa caducada y cuenta sin catálogo;
- ficha, carrito, checkout, pedido, email y ERP muestran el mismo desglose;
- caché fría, caché caliente, cierre de sesión y cambio de cuenta no filtran precios.
Métricas que detectan una degradación real
Controla el porcentaje de líneas sin precio, diferencias ecommerce–ERP, pedidos retenidos por valoración, latencia del servicio de precios, reglas rechazadas al importar y reclamaciones por discrepancia. Segmenta por cuenta, mercado, catálogo y versión; una media global puede ocultar que un contrato concreto ha quedado fuera de sincronía.
Para contrastar este modelo con implantaciones reales, revisa también los patrones que separan una transformación B2B real de un simple rediseño.
Preguntas frecuentes
¿Conviene crear una tarifa por cliente?
Sólo cuando existe una condición realmente individual. Si cientos de cuentas comparten condiciones, usa un grupo o catálogo común y añade excepciones por cuenta. Así reduces reglas duplicadas sin perder precisión contractual.
¿Debe mostrarse el precio antes de iniciar sesión?
Depende de la política comercial. El precio público puede mostrarse a visitantes, pero nunca debe confundirse con el contractual. Si todo el precio es privado, muestra acceso o solicitud de cuenta y evita exponerlo en HTML, feeds o datos estructurados públicos.
¿Qué ocurre si coinciden dos contratos?
La carga debe rechazar el solapamiento o resolverlo mediante una prioridad explícita. Elegir el menor precio o la última fila importada sin una regla aprobada convierte el resultado en impredecible.
¿Dónde se calculan los impuestos?
El modelo de precios debe declarar si los importes son netos o brutos y quién determina el régimen fiscal. El impuesto puede depender de la dirección, el tipo de cliente y el producto; no debe incrustarse de forma ambigua dentro de una tarifa contractual.
Fuentes primarias para contrastar el modelo
- Shopify: catálogos y precios B2B, para asignación de catálogos, empresas y ubicaciones.
- Shopify: reglas de cantidad y precios por volumen, para mínimos, incrementos y tramos por variante.
- commercetools: selección de precios y descuentos, para ámbitos, grupos de clientes y precedencia.
- Adobe Commerce: catálogos compartidos, para alcance, precios personalizados y asignación a empresas.
Siguiente paso
Antes de migrar tarifas o añadir descuentos, construye una tabla de decisión con diez pedidos reales y obliga a que negocio, ecommerce y ERP expliquen el mismo resultado. Si necesitas revisar la arquitectura, la jerarquía y las pruebas de tu caso, consulta los recursos de CODE B2B.