Use Cases

This page is for whoever keeps people administration running at a multi-branch group — usually someone in finance, sometimes in HR — and wants to know which shape their month should take before a number turns up wrong. BigLedger’s people side is used in four shapes. For each one: what happens behind the screen, whose job it is, and how they know it went right. After the four come the things they share: where their numbers come from, what goes wrong, what none of them will do for you, and a month-end check. Allow about fifteen minutes.

The examples use GadgetSphere Sdn Bhd, the wiki’s running example — a Malaysian consumer-electronics retailer with three companies (GS, GSO and GSD) and 22 branches from Klang Valley to Kuching.

Across the companies on BigLedger, employee records are common, many companies name a salesperson on their sales documents, and expense claims are run by very few. So shapes 1, 3 and 4 are the ones most readers are in; shape 2 is for the companies that pay small claims with salary.

1. The multi-branch employee master

The shape. Every branch supervisor, cashier and back-office clerk exists in BigLedger before they can be a salesperson on a document, an account manager for a business customer, or a claimant. GadgetSphere keeps one employee master for all three companies: one tenant, one record per person, not one per company.

What to know, because the screen does not say it:

• One record serves all three companies. The branch you give a person sets their default company. A clerk at GS-KV-04 who also packs orders at the online arm’s fulfilment centre stays one record, with GSO added on Company Linking. When she claims a cost charged to the fulfilment centre, the claim line goes to GSO’s claim cycle, not GS’s, because a line joins the cycle of the company it is charged to. The cycle’s Cross-Billing Report lists the claims charged to another company or branch.
• A transfer moves the person, not their history. Move a supervisor from GS-PEN-01 to GS-JB-02 and the invoices she was named on stay Penang’s — a document keeps its own branch, and copied her name and code when she was picked. Her claims change approvers straight away: a claim line is approved at the branch it is charged to, by whoever holds the designation that matches her Job Title there. If the new branch has no designation of that name, she is routed as Staff and her next claim stops with Your designation: Staff is yet to be configured for branch: … (Core concepts §3).
• A leaver needs two changes. Employment Status records why and when; the record status INACTIVE takes them out of the Sales Invoice and till salesperson pickers. Neither takes them out of Claims or out of the category-based picker most other sales documents use (Core concepts §2).
• Load with a code on every row. A CSV row without EMPLOYEE_CODE is matched against every entity by ID number, tax number, e-mail and phone, and can turn a walk-in customer into an employee rather than create a new person (Employee Maintenance, File Import).
• An idea worth having: because an employee is an entity, staff can buy at the till on their own record against a Spending Limit — a quota of quantity or amount, enforced item by item by the POS General till on cash bills billed to that person (Employee Maintenance, The other tabs).

Whose job, and how they know. Whoever keeps the employee master adds, moves and closes people on the day it happens; the branch manager’s job is to tell them that day, not at month end. They know a new hire or transfer is done when a draft sales invoice and a draft sales order at the new branch both offer the person as salesperson and, for a claimant, My Claim opens without an e-mail error. They know a leaver is done when the person is gone from the Sales Invoice picker and from the Claim Cycle applet’s Reviewer Setting.

2. Expense claims settled through payroll

The shape. GadgetSphere’s branch staff claim mileage between branches and small purchases. Finance does not want to pay each person each month by transfer, so mileage and meal claims are paid with salary and larger one-off items are paid by finance. In the Claim Applet, the mileage and meal claim items get Payment Processing Option = Salary Payment; the rest stay Finance Payment.

What happens behind the screen. At the last supervisor approval a Salary Payment line goes straight to APPROVED; a Finance Payment line waits as PENDING_DOC_REVIEW for finance to review it in the claim cycle. Either way the line is attached, at that moment, to the claim cycle of the company it is charged to, for the month of the approval — but only if that cycle already exists and the approval is on or before the cycle’s approval cut-off.

What the hand-off carries, and what it does not

Before the payroll cut-off, whoever runs payroll opens the month’s cycle in the Claim Cycle Applet and exports the salary-payment CSV from its Payroll Payment tab. Four things about that file are not visible on the tab:

