Tables and Order Flow
Restaurant mode should behave like service and order management, not only invoice entry.
Why tables should be real records
Tables should be configured as records because they support:
- dine-in order assignment
- clearer table status
- easier table-based order management
- better kitchen and service coordination
The manual table or token field should remain as a fallback for quick entry or takeaway reference.
Restaurant order fields
The restaurant Billing Page and Sale Create page should expose:
- order type
- dining table
- table or token
- order staff
- kitchen status
Order type
Order type tells the system how the order should be handled.
Common examples:
- Dine In
- Takeaway
- Delivery
- Counter
If the order is dine-in, a configured dining table should normally be selected.
Order staff
Order staff helps the business know who owns service responsibility.
This improves:
- accountability
- handoff clarity
- staff-based order tracking
Kitchen status
Kitchen status tracks the kitchen lifecycle.
Common statuses:
- Pending
- Preparing
- Ready
- Served
- Not Required
These statuses help the kitchen manage work and help front-of-house staff know when to serve.
Recommended service flow
- waiter captures the order
- system saves the order in Pending state
- kitchen receives pending items
- kitchen updates the order to Preparing
- kitchen marks items Ready
- service staff serves the order
- cashier or waiter completes payment when appropriate
This workflow is different from retail because the sale is not always completed immediately after items are added.