Dine-in, takeaway and delivery
Every sale carries its order type, and dine-in carries its table. Read any report by channel and the answer to "is delivery worth it" stops being an opinion.
Every order knows whether it is dine-in, takeaway or delivery, and which table it belongs to. The kitchen gets a ticket, the recipe takes the ingredients out of stock, and the hourly report tells you when you actually need the extra hand.
A restaurant's first question about its own numbers is never "what did we sell" — it is "how much of that was delivery?" The three channels have different margins, different staff costs and different problems, and a till that lumps them together cannot answer the only question worth asking at the end of the month.
Codipy POS puts the order type on the order. Dine-in carries a table number, delivery carries a rider, takeaway carries neither, and every report can be read by channel. Menu items are made to order rather than held on a shelf, so a sale is never refused for having "0 in stock" — but a recipe still takes the flour, the chicken and the oil out of inventory, which is the only way food cost is ever known rather than estimated.
Choose this business type during setup and these are the modules Codipy switches on for you.
Every sale carries its order type, and dine-in carries its table. Read any report by channel and the answer to "is delivery worth it" stops being an opinion.
The order prints for the kitchen as it is taken, so what is cooked is what was ordered rather than what was shouted across a counter.
A dish knows what goes into it. Selling it takes those ingredients out of stock, so food cost is a figure you can read instead of a percentage somebody once quoted you.
Menu items are services by default — no kitchen keeps a shelf of cooked biryani. Bottled drinks and packaged items can still be stocked as ordinary products.
A second display shows the bill being built. Fewer disputes at payment, and a customer who watches the total is a customer who trusts it.
Points apply themselves at the till, and the hourly report shows exactly when your rush is — which is when to roster staff rather than when you assumed.

Open the cash session. The float is recorded, so the drawer can be reconciled honestly at close.
Pick dine-in, enter the table, tap the items. The kitchen ticket prints as the order is taken.
Order type delivery, assign the rider. The cash he collects at the door stays his responsibility until he hands it in.
F4. Cash, card or split. The customer display shows the total; the receipt prints.
Day Close by channel — dine-in, takeaway and delivery separately — plus the hourly curve and the ingredients used against what you sold.
Yes — that is the point of order types. Every sale carries its channel, so sales, profit and hourly reports can all be read by dine-in, takeaway or delivery.
Yes, through recipes. A dish lists what goes into it, and selling it consumes those ingredients from stock, so you can compare what should have been used against what actually was.
No. Menu items are made-to-order by default rather than stocked, precisely so that a kitchen is never blocked by a stock figure. Bottled and packaged items can still be stocked normally.
Yes. A second screen shows the order as it is built and the total at payment, which settles most disputes before they start.
Yes. A delivery goes out on a named rider, and the cash collected is that person's responsibility until it is handed in and recorded.
Same installer, a different set of modules.