Core Concepts

This page is for whoever keeps the employee records at a multi-branch group and has to explain a people problem to somebody else: why a new manager’s claim will not submit, why a leaver still turns up on sales orders, why a claimant was not paid. Five ideas explain nearly all of it. None of them is a payroll idea; the module page explains why. Read it once, in about ten minutes.

The situation it was written for. At GadgetSphere Sdn Bhd one week in April brings three questions. A store manager promoted at GS-PEN-01 cannot submit a mileage claim: the error calls her Staff, which is not her job (§3). A cashier who left in March is gone from the Sales Invoice salesperson list and still offered on Sales Orders (§2). And a claimant appears twice on the Bank Report, once for each bank account on his record (§4). The first two are the design working as built. The third is a gap you guard against by habit, and each is explained where it comes up.

1. An employee is an entity with a flag

Every customer, supplier, employee and merchant is one entity record with four flags — customer, supplier, employee, merchant. The Entity Type field on the record is multi-select, so one person can be an employee and a customer at once, and they are one record, not two.

Employee Maintenance is the employee lens on that table: it sets the employee flag and shows the employment fields only while EMPLOYEE is among the selected types. Entity Maintenance is the lens with no type: it lists every record and lets you add a flag to an existing one. When you create a record there with EMPLOYEE ticked, the only legal form offered is INDIVIDUAL; the edit screen does not apply that limit, so ticking EMPLOYEE on an existing corporate record is accepted. Check the legal form before you add the employee flag to a record that already exists.

Why one record, and what it is good for

One record is what lets a sales assistant at GS-KV-02 buy a laptop on her own employee record, against a spending limit set for staff purchases, without anybody opening a customer account for her. It is also why the CSV import, given a row with no employee code, can find a walk-in customer with the same phone number and flag that record as an employee instead of creating a new person. The import is not wrong; one person really is one record. Put EMPLOYEE_CODE on every row (Best practices §2).

The employee code is written once

The employee code is generated when left blank — the EMPLOYEE_ID running number plus the tenant’s employee prefix as it stands at that moment — and must be unique among non-deleted entities. Supplying a code on a record that is not flagged EMPLOYEE is refused outright. Codes already issued keep the prefix they were born with, so changing the prefix later gives you two numbering styles side by side; set it before the first record.

2. Employment status is not record status

There are two lifecycles on the same record, and they do not touch each other:

Field	Values	What it means
Status (the entity record)	`ACTIVE`, `TEMP`, `INACTIVE`	Whether the record is live. An `INACTIVE` employee drops out of the Sales Invoice and till salesperson pickers; the category-based picker on most other sales documents, and Claims, do not check it.
Employment Status	`ACTIVE`, `RESIGNED`, `TERMINATED`, `ABSCONDED`, `VOLUNTARY SEPARATION`	Where the person is in their employment. Changing it does not change the record’s status.

So a person who has left can still be ACTIVE as a record — which is what you want while claims are still being settled — and you set the record INACTIVE deliberately, later. Joined Date and Cessation Date sit beside Employment Status on the Main tab; Employment Status and Branch are mandatory on create.

What each one actually changes

Employment Status is a label with one reader. The claim-cycle reviewer lookup skips a person whose Employment Status contains Terminate. That is all: RESIGNED, ABSCONDED and VOLUNTARY SEPARATION leave a reviewer reviewing, and no status of either kind removes anybody from the claimant lookup. Across the companies on BigLedger most employee records carry no Employment Status at all, and leavers are handled with the record status alone.

Record status is read by the Sales Invoice and till salesperson pickers; the category-based picker most other sales documents use does not check it, and neither do the claims lookups. Those start from the person’s platform login, use it only while that login is active, and match the login’s e-mail to the employee record’s.

The leaver is a checklist, and it belongs to a person

Nothing in BigLedger runs a leaver process, so the order is yours. Whoever owns HR agrees the last working day, then: Employment Status and Cessation Date on the record; the last claims approved and paid; their row removed from the Claim Cycle applet’s Reviewer Setting if they reviewed; their platform access ended; the record set INACTIVE. You know it is finished when a draft Sales Invoice at their old branch does not offer them, and the Claim Cycle’s reviewer list for their company does not name them.

3. Reporting lines and designations are two different things

Employee Maintenance holds who reports to whom in two places, and the claims process reads a third:

Report To — up to three levels of manager per employee, each chosen from the employee list.
Org Chart — a separate structure per company with DEPARTMENT and EMPLOYEE nodes, each with a rank and a designation. The employee’s edit form shows, read-only, which org charts they sit in.
Designations per branch — maintained not here but under Settings → Branches in the Claim Applet, as the Approval Designation tab, with the employees who approve for each designation.

Only the third routes an approval. Report To is read by nothing outside the employee screens, and the claim workflow the screen calls Non-Chargeable finds approvers by Job Title, not through the org chart, although its internal name mentions one. Both are reference data.

How a claim line finds its approver

