PC, PAK, CS, KG: el caos de las unidades de proveedor que arruina en silencio tu coste de alimentos

Una lista de precios de un proveedor tiene una fila: Crème entière 35% — CHF 4.80 — PC. ¿Qué es “PC” aquí? ¿Una botella de 1 litro? ¿Un vaso individual de 200 ml? ¿Una bag-in-box de 5 litros? La abreviatura no lo dice. Y tampoco suele decirlo la persona que la está introduciendo en el sistema bajo presión de plazos: elige la lectura que le parece más razonable, sigue adelante, y la receta que usa esa nata ahora tiene una cifra de coste que está aproximadamente bien o desviada por un factor de cinco, sin ninguna forma de saber cuál de las dos cosas con solo mirar el número.

Esto no es un caso aislado. Es, en nuestra experiencia incorporando cocinas de grandes empresas a sistemas de recetas estructurados, una de las mayores fuentes de coste de alimentos silenciosamente erróneo, mayor que la deriva de las porciones, mayor que un precio desactualizado, porque no produce una cifra ligeramente equivocada. Produce una cifra equivocada por un múltiplo entero, disfrazada de cálculo preciso.

Cada proveedor inventa su propio alfabeto

No existe un estándar compartido en el punto donde la mayoría de las cocinas realmente hacen sus pedidos. La exportación de un proveedor usa “PC” para pieza. Otro usa “PC” para paquete. Un tercero usa “STK” (del alemán Stück), un cuarto “CT” para cartón, un quinto “GEB” de Gebinde —un término alemán genérico para “el envase que sea que use este producto para enviarse”. Añada “CS” para caja (case), “BTL” para botella, “BUC” para manojo, y multiplique eso por el número de proveedores de los que realmente compra un grupo de cocinas de tamaño medio —normalmente entre ocho y quince, cada uno con su propia exportación de catálogo, a menudo en idiomas distintos según la región.

Esto no es un problema resuelto a la espera de ser adoptado: es un problema difícil. GS1, el organismo mundial de estándares detrás de los códigos de barras, mantiene una jerarquía formal de embalaje pensada específicamente para solucionar esto: cada unidad física —cada pieza, paquete interior, caja, palet— recibe su propio identificador único, de modo que “una caja” siempre se resuelve en una cantidad exacta e inequívoca en lugar de una suposición. Ese estándar existe precisamente porque el sector reconoció que la ambigüedad del tamaño de envase era lo bastante grave como para necesitar una solución global. En la práctica, las exportaciones de listas de precios de la mayoría de los proveedores de restauración pequeños y medianos todavía no lo siguen, lo que significa que la ambigüedad recae, sin resolver, sobre quien esté introduciendo el producto en el sistema.

Lo que realmente sale mal: tres patrones reales

La suposición sobre el tamaño de la caja. Una línea dice “1 caja — CHF 48.00.” ¿Es una caja de 6 unidades o una caja de 12? Si se equivoca, cada receta que usa ese producto queda costeada exactamente al doble o a la mitad de su coste real de ingrediente —no un error de redondeo, sino un múltiplo exacto, y uno que sobrevive a todo cálculo posterior con un aspecto perfectamente plausible.

El mismo ingrediente, tres envases distintos. La nata para montar del Proveedor A viene en botellas de 1 litro. La misma nata del Proveedor B se envía en una bag-in-box de 5 litros. Un tercer proveedor de formato catering vende vasos individuales de 200 ml. Si el sistema trata “nata” como un único producto intercambiable en lugar de tres registros de envase distintos, el coste de la receta depende por completo de cuál se introdujo —o se volvió a pedir— más recientemente, sin ningún aviso de que la cifra ha cambiado.

La unidad escondida dentro de una descripción. Durante la incorporación, es habitual que una parte considerable de un catálogo de productos existente llegue sin ningún campo de unidad estructurado en absoluto: el tamaño del envase aparece como texto libre dentro del nombre del producto en su lugar: “Box 6x1kg”, “Carton de 24”. Un campo de descripción no es un dato sobre el que un motor de costeo pueda actuar. Cada uno de esos casos hay que reabrirlo manualmente y extraer la cifra real antes de que el producto pueda usarse con confianza en una receta, y hasta que eso ocurra, el coste del producto está en blanco, es cero o está equivocado en silencio.

