Seed timesheet pattern (test)
Repeats an opening week forward across a whole year, so a settlement rule can be validated before go-live — for one employee, a unit, or everyone. It can also approve the periods it seeds, so a whole setup can be checked end to end. Test workspaces only.
Why it exists
A workspace configured in September has exactly one approval period: September. There is no Q1 and no Q2, so there is no settlement chain to look at — and periods can never be created in the past, because each one opens on the previous one’s closing balance.
This job goes the other way. Enter one representative week — on the workspace start date or any later week — and let the job repeat it forward from there. Every period it creates is the newest one, so the chain is built in the order it would really have happened.
Before you run it
- Configure the rules you want to validate — the settlement policy, the time bank accounts, the employment terms with timesheet approval switched on.
- Make sure the holiday calendar covers the months you are about to seed. Days it does not cover are seeded as ordinary working days.
- Give the employee something to auto-fill onto — a default activity or a percentage allocation on their activity list. Switching the auto-fill on in the work time policy is not enough on its own; without a target the job stops rather than filling a year of blank days.
- As that employee, enter your representative week through the normal timesheet. Real entries on real activities. Start it on the workspace start date, or anywhere you like and tell the job where with Pattern start date.
Give the week some shape. A week of exact norm time produces a delta of zero in every period, so no cap is ever reached and nothing expires — the seeded year would prove nothing. Register over norm in some weeks and under in others.
The pattern
The pattern is what you typed, not something you configure. The job reads seven-day blocks from the pattern start date and repeats them forward. Leave that date empty and it starts where the workspace does — or where the employee’s employment starts if that is later, since nothing can be registered before either:
| Pattern weeks | What repeats |
|---|---|
| 1 | A weekly pattern |
| 2 | A fortnightly rotation |
| 4 | A 4-week rotation — an on-call or standby cycle |
A “week” here is seven days from the start date, not Monday to Sunday, so it works whatever weekday your workspace begins on. Weekdays are kept: a Tuesday in the pattern is always copied to a Tuesday.
Options
| Option | Meaning |
|---|---|
| Employee | Seed this one employee. |
| Org unit | Seed every employee in this unit and its sub-units. |
| All employees | Seed every employee in the workspace. |
| Months | How far forward to repeat, 0–24. Rounded outwards so every approval period it touches is filled end to end. 0 repeats nothing: the job only works on the periods the pattern itself covers — see Testing a whole setup. |
| Pattern weeks | How many seven-day blocks make up the pattern, 1–8. |
| Pattern start date | The day the pattern is read from. Leave it empty to read from the workspace start date, or the employment start if that is later. A date before either is moved up to it. |
| Overwrite existing time registrations | Replaces work time already on a target day. Off by default. |
| Auto-approve statements | Submits and approves every seeded period, oldest first, on behalf of the employee and their manager. Off by default. |
Choose exactly one of Employee, Org unit and All employees. Each employee is seeded on their own — their own pattern, employment terms and periods. With a unit or all employees, an employee who can’t be seeded (no employment terms with timesheet approval, an empty pattern window, …) is skipped and listed with the reason, and the others are seeded; with a single employee the run stops instead.
What the job does to each day
Working through the seeded range, day by day:
- A public holiday is left untouched.
- A day carrying time off is left untouched — a planned vacation in month 7 is kept as it is.
- A day that already carries work time is left alone, unless you ticked Overwrite.
- Otherwise the matching day of the pattern is copied across: registrations and check-ins/check-outs alike, at the same times of day.
- A day the pattern leaves blank gets its expected norm. On a weekend or a holiday that is zero, so those days stay empty.
Then the job evaluates allowances and overtime on every day of the periods it covers — the copied days, and days that were already there, such as registrations brought in by an import, which are otherwise not evaluated until the nightly run. Finally, for each approval period it covered, it creates the period and brings it to ready.
Submitting and approving stays with you unless you switch on Auto-approve statements — working through the periods yourself is often the point of the exercise: watch the balance chain from each period’s close into the next one’s open. With Auto-approve on, the job submits and approves each period in order, so settlement runs and the next period opens on the settled balance. It stops at a period that can’t be submitted (a blocking violation, or an earlier period still open) and reports where.
Reading the run results
| Field | Meaning |
|---|---|
source_window | The days the pattern was read from |
resolved_span | The days actually seeded, after rounding out to whole periods |
days_written | Days that received registrations |
days_skipped | Days left alone, by reason: holiday, leave, has_data, locked |
days_erased | Registrations removed by Overwrite |
days_reconciled | Days whose allowances or overtime changed when they were evaluated |
periods_ready | Periods created and brought to ready |
periods_skipped | Periods left alone — already ready, or already submitted or approved |
periods_approved | Periods submitted and approved (with Auto-approve) |
employees, employees_skipped | How many employees were seeded, and how many were skipped |
per_employee | The same counts for each employee, with the reason an employee was skipped or where their approvals stopped |
With several employees the counts are totals across all of them.
Check days_skipped.holiday against the holidays you expect in the seeded year. A count of zero over twelve months means the holiday calendar does not reach that far.
Testing a whole setup
To check that a configuration computes the right numbers, bring in test employees with a whole period of registrations — through an import, or by typing them — and run the job with:
- All employees (or the unit you are testing),
- Pattern start date on the first day of the period, and Pattern weeks covering most of it,
- Months 0, so nothing is repeated beyond the registrations you entered,
- Auto-approve statements on.
The job evaluates the allowances, approves the periods and runs the settlement, so the statements show the final balances, ready to compare with what the rules say. The implementation team runs this from a script with the workspace’s API key.
Running it again
Running the job a second time with the same options changes nothing: days that already carry data are skipped, and periods that already exist are not recreated. To reshape the year, change the pattern week and re-run with Overwrite on.
Troubleshooting
| Issue | Solution |
|---|---|
| The job is not in the list | The workspace is not marked as a test workspace |
| “no registrations between …” | The pattern window is empty — enter the week first, or point the pattern start date at the week you did enter |
| “nothing to register norm time on” | The activity list has no default activity and no percentage allocation — set one. Having the auto-fill plugin switched on in the work time policy does not by itself give it a target |
| “do not enable timesheet approval” | Switch timesheet approval on in the employee’s employment terms |
| “exactly one of employee_id, org_unit_id or all_employees” | Choose one scope: an employee, an org unit, or All employees |
| An employee was skipped | per_employee gives the reason — the same messages as in this table |
| Approvals stopped at a period | per_employee names the period and why: a blocking violation (such as a working day with no registration), or an earlier period that isn’t approved yet |
| Every period’s delta is the full worked time | The seeded days have no expected norm — check the employment terms cover the seeded year |
| Holidays were seeded as working days | The holiday calendar does not cover those months |
| A period was skipped | It was already submitted or approved; reopen it first if you meant to reseed it |