Cómo implementar un sistema de comercio electrónico B2B con catálogo personalizado y precios por cliente en Drupal

El comercio electrónico entre empresas arrastra una paradoja bastante llamativa: las transacciones B2B representan más del 70 % del volumen total del ecommerce global —según datos de Statista para 2025—, y sin embargo la mayoría de plataformas siguen pensadas para el consumidor final. A ver, un fabricante de componentes industriales que vende a 300 distribuidores necesita algo radicalmente distinto a una tienda con carrito y pasarela de pago estándar. Necesita catálogos que varíen según quién se conecte, tarifas negociadas contrato a contrato, flujos de aprobación internos y un back-office que no obligue a duplicar productos para cada cliente.

Drupal, combinado con Drupal Commerce, ofrece una arquitectura que resuelve estos requisitos sin forzar workarounds. Vamos al grano: aquí describo paso a paso cómo montar ese sistema, desde la estructura de datos hasta la lógica de precios y la experiencia de compra.

Por qué Drupal encaja en el B2B mejor que las plataformas convencionales

Las soluciones de ecommerce generalistas parten de un supuesto simple: un producto tiene un precio y cualquier visitante lo ve igual. El B2B rompe ese supuesto en tres puntos:

• Visibilidad selectiva del catálogo. El distribuidor A accede a la línea premium; el distribuidor B solo ve producto estándar. Un mismo SKU puede estar visible para unos y oculto para otros.
• Precios variables por cliente o grupo. El precio de lista es solo el punto de partida. Cada cuenta negociada tiene descuentos, escalados por volumen y condiciones de pago distintas.
• Flujos de pedido con aprobación. El comprador de una empresa no siempre tiene autorización para confirmar un pedido de 40 000 euros; alguien por encima necesita validarlo antes de que llegue al proveedor.

Drupal gestiona estas tres dimensiones porque su núcleo es un sistema de permisos granular combinado con un framework de entidades extensible. Ojo, que no estamos hablando de un plugin que "añade B2B" a una tienda B2C: la propia arquitectura de Drupal permite modelar cada caso desde la base. Esa flexibilidad marca la diferencia.

Arquitectura base: módulos y estructura de datos

Drupal Commerce como cimiento

El punto de partida es Drupal Commerce 2.x (o superior), que trabaja con entidades de producto, variaciones, pedidos y tiendas como objetos de contenido. ¿Qué implica esto? Que cada producto es un nodo con campos personalizables y relaciones entre entidades, no un registro rígido en una tabla cerrada.

Los módulos clave para un proyecto B2B típico son:

Módulo	Función
commerce_product	Gestión del catálogo con tipos de producto y variaciones
commerce_price	Motor de precios con soporte para resolvers encadenados
commerce_order	Flujos de pedido configurables por tipo
commerce_cart	Carrito con soporte multitienda
commerce_checkout	Flujo de checkout personalizable por pasos
commerce_promotion	Descuentos y condiciones complejas

A estos se suman módulos contribuidos y custom que veremos en cada sección.

Modelado de productos para B2B

Un error que veo continuamente en proyectos B2B: replicar la estructura de producto B2C. Ni de broma funciona para un catálogo industrial. Un producto puede tener 15 variaciones (calibres, materiales, acabados) y cada variación puede tener un precio distinto para cada grupo de clientes. La clave está en separar bien:

1. Producto (entidad padre): contiene campos compartidos —descripción técnica, fichas de seguridad, documentación, imágenes.
2. Variaciones (entidades hijas): cada combinación de atributos (tamaño, color, referencia del fabricante) con su SKU, peso, stock y precio base.

Para catálogos grandes (más de 5 000 SKUs), conviene crear tipos de producto separados por familia. Un tipo "Tornillería" tendrá campos como "métrica" y "longitud"; un tipo "Herramienta eléctrica" tendrá "voltaje" y "potencia". Así te evitas campos vacíos y mejoras tanto el rendimiento como la experiencia editorial.

Catálogo personalizado: controlar qué ve cada cliente

Taxonomía de acceso con roles y grupos

Drupal incluye un sistema de roles nativos, pero para B2B nos quedamos cortos con eso. El módulo Group permite crear grupos de clientes (por ejemplo, "Distribuidores Gold", "Distribuidores Silver", "Cuentas OEM") y asignar permisos de visualización a nivel de contenido.

La mecánica funciona así:

