Org configuration, holiday calendars and schedules

Featurekamo-shared-library
Shipped
August 12, 2026 at 6:44 AM UTC
Author
Kamo
Commit
ff8cb91

TimecardOrgConfig holds the workweek, workday boundary, rounding, rule-set pointers and the review switches. Nothing in it is read at calculation time — every value is snapshotted onto a pay period when the period closes and the engine reads the snapshot, which is what lets an org change its rules without rewriting what it has already paid. TimecardHoliday is DATED, not ruled. "Fourth Thursday in November" is a rule and rules drift, so a calendar generated three years ago under a since-edited rule would silently disagree with what was actually paid. The paid/worked split is the reason the entity exists at all: holiday PAY is hours not worked, so 778.218 excludes it from the regular rate and it does not count toward the overtime threshold, while holiday hours WORKED are ordinary hours that may carry a premium. Treating them as one thing overstates the regular rate for everyone who took the day off and understates overtime for everyone who did not. TimecardSchedule is one table for both the org default and a member's override, because the resolution is "the member's row if there is one, the org's otherwise" and two tables would duplicate every column and let them drift. It is effective-dated so a schedule change in June cannot retroactively make March look like absenteeism. A schedule NEVER pays anybody. It is compared against what happened and never used in place of it — paying from a schedule is the auto-deducted lunch of shift planning. What it legitimately drives is exception detection, attendance points, open-shift alerts and predictive-scheduling premiums.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing