Portal B2B con tarifas por cliente en Business Central: la guía completa
Cómo montar un portal B2B sobre Business Central que respete tarifas, descuentos, crédito y condiciones de pago de cada cliente. Casos, errores típicos y arquitectura.
En una distribución industrial, en un mayorista, en una farmacéutica, en un fabricante que vende a canal — el mismo producto no tiene un precio. Tiene un precio por cliente. Y a veces tiene un precio distinto según cuántas unidades pidas, en qué momento del año, qué condición tienes negociada.
Esto es lo que en jerga técnica llamamos tarifas B2B. Y es lo que rompe cuando una empresa intenta usar Shopify, WooCommerce o cualquier tienda B2C estándar para vender a sus clientes profesionales: el cliente entra, ve el precio “público” — no el suyo — y se descuelga del autoservicio.
Esta guía cuenta cómo montar un portal B2B sobre Microsoft Dynamics 365 Business Central que respete tarifas, descuentos, crédito y condiciones de pago de cada cliente — sin duplicar reglas en sistemas paralelos. Es lo que hace dvcommerce, la extensión B2B/B2C de Davisa para BC.
El problema real — “el precio que la web muestra no es el que BC factura”
El síntoma con el que llaman las empresas suele ser este: tienen una tienda B2B montada en Shopify o WooCommerce (porque “es barato y rápido”), y al cabo de 6 meses descubren:
- Los clientes B2B se quejan de que el precio en la web no es el suyo — ven el precio “público” o, peor, un precio que alguien copió mal del Excel.
- Los descuentos escalonados (a partir de N unidades, baja el precio) no funcionan porque la tienda no sabe leer Price Lists.
- Cada vez que cambia una tarifa en BC, hay que acordarse de cambiarla en la tienda. La mitad de las veces, no se cambia.
- Los clientes con “30 días fecha factura” siguen viendo pasarela de pago en el checkout, pagan dos veces o se confunden.
- Si un cliente está bloqueado en BC por crédito agotado, la web le deja comprar igualmente — y financiero rechaza el pedido al día siguiente, con la fricción asociada.
El problema no es Shopify ni WooCommerce — son grandes productos para B2C. El problema es intentar montar B2B encima.
La arquitectura correcta — la tienda lee BC, no lo replica
La solución no es sincronizar dos sistemas. Es que la tienda lea Business Central directamente y aplique en tiempo real lo mismo que aplica el ERP al facturar. Si en BC el cliente CL00042 tiene la tarifa T2024-INDUSTRIAL con descuento del 8 % sobre la familia METAL, la web aplica eso. Sin reglas duplicadas, sin scripts de sincronización.
Esto es lo que hace dvcommerce, porque está construida como extensión AL nativa dentro de Business Central. Las tablas que la web consume son las mismas que usa el ERP:
| Información en la web | Tabla BC |
|---|---|
| Catálogo de productos | Item |
| Tarifas y precios por cliente | Price List Header + Price List Line |
| Descuentos por línea | dentro de Price List Line |
| Stock disponible | Item Ledger Entry / Inventory |
| Datos del cliente B2B logado | Customer |
| Condiciones de pago | Customer.Payment Terms Code |
| Forma de pago | Customer.Payment Method Code |
| Crédito disponible | Customer.Credit Limit LCY – Customer.Balance LCY |
| Pedidos previos del cliente | Sales Header + Sales Line (filtrados por cliente) |
| Documentos asociados | Document Attachment (sobre Customer o Item) |
Sin replicación. Sin “el último export del lunes”. Lo que ves en BC ahora mismo, eso ve la web.
Los 7 escenarios B2B que solo un portal nativo resuelve bien
1. Tarifa específica del cliente
El cliente CL00042 entra a la web, se logea, y ve su catálogo con sus precios. El precio que aparece junto al producto no es el genérico — es el que se aplicaría al facturar. Si el comercial lo ha modificado esa mañana en BC, está ya en la web.
2. Descuento escalonado por cantidad
El cliente quiere comprar 80 unidades de un componente. Al subir la cantidad en el carrito a 100, el precio unitario baja del tramo “50-99 uds” al tramo “100-249 uds”, y la web lo refleja instantáneamente. El cliente ve cómo le sale más a cuenta llegar al siguiente tramo — el equipo comercial no tiene que llamarle para “recomendárselo”.
3. Catálogo restringido por cliente
El cliente es distribuidor en Aragón. No vende productos de la línea “exclusiva canal Madrid”. En BC el grupo de cliente “CANAL-ARAGON” tiene marcada esa restricción — la web oculta esos productos automáticamente. Sin URL alternativa, sin truco.
4. Crédito disponible y bloqueo
El cliente tiene un límite de 30.000 € y debe 27.500 €. La web le muestra “crédito disponible: 2.500 €” en su área privada. Si intenta meter un pedido de 4.000 €, la web puede:
- Avisar y dejar tramitar (configuración “soft” — financiero decidirá).
- Bloquear el checkout y forzar contacto comercial (configuración “hard”).
La regla es la que el cliente Davisa elija en BC — la web la respeta.
5. Condiciones de pago heredadas
En el checkout, el cliente B2B no ve pasarelas de pago genéricas. Ve su forma de pago habitual (“Transferencia 30 días fecha factura”, “Confirming 60 días”, “Pagaré 90 días”). El pedido llega a BC con esa forma de pago — financiero no tiene que cambiar nada.
6. Documentos asociados a la ficha cliente
El cliente entra a su área y ve su contrato firmado, las fichas técnicas de los productos que compra, los certificados de calidad. Todo lo que está en Document Attachment sobre su Customer o sobre los Item que compra. Sin reuploadar nada en otro sitio.
7. Histórico real de pedidos
El cliente puede:
- Ver sus pedidos pasados con su estado actual en BC (en preparación / enviado / facturado).
- Descargar la factura de un pedido cerrado (PDF).
- Repetir un pedido del año pasado con un clic — la web duplica la
Sales Linecon cantidades, precio actual y stock disponible.
Lo que pasa cuando intentas hacer esto con Shopify B2B o WooCommerce
Shopify ha sacado “Shopify B2B” — y, para tiendas con catálogo simple y dos tarifas básicas, está bien. WooCommerce con plugins B2B (WholesaleX, etc.) también cubre lo básico. Pero ninguno de los dos lee Price Lists de BC. Para que funcionen, hay que:
- Exportar tarifas de BC a la plataforma cada N minutos (típicamente con un middleware).
- Recrear los grupos de cliente en la plataforma con sus tarifas asignadas (en paralelo a BC).
- Programar tareas de sincronización de stock, precios, condiciones, crédito, pedidos.
- Resolver los conflictos cuando una tarifa cambia en BC y la sincronización no ha pasado todavía.
- Mantener todo eso a 6, 12, 24 meses — cuando los plugins se actualizan, cuando cambia la API de Shopify, cuando alguien edita una tarifa en la plataforma en vez de en BC.
La pregunta sincera: si tu cliente B2B llama porque “ayer el precio era otro y me han facturado distinto”, ¿qué sistema es la verdad? En arquitectura con tienda B2C+plugin B2B, la respuesta es “depende”. En arquitectura dvcommerce, la respuesta es “BC siempre”.
¿Qué hace falta en BC antes de implantar dvcommerce?
Si el ERP no está bien ordenado, ningún portal lo salva. Antes de la implantación, conviene:
- Limpiar la tabla
Item: códigos, descripciones, fotos, categorización. Si los productos no están bien clasificados en BC, la tienda hereda el caos. - Migrar a Price Lists nativas de BC18+: si todavía estás en Sales Prices/Sales Line Discounts (antiguo), Davisa hace la migración como parte del proyecto.
- Definir grupos de cliente que tengan sentido comercial. Los grupos deciden quién ve qué y a qué precio.
- Cargar fotos y atributos en
Item(o conectar con un PIM tipo Akeneo si los tienes ahí). - Decidir reglas de stock: ¿la web muestra stock real o “disponible para comprometer”? ¿Reservas al añadir al carrito o al cerrar pedido? Esto se configura en dvcommerce.
Davisa hace este trabajo previo de “diagnóstico BC” en la fase 1 del proyecto — la mayoría de empresas tienen BC bien para facturar, pero no necesariamente bien para que un cliente lo consuma en autoservicio.
El proceso de implantación, semana a semana
Para que tengas referencia, este es un proyecto B2B estándar dvcommerce — distribuidor industrial con 1.000 SKUs y 500 clientes activos:
- Semana 1 — Diagnóstico BC: revisión de
Item,Customer,Price List, grupos de cliente, condiciones de pago. - Semana 2 — Maqueta y catálogo: instalación de dvcommerce en el tenant BC, configuración de la maqueta gráfica con la marca del cliente, primer corte del catálogo público.
- Semana 3 — B2B y autenticación: alta de clientes B2B en su portal, conexión con su
Customerde BC, prueba de tarifas y descuentos. - Semana 4 — Pago y checkout: configuración de pasarelas (Redsys, PayPal, transferencia, factura) y reglas de pago por cliente.
- Semana 5 — Pruebas y formación: UAT con clientes piloto, formación al equipo comercial, formación al equipo de operaciones para gestionar pedidos web en BC.
- Semana 6 — Go-live + acompañamiento: paso a producción con backup operativo. La primera semana, Davisa acompaña en tiempo real.
A partir de aquí: soporte continuo, métricas mensuales, evolución funcional con sprints opcionales.
Caso real — distribuidor químico, 600 cuentas B2B
Un cliente Davisa: distribuidor químico nacional con 600 cuentas B2B activas, 8.000 SKUs en BC, 3 niveles de tarifa por canal + 4 segmentos por familia + descuentos por compromiso anual. Antes de dvcommerce, tenían:
- 2 administrativos a tiempo completo introduciendo pedidos B2B (que llegaban por email, fax, WhatsApp).
- Una caída de margen del 3 % estimada por descuentos mal aplicados (al copiar precios manualmente).
- Un proceso de devolución del 12 % por errores de pedido (cliente pide referencia incorrecta porque no tiene catálogo claro).
A los 9 meses del go-live de dvcommerce:
- El 64 % de los pedidos B2B entran en autoservicio (sin intervención humana).
- Los 2 administrativos pasaron a tareas de mayor valor (cobros, conciliaciones).
- La caída de margen por descuentos mal aplicados se eliminó (el cliente ya no puede pedir un precio que no le toca).
- Las devoluciones bajaron al 4 % (el cliente ve foto, ficha técnica, stock, y elige bien).
ROI estimado del proyecto: menos de 8 meses.
Cierre — el portal B2B es el ERP en otro vestido
La forma correcta de pensar en un portal B2B no es “una tienda con un login”. Es “un ERP que el cliente puede consumir directamente”. Cada vez que el cliente entra al portal, debería estar viendo lo mismo que vería su comercial — su tarifa, su stock, su crédito, su histórico.
Esto se consigue cuando la tienda y el ERP comparten la misma fuente. No cuando se sincronizan. dvcommerce hace eso encima de Business Central, sin capa intermedia.
¿Tienes Business Central y quieres montar un portal B2B serio? Contacta con un asesor de Davisa — en menos de una semana recibes una propuesta concreta con alcance, plazos y precio firme.
Artículos relacionados
Captura de facturas: extensión nativa BC vs portal externo
Las soluciones de captura externas obligan a saltar entre sistemas, rompen la conciliación y dependen de APIs que se rompen en cada actualización. Por qué la extensión AL nativa es la forma robusta.
No conformidades y CAPA: cómo dejar de gestionar la calidad por correo electrónico
Las no conformidades sin causa, sin responsable y sin verificación de eficacia no son un sistema de calidad. Cómo cerrar el ciclo CAPA con trazabilidad real dentro del ERP.
OCR vs IA en facturas de proveedor: por qué la diferencia importa más de lo que parece
OCR clásico y captura inteligente con IA suenan parecido pero hacen cosas distintas. Por qué la IA aplicada a tu cartera de proveedores cambia el ROI a 3 años.