Approvals elsewhere in BigLedger: claims, returns, budgets and Workflow Design

The approval mechanisms in BigLedger other than the purchasing approvals this guide sets up: what each one does, and what none of them will do. Read it when somebody asks for sign-off on a document the purchasing engine does not cover. It follows Steps 2 to 5, the last part of the setup.

Looking for approvals somewhere else?

Approvals get asked about across the whole product, so here is the complete picture in one place. Counting the purchasing engine this guide sets up, BigLedger has five approval mechanisms. The other four use the same word, and none of them will give you sign-off on a sales invoice, a payment or a journal.

Expense claims — a separate engine, and it is always on. The Claim applet has its own approval settings, and unlike purchasing it is not optional: a claim goes through it. It is also the only place in BigLedger with approver delegation — a delegation period screen that hands an approver’s requests to a stand-in while they are away. If you have seen delegation working and wondered why purchase orders do not have it, that is why. See the Claim Applet.

Returns (RMA) — approve or reject, and that is the whole thing. An RMA submission carries a single status that moves between Pending Approval, Approved and Rejected, and BigLedger sends the customer an e-mail when it lands on one of the last two. There are no levels, no quorum, no amount thresholds and no settings screen. It is a decision field, not an engine. The separate RMA Staff / HQ / Supplier family has a per-item head-office approval flag of the same kind — a field, a permission on the button, and nothing behind it.

Budgets — the engine exists in the backend, but there is no screen. BigLedger’s code carries a budget-register approval engine built to the same pattern as the purchasing one. The Budgetary applet ships no approval screen to drive it, so there is nothing to switch on today. Do not plan around it.

Workflow Design — labels, not approvals. Covered in the warning on the front page, and worth repeating because it is the single commonest misunderstanding: it puts a status on a document and controls who may change that status. It does not e-mail anyone, and its only hold on posting is the browser-side Final Status setting described there — which the purchase order never reads, and which the sales order, sales return, sales refund note and packing order listings’ own FINAL button skips even where the open document honours it. The status track is also enforced in the browser only, so an API client can set any status on any document. See the Workflow Design Applet.

And everything else has nothing. Sales orders, sales invoices, quotations, delivery orders, goods received notes, purchase invoices, payment vouchers, receipt vouchers, journals, stock adjustments and stock transfers have no approval mechanism of any kind. The control you have on those is who holds the permission to finalise them — set that up in the applet’s Settings → Permission screens instead.

Related documentation

• Purchase Order Applet — the field-level reference for Approval Settings, Approval Monitor, Approval Request and Approval History.
• Purchase Requisition Applet — the same approval loop on requisitions.
• Stock Requisition Applet — has the Approval Settings screen, but no way to submit against it yet.
• Workflow Design Applet — the other thing that looks like approvals, and what it actually does.
• Employee Applet — where approvers’ job titles and e-mail addresses live.