Purchasing Guides

Five guides, one running example. Each one takes a purchase from “we need this” to “the supplier is paid and the ledger agrees”, using GadgetSphere Sdn Bhd — a Malaysian consumer-electronics retailer with 22 branches — as the business in every example. Start with the standard workflow; the other four are the shapes that depart from it for a reason.

Start here

Standard Procurement Workflow

Order → receive → invoice → pay. The full chain, and the one fact about stock that everybody gets wrong

Before your first purchase, the Purchasing module configuration page lists what must exist — the supplier and its AR/AP type, items linked to inventory items, the company’s default GL codes, the knock-off rows, and the receiving-pair decision. The short version:

The supplier exists in Supplier, with the right AR/AP type.
The items exist in Doc Item Maintenance and are linked to inventory items if they are stock.
The company’s default GL codes are mapped — at minimum the creditor code, PURCHASE and INPUT_TAX.
(Optional) approvals on purchase orders or requisitions, if you want them — see Document Approvals. They are off until you build them.

The other four shapes

Direct GRN Workflow

Goods arrived with no purchase order — receive them, bill them, keep the audit trail

Direct Invoice Workflow

Rent, utilities, subscriptions, fees — a supplier bill with nothing to receive

Invoice-First Workflow

The invoice or a deposit demand arrives before the goods — pay without booking stock you do not have

Consignment Purchasing

Stock a supplier still owns: receive it, sell it, pay for what sold, send the rest back

Which document does what

BigLedger gives every document type a quantity signum and an amount signum, fixed in the backend, that decide whether finalising it moves stock and whether it posts. These are the ones the guides use:

Document	Moves stock?	Posts to the ledger?
Purchase Requisition, Purchase Quotation, Blanket Purchase Order, Purchase Order	No	No
Purchase GRN	No	No
Purchase GRN Stock In (alternative receiving pair)	Yes, in	Yes — the goods-received-not-invoiced accrual
Purchase Invoice	Yes, in	Yes
Purchase Invoice No Stock In (pairs with GRN Stock In)	No	Yes
Purchase Return	Yes, out	Yes
Purchase Debit Note, Purchase Credit Note	No	Yes
Payment Voucher	No	Yes

Your company uses either Purchase GRN → Purchase Invoice or Purchase GRN Stock In → Purchase Invoice No Stock In. A document from each pair for the same goods either counts your stock twice or never counts it, with no warning. The guides follow the first pair.

Matching is a knock-off, not an engine

The controlled path uses three documents — the order (what you agreed), the GRN (what arrived and was counted) and the invoice (what the supplier is charging). They are tied together by knock-off: each document pulls the previous one’s open lines from the open queue, so the quantities on the bill are the quantities from the bay, set against the quantities you ordered.

There is no variance engine. BigLedger has no tolerance bands, no variance report and no automatic flag when a supplier bills a different quantity or price than you ordered. The knock-off brings the real numbers onto your screen; noticing that they differ from the supplier’s paper is a person’s job, and the moment to do it is before you click FINAL on the invoice.

Approvals

Purchase approvals are optional and off until you create an Approval Setting. They cover purchase requisitions, purchase orders and stock requisitions only — nothing else in the chain.

Each level names an approver designation, a quorum and a Min Approval Amount. The amount does not choose a different approver; it decides how many levels the document must clear:

Level	Approver designation	Min Approval Amount	Quorum
1	Department manager	RM 0	1
2	Finance director	RM 25,000	1

A RM 3,000 requisition needs level 1 only; a RM 60,000 requisition needs both. Full setup in Document Approvals.

BigLedger will not enforce your spending policy for you. Even with approvals configured, a purchase order can still be finalised by hand while an approval is pending — and the first approval sets the document to FINAL, not the last, so a second level is a recorded opinion rather than a gate. Approval causes FINAL; it never blocks it. If a threshold matters, control who holds the finalise permission.

Common scenarios

Scenario	What happens	How to handle it
Partial delivery	180 of 200 arrive	GRN for 180; the 20 stay in the order’s open queue for the next delivery
Price changed since the order	The knocked-off invoice shows the ordered price; the supplier’s paper shows theirs	Settle it before FINAL — a draft is discarded in seconds, a finalised invoice is a void or a debit note
Goods damaged in transit	Ten units unusable	Receive the good ones only; leave the rest in the queue and ask for a replacement or a credit
Supplier will never send the balance	20 units open forever	CLOSE the order — it zeroes the open quantities and clears the queue. Not VOID
Invoice lost or delayed	Goods on the floor, no bill	Stock Availability shows them as GRN quantity; chase the supplier; the stock is not in the ledger until the invoice posts
Urgent after-hours purchase	No time for an order	Direct GRN, and write who agreed it in the remarks — that sentence is the audit trail
Supplier overcharged	Invoice already FINAL	A Purchase Debit Note lowers what you owe. A Purchase Credit Note raises it — read the direction

Where the numbers are

Purchase Report — what was bought, by document and by item, from finalised invoices and returns.
Purchase Order Queue, PO Line with GRN KO, PO Line with PI KO — inside the Purchase Order applet: what is outstanding, and ordered against received and invoiced.
Creditor Report — what you owe, by supplier and by age, and which payment settled which invoice.
Stock Availability — the GRN quantity column: received and not yet invoiced.

The full list, and the reports people ask for that do not exist, is on the module’s Reports page.

Who does what

Three people, three permissions, and the chain records who did each step without stopping one person doing all three:

The buyer raises and finalises orders, and CLOSEs the ones a supplier will not complete.
The receiver counts and finalises GRNs — only the quantity the business is willing to pay for.
Accounts payable knocks receipts off into invoices, compares them with the supplier’s paper, finalises, and pays.

Separate the three where you can. The finalise permission on the invoice is the control that “three-way matching” would otherwise have been.