• It has three columns and one row per claim line: the employee code, the claim item’s code and the amount including tax. A supervisor with three mileage lines is three rows, not one total. The payroll system adds them up per person.
• The employee code is the key. It is the code copied onto the line when the claim was submitted. If your payroll system numbers people differently, agree once which BigLedger code belongs to which payroll number, and keep that list with the payroll file.
• It holds only lines attached to that cycle. A line approved after the cut-off is in no cycle, so it is in no cycle’s CSV. The Payroll Payment Report run with Claim Cycle left empty finds it — but that report lists every month’s Salary Payment lines with no date filter, and shows at most 1,000 of them. For a group with many claimants, switch on Auto-add approved claims to active cycle on each company’s cut-off row in the Claim Applet: a late approval then joins the current month’s open cycle instead of none. It joins after that cycle’s cut-off, though, so it can arrive after you exported — before you close each payroll, open last month’s cycle tab again and pay anything there that is not in last month’s filed CSV.
• Nothing in BigLedger records that a line was paid. A Salary Payment line stays APPROVED after it reaches a payslip; there is no paid status and no payroll reference on the line. The only record of which lines went on which payslip is the one the payroll owner keeps — the month’s CSV, filed with that month’s payroll.

Where BigLedger stops

At the file. No registered applet computes the salary those amounts are added to, and nothing posts a journal for the claim — a claim is not a financial document. The reimbursement reaches the ledger inside the payroll journal of shape 3, coded to the claim items’ expense accounts. To see those accounts, add Salary Payment to your own Default Payment Processing Option in the Claim Cycle applet’s settings: the cycle’s PV Details Report then lists the salary lines with each claim item’s GL code beside the finance ones.

The other option on the same claim item is the sibling: a Finance Payment line is reviewed in the cycle, paid from the Bank Report, and reaches the books on the Payment Voucher (Internal) a person raises from the PV Details Report, dated the voucher’s date (Claims, Which one to choose).

Whose job, and how they know. The payroll owner pulls the CSV after the cycle’s approval cut-off and before the payroll cut-off, and files it with the month’s payroll. Finance posts the reimbursements in the payroll journal. They know it went right when the CSV’s total equals the claims added to payslips that month, and every line on the cycle’s Payroll Payment tab is on a payslip or written down as carried to next month.

3. Payroll elsewhere, the journal here — the shape that works today

This is what a business in GadgetSphere’s position actually does, and it is a supported shape rather than a workaround. Payroll runs in whatever system computes it. Each month the payroll owner produces the result; finance brings it into BigLedger as a general journal, split across branches, debiting wages expense with gross plus the employer’s contributions and crediting net pay and each statutory liability.

Why payroll runs somewhere else

A tenant that wants attendance feeding a payroll run, with EPF, SOCSO, EIS and PCB computed and a bank file generated, has no registered applet to do it with. A payroll backend and a Payroll Admin applet exist in source; the applet has no row in the applet registry, so it cannot be installed. Its Post GL writes only into the payroll module’s own tables, not the general ledger. What the backend does is described at Payroll Admin — read it to judge the module, not to plan a go-live. Until it is registered, shape 3 is the plan.

Who does what, and when

The payroll owner closes their run and hands over the summary by an agreed day each month — with the salary-paid claims of shape 2 already inside it. Finance posts the journal in the month the work was done, not the month it was paid — a December run paid on 3 January is a December cost. The statutory liabilities are cleared when the contributions are remitted, which in Malaysia is the 15th of the following month for every scheme. This page states no contribution rate; take those from KWSP, PERKESO and LHDN.

The journal at GadgetSphere

Each company keeps its own ledger, so GS, GSO and GSD each get their own journal from their own payroll summary. Take GS’s March, using the figures of the module page’s worked example: gross RM 512,400, employer’s contributions RM 70,180, net pay RM 433,450. One journal dated 31 March debits EXPENSE-WAGES RM 582,580, split into one line per branch, and credits the net-pay payable and each scheme’s liability. If the month’s payslips carried salary-paid claims from shape 2, they go in as their own debit lines to the claim items’ expense accounts, and the net-pay credit grows by the same amount.

Two things the Ledger And Journal screen will let you get wrong without a word. A line’s branch is optional, and a per-branch report drops a line that has none — so a branch whose line was keyed without one reads nil wages. And a manual journal posts the moment you press Create; there is no draft to check first, so check the lines against the payroll summary before you press it.

How much detail the journal carries

Agree this before the first journal, because it is expensive to change later. Employee-level lines make reconciliation easy and put individual salaries into a ledger many people can read. Most businesses aggregate by branch for exactly that reason, and some are required to — no employee names and no individual amounts in a journal narrative is a condition an organisation may be under, and a public-sector one usually is. Decide it once, write it down, and the test is that nobody can read a person’s salary off the general ledger.

How you know it worked

Three checks, each of which takes a minute. The wages expense in the trial balance equals the payroll system’s gross plus employer contributions for the month. Each statutory liability account is nil after the 15th. And every journal line carries a branch, so a branch manager can see their own wages cost without anybody doing an analysis.

4. The salesperson on every sale

The shape. This is the shape most companies are in without thinking of it as people administration. Every sales order, invoice and cash bill at GadgetSphere names the staff member who made the sale, and at month end the sales commission is worked out from those names.

