Allowance reconcile
Keeps the allowance rows on open timesheet statements in step with the allowance configuration that applies right now.
Overview
Allowance rows — the automatic registrations produced by allowance policies and by the employment terms’ hourly activity — are normally written when a day (or its week) is registered or edited. A configuration change does not rewrite days that have already passed, so changing an allowance mid-period used to leave the period half-filled: days before the change kept their old rows, later days got none, and the rest only caught up if someone happened to edit them.
Approving such a period would freeze a total that matched neither the old nor the new configuration — and for an allowance activity that feeds payroll, that total is what gets paid.
This job removes that gap. It recalculates the allowance rows for every statement that is still open, so a change you make today is reflected on the days already registered in the current period.
How it works
- Picks statements — statements that are still open (pending, ready or overdue) and whose period has started. Workspaces without a single allowance activity are skipped outright.
- Skips the uninvolved — an employee with no allowance policy in scope, no hourly activity on their terms, and no existing allowance rows in the period has nothing to reconcile and is skipped without further work.
- Re-evaluates the days — each remaining day is recomputed exactly as it would be if the employee edited it, so allowance policies (rules and counters) and the terms’ hourly activity all behave the same way.
- Writes only what changed — days whose result is identical are left untouched, so a run on an unchanged system writes nothing at all.
Removals and additions are both handled: an allowance that no longer applies has its rows removed, and one that has been added gets its missing rows created across the whole open period.
Only days that belong to an open statement are reconciled. Employees whose employment terms do not use timesheet approval have no statements, so their allowance rows are not covered by this job.
Submitted and approved statements are never touched
The job only ever writes to statements that are still open. A submitted or approved statement keeps the totals that were frozen when it was handed in — the job never rewrites them and never reopens a statement. The same applies day by day: in a week that spans two periods, only the days belonging to the open period are recalculated.
If an allowance is corrected after an employee has already submitted, that statement keeps its frozen figures. Reopen it if the correction should apply: the next run reconciles it, and re-approval records the adjustment.
When it runs
The job runs daily for every workspace that has open statements and at least one allowance activity. In addition, it is triggered immediately when someone changes the allowance configuration, so a correction usually shows within minutes instead of waiting for the night:
| Change | What is reconciled |
|---|---|
| An allowance policy is created, edited, deleted or restored | The employees the policy applies to — both before and after the change |
| The hourly activity on an employment term is changed | Everyone employed on that term |
| A scheduled allowance or terms change reaches its effective date | The same sets, as part of the nightly cycle |
Editing an employment term without touching its hourly activity does not trigger a run. When several changes are made in quick succession, they share the run that is already queued.
The daily run is the safety net for everything the immediate triggers cannot see — an employee moving to another org unit, an employment being edited, or work time norms being published again.
Parameters
| Parameter | Description |
|---|---|
| Employee IDs | Comma-separated employee IDs to limit the run to. Empty means every open statement in the workspace is checked |
| Allowance policy IDs | Comma-separated allowance policy IDs. The run covers the employees those policies currently apply to |
Both are normally left empty — they are what the automatic triggers use to keep a run small. Set them by hand to re-check a single employee or policy.
Job results
| Metric | Description |
|---|---|
processed | Open statements the job examined |
emitted_days | Days whose allowance rows were rewritten |
skipped_statements | Statements skipped because the employee has nothing allowance-related in the period |
errors | Days that could not be evaluated (the rest of the run continues) |
scope_employees | Employees the run was limited to, when it was triggered by a configuration change |
A healthy run on an unchanged system reports emitted_days: 0.
Troubleshooting
| Issue | Solution |
|---|---|
| An allowance change is not visible on the current period | Check that the statement is still open — submitted and approved statements keep their frozen totals until they are reopened. Then run the job for that employee |
| Rows are missing for the first days of a period only | This is what the job repairs. Run it, or wait for the nightly run |
| An allowance still appears after its policy was deleted | Run the job; the run triggered by the deletion may have failed. Check the job run for errors |
| Rows appear for an employee who should not have the allowance | Check the policy’s availability scope and the hourly activity on the employee’s terms — the job reproduces whatever the current configuration gives |
errors is above zero | Open the job run and check the messages. A malformed allowance rule can prevent a day from being evaluated; the remaining days are still reconciled |