Use Cases

“Do I have to raise a sales order before I can invoice?” No — and whether you should depends on the shape of the sale, which is what this page is about. Each shape below says who does the job, what BigLedger does behind the screen and what it leaves to you, and how you know it went right. After the shapes come the four things they share: where their numbers come from, what goes wrong, what none of them will do for you, and the monthly check.

The running example is GadgetSphere Sdn Bhd, a Malaysian consumer-electronics group with three companies — the retail company GS with 22 branches, the online company GSO and the distribution company GSD — around 5,200 active items, SST-registered. The till at the 22 branches is the Point of Sale module’s story; this page is the distribution and online companies’ story, plus the retail branches’ corporate walk-ins.

1. The B2B order-to-invoice desk

The shape. GSD sells to corporate customers on credit terms, against a written quotation and the customer’s purchase order. A corporate client asks for 10 ultraportable laptops at RM 3,800; they are quoted, ordered, delivered in two lots of 6 and 4, and billed.

The flow. Sales Inquiry → Sales Quotation → Sales Order → goods go out → Sales Invoice.

Three corrections to how this is usually drawn:

• The quotation is not “converted” to an order. The order picks the quotation up from its own knock-off tab. (The Convert action on a quotation creates a receipt voucher for a deposit, and deletes the quotation.)
• Nothing in this chain is approved. A discount is released by a permission on one line, not by a routed request.
• The order is where availability is consumed, not the invoice. The order posts nothing; the invoice posts everything.

What happens when each document reaches FINAL

Bill both lots on one invoice instead and the journal reads RM 40,280: RM 38,000 of sales and RM 2,280 of SST. An invoice whose cost is still blank right after FINAL has not finished, rather than gone wrong — the jobs run after the call returns.

Deposits. A deposit taken against a quotation or an order becomes a receipt voucher and is knocked off later. It is real money in a real cashbook from the moment it is taken.

Credit. The order shows which credit limit it carries, not how much of it is left. Nothing checks the limit at save. An optional check, switched on in the Sales Order and Sales Invoice settings, refuses FINAL once the customer’s credit in that company is used up; it counts one company only. If the answer has to be “no” wherever an order or invoice is finalised, blacklist the customer (Deciding on Credit). The online store’s checkout does not check the blacklist, so a stopped trade buyer who orders there needs the extra step in Stopping Supply to a Customer.

Many deliveries, one bill. A corporate customer who takes deliveries every week does not want an invoice for each one. SO Consolidation gathers the finalised order lines and raises one sales invoice per customer — grouped by company, branch, customer and sales agent. It runs on demand, or from a dated event the applet queues the moment the event is saved; no Scheduler clock drives it. Two things decide whether it works: the orders must be FINAL, and every order header must carry a sales agent, because the agent is part of the grouping key and an order without one can never be matched.

When the goods leave from a warehouse, not the selling branch

A corporate walk-in at a small branch buys a laptop the branch does not keep; the Klang Valley hub sends it that afternoon. Each stock line carries a delivery location beside the document’s own location, and when it is set, FINAL’s stock check reads that location. Set it to the hub and the sale goes through; leave the branch’s location on a line the branch cannot cover and FINAL is refused with There’s not enough stock for item …. The same refusal on an item that is on the branch’s shelf usually means the delivery location was saved pointing somewhere else — correct the field, not the stock.

Whose job, and how they know. The sales administrator keys the order from the customer’s purchase order and checks quantities and prices against it before FINAL — nothing else compares them. The credit controller decides on credit before the order is keyed, not after. The billing clerk invoices each delivery (or runs SO Consolidation weekly) by knocking the order off, never by keying the invoice fresh. They know the order is finished when its SO Line with SI KO row shows nothing outstanding: every unit invoiced, or the remainder closed on purpose.

2. Stock placed at a customer’s site

The shape. A corporate customer keeps 30 wireless-audio demo units in its own showroom. GSD still owns them, and bills each month for what the customer reports as sold. It is one of the least-used shapes in the product, which is a reason to rehearse it on one test transfer first.

The flow. Customer Consignment moves stock out to a consignment location held for that customer and receives it back. Both directions move the stock ledger only — amount signum 0, so there is no journal at all until you bill. Billing the consumed units is an ordinary sales invoice.

Billing what the customer used