Nada de esto son fallos de formación. Es lo que ocurre, de forma previsible, al volumen al que funciona un catálogo de proveedor real: cientos o miles de líneas de artículo, varios formatos por proveedor, reintroducidos bajo presión de tiempo, sin ninguna barrera estructural que impida que una unidad ambigua llegue a una receta.

Por qué esto rompe el costeo peor que casi cualquier otra cosa

Los proveedores de software de costeo de recetas llegan a la misma conclusión desde el lado contrario: el tamaño del envase y la unidad de medida son “los campos más responsables de la varianza en el coste de alimentos” —por delante de la deriva de precios, por delante del tamaño de la porción. El motivo es proporcional. Un precio desactualizado puede estar desviado un 5–10%. Una conversión de unidad equivocada está desviada por el múltiplo real del envase —2x, 6x, 12x— y corrompe cada plato individual que use ese producto, en silencio, hasta que alguien audite esa línea concreta.

Y se acumula. El margen de contribución, la ingeniería de menú, la varianza entre lo teórico y lo real: todo en la serie de Rentabilidad da por hecho que el coste del ingrediente que lo alimenta es real. Un factor de conversión equivocado no solo distorsiona una cifra; envenena cada cálculo construido encima de ella, de la misma forma que lo hace una porción indefinida —véase por qué “una porción” no significa nada sin una cifra para la versión de este mismo problema aplicada al emplatado.

Cómo gestionar esto de verdad

La solución no es introducir los datos con más cuidado: los humanos reintroduciendo miles de abreviaturas ambiguas bajo presión de plazos siempre producirán cierto porcentaje de errores. La solución es estructural:

1. La unidad de compra y la unidad de receta son dos campos separados, unidos por un número explícito. Nunca permita que “cómo se compra” y “cómo se usa” compartan un único campo, y nunca permita que la conversión entre ambos viva dentro de una descripción de texto. “1 caja = 12 × 1 kg” es un número, no una frase.
2. Un registro de producto por cada formato de envase real. Si un proveedor —o tres proveedores distintos— venden el mismo ingrediente en envases de tamaños diferentes, eso son varios registros de producto con sus propios factores de conversión, no un registro con un valor por defecto asumido que resulta acertado la mayoría de las veces.
3. Sin factor de conversión, no hay uso en receta. Un producto sin una conversión confirmada de compra a receta no debería poder usarse en el costeo en absoluto: es mejor un vacío evidente marcado para que alguien lo rellene que una cifra equivocada con aspecto plausible que nadie cuestiona.
4. Audite las unidades antes de tocar los precios. Al incorporar un nuevo local o un nuevo catálogo de proveedor, el campo de unidad es lo primero que hay que verificar: un precio correcto sobre un factor de conversión equivocado sigue siendo un coste equivocado. Corregir los precios antes que las unidades es resolver primero el problema más pequeño.
5. Vuelva a comprobar la conversión cada vez que cambie el formato del envase. Los proveedores sí cambian los tamaños de envase —una lata de 5 litros pasa a ser de 3 litros, una caja de 6 pasa a ser de 4— normalmente sin previo aviso. Si nada obliga a revisar el factor de conversión cuando eso ocurre, el múltiplo antiguo se sigue aplicando a la nueva realidad indefinidamente.

Nada de esto elimina la necesidad de una báscula y un ojo entrenado, igual que tampoco lo hace la disciplina de porciones. Lo que sí elimina es la versión silenciosa del error: la que parece una cifra real, sobrevive a cada informe y solo sale a la luz meses después como un margen que se erosionó en silencio y que nadie puede explicar.

Lecturas relacionadas

• El primer artículo de la serie Rentabilidad — los fundamentos para calcular el coste de alimentos real de un plato.
• Por qué ‘una ración’ como instrucción verbal produce tres platos distintos de tres cocineros distintos — y qué anotar en su lugar.

---

¿Está migrando un catálogo de proveedor y no está seguro de qué conversiones son realmente fiables? Reserve una llamada gratuita de 15 minutos con nuestro equipo —sin compromiso: Programe una llamada.

Fuentes y lecturas adicionales

• GS1 Package and Product Measurement Standard
• GS1 GTIN Allocation Rules for Foodservice
• Bad unit conversions poison your costs silently — Recipe Cost Calculator
• Recipe Costing Best Practices for Restaurants — meez
• Restaurant plate and menu costing 101 — MarginEdge