The counter
Selling face to face, on the same records as everything else
Akkad is an operations platform built around inventory, and the counter is one of its surfaces — not a separate product, and not the headline. A sale rung up at the till becomes exactly the same order record as a storefront checkout: same statuses, same pricing rules, same effect on stock. What this page describes is the extra machinery a physical counter needs on top of that: a drawer that has to balance, a scanner that has to be fast, and — in a restaurant — a floor of tables that have to stay straight through a service.
Plenty of products lead with the till. Akkad does not, because a till is the narrowest possible view of a business: it knows what was sold in the last eight hours and nothing about what you own, what you paid for it, what is expiring, what a courier is holding, or what a customer still owes. The counter here is a way into the same order book that the storefront, the landing pages, the delivery desk and the reports all read from.
The practical consequence is that nothing has to be reconciled between systems, because there are not two systems. A counter sale deducts stock through the same path a website order does. A pricing rule you wrote for in-store only is evaluated by the same engine that prices your storefront cart. A shift that closes at ten in the evening feeds the same annual money box that a bank transfer received at noon feeds. There is no nightly export, no matching job, and no window in which the two disagree.
01
One order book, seen from the counter
Four things stay identical between a counter sale and every other kind of order. They are worth stating plainly, because they are what makes the rest of the platform usable by a shop that also sells online.
A counter sale is a source, not a separate ledger
Cashier is one of the four order sources, alongside internal, landing page and website. It lands in the same orders list, exports in the same file and appears in the same reports.
It starts at delivered, because it is
The default status is vertical-aware: a counter sale opens at delivered, since the customer already left with the goods. A processing state would be a fiction that someone would eventually have to clean up.
The same pricing rules apply, with channel targeting
Rules carry a channel list, so a promotion can be in-store only, storefront only, or everywhere. Staff at the till never have to remember which online offer is currently running — the rule knows where it lives, and the scan cart evaluates it as items go in.
Stock moves through the same door
A till sale deducts against the same single stock pool, respecting the same per-item stock management, the same negative-stock setting and the same first-expiry-first-out batch logic used everywhere else.
02
Opening and closing a drawer
A cashier session is a shift with money in it. One user can have exactly one open session at a time, which removes the whole category of “which drawer did that sale go into”.
- 1
Open with a counted opening balance
The cashier records what is physically in the drawer at the start. Everything the close computes is measured against this number, so it is the one figure that has to be right before the shift begins.
- 2
Every sale links itself to the session
Orders taken during the shift carry the session, so the close does not have to guess a time window or infer membership from timestamps.
- 3
The close reads the orders, not a running tally
At close, the session totals are computed from the linked orders themselves — cash orders to cash, card orders to card, and split orders broken apart by their own recorded cash and card amounts.
- 4
Expected is compared against actual
Expected cash in the drawer is the opening balance plus the cash collected. If the cashier enters what is actually there, the discrepancy is the difference — recorded, not silently absorbed.
- 5
The totals are cached on the session
Once computed, every figure is stored on the session row. A shift report can be reprinted next week without recomputing anything, and it will be identical to the one printed on the night, even if an order has been edited since.
03
What the close actually counts
Split payments are where most drawer arithmetic goes wrong: a half-cash, half-card sale counted whole into one bucket throws the count off by exactly the other half, every time.
| Order payment method | Counts toward cash | Counts toward card |
|---|---|---|
| Cash | The order's full total | — |
| Card | — | The order's full total |
| Split | The order's own recorded cash amount | The order's own recorded card amount |
Expected in drawer = opening balance + total cash collected. Cash discrepancy = actual counted − expected. Because a split order stores its cash and card halves as separate fields rather than as one total with a label, the close reads them directly rather than apportioning anything.
04
Rules around the drawer
Blind counting, if you want it
A setting forces a cash count at close, so the cashier enters what is in the drawer rather than being shown the expected figure and confirming it. Whether that is appropriate depends on the shop, so it is a switch rather than a policy.
Denominations you actually use
The counting sheet is built from the note and coin denominations configured for your organisation, so counting the drawer means entering how many of each — not doing mental arithmetic at the end of a shift.
Who may close what
Owners and holders of the cashier-management permission can close any session. A plain cashier can close only their own. Corrections to an opening balance, a counted amount or the notes are limited to the same management permission.
History that opens where you need it
Session history is paginated at up to 100 per page with open sessions listed first, because the question you usually arrive with is “which drawer is still open”.
05
Tiles and scanning
Two ways of getting an item into a sale, aimed at two different kinds of shop.
Up to 30 pinned tiles
Pin your fastest-moving items as a grid of quick-sale tiles in an order you set by hand. The counter knows whether anything is pinned, so a shop that never uses tiles is never shown an empty grid.
Any scanner you already own
The counter reads raw keyboard input from the scanner into a scan buffer, which is how hardware barcode scanners present themselves over USB. There is no driver, no pairing step and no supported-model list — if it types, it works.
It works when the connection does not
A scanned code is looked up through the API or through the local offline cache, so a dropped connection at the counter does not stop the queue moving.
Unknown code, new item, no interruption
Scanning something the catalogue has never seen offers to create it on the spot with the barcode already filled in — instead of forcing the cashier to abandon the sale and go to the catalogue screen.
Strip or box, resolved by the barcode
Where every pack level carries its own barcode, the scan resolves straight to the right pack. Where the base unit or a pack level has no barcode of its own, a selection sheet opens so the cashier picks which one this is.
Discounts evaluated as you scan
Items dropped into the scan cart are priced by the same discount rules the storefront uses, so a volume ladder or an in-store-only promotion fires at the counter without anyone having to remember it.
06
Four scan modes
The dedicated scan screen does four jobs, and it remembers which one you were last doing — because a shop that spends its mornings receiving and its afternoons selling should not be re-selecting a mode all day.
| Mode | What it does |
|---|---|
| Create order | Scan items straight into a cart. A persistent sheet holds the scanned lines with quantity steppers, variant and pack handling and live discount evaluation. A cashier-actions layout puts the order summary beside the live camera with search, customise, new sale and charge to hand, and a missing item can be created inline without leaving the flow. |
| Define item code | Scan to assign a SKU or barcode to an existing item — the fast way to code up stock that arrived unlabelled. |
| Find order | Scan an order's barcode or QR code to open that order directly. |
| Scan to return | Scan an order code to process a return. A full return is a status change on the whole order; a partial return opens a sheet where you keep specific lines, and the order is saved as the lines that were kept. |
Partial returns are handled as “keep these lines” rather than “remove those lines” deliberately: the person holding the goods is looking at what the customer is keeping, and stock, totals and the order record all follow from that single decision.
07
The distinction that makes the numbers true
The cashbox is money you are holding, not revenue
Almost every disagreement between an owner and their software about “how much did we make” is really a disagreement about when money counts. A sale is revenue on the day it happens. Cash is in the box on the day someone actually hands it over — which for a delivered-on-credit order, an installment plan or a refund is a completely different day. Akkad keeps an annual cashbox that answers the second question honestly, in three buckets: cash, card and bank.
Collected when it was collected
An order with payment-ledger rows contributes those rows, dated when they were paid and sorted into each row's own method bucket. A partial payment is visible as a partial payment. An installment collected in March 2027 lands in the 2027 box, not in the box for the year the order was placed. Orders with no ledger rows keep the simpler rule: marked paid means the full total, dated when the order was created.
Refunds take money back out, because they do
A refund is a negative row in the payments ledger, so it reduces the box. That is not a special case in the reporting code — it falls out of the ledger being signed.
One definition of “money moved”, used twice
The same function that computes the cashbox balance computes the financial report. There is exactly one definition of a money movement in the platform, so the box and the report cannot tell you different things about the same day.
A year that closes, and stays closed
Each year runs active, then grace, then closed, with the grace period ending on 1 May of the following year. Closing snapshots the closing balances and records who closed it — a system auto-close is recorded as such. A closed year serves the frozen snapshot rather than a live balance, and reopening it is a deliberate act rather than a side effect.
08
Moving money in the box
Opening balances per bucket
Each year starts with what you actually hold in cash, on card and in the bank, recorded separately, with a setup step you complete once.
Deposits, withdrawals and transfers
Manual movements record their method — and a transfer records both the method it left and the method it arrived in, so moving takings to the bank is one entry rather than two guesses.
Shipping in or out of revenue
A setting controls whether shipping income is stripped out, because merchants disagree about whether delivery money is revenue or a pass-through, and both answers are defensible.
09
Tables, and why a rename never breaks history
Dine-in is a restaurant concern rather than a universal one, so it is built as a distinct service type rather than bent out of the delivery flow.
A floor that sorts the way you read it
Tables carry a name, an optional area that groups the picker, a sort order and an active flag. Ordering is natural — runs of digits compare as numbers, so A1, A2, A10 sit in that order rather than A1, A10, A2, and tables 1 to 12 do too. Tables with no area sort after every named area.
Occupancy comes from the order, not a flag
The table list returns each table together with its currently open dine-in order, so the floor view shows the order number, the total, the guest count, how long the party has been seated, which waiter opened it and how many rounds have gone out. There is no separate occupied field to fall out of sync — the open order is the truth.
You cannot delete an occupied table
Deletion is blocked while a table has an open order. It is the kind of mistake that is easy to make on a busy evening and painful to unwind afterwards.
History keeps the label it was served under
Past orders store a snapshot of the table label rather than only a reference. Renaming table 4 to “Terrace 1”, or deleting it entirely, leaves last month's orders reading exactly as they did on the night.
Three service types, and only the ones you use
Dine-in, takeaway and delivery. The orders list filters by service type, and the platform reports which types your organisation actually uses so the app renders only the relevant chips — a delivery-only kitchen never sees a dine-in filter.
A table is held until the bill is settled
A dine-in order holds its table while it is unpaid and still in pending, processing or shipped. Settling marks it paid and delivered, which releases the table; cancelling or returning releases it too.
10
Rounds, and why they are safe to retry
A dine-in order grows through the service — drinks, then starters, then someone orders dessert. Each of those is a round, and appending one is deliberately a different operation from editing the order.
- 1
The append endpoint only adds lines
Unlike a whole-order edit, appending a round cannot remove or rewrite anything already on the order. That narrowness is what makes it safe to retry from an offline flush or a relay on the local network — a repeat cannot destroy what a colleague added in between.
- 2
The server allocates the round number
Two waiters can hit send at the same moment, so the number the client sends is ignored. The order row is locked and the existing lines are read under that lock, which prevents the isolation-level trap where a plain read serves a pre-lock snapshot and two devices both produce round three.
- 3
Each round carries its own notes
Rounds record when they were added, and every line can carry a kitchen note — “no sugar”, “cold” — attached to that line rather than dumped into a single order-level comment box.
- 4
A settled order refuses new rounds
Once an order is paid, delivered, cancelled or returned, an append is rejected outright rather than quietly landing on a closed bill. Requests carry their own identifier, so a genuine retry returns the original round instead of creating a duplicate.
- 5
Settling hands the table back and feeds the drawer
Settle sets the payment status and method, and attaches the settling cashier's drawer session along with the split tender — which is precisely what the shift close reads to compute cash and card. A party moved to a different table mid-service re-snapshots the label, so the bill reads as the table it was actually settled at.
11
Questions
Is this a point-of-sale product?
It is a point-of-sale surface inside an operations platform. If a till is all you need, a dedicated till will serve you. Akkad is worth it when the counter is one of several ways you sell and you want stock, costs, debts, couriers and reporting to be the same set of records rather than four systems that have to agree.
Do I need a specific barcode scanner?
No. The counter reads raw keyboard input, which is how USB barcode scanners present themselves, so any scanner that types works. Lookups run against the API or the local offline cache, so a brief loss of connection does not stop the queue.
How does a split payment affect the drawer count?
Correctly. A split order stores its cash and card halves as separate fields, and the close routine reads each into its own bucket rather than assigning the whole total to one method. Expected cash is the opening balance plus the cash collected, and any difference against the counted amount is recorded as a discrepancy.
What is the difference between the drawer and the cashbox?
The drawer is one cashier's shift. The cashbox is the organisation's money for a whole year, split across cash, card and bank, and it tracks what you are physically holding rather than what you earned. Money enters the box when it is actually collected, which for installments and credit sales is often a different year from the sale.
Can a cashier close someone else's shift?
Only if they hold the cashier-management permission, or they are the owner. A plain cashier can close their own session and nothing else. The same permission governs correcting an opening balance or a counted amount after the fact.
If a waiter's phone drops mid-round, will the kitchen get the items twice?
No. Round appends carry their own request identifier with a uniqueness constraint, and the round number is allocated by the server under a lock. A retry returns the original round rather than creating a second one, and an order that has already been settled rejects the append outright.
Related
Orders
The record a counter sale becomes — statuses, the totals engine, cash rounding and idempotency.
Reporting
The financial report, driven by the same definition of a money movement the cashbox uses.
Verticals
Where dine-in, dosage fields and the rest of the per-industry tuning actually live.
آن را روی فهرست کالاهای خودتان ببینید
با بستهٔ مناسب شروع کنید، کالاهایتان را از یک فایل اکسل وارد کنید، و همان روز فروشگاه، صندوق و دفتر سفارشِ فعال داشته باشید.
بستهٔ رایگان موجود است. برای امتحان به کارت نیاز نیست. ورود اطلاعات، فهرست کالاهای فعلی شما را همراهتان میآورد.