How to set up a restaurant

Yes, at two levels. Restaurant level: the "Access code" field in the add/edit restaurant dialog, shared by every table. Table level: the "Access code" field in the add/edit table dialog.

The part most people get wrong: the restaurant-level code does not merely "win a tie" — it SHORT-CIRCUITS the whole check. Once the restaurant field has a value, only that code is ever evaluated and the per-table codes are never read at all. A table code only matters while the restaurant field is empty.

On a wrong code the guest sees the information dialog reopen with "Restaurant access code is incorrect" or "Table access code is incorrect" — not an error page.

Access codes have no length limit, no format rule and no uniqueness check. You can reuse one code across restaurants, or rotate it daily without reprinting anything — the QR code and the access code are entirely independent.

Practical guidance: use a restaurant-level code if you just want to stop passers-by from ordering; use table-level codes if you want per-table control, and remember to leave the restaurant field empty in that case.

Yes. In "Tables" the "Change status" button on the table row flips it between "Enable" and "Disable".

You can also right-click the row and choose "Change Status" to open a dialog of the same name, pick the value and press "Save" (or "Close" to discard).

Warning: the in-grid "Change status" button saves IMMEDIATELY, with no confirmation and no undo. One misplaced click and that table stops accepting orders straight away.

When a table is set to "Disable", scanning its QR redirects the guest to the sign-in page rather than showing an error message. This is a common source of confusion — if a guest says "scanning does nothing", check the table status first.

Re-enabling the table makes the exact same QR work again; there is no need to print a new one.

Yes. In the dish grid on "Menus", the "Change status" button flips a dish between "Active" and "InActive". As with tables, this saves instantly with no confirmation dialog.

Guests still SEE a disabled dish on their phone but cannot order it: the add button loses its cart icon, turns grey and stops responding to taps.

The system shows no error message and adds no "sold out" badge. If you want guests to understand why, add a line to the dish "Description", for example "Sold out today".

This is the fastest way to handle running out mid-service — much quicker than deleting the dish and recreating it later, and it preserves the photo and any options you configured.

Yes. There is a per-company cap on the number of restaurants. Once you hit it, the add button is blocked with "Your company reached max restaurants allowed".

The free plan allows up to 2 restaurants and 50 tables in total across all of them. If you need more, upgrade — see the pricing page for the limits on each plan.

One thing to plan around when scaling: the table (QR) quota is counted COMPANY-WIDE, added up across all your restaurants, not per restaurant. Budget for the combined table count of the whole chain when choosing a plan.

Each restaurant needs its own menu, because a menu can be linked to only one restaurant.

The guest types their own address into "Email (to receive receipt)" on the information screen, right after scanning the QR.

The receipt is sent at exactly one moment: when staff move the order to "Completed". There is no "resend" button and nothing is sent at any other status.

The system collects every email address on that order and de-duplicates them, so each address receives exactly ONE email even if that person ordered three or four separate rounds within the same order.

Each receipt is rendered in the language that particular recipient chose when they scanned. A single order can quite happily send a Vietnamese receipt to one guest and an English one to another.

The email field is OPTIONAL. If nobody at the table enters an address, the order still completes normally, no error is shown, and simply no email goes out.

The receipt contains: the restaurant name, address, email and phone; the table number; the order ID; the timestamp; the total item count; the items total; percentage and fixed discounts; the additional fee; the subtotal; the service fee and tax with their percentages; the grand total; and any note. The subject line is "Restaurant Receipt".

The email is generated automatically and states that it should not be replied to. Delivery depends on the mail queue, so avoid promising a guest that it arrives instantly.

Yes, and this is how the system is designed to be used. Several guests scanning the same QR all add to a SINGLE order for that table, and items ordered earlier are preserved.

When someone adds to an already-open order, the order moves to "User Updated" and its row is highlighted on both the counter and the kitchen board, so staff immediately notice that something new came in.

Before pressing the order button, each guest can remove the lines they just picked — the system asks for confirmation through a "Remove Food Item" dialog.

After placing, guests can no longer remove anything: the red delete button disappears from their view. Only staff on the Counter board can amend or cancel.

Each guest enters their own email address, so everyone at the table can get a receipt if they want one.

Yes. On the dish row in the dish grid, press "Add Option" to open the "Create Option" dialog.