When a Non-Chargeable claim line is saved, BigLedger takes the claimant’s Job Title from the Main tab and looks for a designation, or an approval setting, of the same name at the line’s cost-centre branch — compared without regard to capitals, otherwise exactly. If it finds one, the line takes that designation. If not, the line is treated as Staff. The approvers are whoever is linked to that designation at that branch.

That explains the promoted store manager. Her Job Title reads Store Manager; GS-PEN-01’s designation is called Branch Manager. No match, so her line was routed as Staff, and the branch she charged the mileage to has no Staff designation set up. Depending on what is missing there, the message is Your designation: Staff is yet to be configured for branch: … or Approval level & quorum are yet to be configured for job designation: Staff …. Either way, the fix is the spelling of one field or one designation, not her permissions.

What this is good for. Approval follows the branch that bears the cost, not the claimant’s home branch, so a regional manager who visits four branches in a week has each line approved by the branch that pays for it. The price is that every branch that receives claims needs a Staff designation and one for every senior Job Title that should not be treated as staff.

Who keeps the reporting line true

Across the companies on BigLedger, Report To is empty on essentially every employee record and few records carry a Job Title — so in practice most claimants are routed as Staff. That is a fine setting for a small team and a poor one for a group where a manager’s claim should not be approved by the people they manage. Decide which of the three structures is the authoritative reporting line, write it down, and keep the other two from contradicting it. For claims, that means the Job Title spelled as the branch designation is spelled. The check, after every promotion: open the claimant’s branch designations in the Claim Applet and find their Job Title there by name.

4. Bank details live on the employee, and two places read them

The Payment Config tab on the employee record holds payee residential status and country (mandatory) and bank, SWIFT code, account number, account holder name, IBN number and account expiry (optional). Two things in the registered product read it, at different moments:

The Bank Report in the Claim Cycle Applet adds up each claimant’s approved Finance Payment lines for the cycle and joins their payment details when you press Generate, then keeps the result. A claimant without a Payment Config gets a row with no account, and is not paid until someone notices.
The File Export in Payment Voucher (Internal) writes the payee’s residential status, country, bank, SWIFT code, account number and holder name into each exported voucher row, read when you export.

Keep one Payment Config row per employee

The tab accepts several rows, and neither reader chooses between them. The Bank Report joins every row that is not deleted, so a claimant with two accounts appears twice, each time with the full amount. The voucher export takes the first row it finds and does not skip a deleted one, so it can print an account the employee has replaced. No employee on BigLedger holds two rows today; the first person to add a second account for a staff member will find this out on a payment file.

Who verifies a bank change

BigLedger stores the account; it does not check that the account belongs to the employee. A changed bank account is the oldest payroll fraud there is, so a change should come from the employee in writing, be confirmed with them by a call to the number already on file, and be made by someone other than the person who releases the payment. Compare the Bank Report’s accounts with last month’s before you upload it to the bank.

5. A claim is paid one of two ways, and the claim item decides which

Every claim item carries a Payment Processing Option:

Option	What happens at the last supervisor approval	Who pays
`FINANCE_PAYMENT`	Line goes to `PENDING_DOC_REVIEW` and waits for the month’s claim cycle	Finance, from the Bank Report or a Payment Voucher (Internal)
`SALARY_PAYMENT`	Line goes straight to `APPROVED`	Payroll — the line appears on the Claim Cycle’s Payroll Payment Report and its CSV export

That second row is the whole of the module’s link to payroll today. The report is a hand-off: the approved amounts are listed for a person or a payroll system outside BigLedger, and nothing in the registered product computes a salary, deducts anything, or posts a journal from it.

The cut-off decides which list a line is on

At the last approval a line is attached to its company’s claim cycle for that month — if the cycle already exists and the approval falls on or before the cycle’s approval cut-off. A Salary Payment line approved on 28 March against a cut-off of 25 March is on no cycle’s list, so a payroll clerk who reads only the March cycle’s tab never sees it. Run the Payroll Payment Report with Claim Cycle left empty and it is there — the report returns at most 1,000 lines from every month, with no date filter and no next page, so choose your company too. Whoever runs payroll owns the reconciliation: each month, every line on that unfiltered report is either on a payslip or carried to the next one, and nothing is on neither.

What is not a concept here

Leave. The Approved Leave tab on the employee record has a form and an Add button, and no save path — the handler is empty and the save call is commented out. There is no leave balance in the registered product.
Attendance. No registered applet records a clock-in.
Pay run, payslip, statutory contribution. These exist as backend tables and endpoints (a pyrll package) and no registered applet reaches them. What that backend does is described at Payroll Admin.

All three absences hand the same job to the same person, so it is worth saying once. Whoever computes your payroll — a payroll bureau, an HR system, a spreadsheet — owns leave balances, attendance and the gross-to-net calculation, and BigLedger’s part begins when their monthly result becomes a journal. The seam to agree with them is: what they send, when they send it, and at what level of detail. The check that the seam works is that the wages expense in your trial balance equals their gross plus employer contributions for the month, every month, without anybody investigating. See Use cases.

