Compra a peso variable: por qué el 'precio por kilo' rompe la mayoría de sistemas de back-office

Si gestionas compras en una cocina de colectividades —hospital, hotel, residencia o línea de catering—, sabes que el precio pactado con el proveedor no es el precio real que pagas. Con el pescado fresco, la carne con hueso o el queso curado, cada entrega llega con un peso distinto. El albarán dice 4,3 kg; la semana que viene dice 3,8 kg. El precio por kilo es el mismo, pero la factura cambia cada vez.

Este fenómeno tiene nombre: compra a peso variable o catch-weight purchasing. Y es donde la mayoría de sistemas de back-office empiezan a mentir en silencio.

Qué es exactamente el precio a peso variable

En la compra a peso fijo, el artículo tiene un precio unitario estable: una lata de tomate, un paquete de 1 kg de pasta. El sistema anota la cantidad y multiplica. Sencillo.

En la compra a peso variable, la unidad de pedido y la unidad de precio son distintas. Pides “1 pieza de salmón entero” pero pagas “X € por kilo real entregado”. El sistema necesita capturar dos magnitudes —unidades y kilos reales— para calcular el coste correcto. La mayoría de ERP generalistas solo anotan una de las dos, o fuerzan al usuario a convertir a mano antes de registrar.

Dónde se rompe el proceso en la práctica

1. El albarán llega con pesos reales; el pedido estaba en unidades. Si tu sistema no permite que la recepción corrija el peso en el momento de entrada, alguien lo redondea o lo ignora. El stock queda incorrecto desde el primer minuto.

2. El coste de receta se calcula sobre el peso teórico, no el real. Si la ficha técnica de un plato usa 200 g de lubina y la compra se registró a peso estimado, el coste por ración que ves en pantalla es una ficción. Las desviaciones se acumulan semana a semana sin que nadie las vea.

3. La trazabilidad por lote queda incompleta. En entornos regulados —hospitales, líneas de producción alimentaria— necesitas saber exactamente qué lote de producto, con qué peso real, entró en qué elaboración. Si el sistema solo guarda el número de unidades, el rastro se rompe en la recepción.

4. El FEFO no funciona si el stock no es fiable. La gestión por fecha de caducidad (First Expired, First Out) solo es efectiva cuando el inventario en sistema refleja la realidad del almacén. Un peso mal registrado desincroniza ambos mundos.

Por qué los ERP generalistas no resuelven esto bien

Los grandes ERP están diseñados para la lógica del comercio: unidades, referencias, tarifas. La doble unidad de medida existe en algunos módulos, pero implementarla correctamente para hostelería y alimentación colectiva requiere parametrización extensa que pocos equipos tienen tiempo o recursos de mantener. El resultado habitual es una solución parcial: el sistema acepta el dato pero no lo propaga bien hacia costes, inventario y trazabilidad al mismo tiempo.

Cómo debería funcionar un sistema pensado para F&B

Un back-office diseñado para la restauración y la producción alimentaria debería:

• Capturar peso real en la recepción, directamente sobre el pedido, sin pasos intermedios.
• Actualizar el coste de receta en CalcMenu con el precio real por kilo del lote recibido, no con el precio teórico del contrato.
• Asignar número de lote y peso real a cada movimiento de stock para mantener la trazabilidad completa.
• Respetar el FEFO con datos de inventario verídicos, no estimados.

---

FoodOps, la capa de back-office de la familia CalcMenu, resuelve exactamente esta cadena: gestiona la doble unidad de medida en recepción, sincroniza el coste real con las fichas técnicas y mantiene la trazabilidad por lote sin necesidad de un ERP previo. Nada se redondea, nada se pierde entre el albarán y la cocina.

Descubre cómo funciona en /es/foodops — o si prefieres verlo aplicado a tu operativa, reserva una llamada de 15 minutos.

Descubra el software de gestión de recetas de CalcMenu para restaurantes, hoteles y catering y vea cómo se aplica a su cocina.