The structure has two levels: first create an option GROUP (for example "Size", "Toppings", "Sugar level") with the "Add Group Option" button, then add individual ITEMS to that group (for example "Large", "Regular") with the "Add Option Item" button. Finish with "Save".

Each item has its own "Price" field, which acts as a surcharge. It is non-negative and defaults to 0 — a free option is simply left at 0.

Each group has a "Select Type" field with two values, "Single" or "Multi". These ONLY control how many items a guest may pick from that group.

There is NO concept of a mandatory option group. Nothing forces a guest to choose before adding to the cart. If a choice is genuinely required by your business rules, split it into two separate dishes rather than relying on the system to enforce it.

Important warning: pressing "Save" is a DESTRUCTIVE REPLACE. The system clears the dish's existing option groups and re-saves exactly what is in the dialog. Do not open it, accidentally delete a group and then save — what was removed cannot be recovered.

Limits: at most 10 groups per dish, and at most 10 items per group, so up to 100 option items on one dish.

On the guest's phone, the selected surcharges are added to the base price and multiplied by the quantity, and the confirm button relabels live so the guest always sees the exact amount about to be added.

There are two routes. For detailed data, open "All Orders", set the filters, press "Query" and then "Export to Excel". For an overview chart, open the "Dashboard" page of the company portal and pick the restaurant.

The "All Orders" filters are: "Select Restaurant", "Select Table" (which includes an "All" entry), "Select Status", "From Date" and "To Date". Leaving the restaurant field empty is valid and queries across every restaurant.

Date rules are checked in this order and stop at the first failure: a missing start date gives "Please select from date"; a missing end date gives "Please select to date"; a start date after the end date gives "From Date cannot after To Date"; and a range over 65 days gives "Range is not more than 65 days". Exactly 65 days is still accepted.

That means a single query can never span more than 65 days. For a full-year report you have to export in several passes and combine them.

If there is no data, the export button still works but the system shows "No data" instead of downloading an empty file. Exported filenames start with "ListOrders_" followed by the company name.

The page also has an "AI Summary" button that produces an automatic summary of the data you just filtered.

About the revenue chart: it counts only orders in status "Completed", summing the grand total stored on each order; it buckets by the order's CREATION date rather than its completion date; and it separates figures per restaurant and per currency — so a company trading in several currencies sees several series rather than one merged number.

It is a scheduled batch statistic rather than a live query, so today's orders may not appear on the chart immediately. For up-to-the-minute numbers, use "All Orders".

Yes, but three details are worth understanding before you roll out, because they differ from what most people expect.

Currency: a restaurant has NO currency field. Currency lives on the menu and is chosen in the "Create Menu" dialog. Since a menu links to only one restaurant, branches trading in different currencies must have separate menus.

Language: the GUEST picks the language on the information screen after scanning. There is no per-restaurant language setting, so you cannot make a Japanese branch always display Japanese — but Japanese guests can select it themselves, and their receipt arrives in Japanese too.

Time zone: the whole company shares ONE time zone. A restaurant has no time-zone field of its own. A branch in another zone will see order creation and update times rendered in the head-office zone — worth remembering when reconciling end-of-shift reports across countries.

A restaurant also has no country field, so put the country or city into the "Name" or "Address" field to tell branches apart in the list.

In practice ONE company (admin) account runs the entire workflow.

The Counter, Kitchen and Payment Page screens are all opened from that account. In real use you sign in with the same account on several machines: the counter PC, the kitchen screen and the customer-facing display.

There are currently no scoped staff logins for the restaurant module — all eight restaurant screens live in the company portal, and the staff portal has no restaurant menu at all.

Operationally that means you should leave the kitchen machine and the customer display parked on just the page they need, since the signed-in account still has access to the rest of the system.

Work through these six checks. The useful part is that each cause has a different symptom, so you can tell them apart.

1. Has a menu been linked to the restaurant? Open "Restaurants" and look at the "Menu" column — empty means unlinked.

2. Has the menu or the restaurant behind that QR been deleted? In this case the guest is redirected to the sign-in page.

3. Is the table set to "Disable"? This also redirects to the sign-in page rather than showing an error — easy to mistake for a network problem.

4. If an access code is set, was it typed correctly? A wrong code reopens the information dialog with a mismatch message, which looks quite different from the two cases above.

