MOQ, múltiplos de pedido y unidades de medida en ecommerce B2B: diseño funcional y reglas de ERP

En ecommerce B2B, la cantidad mínima de pedido (MOQ), el múltiplo y la unidad de medida deben resolverse como una sola regla comercial. El comprador necesita saber qué unidad selecciona, cuántas unidades base contiene, cuál es el mínimo y en qué incrementos puede aumentar. El ERP debe recibir una cantidad y una unidad inequívocas, no un número que cada sistema interprete de forma distinta.

Una configuración correcta permite, por ejemplo, vender una válvula por unidad, caja de 6 o palé de 120, exigir un mínimo de 2 cajas para una cuenta concreta y conservar el inventario en unidades. El portal muestra 2 cajas, calcula 12 unidades base, aplica el precio de caja correspondiente y envía ambos valores al ERP con la conversión utilizada.

Separa cinco conceptos que suelen mezclarse

• Unidad base: unidad mínima en la que se controla inventario o se identifica la cantidad física, como pieza, kilogramo o metro.
• Unidad de venta: presentación que el cliente puede seleccionar: unidad, caja, rollo, bidón o palé.
• Factor de conversión: equivalencia entre unidad de venta y unidad base para un SKU o variante.
• MOQ: cantidad mínima aceptable en una unidad definida.
• Múltiplo o incremento: paso válido a partir del mínimo.

«MOQ = 10» es un dato incompleto. Debe indicar 10 unidades, 10 cajas o 10 kilogramos; también necesita ámbito y vigencia. La regla mínima debería expresarse así: «para la cuenta ACME, el SKU VAL-80 se vende desde 2 cajas, en incrementos de 1 caja; cada caja equivale a 6 unidades; regla vigente desde el 1 de octubre».

Modelo de datos mínimo

Campo	Ejemplo	Por qué importa
product_variant_id	VAL-80-BRASS	La conversión puede variar por variante
selling_uom	BOX	Unidad que introduce y ve el comprador
base_uom	EA	Unidad de inventario o referencia
conversion_factor	6 EA/BOX	Permite convertir sin ambigüedad
minimum	2 BOX	Primera cantidad comprable
increment	1 BOX	Secuencia válida: 2, 3, 4…
maximum	40 BOX	Límite comercial o logístico opcional
scope	Cuenta ACME / almacén BCN	Indica para quién y desde dónde aplica
valid_from / valid_to	01/10–31/12	Evita reglas caducadas o solapadas

Guarda conversiones como razones exactas siempre que sea posible, no como decimales redondeados. Una caja de 6 es 6/1; un rollo de 12,5 metros puede requerir 25/2. La conversión debe estar vinculada al producto o variante cuando el embalaje cambia: una caja de talla XL puede contener cuatro piezas mientras otras tallas contienen cinco. Microsoft Dynamics 365 documenta precisamente conversiones distintas por variante.

Define la precedencia de las reglas

MOQ e incremento pueden depender del producto, cuenta, catálogo, mercado, almacén, canal o periodo. Cuando coinciden varias reglas, la precedencia debe ser explícita. Un orden posible es:

1. Cuenta + variante + unidad + almacén.
2. Grupo de cuentas + variante + unidad + mercado.
3. Catálogo B2B + variante + unidad.
4. Regla logística general de la variante.
5. Regla general del producto.

La regla ganadora debe ser una sola o combinarse mediante una política documentada. Si el contrato exige un mínimo de 2 cajas y el almacén sólo prepara capas de 8 cajas, el resultado no puede ser el menor de ambos. Puede prevalecer el requisito más restrictivo, de modo que la primera cantidad válida sea 8, pero negocio debe aprobar esa política.

La validación matemática correcta

Para una cantidad introducida q, un mínimo m y un incremento i, la compra es válida si:

• q >= m;
• si existe máximo, q <= max;
• (q - m) mod i = 0.

Antes de aplicar el módulo, normaliza los tres valores a la misma unidad y a enteros exactos. Si se permiten pasos de 0,25 kg, trabaja en gramos o escala por 100; no uses restos calculados directamente con decimales binarios, porque pueden rechazar una cantidad válida por error de precisión.

El último criterio es importante. Con mínimo 6 e incremento 4, las cantidades válidas son 6, 10, 14 y 18; no todos los múltiplos de 4. Si la política pretende 8, 12, 16, el mínimo debe estar alineado con el incremento o la secuencia debe definirse de otra manera.

Realiza la validación en la unidad seleccionada y vuelve a validarla en checkout y servidor. El selector del navegador es una ayuda, no un control suficiente: integraciones, importaciones rápidas, listas guardadas y llamadas API pueden saltarse la interfaz.

Conversión, redondeo y productos variables

No redondees sin informar. Si se venden 2,5 kg pero el almacén prepara sacos de 1 kg, hay que decidir si se rechaza, se redondea a 3 kg o se ofrece otra unidad. La política de redondeo —al alza, a la baja o al valor más próximo— debe pertenecer a la conversión y aparecer antes de añadir al carrito.

Para productos de peso variable, longitud cortada o «catch weight», separa cantidad pedida, cantidad preparada y cantidad facturada. Un comprador puede pedir 10 kg y recibir 10,34 kg; el portal debe explicar la tolerancia, el precio estimado y cuándo se conocerá el total definitivo.