1. Se crean grupos que representan niveles comerciales o segmentos de cliente.
2. Cada producto o categoría se asocia a uno o varios grupos.
3. Cuando un usuario autenticado pertenece al grupo "Distribuidores Gold", solo ve los productos vinculados a ese grupo.
4. Los usuarios no autenticados no ven el catálogo (o ven una versión pública reducida).

Y aquí viene lo bueno: esto se implementa sin duplicar productos. Un mismo producto puede pertenecer a varios grupos simultáneamente.

Filtrado dinámico con Views y acceso por campo

Para catálogos con lógica más fina —por ejemplo, un distribuidor que solo puede vender en ciertas zonas geográficas y por tanto solo accede a productos homologados para esas zonas—, se combinan:

• Views con filtros contextuales basados en el perfil del usuario.
• Field-level access control mediante hooks personalizados que ocultan campos específicos (como el precio de coste o la referencia interna del fabricante) según el rol.

Te pongo un caso real: un fabricante de material eléctrico con 12 000 referencias y 4 niveles de distribución. Cada nivel ve un subconjunto del catálogo, y dentro de ese subconjunto, los campos visibles varían. El distribuidor autorizado ve la ficha técnica completa; el instalador final ve solo las especificaciones básicas y el precio con su tarifa. Todo gestionado desde un único catálogo editorial.

Motor de precios por cliente: resolvers y listas de precios

Cómo funciona el price resolver de Drupal Commerce

Drupal Commerce no almacena "el precio" de un producto como un valor fijo e inmutable. Utiliza un sistema de price resolvers encadenados: cuando el sistema necesita mostrar un precio, recorre una cadena de resolvers ordenados por prioridad hasta que uno devuelve un resultado.

El resolver por defecto toma el precio de la variación del producto. Pero podemos insertar resolvers custom que consulten:

• Una lista de precios específica para el cliente o su grupo.
• Un descuento por volumen que se aplica a partir de cierta cantidad.
• Un precio contractual almacenado en un campo del perfil del cliente.

Implementación de listas de precios

El módulo commerce_pricelist permite crear listas de precios asociadas a usuarios o roles. Cada lista contiene pares SKU-precio con fechas de vigencia opcionales.

La estructura típica para un B2B con 200 clientes activos:

1. Lista base (prioridad baja): precios de tarifa general.
2. Listas por grupo (prioridad media): tarifas para "Distribuidores Gold", "Distribuidores Silver", etc.
3. Listas por cliente (prioridad alta): precios negociados individualmente.

El resolver recorre las listas de mayor a menor prioridad. Si el cliente tiene un precio pactado para ese SKU, lo usa. Si no, sube al nivel de grupo. Si tampoco existe, aplica la tarifa base. Lógica limpia, sin líos.

Precios por volumen y escalados

Para descuentos por cantidad (compra 100 unidades y baja un 8 %, compra 500 y baja un 15 %), se utiliza commerce_promotion con condiciones de cantidad en el carrito, o bien un resolver custom que consulte una tabla de escalados por SKU y grupo.

¿La ventaja de hacerlo mediante resolver en vez de promociones? Que el precio mostrado en el catálogo ya refleja el escalado según las condiciones del cliente, sin necesidad de que añada productos al carrito para ver el descuento. El comprador ve su precio real desde el primer momento.

Flujo de pedido B2B: aprobaciones, presupuestos y repetición de compras

Pedidos con aprobación interna

En muchas empresas, el usuario que navega el catálogo y monta el carrito no es quien autoriza la compra. Drupal Commerce permite definir estados de pedido personalizados dentro del flujo (order workflow). Un flujo B2B típico tiene esta pinta:

1. borrador → el comprador monta el pedido.
2. pendiente_aprobacion → se notifica al responsable de compras.
3. aprobado → el pedido pasa a procesamiento.
4. rechazado → vuelve al comprador con comentarios.

Estos estados se configuran en el archivo de workflow YAML y se gestionan con transiciones protegidas por permisos. Solo el rol "Aprobador" puede mover un pedido de pendiente_aprobacion a aprobado. Separación de responsabilidades clara.

Pedidos recurrentes y repetición rápida

Al fin y al cabo, el 60 % de las compras B2B son repetitivas. Un taller mecánico pide los mismos consumibles cada mes. Para facilitar esto:

