Cómo configurar Drupal Commerce para tienda online B2B

El e-commerce B2B en España mueve más de 230.000 millones de euros anuales (ONTSI). Y aun así, la mayoría de empresas que venden a otras empresas siguen tramitando pedidos por teléfono, email o WhatsApp. Cuando por fin se deciden a montar la tienda, el error más caro que veo repetirse en cliente tras cliente es el mismo: coger una plataforma pensada para B2C y forzarla a hacer cosas para las que no fue diseñada.

Drupal Commerce está construido al revés. Asume desde el primer commit del módulo que vas a tener precios por cliente, pedidos con aprobación, catálogos restringidos y un ERP detrás. La lógica de negocio se modela con las herramientas del core de Drupal — entidades, campos, permisos, state machine —, no con plugins de terceros con licencias que se renuevan a discreción del vendor.

En esta guía recorro la configuración de una tienda B2B real con Drupal Commerce: qué módulos hacen falta de verdad, cómo se atan los precios por cliente, qué pasa cuando metes Redsys en un flujo de pago a 60 días, y cuánto cuesta y tarda esto en el mercado español.

Qué es Drupal Commerce y por qué encaja en el B2B

Drupal Commerce no es un plugin que se instale sobre un CMS genérico. Es un framework de comercio electrónico nativo de Drupal, desarrollado y mantenido por Centarro (antes Commerce Guys), que se apoya en toda la arquitectura del CMS: sistema de entidades, campos configurables, permisos granulares por rol, Views, REST API y un ecosistema de más de 47.000 módulos contribuidos.

En la práctica eso significa que cuando un cliente B2B te pide algo “raro” — un campo nuevo en el pedido, un estado intermedio en el workflow, un permiso solo para el responsable de compras —, lo resuelves configurando, no escribiendo un módulo nuevo desde cero.

Ventajas concretas frente a otras plataformas

Frente a WooCommerce: WooCommerce funciona bien para tiendas B2C sencillas. En cuanto necesitas precios diferentes por cliente, flujos de aprobación, catálogos por rol o integración con un ERP industrial, empiezas a apilar plugins de pago que se pisan entre sí en cada actualización. Con Drupal Commerce esa lógica vive en el core de Drupal, sin dependencias externas frágiles.

Frente a Magento/Adobe Commerce: Magento ofrece funcionalidad B2B potente, pero el coste de licencia de Adobe Commerce (la versión con B2B nativo) supera los 22.000 USD anuales en su plan más básico. Drupal Commerce es open source sin coste de licencia. La inversión está en desarrollo y configuración, pero el total suele quedar entre un 30% y un 50% por debajo en proyectos de complejidad media.

Frente a PrestaShop: PrestaShop tiene módulos B2B, pero su arquitectura está orientada al B2C. Las personalizaciones profundas tocan el core, y entonces las actualizaciones se vuelven un problema. Drupal Commerce, al estar basado en entidades y campos configurables, permite extender sin parchear.

Frente a Shopify Plus: Shopify Plus ofrece funcionalidad B2B desde 2023, pero es un SaaS cerrado. Si necesitas reglas de pricing con varias capas, aprobaciones multinivel o integración con sistemas legacy propietarios, te chocas con los límites del entorno gestionado. En Drupal Commerce no existen esos techos porque controlas el código.

Módulos esenciales para una tienda B2B

La instalación base de Drupal Commerce trae los módulos core del framework. Para una tienda B2B de verdad hay que sumar módulos contribuidos y, en algunos puntos, código a medida. Este es el mapa que monto en cada proyecto.

Commerce Product (core)

Define la estructura de productos. En B2B un “producto” suele tener variaciones tirando a complejas: el mismo tornillo en 14 medidas, 3 materiales y 2 acabados. Commerce Product resuelve esto con product variations que comparten un producto padre pero llevan SKU, precio y stock propios.

Configuración B2B clave: crear tipos de producto específicos por familia (materia prima, producto acabado, servicio, recambio) con campos personalizados — ficha técnica PDF, certificaciones, unidad de medida, múltiplo de pedido. Ese múltiplo de pedido es el que te ahorra después medio centenar de incidencias mensuales.

Commerce Cart (core)

Gestiona el carrito de compra. En B2B el carrito tiene particularidades que en B2C ni se plantean.

Configuración B2B clave:

