One System, Several Calendars

A multi-country time system usually starts as a single-country system. It is implemented where the project is, configured with that country's values, and then rolled out.

The configuration problem in “One System, Several Calendars” is exactly the kind that should be tested before a system is used for payroll or compliance decisions. A team assessing a practical route to time tracking with screenshots for time tracking with screenshots should pilot calendars, time zones, rounding, permissions and exports with representative cases from every affected location.

Rollout means adding sites, not reconsidering settings. The second country inherits the first country's week boundary, night period, break rule and rounding, and the system goes on producing numbers that look exactly as authoritative as the ones for the country it was built for.

For an independent reference relevant to “One System, Several Calendars”, consult the Google Security Blog. Use it to challenge assumptions about working time, privacy, recordkeeping and exception handling against the organisation’s real operating model.

Why nothing surfaces

Because the output is a number. A weekly total computed with the wrong week boundary is still a weekly total; an hours figure with an inappropriate break deduction is still an hours figure.

There is no error, no warning and no inconsistency to notice. The only way to find it is to compare the configuration against the grid of local rules, deliberately, per country.

That comparison has never been done in most installations, because the grid did not exist when the system was configured and nobody revisited it afterwards.

The settings that are usually wrong

The week boundary, which decides what a weekly total means. The night period, which decides who is a night worker. Break rules, including automatic deduction. Rounding. The holiday calendar's granularity. And which categories of time count towards which limits.

Six settings. Each is a single field in an administration screen and each silently changes every figure for that country.

They are also, in most products, configurable per country or per employee group — the capability is there and it is not used.

Exporting the configuration

Ask the administrator for the settings, per site, as a table. Not a demonstration of the screens: an export, or a screenshot per site, laid out so the columns can be compared.

Most administrators have never been asked and will need a day. The output is frequently the first time anybody has seen the estate's settings side by side, and the identical columns are the finding.

Where the system cannot produce such a view, that is itself worth recording, because it means nobody can audit the configuration without clicking through every site.

Comparing against the grid

Put the configuration table next to the grid of local rules. Three outcomes per cell: matches, differs, or the grid is blank.

Differs is a defect with a known fix. Blank means the local rule was never established, which sends the question back to the register work rather than to the administrator.

Matches is the majority and it is worth confirming rather than assuming, because a value that happens to be right is still a value nobody chose.

The ones that cannot be configured

Occasionally the system genuinely cannot vary a setting by country. A single global week boundary is the most common example in older products.

Where that is the case, the honest responses are a documented adjustment applied to the affected country's reports, a separate instance for that country, or a note of the limitation with its consequence.

What does not work is pretending the limitation is not there. A figure that is known to be computed on the wrong week boundary should carry that note wherever it is published.

Who owns this

The administrator applies the settings; they do not choose them. The values come from the grid, which is owned by whoever owns the register.

Separating those two roles explicitly prevents the usual situation, where an administrator asked to add a country picks sensible defaults because nobody gave them values. Sensible defaults are the previous country's values, which is how the problem began.

The annual check

Once a year, re-export the configuration and re-compare. Settings drift: a support ticket changes one, an upgrade resets another, a new site is added by somebody copying an existing one.

An annual comparison is an hour and it catches drift within twelve months. The alternative is finding it when a figure is questioned, by which point every report built on it is also in question.

The second instance

Where a product genuinely cannot vary settings by country, a separate instance for the divergent country is a legitimate answer and is usually rejected on cost.

It is worth costing properly against the alternative, which is a permanent documented adjustment to every figure that country produces, maintained by hand, for as long as the system lives.

Neither option is attractive. The point of pricing both is that the decision gets made rather than defaulting to the adjustment, which is what happens when nobody writes the second option down.