Sales Workflow Guides
“Which document actually takes stock out?” On the sales side it is the one you finalise, and the first section below names it. Quotations, orders, delivery notes and picking lists are planning and paperwork. The guides in this section each cover one sales job a Malaysian retail or distribution business does, from the counter to the corporate invoice and on to collecting what is owed, and each is written so you can follow it with the screen open. If you arrived with a problem, start at When a sale goes wrong. If you have just recorded your first sale, What success looks like checks it in three places.
Read this before you read anything else
On the sales side of BigLedger, stock leaves and money posts when you finalise one of these:
- a Sales Invoice (Internal),
- a cash bill raised at the counter in POS General, or
- a Sales GIN Stock Out — a goods issue that takes stock out and posts by itself. No installed applet offers it — the applet bundle exists, but there is no applet registry row — so it is created only through the API, and you meet it only if an integration raises it.
Everything upstream of them is a promise. A sales quotation posts nothing. A sales order posts nothing — it reduces the available figure and it plans, but no stock leaves and no journal is written (and it reaches the Pick Pack Queue — the list that dispatch and the warehouse each take work from — only when somebody clicks Send To Queue on the finalised order, not on FINAL). Delivery notes and delivery orders post nothing either: they record that goods were handed over, and the stock balance does not move when you finalise one.
Which guide do you need?
Meet GadgetSphere
Every guide in this section uses the same business, so the numbers and the branch codes carry across. GadgetSphere Sdn Bhd is a Malaysian consumer-electronics retail group: 22 branches across Klang Valley, Penang, Johor Bahru, Kota Kinabalu and Kuching, about 5,200 active SKUs, three companies in the group (retail GS, online GSO, distribution GSD), SST-registered at 6%, and roughly 85,000 customer records — mostly walk-in, some corporate.
When a guide says branch GS-KV-01, that is a Klang Valley store. GS-PEN-01 is in Penang. The prices are retail prices you would recognise: a flagship smartphone at RM 3,800, an ultraportable laptop at RM 4,200, a pair of wireless earbuds at RM 249.
Before you start any of these guides
These five things must be in place before a single sale can be recorded. If one is missing you will find out at the worst possible moment — when someone clicks FINAL and the posting fails.
| What | Where you set it | What breaks without it |
|---|---|---|
| Company, branch and location | Organisation | Nothing can be created; the header requires all three |
| The customer | Customer Maintenance | No sale can be raised. A walk-in default customer is enough for the counter |
| Items and their prices | Doc Item Maintenance, Pricebook | No lines to sell |
Default GL codes for SALES, DEBTOR and OUTPUT_TAX (plus COGS and STOCK_BALANCE for the month-end cost-of-sales journal) | Chart of Account | The invoice finalises either way. A missing DEBTOR fails the posting job, leaving no journal; a missing SALES or OUTPUT_TAX posts a journal without that line, with trade debtors absorbing it |
| A settlement method per tender, each linked to a cashbook | Cashbook | No payment buttons at the counter; the posting job fails with MISSING_CASHBOOK: STL_MTHD [code] after FINAL |
MISSING_DEFAULT_GL_CODE: DEBTOR; the document looks fine on the listing and no journal exists behind it. A sales or tax line with no GL code fails nothing: the line is left out, the customer’s line takes up the amount, and the journal posts — a RM 106 bill with no SALES code credits trade debtors RM 100 instead of sales. You notice it only in the receivable GL account, which stops agreeing with the debtor ageing (the statement and ageing are built from documents and look right); only a customer with no AR/AP type turns it into TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES. So before go-live, check every sales, return and tax code has a company default. Where you find it depends on which document it is. A sales invoice has a Posting tab that shows Journal blank while Inventory reads POSTED; a cash bill does not — the POS applet has no such tab and its listing has no posting-status column, so a failed cash bill is indistinguishable from a good one on every screen at the counter. For a failed posting, Financial Report › Error Checking › Trace Document answers for either, one document at a time, and Resolve re-runs the posting once the code is mapped. GadgetSphere would use SALES-SMARTPHONE, LIAB-SST-OUTPUT, COST-SMARTPHONE and DEBTOR-TRADE-RETAIL.Two things people expect that are not there
There is no document approval step on a sales document. Not on quotations, not on orders, not on invoices. BigLedger’s approval engine exists, but only Purchase Order, Purchase Requisition and Stock Requisition can be configured to use it (the sales order applet’s Approval menu is for sell-below-minimum-price line approvals and does not gate FINAL). If your business needs a sales order signed off before it ships, that control has to live in who you give the FINAL permission to — not in a routing rule.
There is no server-side credit-limit block at the moment of sale. A credit limit on a customer record stops nothing by itself. The one exception is an optional check on the Sales Order and Sales Invoice screens, off unless somebody turned it on, which refuses FINAL when the customer has no credit left in that company (Deciding on Credit explains what it counts and misses). What BigLedger has instead is a blacklist flag set by a job — one an administrator runs on demand or puts on the tenant’s job schedule; nothing in the product schedules it — and once it is set the customer is blocked from everything. The Credit Sales Workflow guide explains how to work with that rather than against it.
When a sale goes wrong
These are the sales problems people raise most often, in their own words where the words are quoted, with the guide that answers each. Most of them show no error message. The screen reports success at FINAL, and the stock, the journal and the customer’s balance are written after it, by separate jobs and from separate records.
| What you see | Read | Why it happens |
|---|---|---|
| The goods went out on a delivery order, and the stock balance has not moved | Standard Sales Workflow, Step 5 | Delivery documents record a hand-over and move no stock. The stock leaves when the invoice or the cash bill is finalised, so invoice when the goods leave |
| “Do I have to raise a sales order before I can invoice?” | Standard Sales Workflow | No. An order posts nothing. It holds the quantity out of available stock and lets the invoice copy its lines. Raise one when there is a promise worth tracking |
| “Stock Availability shows 50 physical but 0 available.” | Standard Sales Workflow, Common mistakes | An open order line’s uninvoiced balance is taken off Available until it is invoiced or closed. An order that will never ship goes on holding stock back |
| “The order still shows a quantity outstanding after I invoiced it all.” | Partial Delivery Workflow, then the troubleshooting page | The balance is a stored row, not a live subtraction of the invoices, so it can drift from them. The troubleshooting page works through the three ordinary reasons |
| “Cash bills are missing from my Z report.” | Balancing the Drawer | A report run for one device leaves out bills rung on any other terminal. Run it again with Device set to All |
| A laptop is back on the shelf, and BigLedger still says it was sold | Returns and Exchanges | It went back on a credit note, which moves money and leaves stock alone. Goods that come back belong on a sales return or a refund note |
| “Can I set a credit limit that actually stops an order?” | Can This Customer Take More Goods?, then Credit Sales Workflow | Only through the optional check on the order and invoice screens, and that check counts one company. At FINAL the server refuses a blacklisted customer and nothing else on credit grounds |
| “I knocked off the payment and the outstanding balance hasn’t changed.” Or a customer who has paid is still being chased | Standard Sales Workflow, Step 6, then the troubleshooting page | A receipt finalised without a contra puts the money in the bank and leaves the invoice open. If you did contra it, read Outstanding rather than Doc Open Amount, which keeps the invoice’s own total |
| “Every sales invoice finalises, but none of them post, and the trace names a missing default GL code.” | The callout under Before you start any of these guides, and Standard Sales Workflow, Step 5 | FINAL succeeds first and the posting runs after it. The company has no default for the customer’s receivable account, which in a group is usually the second or third company |
| Trade debtors in the ledger has stopped agreeing with the debtor ageing, and nothing failed | The same callout | A sales or tax line with no GL code was left out of the journal, and the customer’s line absorbed it. The ageing is built from the documents, so it still looks right |
What success looks like
Run this once, on the first real sale you record after following the guide that fits you. One sale is enough, because every later sale at that company posts the same way. At GadgetSphere it is one ultraportable laptop, sold on credit from GS-KV-01: RM 4,200 plus RM 252 SST at 6%, RM 4,452 in all. Open the invoice and look in three places:
| Place | Where you look | What it should read |
|---|---|---|
| The document | The invoice’s Posting tab, and Stock Balance for the laptop at GS-KV-01 | Journal and Inventory both posted, and one fewer laptop on the shelf |
| The customer’s balance | The invoice’s ARAP tab, then the customer’s Statement of Account | Doc Open Amount RM 4,452.00 and Outstanding RM 4,452.00, with the invoice on the statement. Once the receipt is contra’d, Outstanding reads 0.00 and Doc Open Amount still reads 4,452.00 |
| The journal | The invoice’s TraceDocument tab, Journal Txn | Three lines: debit trade debtors (DEBTOR-TRADE-RETAIL) 4,452.00, credit sales (SALES-LAPTOP) 4,200.00, credit output tax (LIAB-SST-OUTPUT) 252.00. There is no cost-of-sales line, because that is written by month-end processing |
The three are separate records, which is why one check is not enough. FINAL sets the document’s status. The customer’s balance is recalculated each time you run the statement, from the open amount stored on the invoice when it was saved and the contras against it. The journal is written by a background job after FINAL. So the statement can read RM 4,452 while the journal is wrong:
- Journal Txn is empty while Inventory reads posted. The posting failed after FINAL. Map the missing code, then use Resolve in Trace Document, as the callout under Before you start any of these guides describes.
- Trade debtors is debited less than 4,452.00, or a credit line is missing. A sales or tax code is unmapped. Map it, then press Repost beside Posting Journal in Trace Document.
If your first sale was a cash bill at the counter, the till has no Posting tab, and a bill paid in full leaves nothing on the customer’s balance. The journal check is finance’s job, and it takes them under a minute: Cash Sales at the Counter, check 3 of What success looks like. The guides’ own checks then go further for their path, such as the stock at each van in Partial Delivery or the stock back at the right location in Returns and Exchanges.
Related documentation
- Sales Workflow applets — the reference pages for every document named here
- Sales module
- Financial Accounting module and the accounting guides
- E-Invoice guides — what happens to a finalised invoice on its way to LHDN
- Purchasing guides — the mirror image of this section