Shifts, Financial Years, and Custom Periods

Shift schemes#

A shift scheme belongs to a time scheme and defines the named shifts that divide its day. Once defined, the Shiftly interval becomes available, and measures at that interval aggregate over shift boundaries rather than clock hours.

A simple three-shift pattern:

The night shift crosses midnight, which is normal and is precisely why shifts cannot be expressed as a simple offset. Note how this interacts with the time scheme's hour offset: with an hour offset of 6, the production day begins with the Morning shift and the Night shift closes it, so a day's three shifts belong to the same day. With an offset of 0, the night shift is split across two days — almost never what anyone wants.

Shifts of unequal length#

Shifts do not have to be equal. A common pattern is two long production shifts and a shorter maintenance window:

This matters for anything normalised by time. A shift total is a total and needs no adjustment, but a rate per shift, or a utilisation percentage per shift, must divide by that shift's actual length. Use Period.Duration.TotalHours rather than assuming a number:

Period.Duration.TotalHours == 0 ? 0
    : Measure_3010.Value / Period.Duration.TotalHours

Hard-coding 8 will be wrong on two of the three shifts above.

Rotating patterns and crews#

Infohub's shift scheme defines the shifts of a day — the time boundaries. It does not, by itself, track which crew is on.

Where crew accountability matters, model the crew as event attributes on a shift event scheme rather than trying to encode a rotating roster into the calendar. An event scheme with a shift event carrying a Crew attribute lets you report by crew, compare crews, and handle the roster changing without touching the calendar.

That separation is worth holding onto: the calendar describes time, event schemes describe what was happening. A four-crew, twelve-hour, continental rotation is a roster, not a calendar, and trying to express it as time periods produces a scheme nobody can maintain.

See Designing an Event Scheme.

Financial years#

Set the time scheme's month offset to the month your financial year begins. A July-to-June year uses an offset of July.

Everything follows automatically: yearly measures cover July to June, quarterly measures fall on the financial quarters, and year-to-date accumulates from July.

Where both calendars are needed — operations reporting on a calendar year, finance on a financial year — use two time schemes and attach measures to whichever they belong to. This is the clearest use case for multiple schemes and worth the extra periods.

Weeks that do not fit months#

A week frequently spans a month boundary, and a week can span a year boundary. Neither is a bug, but both need a decision.

Infohub's week is defined by the day offset and runs continuously. When a week straddles two months, its values belong to that week, and the monthly measure — built from days, not weeks — is unaffected. Problems arise only when someone tries to build a monthly figure by summing weeks, which will not reconcile. Build monthly from daily.

Be aware too that week numbering near a year boundary is genuinely ambiguous: the last days of December can fall in week 1 of the following year depending on the convention. If weekly reporting across a year boundary matters, verify how your weeks are labelled and make it explicit in the report rather than assuming.

When the calendar follows no rule#

Some plants have periods that cannot be derived from offsets. A campaign-based operation, a seasonal processor, a maintenance calendar agreed annually, a retail 4-4-5 accounting period.

For these, a time scheme can be set to Manual — "manage this calendar externally (e.g. non-standard time periods)". Infohub then stops generating the periods and expects them to be supplied.

This is a genuine capability and a real commitment. When a scheme is manual:

• Periods must be maintained externally, indefinitely, by whoever owns that process.
• If periods run out, aggregation silently stops for every measure on that scheme.
• Whoever inherits the system needs to know it exists.

A rule of thumb: if the periods tile the timeline with no gaps and no overlaps, and recur on a rule, it is a calendar. If they have gaps, overlap, or are decided case by case, it is an event scheme.

Public holidays and planned shutdowns#

Neither is a calendar feature. A holiday does not change when a day starts; it changes whether production was expected.

Model them as:

• An event scheme for planned shutdowns, with attributes for reason and category, so downtime analysis can distinguish planned from unplanned.
• A manual entry measure for planned running hours or target, entered as zero for a shutdown, so availability and target comparisons behave correctly.

Both keep the calendar simple and put the information where analysis can reach it.

Diagnosing calendar and shift problems#

See also#

• Interval Types and Time Schemes
• Aggregated Measures
• Designing an Event Scheme