Timesheet statement generation
Opens a pending timesheet statement for each active employee whose current approval period is not yet covered.
How it works
When timesheet approval is enabled on an employment terms (weekly, biweekly, or monthly), every employee on those terms should have one timesheet statement per approval period. This job opens the missing statement for the current period:
- Finds approval-enabled terms — employment terms with a non-empty approval mode
- Computes the current period — for each set of terms, derives the approval period bounds for the run date
- Selects candidates — active employees on those terms whose current period is not yet materialised as a statement with those exact bounds
- Emits a period-started event — one event per candidate. The downstream handler creates the pending statement, or does nothing if an exact match already exists
The “exact bounds” match matters: switching the approval period (e.g. monthly → weekly) leaves the old monthly statement in place but creates fresh weekly ones from the next run on.
When it runs
The job runs automatically and only triggers when there is at least one candidate to open a statement for. Enabling approval mid-period creates the missing statement on the next run, not on the period boundary.
Parameters
This job has no parameters. The run date controls which period is considered “current”.
Running with a past run date
You can pre-create or backfill statements for a specific period by triggering the job manually with a run date inside that period. The handler is idempotent, so re-runs are safe.
Job results
| Metric | Description |
|---|---|
created | Number of pending statements created |
errors | Number of failures while emitting events |
When no terms have approval enabled, the run reports skipped: "no employment terms with approval enabled".
Troubleshooting
| Issue | Solution |
|---|---|
| Statement not generated for an employee | Confirm the employee’s employment terms have a non-empty approval mode and the employee is active |
| Statement created with old period bounds | Period bounds are derived from the terms at run time. If the terms changed mid-period, the next run will generate a new statement for the updated bounds; the old one remains until reviewed |
| No statements created for a new approval mode | Run the job manually after the change. The change handler also rebuilds projections, so an immediate run picks up the new bounds |