Core Concepts

Which document actually takes stock out? The document is Final but it is not in the general ledger. How do I take goods back — refund, credit note or exchange? Those three questions, and the one about stock that shows on the shelf and not as available, all have the same answer underneath: five ideas about how a sales document works behind the screen. This page is for whoever raises, corrects or checks sales documents in a group like yours. Learn the ideas once, with one order followed from quotation to credit note, and the applet pages stop being a list of screens.

One order, followed through

GadgetSphere Distribution (GSD) holds 60 ultraportable laptops at its warehouse. A corporate client asks for 20 at RM 3,800 each, takes 12 this month, sends two back damaged, and is given RM 500 off for the late delivery. Here is what each document did, and when.

Four things in that table surprise people, and each is one of the ideas below. The delivery order moved nothing (§2). Available stock fell at the order and did not move at the invoice (§3). The return and the credit note landed on different accounts (§2, §5). And COST-LAPTOP waited for the month-end. The figures are illustrative; the arithmetic is the product’s.

1. FINAL is the only moment that matters

Every sales document has a posting status. DRAFT means nothing has happened: the document is editable, the ledger has not heard of it, and no stock has moved. FINAL is the event. VOID reverses whatever FINAL did and records a reason. Do not confuse posting status with the record’s own status (active, inactive, deleted): they are two separate fields, and only the posting status decides whether anything posts.

Pressing FINAL is its own call, not a save. It checks the document, commits the new posting status, and then queues one job. That job starts the others: the journal, the stock movement, the cost written back onto the lines, the order’s open quantity, the e-invoice queue entry, member points. Each runs afterwards in its own transaction. Which of them run for your tenant is a subscription, the same one the Point of Sale module explains for the till.

Two consequences people meet the hard way:

• Nothing stands between a person and FINAL except having the applet installed. There is no sign-off step (see §4).
• “It did not post” usually means “it has not finished yet”, or “a job behind it failed”. The document reads FINAL the moment the call returns. On a busy day a stock line or a journal can appear a moment later; if a job fails, the document stays FINAL and nothing on the listing says so. §7 is the check that tells the two apart.

What FINAL refuses, and what it leaves to the jobs

FINAL is refused, and nothing at all is written, when the transaction date falls in a locked fiscal period (a date that falls in no fiscal period at all is not refused), the customer is blacklisted (on an invoice, order or outbound delivery order), a foreign-currency document has no exchange rate, or the serial, batch or bin counts on a line do not match its quantity. Three more — enough stock on the lines going out, selling below cost, and enough member points for a redemption — depend on what the screen you finalised from asks the server to check.

Everything else is found later, by a job. A missing default GL code, a customer with no AR/AP type, a receivable account that is wrong: none of them stops FINAL. They show up as a FINAL invoice with no journal behind it, or a journal that is quietly short. That is deliberate — the person at the desk finalises the sale, and the person who owns the chart of accounts repairs the mapping — but it means somebody has to look (§7).

2. Most sales documents post nothing

Two numbers on each document type decide its effect: the amount signum (does money move, and in which direction) and the quantity signum (does stock move, and in which direction). They are carried on every line the document writes. A zero means nothing happens: the journal job builds a line only for a document line whose amount signum is not zero, and the stock job only for a goods line whose quantity signum is not zero.

A deposit keyed on a sales order’s Settlement tab posts at the order for some payment methods and not for the others. For those its line takes the order’s zero like the rest, so nothing at all posts and even the cashbook line is RM 0.00. This is a known defect BigLedger is tracking.

The till’s own sale document, in the Point of Sale module, is +1 / −1 like the invoice, and the reports and commission runs in this module count it alongside invoices.

The general ledger is reached through exactly seven journal handlers in the whole product, and the one this module uses is SALES — the same handler the till’s cash bill uses. At FINAL an invoice posts Dr Debtor / Cr Sales, Output Tax and a debit note the same; a return posts Dr Sales Return, Output Tax / Cr Debtor; a credit note Dr Sales, Output Tax / Cr Debtor; a refund note reverses the invoice entries, and its stock returns to the line’s location.

    flowchart LR
  INQ["Sales Inquiry"] --> QUO["Sales Quotation<br/>signum 0/0"]
  QUO --> SO["Sales Order<br/>signum 0/0"]
  SO --> INV["Sales Invoice<br/>amount +1, qty −1"]
  SO --> DO["Delivery Order"]
  DO --> INV
  INV --> LEDGER[["General ledger<br/>+ stock ledger"]]
  INV --> RET["Sales Return<br/>amount −1, qty +1"] --> LEDGER
  INV --> CN["Sales Credit Note<br/>amount −1, qty 0"] --> LEDGER
  INV --> DN["Sales Debit Note<br/>amount +1, qty 0"] --> LEDGER
  INV --> RN["Sales Refund Note<br/>amount −1, qty +1"] --> LEDGER
  GIN["Sales GIN<br/>signum 0/0 — inert"] -.-> NOTHING(["no ledger effect"])
  QUO -.-> NOTHING
  SO -.-> NOTHING
  

