From kitchen to settlement: labels, routes and meal counts in one system

A production list instead of shouting in the kitchen

The kitchen needs an aggregate: how many pork chops, how many milk soups, how many diets. Not a list of 60 children in alphabetical order.

If the production report counts from the same orders as the labels, the “how many gluten-free?” question disappears.

PDF labels: codes, meal and exceptions

Hand-writing containers does not scale and breaks on a substitute shift. The label generator takes order data: facility code, child code, meal name and dishes — with a substitute, exclusions and a comment when they exist. There is no name and no diet name on the sticker.

By default the PDF focuses on containers with changes, not every standard lunch. The sheet format is a detail. The data source is not.

The route is the packing order — not a driver app

Facilities are assigned to routes. From that comes a packing-list PDF in drop-off order — for the kitchen and manager, not a GPS panel for the driver.

The system is not a TMS. It needs to know which facility travels with whom and in what order, so the bag is not mixed up at handover.

Settlements: the sum of ordered meals, not a notebook

At month-end you need breakfast, lunch, dinner and diet counts per client. The summary comes from the same orders as production — input for an invoice, not an invoicing module or a CSV export to accounting.

As long as someone keeps a parallel Excel “because the system is still learning”, the numbers will still diverge. The implementation test: you close the month from the report, not from notes.

What this means

• The day report, the label and the packing list read the same order.
• The label identifies the container with codes and exceptions — it does not replace the diet record.
• Month-end meal counts are the test of whether the software actually replaced the spreadsheet.