• Reorder button: un enlace en el historial de pedidos que copia todos los ítems de un pedido anterior al carrito actual.
• Listas de compra guardadas: el usuario crea listas predefinidas ("Consumibles mensuales", "Material de oficina") y las convierte en pedido con un clic.
• Pedidos programados: con el módulo commerce_recurring, se pueden automatizar pedidos periódicos.

Estas funcionalidades reducen fricción y suben la retención. Los clientes B2B que usan listas de compra guardadas generan un 35 % más de pedidos recurrentes.

Integración con ERP y sistemas de gestión

Ningún ecommerce B2B opera aislado. Los precios, el stock y los estados de pedido suelen vivir en un ERP (SAP, Sage, Navision, A3). Drupal facilita la integración mediante:

• API REST nativa para sincronización bidireccional de productos, precios y stock.
• Migrate API para importaciones masivas iniciales o periódicas desde CSV, XML o conexiones directas a base de datos.
• Webhooks y colas (con el módulo advancedqueue) para procesar eventos asíncronos: cuando se confirma un pedido en Drupal, se encola un mensaje que el ERP consume para generar el albarán.

La estrategia que mejor funciona: tratar a Drupal como el canal de venta y al ERP como la fuente de verdad para stock y facturación. Los precios pueden gestionarse en cualquiera de los dos, pero la sincronización debe ser unidireccional. Si vas bidireccional con precios, ya te digo que acabas con inconsistencias que nadie sabe de dónde salen.

Rendimiento y escalabilidad con catálogos grandes

Un catálogo B2B de 20 000 productos con 5 variaciones promedio genera 100 000 entidades de variación. Eso no se gestiona sin pensar en rendimiento:

• Índice de búsqueda con Search API + Solr: las consultas al catálogo no deben golpear la base de datos directamente. Solr indexa productos, variaciones y precios, y responde en milisegundos incluso con filtros combinados.
• Caché por contexto de usuario: Drupal cachea páginas y bloques por rol, pero en B2B necesitamos cachear por grupo de cliente. El módulo cache_context permite definir contextos de caché granulares.
• Lazy loading de precios: en listados de catálogo con 50 productos por página, calcular 50 precios personalizados puede ser costoso. Una técnica que nos ha funcionado bien: cargar los precios vía AJAX tras el renderizado inicial de la página.

Con estas optimizaciones, hemos gestionado catálogos con más de 80 000 referencias con tiempos de carga por debajo de 2 segundos.

Seguridad y control de acceso en entornos B2B

El acceso al catálogo y a los precios es información comercial sensible. Ojo con esto, porque varios controles son imprescindibles:

• Autenticación obligatoria para acceder al catálogo completo. La versión pública del sitio puede mostrar información institucional, pero el catálogo con precios requiere login.
• Doble factor de autenticación (2FA) para roles con permisos de aprobación de pedidos o acceso a informes de ventas.
• Logs de auditoría con el módulo admin_audit_trail para registrar quién consultó qué precios, quién aprobó qué pedidos y cuándo.
• Expiración de sesiones configurada para cerrar automáticamente sesiones inactivas tras 30 minutos.

No te la juegues con la seguridad en un portal donde se mueven tarifas confidenciales.

Pasos para arrancar tu proyecto B2B en Drupal

Montar un ecommerce B2B funcional en Drupal no es un proyecto de fin de semana, pero tampoco requiere 18 meses de desarrollo. Un enfoque pragmático:

1. Fase 1 (4-6 semanas): catálogo base con variaciones, sistema de roles y grupos, precio por lista. MVP funcional con 3-5 clientes piloto.
2. Fase 2 (3-4 semanas): flujo de pedido con aprobaciones, historial de compras y reorder. Integración básica con ERP.
3. Fase 3 (2-3 semanas): optimización de rendimiento, búsqueda facetada, listas de compra guardadas y automatizaciones.

Cada fase se prueba con usuarios reales antes de avanzar. El feedback del equipo comercial y de los primeros compradores define las prioridades siguientes. Nada de construir en el vacío durante meses.

Si tu empresa vende a otras empresas y el proceso de pedido todavía depende de llamadas telefónicas, PDFs por email o un Excel compartido con tarifas, la cosa está clara: el salto a un sistema B2B profesional en Drupal cambia las reglas. Consulta con nuestros especialistas en Drupal Commerce y analizamos juntos qué modelo se adapta a tu operativa y a tu catálogo.