Use Cases

The running example throughout the wiki is GadgetSphere Sdn Bhd, a Malaysian consumer- electronics group: 22 retail branches, a separate online company and a distribution company, around 5,200 active items, SST-registered. This page is the retail branches’ story; the distribution company’s is on the Sales module.

The multi-branch retail counter

The shape. Twenty-two branches, a till or two in each, walk-in customers who mostly have no tax number, a loyalty programme, and a shift that has to balance before anyone goes home.

This is the most reproducible footprint in BigLedger’s own installation data: a login that holds POS General, Sales Order, Daily Cashier Reports, stock report, stock availability and the purchase receiving and return documents — one person’s whole job, crossing this module, Sales, Inventory and Purchasing. The cashier course is built from that footprint, not from this module alone.

A sale. The item is scanned; the member is looked up and a tier price or point rule applies; payment is split across cash, card and points if need be; FINAL writes the bill. Behind it, the stock line, the journal, the cashbook line, the point transaction and the e-Invoice queue entry are all raised by background processors — quickly, but not instantaneously.

A trade-in. Taking an old handset against a new one adds a trade-in line: the unit comes in, the amount due goes down, and a non-stock unit is created keyed by item, serial number and location. It only works if the item is set up as a trade-in item and the line carries a serial number — a trade-in line with no serial creates nothing.

A return at the counter. Goods coming back at the till go on as return lines on a bill, and the refund is at the price actually paid, because the original line is copied with its original discount. That is why a counter return still shows up on the till’s Z Report: the header is a cash bill. A Sales Return raised as its own document — a Sales module document, used when goods have to be inspected or the refund arranged — does not appear on the till’s Z Report at all, and the person balancing the shift needs to know which of the two happened before they start looking for a difference.

Deciding whether to take it back at all is a person’s decision, and the product does not second- guess it. When you pull a line off the original bill, the till writes a link row back to it — marked RETURNED_FOR, carrying the quantity returned — so the evidence of which sale this refund belongs to exists and can be read afterwards. What you should not assume is that the link is also a control. Nothing at the counter tests it: the basket in front of you is the only quantity check there is, and no refusal has been observed or found for a line that has already been returned once on another bill. Treat a second return of the same line as something your procedure prevents, not something the product does.

That puts the whole control in three places, and all three are the branch’s: the receipt, the serial number on a serialised item, and somebody reviewing returns against the original bills. Who: the supervisor, on the same pass as the void list. When: weekly is enough for a counter, daily if a pattern has already appeared. How they know it is working: every return over the branch’s own threshold has an original bill number against it, and the same bill number does not appear twice.

End of shift. Count the drawer, work out what you expected, then the day’s collection summary against the cashbooks. Both the arithmetic and the four things a difference can be are on Balancing the Drawer — the expected figure is one a person works out, because no screen computes it.

What goes wrong. Almost always one of: the till’s location is not the branch’s default location; there is no rounding adjustment item so settlement never quite equals the lines; or a settlement method has a cashbook but no GL code. The first two fail at FINAL, with a customer standing there; the third lets the bill through and fails its posting afterwards, when nobody is watching. Fix them before go-live, not on the first Saturday — and check every sales, tax and charge code has a company default while you are there, because a missing one fails nothing and simply moves the amount onto trade debtors.

And the shape of the job that is not on any screen. Twenty-two branches means twenty-two people holding cash they did not earn, handing it to other people, and being asked at the end of the day whether the amount is right. BigLedger records the sales perfectly and records almost none of that: it stores what the drawer opened with and what it closed with, and computes no difference between them; the money moving in and out mid-shift never reaches the shift’s own report; and the free-text box on the closing screen is not saved. So the branch owns the custody chain, the arithmetic and the explanation, and the product owns everything downstream of the deposit. The two guides that split the job that way are Balancing the Drawer and Banking the Day’s Takings.