Sales Workflow Guides

Whatever your business sells and however the customer pays, one thing decides how BigLedger records it: which document you finalise. Everything else — quotations, orders, delivery notes, picking lists — is planning and paperwork. This section walks you through the six sales paths a Malaysian retail or distribution business actually runs, and each guide is written so you can follow it with the screen open.

Read this before you read anything else

On the sales side of BigLedger, exactly two documents move stock and post money:

a Sales Invoice (Internal), and
a cash bill raised at the counter in POS General.

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 warehouse’s Pick Pack Queue 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.

This is the single most common misunderstanding about BigLedger sales. If you are waiting for the delivery document to reduce your stock, it never will. Stock leaves when the invoice or the cash bill is finalised. Plan your day around that and everything downstream — stock counts, gross margin, SST — comes out right.

Which guide do you need?

Cash Sales at the Counter

A customer pays now and walks out with the goods. One cash bill, one screen, sixty seconds.

Standard Sales Workflow

Quote, order, deposit, pick, invoice, collect — the full order-to-cash path for a scheduled sale.

Credit Sales Workflow

Selling on terms to a business customer, and what BigLedger does and does not do about credit limits.

Partial Delivery Workflow

One order, several shipments. Invoicing part of an order and keeping the balance open.

Returns and Exchanges

Three different documents for three different situations — pick the wrong one and your stock drifts.

Delivery and Installation Scheduling

Turning finalised orders into delivery jobs, grouping them onto a trip, and tracking them to the door.

Selling on Instalments

The two ways to record a sale the customer pays for over time — and the workflow BigLedger does not have.

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 and the posting job behind it fails, leaving no journal
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

Map the GL codes before your first sale, not after. A missing code never stops FINAL: BigLedger accepts the document and the posting job then fails — MISSING_DEFAULT_GL_CODE: DEBTOR when the receivable account is unmapped, TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES when a sales or tax line is dropped for having no GL code. The invoice looks fine on the listing and no journal exists behind it; the Posting tab and Financial Report > Error Checking > Trace Document are where you find it, 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 credit-limit block at the moment of sale. A credit limit on a customer record does not stop an order that exceeds it. 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.