Which receivable account the +1 lands on is decided by the customer’s AR/AP type, not by the document: sell to an entity typed AP_TRADE — a supplier you also sell to — and the invoice debits the creditor account, netting against what you owe them (see Who you trade with).

Where the figures on a posted document come from

The figures on a posted document — which account each line lands on, the cost on each line, cost of sales, the effect of a line discount — and where each one comes from are set out after the ideas, in Where the numbers on these screens come from.

3. Stock balance and stock availability are different numbers

Balance is what the stock ledger says you physically hold, at a company and a location. It is a stored figure, changed by the stock job only when a document with a non-zero quantity signum reaches FINAL — the invoice, the return, the refund note. The delivery order is not one of them.

Availability is what you can still promise, and it is never stored. Stock Availability works it out each time you open it: the stored balance, less the quantity on finalised sales orders not yet invoiced, plus goods received on a purchase GRN not yet invoiced, less anything reserved at that location. Quotations are not in the calculation at all. The full formula, and the Details screen that adds up differently, are on Stock Availability.

So “available is lower than balance” is normal and usually means open sales orders. In the table at the top, the order took 20 out of availability the moment it was finalised; the invoice for 12 then took 12 out of the balance and 12 off the order’s open quantity, so availability did not move again.

The order counts only where the company links it to the invoice

The “not yet invoiced” quantity is not a sum over orders. It is the order’s open quantity toward the sales invoice, which a job writes when the order is finalised — and only for the pairs your company has switched on under Organisation → Company → Knock Off Configuration. With no Sales Order → Sales Invoice row, the order finalises cleanly, availability ignores it, and the invoice’s KO For tab cannot find it. A company that delivers against orders and invoices from the delivery order, with only Sales Order → Delivery Order switched on, gets the same blind spot in availability. Both are on Sales Order, with the repair for orders finalised before the row existed.

Who checks this, and when: whoever sets up a company, before its first order, and again whenever a salesperson reports promising stock that turned out to be gone. How they know it holds: finalise a test order and watch Available fall by its quantity on Stock Availability, at the order’s location.

Reservation is opt-in, and it is a separate applet

There is no hard and soft allocation. A sales order line may hold a reservation over specific quantities, serials or bins; you see it on the Reserved Stock tab, and it shows who reserved it. Voiding the order does not release it — none of the jobs a void starts touches a reservation — so whoever voids the order releases its reservations in the Stock Reservation applet as well, or the stock stays held. Holding stock is an action somebody takes, not a state a FINAL order enters.

The reservation record has its own statuses — TMP, DRAFT, RESERVED, RELEASED — documented on the Stock Reservation applet page, along with a known defect in the bin-pinned path. Treat a reservation as a note to your colleagues, not as a lock the system enforces.

4. Nothing here is approved, and the credit limit does not stop anyone

BigLedger’s document-approval engine exists, but only the Purchase Order and Purchase Requisition screens can submit a document for approval (Stock Requisition has approval settings but no submit step, a known gap); the engine is off until a tenant configures it, and even when configured it causes FINAL rather than gating it. No sales document consults it, so no sales document waits in anyone’s approval inbox. A discount on a line is released by a permission, not by a routed request.

What a sales desk has instead is a hold on the FINAL button, on the screens. The applet setting that hides FINAL, paired with the permission that shows it again to named people, lets clerks save drafts that only a supervisor can finalise — on the Sales Order and Sales Invoice, on the open document and in the listing’s bulk FINAL alike. On the Sales Quotation the permission works in the listing only; the open quotation hides FINAL from everybody once the setting is on.

The Final Status setting of Workflow Design also hides FINAL on an open Sales Order until it is saved at a chosen status, but the listing’s bulk FINAL does not check it, so the permission is the hold that counts. Neither is checked by the server, so a document an integration finalises through the API is not held. (The Sales Order’s Approval menu is a release for selling below price, not a sign-off.) The test: signed in as a clerk, open a draft order and its listing — neither shows FINAL.

Credit limit is close to the same. Switching on the credit-limit filter makes the Sales Order and Sales Invoice screens work out the customer’s available credit (limit, less what they owe this company, less open delivery-queue amounts) and refuse FINAL when it is used up. It is a check in the screen, not on the server: a document that arrives any other way, a cash bill and a delivery order are never measured, and no figure adds up what the customer owes the whole group.

The only hard stop on the server is the blacklist, which rejects a sales invoice, sales order, cash bill or outbound delivery order with ENTITY_BLACKLISTED. It is not checked on quotations, returns, credit notes or debit notes, and a document an integration creates already FINAL skips it (Stopping Supply to a Customer lists the routes it does not cover). Exposure across the group is the credit controller’s to read, company by company.

So the approval a sales document does not have is a person’s job, done at a moment you choose: a manager who reads the day’s FINAL orders over a set value, or a credit controller who decides before the order is keyed. The person who decides credit has three guides of their own: Deciding on Credit, Stopping Supply to a Customer and Chasing Overdue Accounts.

