Growth and Scaling
Most of what changes as a business grows is not new software — it is turning on controls you did not need at five people and do need at fifty. This page is what those controls actually are in BigLedger, and which of them enforce anything.
More people
Q: How does access control work?
The chain is: permissions → permission sets → roles → teams → people. You do not grant a permission to a person; you build a role and put people in a team that holds it.
The part that matters as you grow is that each permission set is scoped to a target — a company, a branch or a location. A cashier at one branch scoped to that branch does not see other branches’ customers: out-of-scope records do not appear at all, with no error message.
A permission set with no target confers access to everything. That is fine for your administrator and almost never right for anybody else. It is also invisible until somebody exercises it, which is why you test a new role on one person before rolling it out.
Q: Can somebody view customers without being able to export them?
Yes, and this is the control most businesses are looking for. View and export are separate permissions, and the check is on the server — hiding the button is not what stops it. See teams and permissions.
Q: Should we share a login while we are small?
No. It removes the one thing an audit trail is for: knowing who did it. Every create, update and delete is recorded with the user’s identity, and a shared login makes all of that worthless.
More branches and more companies
Q: What do I have to do before opening a second branch?
Set it up in the Organisation applet, and then check the things that hang off the structure:
- Cashbook and settlement-method access for the new branch.
- Stock locations under it, so availability is meaningful per site.
- Permission targets for the people who work there.
- Where pricing differs by site, the branch pricing settings — POS in particular decides its pricing scheme by branch and by role.
Q: And a second company?
One extra thing, and it is the one people miss: company default GL codes are per company. Set them up for the new company before anybody raises a document in it, or the first invoice fails to post — typically three weeks later, in front of a customer. See chart of accounts setup.
More control over spending
Q: Can I make large purchases wait for approval?
Yes, with two important qualifications.
Approvals are optional — off until somebody configures them — and they cover three document types only: purchase requisitions, purchase orders and stock requisitions. Expense claims have their own separate engine. There is no approval workflow for sales orders, sales invoices, discounts, credit limits, journals or payments; for those, the control is who holds the permission.
The rule is a list of levels. Each level names an approver designation, a quorum and a Min Approval Amount — and the amount decides how many levels a document must clear, not who sees it. So thresholds of RM 500 / RM 2,000 / RM 10,000 become three levels with those Min Approval Amounts.
A document reaches FINAL when the first approver approves it, not the last. The approval record behaves correctly — a second level is still created, still e-mailed, and still has to act — but the purchase order has already moved and can be acted on.
If you are building a second level to stop something until a director sees it, it does not stop it. Use levels to record sign-off, and enforce genuine holds with permissions instead.
Setting it up, in four steps:
- Create the designations — Purchase Order applet → Settings → Branch → Designation. One for submitters, one per rank of approver.
- Assign the approvers — Designation Employee, each with an approval level. Two people at the same level with a quorum of 1 means either can clear it, which is the nearest thing to a backup. Every approver needs an e-mail address on their employee record.
- Create the Approval Setting — Settings → Approval Settings: the document type, the submitter designation, and the levels.
- Test it on a small purchase order: submit, confirm the e-mail arrives, approve from the link, and watch what happens to the document.
What is not there: no escalation when an approval goes stale, no reminder e-mails, no delegation or stand-in approver, and no approval app — approvers use the link in their e-mail, which opens in any phone browser. Full detail in document approvals.
Q: Can I stop a customer who owes too much from ordering?
Partly, and not in the way most people assume.
Nothing calculates a customer’s exposure while an order is being typed. A scheduled job totals outstanding documents against credit limits and overdue terms and flags the failures; a flagged customer is then refused on a cash bill, sales invoice, sales order or outbound delivery order.
So: the block is only as current as the last run of that job, it covers those four document types and nothing else, and the job clears every existing flag before it recalculates — meaning a flag you set by hand on a disputed account does not survive it. For a permanent stop, set the customer’s credit limit, which does survive.
Know when that job runs. If nobody can tell you, your credit control is not running.
More volume
Four things exist specifically for when the counts get large:
- SO Consolidation — one invoice per customer per period instead of one per order. For a business delivering daily to the same customers, this is the difference between a workable month end and an unworkable one.
- Stock Replenishment — generates purchase orders from stock levels rather than from memory.
- Blanket Purchase Orders — a long-term agreement with a supplier that buyers draw down, rather than renegotiating each order.
- Imports and exports — almost every master-data screen has a CSV import with a validation tab, and the export-edit-reimport pattern is the safe way to make a bulk change.
More channels
Selling online as well as in store does not mean a second system. Marketplace orders arrive as ordinary sales orders in the same tenant, against the same items and the same stock. See the E-commerce module for how each order arrives, and the Sales module use cases for what happens once it has.
What it does demand is one item master, maintained properly — a product missing its category misses the promotion in every channel at once.
What success looks like
Before you add the next branch, company or twenty people:
- Open one non-administrator role and look at its permission sets. Every one has a target. If any has none, that person has access to everything.
- Ask when the credit-blacklist job last ran — and get an answer.
- Check the new company’s default GL codes by finalising one test document of each type you use, in that company.
Common mistakes
| What goes wrong | The fix |
|---|---|
| Permission sets left unscoped | Scope every set to a company, branch or location |
| Sharing a login | The audit trail becomes worthless |
| Treating a second approval level as a hold | The document goes FINAL on the first approval |
| Expecting approvals on sales documents | The engine covers PO, PR and stock requisitions only |
| Relying on a credit limit to block at save | The block reads a flag set by a scheduled job |
| Setting a blacklist flag by hand as a permanent stop | The next run clears it — set the credit limit |
| New company without its own default GL codes | Its first document fails to post, weeks later |
| Growing transaction volume with per-order invoicing | Use SO Consolidation |