El mismo producto entra en tarima, se guarda en caja y sale en pieza. Cuando las unidades de medida no están declaradas en el sistema, cada conversión se hace de memoria y el inventario deja de cuadrar por una multiplicación.
Un producto casi nunca se maneja en una sola presentación. Llega en tarima, se acomoda en caja y se surte en pieza, y en cada uno de esos pasos alguien está haciendo una multiplicación mental. Mientras las unidades de medida no estén declaradas en el sistema, esa multiplicación se repite decenas de veces al día y basta con que falle una para que el inventario deje de cuadrar.
Lo engañoso es que el error no se ve como error. Se ve como una diferencia de conteo, y se corrige con un ajuste. Solo cuando las diferencias se repiten siempre en los mismos productos aparece el patrón: no es que se pierda mercancía, es que se está contando en unidades distintas en dos lugares del proceso.
Las tres unidades de medida que conviven
En la práctica casi toda operación maneja tres niveles del mismo artículo, aunque no los llame así: la pieza, que es lo que compra el consumidor final; la caja o empaque intermedio, que es como viene del proveedor y como se acomoda en el rack; y la tarima, que es como llega, se mueve y se guarda en reserva.
Cada uno se usa en un momento distinto del ciclo. Se recibe en tarima, se almacena en caja, se surte en pieza y a veces se vende de nuevo en caja cuando el pedido es grande. El sistema tiene que saber cuántas piezas trae la caja y cuántas cajas trae la tarima, y esa relación tiene que vivir en el catálogo del producto y no en la cabeza del que lleva más tiempo en el almacén.
Dónde se rompe cuando no están declaradas
Los síntomas son bastante reconocibles, y casi siempre aparecen juntos:
- Diferencias de conteo que siempre caen en múltiplos exactos: doce de más, veinticuatro de menos
- Un mismo SKU que en un reporte aparece con existencia de cientos y en otro con existencia de decenas
- Pedidos surtidos de más porque el cliente pidió «diez» y no dijo diez de qué
- Cargos de almacenaje que no cuadran porque unos clientes se cobran por tarima y el sistema lleva piezas
- Recepciones que tardan porque hay que abrir tarimas para contar pieza por pieza
El último es el más caro y el menos discutido. Si el sistema no sabe qué trae una tarima, la única forma de dar una entrada confiable es desarmarla, y eso convierte una recepción de veinte minutos en una de media jornada.
Las diferencias que caen siempre en múltiplos exactos no son mermas: son conversiones que alguien está haciendo de memoria.
La regla que evita casi todo el problema
Hay una decisión que conviene tomar una sola vez y respetar: el inventario se lleva en una unidad base —normalmente la pieza— y todo lo demás son presentaciones que se convierten a ella. Que la pantalla muestre tarimas, que la etiqueta diga cajas y que el reporte del cliente hable de piezas está bien; lo que no puede pasar es que el sistema guarde el saldo unas veces en una y otras en otra.
A partir de ahí el resto es disciplina de catálogo: cada producto declara cuántas piezas trae su caja y cuántas cajas su tarima, y cada movimiento registra en qué unidad se hizo, aunque por dentro se guarde en la base. Así una entrada de dos tarimas y una salida de tres piezas viven en el mismo saldo sin que nadie multiplique nada.
Los casos que se salen de la regla
Hay dos que conviene tener pensados desde el principio. El primero es el producto cuyo empaque cambia: el proveedor pasa de cajas de veinticuatro a cajas de veinte y el catálogo se queda con el número viejo. Ahí no se corrige el dato encima —se pierde la historia—: se maneja como una presentación nueva, para que lo recibido antes siga cuadrando.
El segundo es el producto que se vende a granel o por peso, donde la «pieza» no es una unidad natural. Ese caso pide decidir explícitamente cuál es la base y aceptar que va a haber decimales, en lugar de forzarlo a números enteros y descubrir el redondeo tres meses después, repartido en cien movimientos.
Qué revisar antes de dar de alta el siguiente producto
Cuatro datos, y ninguno es difícil de conseguir si se piden a tiempo: en qué unidad llega, en qué unidad se guarda, en qué unidad se surte y cuántas piezas hay en cada nivel. Pedirlos al dar de alta el SKU cuesta un correo; reconstruirlos después de tres meses de movimientos cuesta un inventario físico.
Y vale la pena revisar los que ya están dados de alta: los productos que arrastran diferencias recurrentes suelen ser los mismos que entraron al catálogo sin esa conversión declarada. No es un problema de conteo ni de gente distraída, y por eso contar otra vez no lo arregla.
Que cada artículo declare sus presentaciones, que todo movimiento se asiente en una unidad base y que el reporte del cliente hable en la unidad que él usa es de lo que hoy se espera de un software WMS para 3PL en México.
Ninguna de estas correcciones es glamorosa y todas se hacen una sola vez por producto. Lo que compran es que la pregunta «¿cuántos hay?» tenga una respuesta y no tres, que es el punto donde un almacén deja de discutir su propio inventario con sus clientes.