5. How a sale is reversed — pick the right document

    flowchart TD
  Q{"What went wrong?"}
  Q -->|"The whole invoice was a mistake<br/>and nothing has moved yet"| V["VOID the invoice<br/>(reverses everything)"]
  Q -->|"Goods are coming back"| R["Sales Return<br/>stock in, sale reversed"]
  Q -->|"Price or charge was wrong,<br/>no goods move"| CN["Sales Credit Note<br/>no stock effect"]
  Q -->|"We undercharged"| DN["Sales Debit Note"]
  Q -->|"Money back and goods back"| RN["Sales Refund Note<br/>or a Sales Return<br/>with the refund on it"]
  

Two traps worth knowing before you need them:

• A credit note does not put stock back. Its quantity signum is 0. If the goods returned, you need a Sales Return or a Refund Note as well, or your shelf and your ledger will disagree.
• When e-Invoice is switched on, the VOID button disappears from a Sales Refund Note’s edit screen and the Cancellation tab replaces it. The refusal goes further than the button: while e-Invoice is enabled for the company, a sales return, refund note, invoice, credit note or debit note cannot be voided from any Void button or through the void API, whether or not it has been submitted to LHDN (What a void undoes → when BigLedger refuses). The one route to a void is the e-invoice cancellation’s Void original document, which voids the document once LHDN accepts the cancellation; after the 72-hour window the correction is a credit note (Cancelling and correcting a validated e-invoice).

Two documents bring goods and money back, and they post differently

A sales return can carry its own refund: record the money going back on its Payment tab and the return opens at zero, with nothing left owing (the refund paid on the return itself). A refund note does the same job as a separate document. The stock comes back either way. What differs is where the reversal lands, and what LHDN receives:

Neither is wrong. Which one your group uses is a decision about reporting — whether the sales-return account should hold every ringgit refunded on returned goods — and it is worth making once, for every branch, rather than leaving it to whoever is at the desk. If you report returns from the sales-return account, refund notes are not in it.

Who decides, and when: the person who accepts goods back decides return or credit note at the counter or the desk; finance decides, once, which of the two refund documents the group uses. How they know it was right: the stock balance for the item came back by the returned quantity, and the reversal sits on the account your returns report reads.

Where the numbers on these screens come from

Raising an invoice is the easy part; working out where a number came from is the hard one. Each figure below was either written at one moment and kept, or is worked out again every time you look — and knowing which tells you where to look when it seems wrong.

One invoice, followed through

Take, for example, a corporate customer that GadgetSphere Distribution (GSD) invoices on 28 March for ten ultraportable laptops: RM 38,000 of goods and RM 2,280 SST, RM 40,280 in all. You press FINAL and the invoice is numbered at once; a moment later the posting job writes the journal — debit trade debtors RM 40,280, credit SALES-LAPTOP RM 38,000 and LIAB-SST-OUTPUT RM 2,280 — and the Posting tab reads POSTED. The ten units leave the stock ledger and, where e-invoicing is on for the company, the invoice joins the e-invoice queue.

When the costing job has run, each invoice line carries its moving-average cost, and the Sales Report’s margin column reads it from there; COST-LAPTOP in the ledger hears nothing about the sale until March’s month-end processing runs. Key in April a purchase that brought laptops into stock on 20 March, and the costing job replays the chain and rewrites the cost on this invoice’s lines — so the margin you reported for March moves, while the March journals stay as they were.

If the customer moves office in April, the March invoice still carries the old address — that is the copy doing its job, because a reprint has to match the one the customer holds.

6. When it goes wrong — what you see, why, what to do

7. How you know a sale finished

FINAL tells you the call succeeded, not that the jobs behind it did. The check below takes thirty seconds. Run it on the first order and invoice in any new company, and again whenever a number looks wrong.

Who runs this, and when: the sales administrator on the first documents of a new company or a new document flow; finance whenever the ledger and a sales report disagree. How they know they got it right: every step that applies holds for the same document.

How you know it worked

Thirty seconds, one test invoice, in GSD. Raise an invoice for one item to a customer on terms, finalise it, give the job a moment, then run steps 2 to 4. If the sale went through an order, start with step 1, on the order, before you invoice it.

1. The order, if there is one. After finalising it, open Stock Availability for the item at the order’s location. Available is lower by the ordered quantity. If it is not, read the third row of the table in §6.
2. The invoice’s Posting tab. Journal Posting Status reads POSTED. Empty means the posting job failed; Financial Report → Error Checking → Trace Document names the failed check for that invoice.
3. The invoice’s journal. One debit to trade debtors equal to the invoice total, with credits to sales and to SST payable. A debit equal to the tax alone means SALES is unmapped; a debit to creditors means the customer’s AR/AP type is wrong.
4. The stock. Stock Balance for the item at the invoice’s location is lower by the invoiced quantity. Where the invoice was knocked off an order, Available has not moved, because the invoice took the same quantity off the order.

If any of these is missing, the row in §6 with the same symptom names the page that fixes it.

Read next