Precio e inventario deben usar unidades compatibles

Cada precio necesita una unidad: 12 EUR por pieza no equivale automáticamente a 72 EUR por caja si la caja tiene un descuento o coste de embalaje. Conserva:

• unidad de precio y cantidad base del precio;
• unidad de pedido;
• factor aplicado;
• precio unitario mostrado y total de línea;
• tramo de volumen calculado en la unidad definida por el contrato.

El stock también debe quedar claro. Si hay 35 unidades disponibles y la venta es por cajas cerradas de 6, sólo hay 5 cajas vendibles aunque sobren 5 unidades. No prometas 6 cajas por redondear inventario. Si varios almacenes tienen embalajes o reglas diferentes, la disponibilidad debe resolverse después de seleccionar el origen logístico o dividir la línea de forma explícita.

Experiencia de usuario: prevenir antes que corregir

La ficha de producto debe mostrar junto al selector: «Mínimo: 2 cajas · Incrementos de 1 caja · 6 unidades por caja». Al cambiar la unidad, recalcula mínimo, incremento, precio, disponibilidad y entrega. En el carrito, conserva la unidad elegida y muestra la equivalencia, no sólo la cantidad base.

Si el usuario introduce un valor inválido, no lo cambies silenciosamente. Explica: «Se vende desde 2 cajas y en cajas completas. Hemos propuesto 3 cajas (18 unidades)». Pide confirmación cuando el ajuste altere importe, peso, transporte o plazo. Para entrada rápida por SKU y CSV, devuelve errores por línea con valor introducido, regla aplicable y cantidades válidas más cercanas.

Contrato entre portal y ERP

Cada línea enviada al ERP debería incluir:

• SKU y variante;
• cantidad solicitada y unidad de venta;
• cantidad base y factor de conversión;
• identificador y versión de la regla MOQ/incremento;
• precio, unidad de precio y moneda;
• almacén o fuente de suministro, si condiciona la regla.

El ERP debe validar de nuevo. Si rechaza la línea, el portal no debe sustituir la cantidad sin permiso ni crear un pedido distinto del confirmado. Devuelve un estado accionable: requiere aceptación del nuevo embalaje, cambio de almacén, solicitud de cotización o intervención comercial.

Importación y reconciliación

Antes de activar una versión de reglas, rechaza conversiones con factor cero o negativo, unidades inexistentes, mínimos inferiores a cero, incrementos no positivos, máximos menores que mínimos, periodos solapados y referencias a variantes desconocidas. Compara una muestra determinista entre ERP y ecommerce y contabiliza registros recibidos, aceptados y rechazados.

No sobrescribas la versión que valoró pedidos antiguos. Publica una nueva con fecha de efecto y conserva la regla usada en cada línea. Así una modificación de embalaje no cambia retrospectivamente la explicación de una factura.

Pruebas imprescindibles

• Valor inferior, igual y superior al MOQ.
• Primer incremento válido y valores justo a ambos lados.
• Cambio entre unidad, caja y palé con conversiones exactas.
• Variante cuya caja contiene una cantidad diferente.
• Regla específica de cliente frente a regla general.
• Stock no divisible por el embalaje de venta.
• Cambio de almacén, mercado, moneda y fecha de vigencia.
• Entrada desde ficha, carrito, lista, CSV, API y repetición de pedido.
• Precio por unidad y total iguales en portal, confirmación, ERP y factura.
• Regla ausente, conversión inválida y solapamiento de versiones.

Las reglas de MOQ y unidades deben probarse dentro de las capacidades operativas del portal B2B para distribuidores, no como una validación aislada.

Preguntas frecuentes

¿MOQ y múltiplo son lo mismo?

No. El MOQ indica la primera cantidad aceptable; el múltiplo determina los pasos posteriores. Un mínimo de 6 con incremento de 2 permite 6, 8, 10 y 12.

¿Debe el cliente elegir unidades o cajas?

Ofrece sólo las unidades realmente vendibles y muestra la equivalencia. Si la caja está cerrada, no presentes unidades sueltas aunque el inventario se gestione internamente por pieza.

¿Quién debe gobernar la conversión?

Normalmente ERP o PIM, con un único propietario. El ecommerce consume una versión publicada y no inventa factores para resolver datos ausentes.

¿Se puede redondear automáticamente?

Sólo con una política visible y autorizada. Si cambia importe o logística, muestra la cantidad propuesta y solicita confirmación.

Fuentes primarias

• Shopify: reglas de cantidad y precio por volumen B2B, para mínimos, máximos e incrementos por variante.
• Microsoft Dynamics 365: conversiones de unidad por variante, para factores distintos según presentación o variante.
• Microsoft Dynamics 365: gestión de unidades de medida, para conversiones, precisión y redondeo.
• Microsoft Dynamics 365: unidades y políticas de almacenamiento, para jerarquías logísticas y conversiones entre capas.

Siguiente paso

Selecciona diez SKU con embalajes distintos y construye para cada uno una tabla con unidad base, unidades vendibles, factor, MOQ, incremento, stock y precio. Después comprueba que portal y ERP aceptan y rechazan exactamente las mismas cantidades. Para ampliar el diseño funcional, consulta los recursos de CODE B2B.