• Carritos persistentes: el comprador B2B no cierra el pedido en una sesión. Va sumando referencias durante días. Hay que ajustar la persistencia para que no caduque.
• Múltiples carritos: dejar que un usuario tenga varios carritos a la vez, típicamente uno por obra, proyecto o centro de coste.
• Cantidades con validación: forzar múltiplos de pedido (los tornillos solo se venden en cajas de 100) con reglas de validación sobre el campo cantidad.

Commerce Checkout (core)

Define el flujo de pasos del proceso de compra. El checkout B2B es más largo que el B2C y no se parece en nada.

Flujo de checkout B2B típico:

1. Revisión del carrito con precios negociados.
2. Selección de dirección de entrega (un cliente B2B suele tener varias: central, delegación, obra).
3. Selección de método de envío o recogida.
4. Referencia de pedido del cliente: campo obligatorio donde el comprador mete su número interno o la referencia del proyecto. Sin esto no entran las facturas en su contabilidad.
5. Comentarios y observaciones.
6. Selección de método de pago (transferencia, domiciliación, pago contra factura, TPV virtual).
7. Confirmación y envío del pedido.

El módulo Commerce Checkout permite configurar estos pasos de forma visual, añadiendo o eliminando paneles según haga falta.

Commerce Payment (core)

Gestiona las pasarelas. En B2B los métodos de pago no se parecen a los del consumidor final.

Pasarelas habituales en B2B España:

• Transferencia bancaria — el más utilizado. El módulo Commerce Payment Manual te deja configurar este método con instrucciones de pago personalizadas por cliente.
• Domiciliación bancaria (SEPA) — para clientes recurrentes con contrato. Se genera el mandato SEPA y se domicilian los cobros.
• Pago contra factura (net 30/60/90) — el comprador recibe la mercancía y paga a vencimiento. Esto exige un control de crédito y riesgo del lado del ERP, no de la tienda.
• TPV virtual (Redsys) — para pagos puntuales o clientes nuevos. El módulo Commerce Redsys conecta con la pasarela española más extendida.

Aviso desde la experiencia: Redsys en B2B se rompe en dos sitios. Uno, importes por encima del límite del comercio (te dan SIS0042 sin que sepas por qué hasta que llamas al banco). Dos, intentos de pago con tarjetas corporativas con 3DS mal configurado en la entidad. Adyen y Stripe se manejan mejor en operaciones de tique alto y multi-divisa, pero Redsys sigue siendo el estándar cuando el cliente tiene cuenta en Santander, BBVA o CaixaBank y no quiere comisiones extra.

Commerce Pricing (core) + Commerce Price List

El módulo de precios es donde Drupal Commerce le saca cabezas al resto en B2B. El price resolver permite encadenar fuentes de precio con prioridades, y eso es exactamente lo que necesitas cuando un mismo SKU vale tres cosas distintas según quién lo mire.

Cómo se monta la tabla de precios por cliente en la práctica:

• Tarifa base (PVP) — el precio público del catálogo. Vive en el propio Commerce Product Variation.
• Tarifa por grupo de cliente — descuento por categoría (distribuidor, instalador, gran cuenta). Se implementa con Commerce Price List: creas una lista, le metes los SKU con sus precios y la asocias a un rol o a un grupo de usuarios.
• Precio negociado individual — para grandes cuentas con acuerdo comercial específico. Lista de precios exclusiva asignada a ese usuario, normalmente importada del ERP cada noche.
• Descuentos por volumen — reglas automáticas que aplican descuento según cantidad (desde 500 unidades, -5%; desde 2.000, -12%). Se configuran como promotions o como columnas de la propia price list según el caso.
• Promociones temporales — ofertas de campaña que se superponen a la tarifa habitual.

El price resolver evalúa todas las fuentes y aplica la de mayor prioridad. Resultado: el distribuidor con tarifa negociada entra en la tienda y ve sus precios sin tocar nada. El instalador ve los suyos. Y la fuerza comercial deja de gestionar PDFs de tarifas por email.

Commerce Order (core) + módulos de workflow

La gestión de pedidos en B2B exige estados y transiciones que en B2C no existen.

Estados habituales de un pedido B2B:

1. Borrador (el comprador lo está preparando).
2. Enviado (el comprador lo ha confirmado).
3. Pendiente de aprobación (un responsable del comprador tiene que validarlo).
4. Aceptado (el vendedor confirma disponibilidad y condiciones).
5. En preparación.
6. Enviado / entregado.
7. Facturado.
8. Cobrado.