5. A restaurant with no usable menu shows the message "This table is not ready for order now" rather than a blank page.

6. If the company record is gone, the page shows "No events are assigned to this QR".

Quick way to tell them apart: bounced to the sign-in page means a disabled table or deleted data; a code mismatch message means an access-code problem; "This table is not ready for order now" means a missing menu.

Open "Payment Page" in the Restaurant Manager group, pick the restaurant and the language, then press the button of the same name. The browser switches to a standalone display page with no left menu. Go full screen with F11 and turn the monitor towards the guest.

Normally the screen shows the restaurant name with the "Welcome Message" you configured, the "Note Message" underneath, and up to three transfer QR codes. Any slot without an uploaded image is simply skipped.

When an order moves to "Payment", the itemised bill appears automatically with these rows: Total Items, Amount, Discount (%), Discount (Amount), Additional Fee, Subtotal, Service Fee with its actual percentage, Tax with its actual percentage, and a Grand Total styled larger. The Order ID and Time appear above.

The single most important point: the bill only shows while the order is in "Payment". Every other status — including "Completed" — clears it and returns the screen to the welcome text. So let the guest check the figures BEFORE you complete the order.

The display is built to stay open for the whole shift: it sends a keep-alive every 4 minutes, without which the session would expire after 15 minutes and the screen would quietly stop receiving updates.

If you need to adjust a discount or fee while the bill is on the guest screen, just change it on the counter and press "Save" — the display refreshes to match.

Not by the guest. There is no cancel button anywhere on the guest side.

Staff on the "Counter" board right-click the order row and choose "Cancelled", or pick that value in the row's status selector.

A note on wording: this status always displays as "Cancelled" to users. Avoid saying "rejected" to guests or in internal documentation, so your language matches the interface.

After cancelling, the row disappears from the counter grid and the tax and service-fee rates are frozen onto that order.

On their phone the guest sees a cancellation message and can no longer add to the old order; a "New Order" button appears in their cart so they can start again. Re-scanning the QR also starts a fresh order.

The Kitchen board CANNOT cancel an order — that is deliberate, and the ability sits only with the counter.

Yes, with no limit. You can run several Counter screens, several Kitchen screens and several Payment Page displays for the same restaurant at once.

They are all registered against the restaurant, and they all receive the same update stream, so a new order appears simultaneously on every open screen.

A practical example: a two-floor venue can put a kitchen screen on each floor, and a busy venue can run two counter machines to take payments in parallel.

Updates travel through the platform message queue, so this keeps working when the application runs as multiple processes. If the queue has a problem, orders will not appear by themselves — use the "Refresh" button on the board in that case.

Each screen sends a keep-alive every 4 minutes, so a display left untouched still keeps receiving updates.

No. The grand total is always calculated and cannot be typed into.

To change what the guest pays, adjust one of the three fields on the "Counter" board — "Discount %", "Discount Amount" or "Additional Fee" — and press "Save".

The total is recalculated after EVERY save, and the new value is written to the order at that moment.

You can still adjust after the order has reached "Payment" and the bill is already on the guest screen; the display refreshes to match. Just finish adjusting before you move it to "Completed".

None of the three fields accepts a negative value. If a discount is large enough to push the result below zero, the system stores a grand total of 0 rather than a negative number.

The "Notes" field alongside them is the place to record why a discount was given — worth filling in for end-of-shift reconciliation.

When you create or edit a restaurant, fill in "Tax (%)" and "Service Fee(%)". These are restaurant-level settings and apply to every order of that restaurant.

Both default to 0 and reject negative values, but there is NO upper bound — nothing stops you typing 80 when you meant 8. Double-check after entering them.

Both are calculated on the amount AFTER discounts, not on the raw items total. See question 17 for the full formula.

The rates are frozen onto an order only when it becomes "Completed" or "Cancelled". That is why changing your tax rate next month leaves old receipts showing the figures that applied at the time of sale — historical reports are never rewritten.

One consequence to watch: if you change a rate while an order is still open, that order will use the NEW rate when it completes. Change rates when no orders are in service.

On the receipt and the customer display, these two rows show the percentage actually applied, for example "Service Fee (5 %)".

The full calculation has four steps, in this exact order:

Step 1 — Percentage discount = Discount % × (Items total + Additional Fee) ÷ 100

