Why CateringOS works the way it does
Some rules in CateringOS feel strict at first: a day can no longer be changed, a unit belongs to exactly one group, an invoice cannot be corrected. This page explains the reasoning. Knowing it makes you faster — and means fewer arguments with the software.
What holds does not change quietly
As soon as others have acted on a piece of information, it is protected.
-
A released menu plan is locked from the configured lead time — by then goods are bought and families have ordered.
-
An accepted service statement is a final state.
-
An issued invoice is immutable; corrections run via cancellation and re-issue.
-
A HACCP reading is never overwritten — a corrective action added later becomes its own linked entry.
The common denominator: a value changed after the fact would no longer be evidence. Where you may intervene in an emergency, it is limited to a few roles and always logged.
Numbers, not names
The kitchen sees headcounts and portion groups — no individual personal data of end users. Data ownership over people lies with the facility, not the caterer.
This is not a setting that could be flipped; it is how the application is built. It protects both sides: the facility legally, and the caterer from responsibility for data they do not need for their work.
Deadlines are cost boundaries, not penalties
The cancellation deadline separates "free of charge" from "chargeable". After the cut-off, goods are bought and production is planned — the cost has genuinely been incurred. That is why the deadline is agreed in the contract rather than fixed in the software: it is a commercial arrangement, not a technical setting.
The same logic carries the automatic acceptance of service statements after seven days: without a deadline, your billing would depend on how quickly your customers respond.
Derived beats typed
Wherever a value can be derived from existing data, it is derived:
-
Allergens and nutrition follow from the ingredients.
-
The shopping list is menu plan minus stock.
-
The service statement comes from orders and headcounts.
A hand-maintained field is correct exactly until the first change. With allergens that is not a cosmetic flaw but a health risk.
One truth, no second place to maintain
Every piece of information has exactly one home:
-
Prices live in the contract — the kitchen view only displays them.
-
A unit belongs to exactly one menu plan group — otherwise there would be two contradictory plans for the same table.
-
What each plan includes lives in the operator console — the pricing page and this documentation are generated from it.