El módulo State Machine de Drupal, integrado con Commerce Order, te deja definir estos estados y las transiciones permitidas. Por ejemplo: solo un usuario con rol “responsable de compras” puede pasar un pedido de “enviado” a “aprobado”. Los approval workflows se modelan con State Machine + reglas de permisos por rol, y los disparadores (email al aprobador, notificación al comercial) se enganchan con Rules o con event subscribers a medida — yo prefiero los segundos porque son testeables.

Módulos adicionales relevantes

• Commerce Stock — gestión de inventario con control de disponibilidad en tiempo real.
• Commerce Shipping — cálculo de costes de envío por peso, volumen o transportista.
• Commerce Invoice — generación de facturas en PDF desde los pedidos.
• Search API + Solr/Elasticsearch — búsqueda avanzada en catálogos de miles de referencias, con filtros por atributos técnicos. Innegociable a partir de 3.000 SKU.
• Commerce Feeds / Migrate — importación masiva de productos desde ERP o ficheros CSV.

Configuración del catálogo B2B

El catálogo B2B tiene exigencias que no se cubren con “foto, nombre y precio”.

Catálogo restringido por cliente

No todos los clientes pueden ver todos los productos. Un distribuidor regional solo ve las familias para las que tiene acuerdo. Un instalador ve precios de instalador, no de distribuidor.

Implementación en Drupal Commerce: se usa el sistema de permisos de Drupal (roles + módulo Commerce Product Access, o configuración con Taxonomy Access Control) para mostrar u ocultar productos según el rol o grupo del usuario. Un distribuidor con rol “distribuidor_zona_norte” solo ve los productos etiquetados con la taxonomía correspondiente.

Pedidos mínimos

En B2B suele haber un importe mínimo de pedido (200 euros, por ejemplo) o una cantidad mínima por producto (caja completa, palet completo).

Implementación: reglas de validación en el checkout (Commerce Order Validation, o reglas a medida con Rules o un event subscriber del propio checkout) que comprueban importe del carrito y cantidades por producto antes de dejar avanzar al siguiente paso.

Fichas de producto técnicas

El comprador B2B no busca fotos bonitas. Busca especificaciones, fichas de seguridad, certificaciones, planos CAD y documentación de instalación.

Implementación: campos File en las variaciones de producto para adjuntar PDFs. Campos de texto estructurado para especificaciones (dimensiones, peso, material, normativa). Media system de Drupal para gestionar documentos y vídeos técnicos con sus revisiones.

Si estás valorando montar tu tienda B2B y necesitas orientación sobre la arquitectura técnica más adecuada para tu caso, habla con nuestros especialistas en Drupal Commerce.

Integración con ERP y CRM

Una tienda B2B sin ERP detrás es una fábrica de trabajo manual, errores y discusiones por email. La integración no es opcional, es la mitad del proyecto.

Datos que deben fluir entre la tienda y el ERP

Dirección	Datos
ERP hacia la tienda	Catálogo de productos, precios, stock, datos de clientes, condiciones comerciales, histórico de pedidos
Tienda hacia el ERP	Pedidos nuevos, datos de nuevos clientes (solicitudes de alta), consultas de disponibilidad

Métodos de integración

API REST bidireccional — el enfoque más sólido cuando el ERP coopera. Se desarrolla una capa que conecta el ERP con Drupal Commerce vía REST. Los datos se sincronizan en tiempo real o con frecuencia configurable (cada 5, 15, 60 minutos). Drupal Commerce expone su propia API REST nativa, lo que facilita la comunicación en ambos sentidos. Con SAP Business One y Holded esto funciona bien; con Sage 200 hay que envolver llamadas en un intermediario porque su API REST está incompleta en varios endpoints clave.

Importación/exportación por ficheros — para ERPs que no tienen API decente (muchos sistemas legacy españoles, AS/400 incluidos). Se exporta del ERP a ficheros CSV o XML en una carpeta compartida, y Commerce Feeds o Drupal Migrate procesa esos ficheros y actualiza productos, precios y stock. Los pedidos nuevos se exportan en sentido inverso, normalmente como CSV que el ERP ingiere en un proceso nocturno.

Middleware — para escenarios con varios sistemas (ERP + CRM + almacén + contabilidad). Una plataforma como MuleSoft, n8n o Apache Camel actúa como hub central que orquesta los flujos. Lo elegiría cuando hay más de tres sistemas en juego o cuando el cliente ya tiene n8n corriendo para otra cosa.

