Pay structure

Without it, a salary package is a basic and a list of allowances somebody typed: any name, any amount. That works until the business decides what each role should be paid and wants everyone moved onto it. This module is that decision held as data, in two halves that can be switched on separately:

• Pay grades — the grid of levels, positions and steps with the basic each step pays; the catalogue rates that lock an allowance's amount; and the placement that moves one employee onto a step with the allowances they qualify for, from a month you choose.
• Allowance sheets — one sheet per variable allowance per month (days attended, sittings, acting days, operator days), filled in by HR and paid by the run. The app fills in what it can; it never decides the amount.

Nobody has to move at once. Someone who is not placed is paid exactly as before, from the package they already have, for as long as it takes to reach them.

The catalogue is the Payroll components card under Reference data → Payroll — the same list of earning and deduction codes the run already uses, with four more things on each earning:

• Basis — Monthly, per working day, per sitting, per acting day, annual, per course, or as applicable. Anything other than Monthly is paid through monthly sheets.
• Rate — the catalogue amount. When it is set, the amount on every package is locked to it. When it is blank, the amount is typed per person (an offshore allowance paid "by assignment").
• Currency — blank means the package's own currency.
• Description — what the allowance is for, in the words of the policy.

On the salary page an allowance is then picked from a list rather than typed, and a rated one fills its own amount. The lock is enforced when the row is saved, not only on the screen. An allowance paid through sheets is saved with an amount of zero: on the package it is a tick that says "this person is entitled", and the sheet carries the money. Those zero rows are hidden on payslips, letters and the staff record.

A field the catalogue or the grade fills is greyed out with a dashed border and cannot be typed in. On a placed person's package the basic is one of them; hover the info icon beside it to see the grade it comes from, for example "grade L02P01G03 · Officer 3 — changes by placement". The person's overtime and late-fine overrides sit in a folded Overtime & late-fine rules section under the main package; its heading says how many overrides they have, or that every rule comes from the work site.

Rows typed before the catalogue existed keep working. They show a not in catalogue badge and a Map button; mapping one to a rated code re-prices it to the rate, after the page shows you the old and new amounts. That is the only time an existing amount changes without a placement.

A grade code reads as level, position and step: L02P01G03 is level 2, position 1, step 3. The first six characters, L02P01, are the band. A designation belongs to a band (every step of a band carries the same job title), and the placement picks the step.

The grid is the Pay grades page under Payroll setup → Pay grades: each step with its basic and how many people sit on it. Rename a level, change a basic or untick active in place; add a step from the row at the bottom. Set a designation's band on the Designations card under Reference data, or let the placement page ask the first time it meets one without.

The grid is usually loaded once from the structure workbook through Data import → Pay grades, and the allowance registry through Pay components. An allowance that payroll already computes (Friday pay, overtime, service charge) is recognised by name and left alone; the import says so rather than creating a second code. A step that people sit on is retired, never deleted. Changing a step's basic does not re-price anyone already on it.

On an employee's salary page, use Place on the grade structure. The page shows today's packages on the left and the proposal on the right: band (from the designation), step, whether the basic is split half in US dollars, and one tick per allowance with its rate. Long-service ticks are pre-ticked from the join date, and anything on today's package that matches a catalogue code is carried over. Untick what does not apply. Preview shows the new total against the old one, per currency, with the percentage change.

Submit for approval sends the placement down the same route as a salary increment, and the approver sees the grade and the monthly difference. Once approved, it is Scheduled, and nothing has changed yet. The payroll run for the effective month applies it before it builds any lines: the existing packages are rewritten in place from the grade and the ticks, and the basic is locked to the step. To apply it straight away, use Apply now. To call it off after approval, use Withdraw and give a reason.

Late placements are back-paid. If the effective month's run was finalized before the placement was applied, the next run adds the difference for each month missed, as it does for a late raise. Allowances paid through sheets are not back-paid, because no sheet was worked out for those months.

