CalcMenu
Blog
CalcMenu2 augustus 2026 · 5 min

Eén recept, duizenden etiketten: ERP, CalcMenu en ingrediëntendeclaraties synchroon

Een productiebedrijf dat in opdracht werkt, kan het zich niet veroorloven dat personeel de ingrediëntenlijst voor elk etiket met de hand opnieuw overtypt. Dit is het algemene patroon om een dagelijkse ERP-bestelfeed automatisch om te zetten in volledige, QUID-conforme en meertalige ingrediënten- en allergenenetiketten, elke dag opnieuw.

BlazeIQ Labels genereert een gedrukt ingrediënten- en allergenenetiket vanuit een recept

Bestelgestuurde productie, geen vast menu

Een productiebedrijf dat in opdracht werkt — een bakkerij die gebak produceert voor een huismerk, een sandwichfabriek die retail- en cateringklanten bevoorraadt, een producent van kant-en-klaarmaaltijden die voor meerdere private labels werkt — werkt niet vanuit een vast weekmenu zoals een restaurant. De productie hangt af van wat klanten die dag daadwerkelijk hebben besteld, en die bestellingen komen doorgaans binnen via een ERP-systeem — vaak iets als Oracle — dat inkooporders, orderregels en hoeveelheden beheert. Wat morgenochtend van de lijn komt, is wat het ERP zegt dat besteld is — niet wat vorige maand gepland stond.

Dat levert een specifiek integratieprobleem op dat de meeste receptensoftware voor restaurants nooit hoeft op te lossen. Een receptenbeheersysteem als CalcMenu beheert het voedingsmiddel zelf — het recept, de kostprijs, de voedingswaarde, de allergenen. Een etiketteringssysteem als BlazeIQ Labels beheert wat daadwerkelijk wordt afgedrukt en op de verpakking terechtkomt. Geen van de drie systemen heeft ongelijk om te bezitten wat het bezit. Het probleem is dat standaard niemand de dagelijkse overdracht ertussen bezit — en zonder die overdracht typt uiteindelijk iemand de hoeveelheden van de bestelling van vandaag met de hand over in het etiketteringssysteem, precies op het moment van de dag waarop een fout het meest waarschijnlijk is en het minst snel wordt opgemerkt.

Wat van het ERP naar het etiket moet — en waarom QUID het lastige onderdeel is

Het mechanische verloop is eenvoudig te beschrijven: een orderregel komt binnen vanuit het ERP, CalcMenu koppelt die aan een recept, en dat recept wordt geschaald naar de batchhoeveelheid die in die productierun daadwerkelijk wordt gemaakt — niet naar een vaste referentieopbrengst van maanden geleden. Vanaf dat punt moeten drie soorten declaratiegegevens elke keer correct op het etiket terechtkomen:

De volledige ingrediëntenlijst. Niet alleen “wat erin zit”, maar QUID — de kwantitatieve ingrediëntendeclaratie die de Europese en Zwitserse levensmiddelenwetgeving verplicht voor elk ingrediënt dat op de verpakking wordt genoemd of benadrukt (de “Kip (30%)” op een etiket van een kipsandwich is een QUID-declaratie). QUID is geen vast getal per recept: het moet opnieuw worden berekend op basis van de hoeveelheden die daadwerkelijk in die specifieke batch zijn gegaan — precies daarom werkt een statisch, vooraf gedrukt etiket niet bij bestelgestuurde volumes. Het percentage kan van batch tot batch, van run tot run, echt verschuiven.

Allergenen. Omdat de receptendatabase de enige bron van waarheid is over wat er daadwerkelijk in een formulering zit, hoeven allergeengegevens niet apart per artikel, per productierun of per markt opnieuw te worden ingevoerd — ze komen voort uit hetzelfde receptrecord dat een moment eerder al de QUID-berekening leverde.

De taal. Een productiebedrijf dat klanten in meer dan één markt bevoorraadt, heeft nodig dat hetzelfde recept etiketten oplevert in de taal die die markt vereist — de ene week Frans, de andere week Duits — zonder een aparte vertaalslag per etiket, per artikel, per taal. Dat werkt alleen als ingrediëntnamen en allergeentermen als gestructureerde data aan het recept hangen, en niet als vrije tekst die iemand met de hand in een etiketsjabloon typt.

Waarom dit alleen werkt als het gebouwd is om uit te breiden

Dit soort pijplijn draait onbewaakt, vroeg in de ochtend, op het volume dat het ERP die dag heeft doorgegeven — wat betekent dat het veel variatie moet kunnen opvangen waar een eenmalige export nooit mee te maken krijgt. Bestelvolumes schommelen van dag tot dag. Nieuwe receptvarianten komen erbij voor nieuwe klanten. Een uitgefaseerd product moet stoppen met etiketten genereren zonder dat iemand eraan hoeft te denken het met de hand uit te zetten. Wijzigingen in printer of etiketformaat volgen hun eigen tijdlijn, los van de receptenkant. Een interface die als één star script is gebouwd, breekt bij het eerste van deze gevallen; een interface met een duidelijke koppelingslaag tussen de orderdata van het ERP en de receptdata van CalcMenu vangt elke wijziging op als een kleine, afgebakende update in plaats van een opnieuw te onderhandelen project.

Het voordeel, concreet

Goed gedaan, haalt dit een specifiek, terugkerend risico weg in plaats van een functie toe te voegen om de functie zelf:

  1. Geen herinvoer van ingrediënten- of allergeengegevens, per artikel, per productierun of per markt — ze bestaan één keer, op het recept, en bereiken automatisch het etiket.
  2. QUID-percentages worden herberekend op basis van de daadwerkelijk geproduceerde batch, niet op een statisch referentierecept dat stilletjes verouderd raakt zodra de specificatie van een leverancier verandert.
  3. Meertalige etiketten komen uit één receptrecord, zonder apart vertaalproject bij elke nieuwe markt.
  4. De pijplijn vangt dagelijkse volumeschommelingen en nieuwe receptvarianten op omdat ze gebouwd is om onbewaakt te draaien op wat het ERP stuurt, in plaats van elke keer met de hand opnieuw te worden gestart bij een wijziging stroomopwaarts.

Dit is geen hypothetisch scenario — dit is de vorm van een pijplijn die we dagelijks draaien voor een productiebedrijf dat sandwiches in opdracht maakt en retail- en cateringklanten bevoorraadt.

Dit patroon is niet specifiek voor sandwiches — elk productiebedrijf dat in opdracht produceert voor retail- of cateringklanten loopt tegen hetzelfde fragmentatierisico aan zodra een ERP, een receptensysteem en een etiketprinter elke dag over dezelfde feiten moeten overeenstemmen. Het is een naaste verwant van het ERP/POS/CalcMenu-patroon dat we beschrijven voor hotelbedrijven met meerdere vestigingen — hetzelfde onderliggende probleem, andere systemen aan de andere kant. Zie onze pagina voor voedselfabrikanten voor hoe dit breder geldt voor receptgestuurde productie, en BlazeIQ Labels voor de etiketkant van de pijplijn zelf.


Produceert u tegen een dagelijkse stroom ERP-bestellingen, en bent u het beu dat ingrediëntenlijsten niet helemaal overeenkomen met wat er vandaag daadwerkelijk van de lijn komt? Boek een gesprek van 15 minuten: Hier inplannen.

Ontdek CalcMenu's receptenbeheersoftware voor voedselfabrikanten en bekijk hoe dit voor uw keuken werkt.

Betrokken sectoren

Reacties

Reacties komen binnenkort.