Where the figures on this page come from

Each idea above leaves a name or a number on some screen. Each is either a snapshot, stored at the time something happened, or read again every time you look — and that decides when it can be out of date.

The figure	Written when, from what	So, when it looks wrong
An employee code	Generated at the first save with the code blank, from the running number and the prefix at that moment	Old codes with the old prefix are the copy doing its job; nothing renumbers them
A manager’s name on Report To	Copied — name, e-mail and code — when the manager was chosen	The manager was renamed or replaced; choose them again
The designation on a claim line	Worked out when the line is saved, from the claimant’s Job Title and the line’s branch	`Staff` where you expected a senior title: the Job Title and the designation are spelled differently (§3)
The claimant’s name on a claim line	Copied from the employee record at Submit	A rename does not reach lines already submitted
Bank details on the Bank Report	Read from Payment Config at Generate, then kept	You fixed the account and the report still shows the old one: generate it again
Bank details on a voucher export	Read from Payment Config at each export	An old account: a second or deleted Payment Config row (§4)
A line on the Payroll Payment Report	Worked out each time you run it, from Salary Payment lines	Missing with a cycle chosen: approved after that cycle’s cut-off (§5)

When one of these ideas bites

What you see	Which idea	What to do
Your designation: Staff is yet to be configured for branch: … on a senior employee’s claim	§3: their Job Title matches no designation at the line’s branch	Make the Job Title and the branch designation the same name, or set up `Staff` at that branch
A claim is routed to the branch where the cost was charged, not the claimant’s own	§3: approval follows the line’s cost-centre branch	Expected; charge the line to the right branch
Report To names a manager who left last year	§3: Report To is a copy, and routes nothing	Update it for the record’s sake; fix approvals in the Claim Applet
A leaver still reviews claims	§2: `RESIGNED` is not Terminate, and the lookup ignores record status	Remove their Reviewer Setting row in the Claim Cycle applet and end their platform access
A leaver is gone from Sales Invoices and still offered on Sales Orders	§2: only the Sales Invoice and till pickers read record status	Expected; the Sales Order picker lists by Employee Category
A claimant appears twice on the Bank Report, each with the whole amount	§4: two Payment Config rows	Remove the old row on its edit panel, then generate the report again — before you upload it
The voucher export shows an account the employee closed	§4: the export takes the first Payment Config row, deleted or not	Keep one row per employee; correct the payment file by hand this time
An approved Salary Payment claim never reached a payslip	§5: approved after its cycle’s cut-off	Run the Payroll Payment Report with Claim Cycle empty and your company chosen; it returns at most 1,000 lines
Leave keyed on Approved Leave has vanished	The tab saves nothing	Keep leave where you keep it today

The symptoms that start in sales, journals and the CSV import are on the module page.

How you know your company follows them

About ten minutes, once, and again after a restructure or a run of promotions:

Approvals match your reporting line. For each branch that receives claims, the Claim Applet’s Approval Designation tab has a Staff designation and one for every senior Job Title used there, spelled as the Job Title is spelled. You are done when a draft claim from your most senior claimant at that branch shows their own designation, not Staff.
Leavers are finished. Filter the employee listing by Employment Status. You are done when everyone who has left is INACTIVE or has a named reason (a claim still being paid), and nobody who has left is in a Reviewer Setting row.
One account each. Open Payment Config for this month’s claimants. You are done when each has exactly one row and it matches the account they confirmed in writing.
Nothing falls between payroll and claims. Run the Payroll Payment Report with Claim Cycle empty and your company chosen. You are done when every line on it is on a payslip or carried forward, and the list is shorter than 1,000 lines — at 1,000 it may be cut short.

How these ideas sit among the other modules

What must exist first. Companies and branches in Organization — no employee saves without a branch. A platform login for anyone who will claim, with the same e-mail on the Main tab. For claims, the branch designations and approval settings of §3.
What a complete record makes possible. Naming a salesperson on sales documents and at the till, which is what commission is calculated from; staff purchases against a spending limit; claims; bank details on the Bank Report and on Payment Voucher (Internal) exports; and a self-billed e-Invoice to the employee.
Siblings, and when to use which. Employee Maintenance for new people and employment fields; Entity Maintenance when an existing customer or supplier becomes an employee. Record status to take someone out of the pickers that check it; Employment Status to record why and when they left — a leaver needs both. Salary Payment for small regular amounts added to pay; Finance Payment for anything finance should review and pay.
What breaks elsewhere when the record is wrong. A Main-tab e-mail that differs from the login stops the person in Claims (Cannot find your email … from Employee Applet). A Job Title spelled differently from the branch designation sends their claims to the wrong approvers. A second Payment Config row doubles them on the Bank Report. A missing Employee Category hides them from the Sales Order picker.
What it pairs with in practice. For most companies on BigLedger this module is the employee master behind sales and commission; expense claims are run by very few, and payroll runs somewhere else, with the monthly journal in Ledger And Journal.