A batch from the workbook comes in through Data import → Grade placements, one row per coded employee, with the effective month as a column. Importing does not submit anything: the increments page lists the imported rows, and Submit all for approval sends them on. Once someone is placed, a raise is a step change: use a new placement, not a salary increment.

Pay adjustments → Allowance sheets lists one sheet per allowance per month. The allowance list on the create form is the catalogue's active earning codes, so an allowance has to be in the catalogue before it can have a sheet. Codes the run works out by itself (salary arrears, reimbursements) are left out. Creating a sheet fills it in from what the app knows:

• who — everyone on the payroll whose package carries that allowance;
• units — for a per-working-day allowance, the days marked present in the run's attendance period (Refresh days re-counts them after a late sync, leaving rows you typed over alone);
• rate — the catalogue rate, else what this person was paid per unit on the last sheet (so an operator's rate is typed once, then remembered);
• amount — units × rate where both are known.

Then it is yours. Change any row, type over an amount (the row is flagged where it no longer equals units × rate), Add someone not on it, or Download .xlsx, work in Excel and Upload it back: the preview lists every change, and unknown staff numbers are reported, never guessed. When it is right, Mark ready.

The run pays every Ready sheet for its month: one line item per row, on the person's package in the sheet's currency, or on a separate "allowance sheet only" line if they have none. The item is taxed when its catalogue code is taxable; pension is not charged on it. Regenerating a draft run picks up any edits. Once a run carrying a row has gone to sign-off, that row is locked; once the run is finalized, it is paid and never paid again.

Back to draft takes a sheet out of the next regenerate. Cancel sheet retires it. A sheet whose rows have all been paid reads as applied.

1. Map new codes in the ledger. Every new allowance code reaches a payslip by name, and the journal export refuses a run with an unmapped earning. Map them in Finance → Mappings before the first run that pays them.
2. Approve the month's placements so they are Scheduled.
3. Mark the month's sheets ready.
4. Create (or regenerate) the run. It applies the due placements, then builds lines, then pays the ready sheets. Its message says how many sheet rows it paid.
5. Send it for sign-off and finalize as usual.

Applying a placement is one-way: deleting or regenerating the draft run does not undo it. The placement keeps a before-and-after copy of the packages, and every changed field is in the audit trail, so a mistake is corrected with a new placement.

Analytics → Pay structure shows how far the move has got: placed and unplaced headcount, placements scheduled and awaiting approval, the change in monthly fixed pay they bring (per currency), placed staff by level and step, placements by effective month, and sheet totals by month. It also lists what needs attention: placements whose month has passed, sheets still in draft for a run that exists, designations without a band, and sheet codes with no GL account.

In the report builder, Pay grades and Allowance sheet rows are sources of their own, and salary packages and increments gain grade, band and step fields. The ready-made reports include who is still on the old structure, headcount by grade, this year's placements, and the month's allowance sheets. The grade grid and the month's sheets also download as CSV or Excel from their own pages.

Two widgets can be added to a home page: Pay structure placements and Allowance sheets to prepare.

• payroll.manage edits the grade grid; payroll.view sees it.
• refdata.manage edits the catalogue and designation bands.
• payroll.manage prepares placements and sheets. Approving a placement is a step on the salary-increment route. Without a route, any payroll.manage holder can approve, including the person who submitted it, so set up a route before the first placement.
• Basics, rates and amounts need sensitive.pay, on every page, report and download. Headcounts and units do not.
• Each half is behind its own switch: Features:EnablePayGrades and Features:EnableAllowanceSheets. Sheets work without grades, which is how an operator allowance is paid without a grade structure.
• Finalize the month before switching either off. With grades off, scheduled placements wait and graded packages can be edited again. With sheets off, a draft run regenerated afterwards loses its sheet items.
• A ready row for someone who has since left is still paid. Remove the row if that is not intended.