What to know:

• Which salespeople a document offers depends on the document. The Sales Invoice and the till list ACTIVE employees. The Sales Order, Quotation, Delivery Order and most other sales documents list employees who carry an Employee Category, whatever their status — so a new hire with no category is missing from the order and present on the invoice.
• The document keeps a copy. The salesperson’s name and code are copied onto the document when picked; renaming the employee later does not change last month’s invoices, which is what lets a reprint match the original.
• A wrong name after FINAL is a setting, not a void. At FINAL the Sales Invoice locks its header, the salesperson with it. The Sales Invoice applet setting ALLOW_EDIT_SALES_AGENT_FINAL re-opens just that field, and it is off unless someone switches it on. Two kinds of business want opposite things here — one wants the salesperson locked against tampering, the other wants to correct a wrong pick without reversing a correct posting — which is why it is a setting (Why you cannot edit a finalised invoice, The sales agent).
• Correct it before the commission cycle runs. The commission cycle’s first stage reads the month’s FINAL sales orders, invoices and cash bills and marks each one it used as processed; a later cycle does not pick that document up again. A salesperson corrected after that changes the document and not the commission (Sales Commission).
• No salesperson, no commission line, no warning. A sale saved with the field empty produces no commission line for anyone.

Whose job, and how they know. The branch supervisor checks the day’s documents name the right person before the day is closed; the sales administrator runs the commission cycle only after the month’s corrections are in. They know it went right when the month’s commission report has a line for every person who sold that month, and nobody asks why their sales are missing.

What every one of these shapes has in common

• What must exist first. Companies and branches in Organization — no employee saves without a branch. For anyone who claims, a platform login linked on the employee’s Login tab, with the same e-mail on the Main tab. For shape 2, each company’s Claim Cut-Off Logic row, without which no monthly cycle is created and no line has a cycle to join (Configuration puts them in order).
• What they make possible. Commission (shape 4), claims and their hand-off (shape 2), staff purchases against a spending limit (shape 1), and per-branch wages cost (shape 3).
• Siblings, and when to choose which. Salary Payment for small, regular amounts you would rather add to pay; Finance Payment for anything that should be reviewed in the cycle and paid by transfer. Shape 3 today; Payroll Admin when it is registered and you have tested its output.
• What breaks elsewhere when one record is wrong. A Main-tab e-mail that differs from the login stops the person in Claims. A missing Employee Category hides them from the Sales Order picker and so from that order’s commission. A Job Title spelled differently from the branch designation routes their claims as Staff. A missing Payment Config leaves their Bank Report row with no account.
• What they pair with in practice. The employee master behind sales and commission, beside a payroll that runs somewhere else, with the monthly journal in Ledger And Journal as the module’s other half.

Where the numbers in these shapes come from

Each figure these shapes leave behind is either a snapshot, stored at the time something happened, or recomputed every time you look — and that decides whether fixing the record fixes the figure.

When one of these shapes goes wrong

What none of these shapes will do for you

Each limit below runs across these shapes. After each one, the person who does the job instead.

• Nothing computes pay, leave or attendance. The payroll owner does, in the system that runs payroll today, and hands BigLedger one summary a month.
• Nothing posts the payroll or the salary-paid claims to the ledger. Finance does, as one journal per company, in the month the work was done.
• Nothing tells payroll which claim lines it has already paid. The payroll owner files each month’s CSV with that month’s payroll and reconciles against it.
• No registered applet keeps the statutory calendar. Whoever remits the contributions keeps the diary of the 15th, and finance checks the liabilities are nil afterwards.
• A salesperson corrected after the commission cycle used the document does not move the commission. The sales administrator holds the cycle until the month’s corrections are in.

How you know a month of people administration went right

About twenty minutes on the first working day after the 15th, per company.

1. Everyone is where they work (shape 1). Open the record of each person hired, transferred or lost this month. You are done when each change is on the record and every leaver is INACTIVE or has a named reason.
2. Nothing fell between claims and payroll (shape 2). Compare this month’s and last month’s Payroll Payment tabs with the CSVs filed with each payroll. You are done when every line on both tabs is on a payslip or written down as carried forward.
3. The journal agrees with payroll (shape 3). The month’s wages expense equals gross plus employer contributions, every line names a branch, and each statutory liability is nil. You are done when all three hold without an adjustment.
4. Everyone who sold was paid commission (shape 4). You are done when the month’s commission report has a line for each person who sold, and the cycle ran after the last salesperson correction.

If a step fails, the row above with the same symptom names the fix.

Where to go next

If you are setting up from nothing, start with Configuration: it creates what these shapes depend on, in order.