Orden de despliegue que recomiendo. Cuando me preguntan por dónde empezar, la secuencia que mejor me ha funcionado es: primero importar el maestro de productos del ERP (catálogo + categorías), luego sincronizar stock, luego precios (empezando por tarifa base y dejando price lists por cliente para una fase posterior), y solo cuando los tres flujos anteriores son estables, abrir el canal de pedidos hacia el ERP. Saltarse este orden — sobre todo lanzar la entrada de pedidos antes de tener catálogo y stock fiables — es la receta para pedidos duplicados y stock fantasma.

Integración con CRM

El CRM (HubSpot, Salesforce, SuiteCRM, Zoho) recibe los datos de actividad: productos consultados, pedidos realizados, frecuencia de compra, importe medio. Eso alimenta la segmentación comercial y permite al equipo de ventas mover ficha antes de que el cliente lo pida.

En Drupal la integración con CRM se resuelve con módulos contribuidos (Webform CRM, HubSpot Integration) o con la API REST de ambos sistemas. Yo prefiero la API REST directa: menos magia, más control.

SEO para e-commerce B2B en Drupal

El SEO B2B no se parece al B2C. Menos volumen por keyword, intención de compra mucho más alta y ticket medio incomparablemente mayor.

Acciones de SEO específicas para Drupal Commerce B2B

URLs limpias y descriptivas. Drupal permite configurar patrones de URL automáticos con Pathauto. Para productos B2B, /productos/[categoria]/[nombre-producto] rinde mejor que IDs numéricos.

Meta tags por producto y categoría. El módulo Metatag te deja definir plantillas que se generan automáticamente para miles de productos. Ejemplo: “Comprar [nombre-producto] para [sector] | [marca] - Precio B2B”.

Schema markup (datos estructurados). El módulo Schema.org Metatag genera JSON-LD de tipo Product con precio, disponibilidad, SKU y reseñas, lo que ayuda en la visibilidad de Google.

Contenido técnico indexable. Las fichas con especificaciones detalladas (no solo nombre y precio) atraen tráfico long-tail valioso. Un comprador técnico busca “tornillo DIN 933 M10x50 acero inoxidable A2”, no “tornillos”.

Blog técnico integrado. Drupal te permite montar un blog nativo (tipo de contenido “Artículo”) que se vincula con los productos del catálogo. Los artículos técnicos posicionan a la empresa como referencia del sector.

Velocidad de carga. Google penaliza las tiendas lentas. Drupal Commerce soporta caché agresiva (Internal Page Cache, Dynamic Page Cache, BigPipe) y CDN. Un catálogo de 10.000 productos bien configurado con Varnish delante sirve páginas de categoría por debajo de los 200 ms.

Gestión de clientes mayoristas

El cliente B2B no es un visitante anónimo. Es una empresa con la que existe (o se quiere abrir) una relación comercial. La gestión de clientes en Drupal Commerce tiene que reflejarlo.

Alta de clientes con validación

En B2B no compra cualquiera. El proceso de registro suele ser:

1. El visitante solicita alta como cliente vía formulario (datos fiscales, CIF, sector, volumen estimado).
2. El equipo comercial revisa la solicitud y aprueba o rechaza.
3. Si se aprueba, se asigna al cliente un rol (distribuidor, instalador, gran cuenta), una lista de precios y unas condiciones de pago.
4. El cliente recibe credenciales y empieza a comprar con sus condiciones personalizadas.

Implementación en Drupal: formulario de registro personalizado con Webform o un form custom, flujo de aprobación con el módulo User Approval o desarrollo a medida, asignación automática de rol y lista de precios al activar la cuenta. La asignación automática es el paso que casi todo el mundo deja para “después” y luego nadie hace.

Panel de cliente

El cliente B2B espera un panel donde pueda:

• Ver el histórico de pedidos y repetir uno anterior con un clic.
• Descargar facturas y albaranes en PDF.
• Gestionar varias direcciones de entrega.
• Ver su cuenta corriente (saldo pendiente, facturas vencidas).
• Crear listas de favoritos o listas de compra frecuente.

Todo esto se monta en Drupal Commerce con Views, campos personalizados y módulos contribuidos. Sin desarrollar desde cero.

Costes y plazos realistas

Estos son los rangos que veo habitualmente en el mercado español para un proyecto de Drupal Commerce B2B con integración ERP.

Costes por fase

Fase	Rango orientativo
Consultoría y diseño funcional	3.000 - 6.000 EUR
Diseño UX/UI (tema personalizado)	4.000 - 10.000 EUR
Desarrollo y configuración de Drupal Commerce	15.000 - 40.000 EUR
Integración con ERP	8.000 - 25.000 EUR
Importación inicial de catálogo	2.000 - 5.000 EUR
SEO técnico y configuración	2.000 - 4.000 EUR
Formación del equipo	1.500 - 3.000 EUR
Total proyecto	35.000 - 90.000 EUR

