Office Meal Ordering: Which Location, Which Day and Which Cutoff?

An office meal-ordering app should make the delivery place and day explicit before a person submits. It should also explain when requests stop being editable and who handles changes after the vendor handover. “Ordered” is too vague if staff cannot tell whether a request is still internal or has reached the supplier.

This is a commissioning guide for coordinating employee meals, not a restaurant food-safety system or a guarantee that dietary requests can be fulfilled.

Confirm where the person will eat

A person's normal workplace is not always their lunch destination. In a fictional example, someone works at a workshop in the morning but attends a meeting at another office at lunchtime. A correct employee profile can still produce a wrongly delivered meal if the ordering app assumes the usual address.

The Odoo 19 Lunch orders guide explicitly says the employee's work schedule is not reflected in the lunch Location field. Its location is selected separately. That is a product-specific example of a decision your brief must settle: propose a default if useful, but show the actual destination before confirmation.

Use a recognisable location name and a delivery point staff can find. Decide what happens if the chosen location is unavailable on that day. Changing an employee's default office should not silently move a meal already handed to the vendor.

Make the meal date visible throughout

Odoo documents choosing a date before adding products, which then belong to that delivery date. For your app, keep the date beside each meal in the summary, not only at the top of a calendar that may have changed.

If someone orders for several days, show the day, location and items together so they can check each delivery. A total alone cannot reveal that Tuesday's meal went to Wednesday. Agree how copying a previous meal works: reusing the items must not accidentally reuse an old delivery date or destination.

These summary and copy safeguards are proposed requirements to demonstrate, not verified Odoo behaviour.

Define the vendor handover boundary

The source describes vendor operating hours and a deadline for sending orders by email. A supplier being open does not mean your office can still amend the batch already sent to them.

Write down the cutoff, its time zone, the responsible coordinator and the rule for a request arriving at the boundary. Show whether a meal is an internal request, handed to the vendor or received at the office. If dispatch has an uncertain outcome, the coordinator should reconcile the existing batch rather than send another full order blindly.

After handover, a requested change needs its own result. Do not show “cancelled” merely because an employee asked to cancel. Agree how the coordinator obtains the vendor's response and how any account adjustment is recorded. The cited guide has differing cancellation descriptions for its dashboard and history; it does not justify assuming one universal rule for your implementation.

Arrival is not personal collection

Odoo defines Received as arrival at the location verified by the administrator. That does not establish that a named employee collected or ate the meal. If individual collection matters, scope a separate acknowledgement and decide who can record it.

Use fictional meals in your acceptance tests: a different office for one day, several future dates, a request at cutoff, an uncertain dispatch and a change after handover. Include a supplier who cannot fulfil an item. Staff should see who must act without an unsupported promise about replacement or reimbursement.

Bring this day-and-location handover to a workflow-app discussion. For allergies or other safety-critical needs, agree a suitable process with the food provider and competent staff; a free-text note in an app is not a safety guarantee.