At month end the customer reports 8 units sold. You raise one sales invoice for 8 — and the invoice lines must carry the customer’s consignment location, because an invoice takes stock out of the location on its line. Key it from your own warehouse while the 8 units sit in the customer’s showroom and FINAL is refused for lack of stock, or — if your company has that check off — the warehouse goes 8 units short and the showroom stays 8 units long.

The invoice does not close anything in Customer Consignment. The Transfer Queue pairs a Transfer Out with a Transfer Receive and nothing else, so the 30 stay “out” on that queue whatever you bill. The figure to watch is the stock balance at the customer’s consignment location: 30 sent, less 8 invoiced, is 22, and that is what the customer should be able to count.

Two things the product will not do for you. It does not check that the from-location and the to-location belong to the same company, so a transfer can land stock in another company’s location without complaint. Pick a location of your own company every time: stock that goes to another company of the group changes owner, and that is a sale and a purchase (intercompany pairing), not a transfer. And the applet exposes no VOID button — a wrong transfer is deleted as a draft or corrected with an opposite movement.

Whose job, and how they know. The account manager collects the customer’s sales report each month and asks for a count of what is left. The billing clerk invoices from the consignment location. The stock controller compares the customer’s count with the stock balance at that location; they agree, or the difference is a loss the account manager takes up with the customer before the next delivery.

3. Orders that arrive from a marketplace or the storefront

The shape. GSO sells on marketplaces and through the group’s own storefront. Nobody keys those orders; they arrive. Few groups run this shape, so its habits are worth setting down before the first order lands.

The flow. A marketplace order is pulled in by a background job and lands as an ordinary Sales Order (Internal) on the marketplace branch — the same INTERNAL_SALES_ORDER document a clerk would raise. A storefront checkout ends as a sales order too: the customer’s submitted cart is the order, the same document row rewritten to the sales-order type, already FINAL and carrying a fresh running number. From there it is the chain in shape 1: deliver, invoice.

What it means for stock. Nothing changes: the order reduces available, and the sales invoice raised from it is what takes the unit out. Sell one unit at the till and one on a marketplace, and Stock Balance drops by two — once the marketplace order has been invoiced, not when it arrived.

What the shop is shown, and why it is not your Available figure

The quantity the connector publishes to a shop is its own calculation, written onto the listing when the stock job runs: the balance at the locations you mapped to that shop, less some of the channel’s open orders, then a safety buffer applied — a fixed number of units subtracted, or a percentage multiplied (a percentage of 5 publishes 5 %, not 95 %). Which orders it subtracts is decided by their marketplace status, not by whether they are still to ship, so a cancelled order on one marketplace goes on holding stock back. The arithmetic, marketplace by marketplace, is in E-commerce Core Concepts §3.

The e-invoice for a shopper with no tax number

A shopper on a marketplace rarely gives a tax identification number, so the invoice you raise from the order usually has no identified buyer. It is not stuck: unless the invoice is marked for individual submission, it is parked in the consolidated pool and submitted as part of one consolidated e-invoice after the month ends — the consolidated run picks up only documents dated before the 1st of the current month, Malaysia time. The deadline for that submission is the 7th (E-invoice Use Cases).

Whose job, and how they know. The online operations lead reads the day’s marketplace orders on the marketplace branch each morning: any order not FINAL, or with no running number, is chased that day. The fulfilment team ships, and the billing clerk invoices what shipped. They know a day went right when the number of orders the seller centre shows for yesterday equals the number of FINAL sales orders on that branch dated yesterday. Setting up the marketplace links and the storefront is the E-commerce module’s story; this module only ever sees a sales order.

4. The invoice with no order in front of it

The shape. A small business buys five power banks over the counter at GS-KV-03 on account. Nobody quotes and nobody orders: the branch keys a sales invoice and presses FINAL. Many companies that invoice in BigLedger finalise no sales order at all, and quotations are rarer still, so this is an ordinary shape, not a shortcut. Far more companies raise credit notes than sales returns — so when goods did come back, check that a return or a refund note went with the credit note, or the shelf and the ledger will disagree. The invoice’s own partner is the Receipt Voucher that knocks it off; until one does, the invoice is what the ageing shows as open.

What you give up. Between the promise and the invoice, nothing holds the stock: Available does not fall until the invoice moves the stock itself. There is no open quantity to track a part delivery against, and SO Consolidation has nothing to gather. What stays is the check at FINAL — by default the invoice is refused when the location cannot cover the quantity.