Costes recurrentes

Concepto	Rango anual
Hosting (servidor dedicado o cloud)	1.200 - 4.800 EUR
Mantenimiento y actualizaciones	3.000 - 8.000 EUR
Soporte técnico	2.000 - 6.000 EUR

Plazos

Un proyecto de complejidad media (catálogo de 2.000-10.000 productos, integración con un ERP, diseño personalizado) se ejecuta entre 12 y 20 semanas desde el kick-off hasta producción.

Proyectos más simples (catálogo pequeño, sin integración ERP, tema basado en plantilla) salen en 6 a 8 semanas.

Casos de uso reales

Distribuidor de material de fontanería (Sevilla)

Catálogo de 18.000 referencias importadas desde un ERP AS/400 mediante ficheros CSV diarios. Precios por tres niveles de cliente (instalador, almacén, gran cuenta). Pedido mínimo de 150 euros. Stock en tiempo real cada 15 minutos. Búsqueda con Solr para filtrar por diámetro, material, normativa y marca.

Resultado a los 8 meses: el 42% de los pedidos de clientes recurrentes entran por la tienda online, sobre todo fuera de horario comercial (noches y fines de semana). El tiempo medio de tramitación pasó de 12 minutos (llamada + entrada manual en el ERP) a menos de 2.

Fabricante de envases industriales (Barcelona)

Catálogo de 800 productos con configurador de personalización (dimensiones, material, impresión). Cada producto con ficha técnica PDF, certificaciones alimentarias y vídeo de proceso. Flujo de pedido con aprobación obligatoria del responsable de compras del cliente. Integración bidireccional con SAP Business One vía API REST.

Resultado: la tienda se convierte en el canal principal de captación internacional. El 30% de la facturación del segundo año procede de clientes captados por búsquedas orgánicas en Google.

Cooperativa de suministros agrícolas (Extremadura)

Catálogo de 5.000 productos (fitosanitarios, semillas, fertilizantes, herramientas). Los socios ven precios de socio; los no socios, tarifa general. Restricciones en productos fitosanitarios (solo visibles para usuarios con carnet de aplicador verificado). Pedidos con recogida en cualquiera de las 7 sucursales.

Resultado: las llamadas para pedidos rutinarios bajan un 60%. Los socios más jóvenes adoptan la plataforma rápido y suben su frecuencia de compra un 25%.

Errores frecuentes que debes evitar

Después de meterme en bastantes proyectos de e-commerce B2B, estos son los errores que vuelven cada cierto tiempo.

Elegir plataforma por coste inicial, no por coste total de propiedad. Lo que parece barato hoy y exige plugins de pago, personalizaciones costosas y migraciones cada 18 meses sale más caro que una solución sólida bien hecha desde el inicio.

No definir los flujos de negocio antes del desarrollo. Si no están claras las reglas de precios, los niveles de aprobación, las condiciones de pago y los estados del pedido antes de escribir la primera línea de código, el proyecto se alarga, se encarece y el equipo acaba quemado.

Lanzar con todo el catálogo desde el día uno. Es preferible salir con las 500 referencias más vendidas, validar que todo el flujo funciona con clientes reales y después ampliar el catálogo de forma progresiva.

Ignorar la UX del comprador B2B. El comprador B2B es un profesional al que le importa la eficiencia, no el diseño. Una búsqueda rápida, filtros precisos, pedido rápido por referencia y “repetir pedido anterior” valen más que un slider con fotos.

No medir. Sin analítica (Google Analytics 4, Matomo o equivalente) con seguimiento de comercio electrónico mejorado activado correctamente, no sabes qué funciona. Tracking desde el día uno, sin excusas.

Siguientes pasos

Drupal Commerce te da la flexibilidad y la potencia para cubrir las necesidades reales del B2B. Pero esa potencia exige un equipo que conozca igual de bien la tecnología y las particularidades del comercio entre empresas.

Si vas a lanzar o renovar tu tienda B2B, el primer movimiento no es elegir plataforma: es cerrar requisitos funcionales y técnicos. Un par de semanas de diagnóstico bien hecho te ahorran meses de retrabajo y bastantes miles de euros en correcciones después.

Cuéntanos tu proyecto y te ayudamos a definir la solución técnica más adecuada. Sin compromiso, con criterio técnico y con experiencia real en proyectos B2B sobre Drupal Commerce.