Step 2 — Subtotal = (Items total + Additional Fee) − (Discount Amount + Percentage discount)

Step 3 — Service Fee = Service Fee(%) × Subtotal ÷ 100, and Tax = Tax (%) × Subtotal ÷ 100

Step 4 — Grand Total = Subtotal + Service Fee + Tax. If the result would be negative, it becomes 0.

"Items total" here is the sum of (dish price + option surcharges) × quantity across every line of the order.

Three things are easy to get wrong. One: the percentage discount applies to (items + additional fee), not to the items alone. Two: tax and service fee are calculated on the DISCOUNTED subtotal, not on the raw items total. Three: the grand total is never negative.

Example: 2 dishes × 50,000 = 100,000 items total, additional fee 10,000, discount 10%, tax 10%, service fee 5%. Percentage discount = 10 × 110,000 ÷ 100 = 11,000. Subtotal = 110,000 − 11,000 = 99,000. Service fee = 4,950. Tax = 9,900. Grand total = 113,850.

A worked example of the zero floor: one dish at 10,000 with a 50% discount plus a further 10,000 off produces a negative figure, but the system stores a grand total of 0.

The same formula is used in all three places — the counter, the customer display and the email receipt — so those three figures always agree.

Standardise at one branch first: build the menu, run a few real services, settle on your table-naming convention and how you handle discounts, and only then roll out.

The most important technical constraint: a menu belongs to exactly one restaurant. There is NO shared chain-wide master menu, so every branch needs its own menu even when the menus are identical.

The consequence: a chain-wide price change means editing every menu. Factor that effort in if you have many branches.

Adopt a naming convention from day one, for example "Sen Vàng - District 1" and "Sen Vàng - District 1 - Main menu", because the menu selector displays entries as "restaurant name - menu name".

Remember that the table (QR) quota is counted company-wide across every branch, while the dish quota is counted per FOOD GROUP.

Revenue reporting is already separated per restaurant and per currency, so you get per-branch figures without any extra configuration.

Images: 250 KB per image, and only the .png or .jpg extensions. The .jpeg extension is NOT accepted. This limit applies equally to dish photos, restaurant photos and all three payment QR codes. An oversized file is rejected with "File is too big".

Orders: at most 200 items in one order, counting both the total quantity and the number of cart lines. Going over shows "You reached maximum number of food items".

Options: at most 10 groups per dish and 10 items per group — up to 100 option items on a single dish.

Dishes: the dish quota is counted PER FOOD GROUP, not per menu. So a menu with several groups holds considerably more dishes than the headline number suggests.

Order lookup: any single "All Orders" query is capped at a 65-day range.

Payment config: exactly one per restaurant, with a maximum of three payment QR codes.

Menus: each menu links to exactly one restaurant.

Plan-dependent: the number of restaurants, tables (QR codes, counted company-wide), menus, food groups per menu, and how long order history is kept. The free plan allows 2 restaurants, 50 tables in total across all of them and 6 months of history — see the pricing page for the paid tiers.

First, the constraint: every order MUST originate from a table QR. There is no screen anywhere that lets staff create an order on a guest's behalf from scratch.

The quickest workaround: a staff member scans that table's QR on their own phone and places the order for the guest. The order is still recorded against the correct table.

Because the QR encodes an ordinary web link, staff can bookmark each table's link on their phone. Opening the bookmark goes straight to the ordering page for that exact table, with no scanning at all.

If a printed code is smudged, torn or missing, open "Tables" and press "Show QR" on the table row to bring the code back up at any time.

Note that the QR dialog is VIEW-ONLY — there is no download button and no print button. Use your browser's print function, or screenshot the code and print that.

If the guest can scan but sees no dishes, that is a different problem — see question 11.

iAttendance runs entirely in the browser, so there is no dedicated POS hardware to buy. A phone, a tablet, a laptop or an old spare monitor all work perfectly well.

Guests do not install anything either: a phone camera pointed at the QR opens the ordering page.

In practice the hardware cost for a small venue is: one computer at the counter, one secondary monitor facing the guest, one screen in the kitchen if it is far from the counter, and the cost of printing the table QR codes.

On the software side there is a free plan for small venues — 2 restaurants, 50 tables in total across both and 6 months of history — plus monthly paid plans when you need more restaurants, more tables or longer history.

See the pricing page for the details of each plan and its limits.