Whose job, and how they know. The finance manager decides, once, which customers are worth an order in front of the invoice: anyone who takes delivery in lots, anyone you quote, anyone whose stock you promise days ahead. The branch supervisor checks the day’s invoices name the right customer and location. They know the choice is right when no corporate customer has disputed a quantity that an order would have tracked.

5. Selling to another company in the group

The shape. GSD supplies the retail company GS with accessories at a transfer price. It is a real sale in GSD and a real purchase in GS.

What BigLedger does. With an intercompany rule set up for the pair, GSD’s sales invoice creates the matching purchase invoice — or a GRN, when GS receives before it is billed — in GS, either at once or into a queue somebody in GS confirms. Either way the mirror arrives as a draft unless the rule finalises it too. The buying side of the same story is Purchasing use case 9.

Whose job, and how they know. The group accountant keeps the intercompany rules in step with how the companies actually trade, and a clerk in GS finalises or confirms what arrives. At month end what GS owes GSD equals what GSD says GS owes it; a gap is a mirror nobody finalised, or a sale that went out without one.

A note on goods-issue documents

“Which document actually takes stock out?” In every shape above, the sales invoice. A document from the registered Sales GIN applet, and an outbound delivery order, record that goods went and move nothing, so a warehouse process built around either will find the shelf never empties. Core concepts §2 has the table of what each document moves, and why.

What every one of these shapes has in common

• What must exist first. A Knock Off Configuration row for Sales Order → Sales Invoice in the company — without it the order finalises cleanly, Available ignores it and the invoice’s KO For tab cannot find it. The company’s default GL codes, and an AR/AP type on every customer, are read by the posting job after FINAL, not at FINAL (Configuration).
• What becomes possible. A FINAL invoice is what a receipt voucher knocks off, what the debtor ageing shows as open, what joins the e-invoice queue, and what a commission cycle pays on.
• The sibling to choose between. An invoice per delivery, or SO Consolidation for many; a sales return when goods come back, a credit note when only money does (Core Concepts §5).
• What breaks elsewhere when one is wrong. A missing trade-debtors default GL code, or a customer with no AR/AP type, leaves a FINAL invoice with no journal (The invoice is FINAL but it is not in the ledger); a missing sales or tax mapping leaves that line out and the receivable absorbs it. Either way the debtor ageing and the ledger disagree. An invoice keyed at the wrong location moves the wrong shelf. An invoice raised fresh instead of from the order leaves the order holding stock back from every other sale (The order still shows a quantity outstanding).
• What it pairs with. Stock Availability for what you can promise, the receipt voucher for what was paid, and the debtor reports for what is still owed.

Where the numbers in these shapes come from

The figures every shape shares — the invoice’s journal, the cost and margin on a line, and the credit check — are set out once on Core concepts, and available stock, with its full formula, in Core concepts §3. These are the ones a particular shape adds, or reads differently.

When one of these shapes goes wrong

What none of these shapes will do for you

Each limit below holds in every shape on this page. After each one, the person who does the job instead.

• Nothing compares the customer’s purchase order with yours. The sales administrator does it, before FINAL on the order.
• Nothing approves a sale. A permission releases a discount on one line. The finance manager decides who holds that permission and who may finalise an invoice, and reads the week’s large orders after the fact.
• The credit check, where you switch it on, counts one company and two screens. The credit controller decides group-wide exposure before an order is keyed, and blacklists a customer when the answer is “no” on every route.
• Customer Consignment does not reconcile what the customer sold against what you sent. The stock controller does, monthly, against the customer’s own count.
• A goods-issue note and a delivery order move no stock. The warehouse lead checks that every despatch ends in an invoice within the week; until it does, the shelf and the ledger disagree.

How you know a month of selling went right

About twenty minutes on the last working day, per company.

1. No order is holding stock back for nothing (shapes 1, 3). In SO Line with SI KO, every line older than your normal delivery time has a reason. You are done when the sales administrator can give one for each, or has closed it.
2. Every FINAL invoice has its journal (all shapes). Trace Document lists no sales invoice without one. You are done when the list is empty.
3. The customer’s site agrees (shape 2). The stock balance at each consignment location equals the customer’s count. You are done when every difference is billed or explained.
4. The channels agree (shape 3). Last month’s orders in each seller centre equal the FINAL sales orders on its marketplace branch. You are done when the counts match.
5. The group nets (shape 5). What each company says the other owes agrees. You are done when the difference is zero.

The ledger side of the same close — what reaches the ledger and how you know it did — is on the Core concepts page.

Where to go next