Leave Accrual Processing

1Purpose #

• Every leave movement is ONE row in the balance ledger, and the balance is always COMPUTED from the rows — opening + carry-over + accruals − utilization − lapse ± adjustments. Nothing stores a running balance that could drift.
• This screen writes the ACCRUAL rows: for each employee's assigned policy it walks the employee's leave year (hire-date anniversary to anniversary) in the policy's accrual steps and posts what the matching service band earns per period.
• The leave year is ANCHORED TO THE HIRE DATE (DOJ) — each employee has their own year, ending on their joining anniversary. The window's start is clamped to the policy assignment's effective date, so a mid-year assignment accrues only from its effective date.
• Only COMPLETED periods post. Future periods of the running year appear in the preview as Projected so the year's full picture is visible, but they are never written — the ledger holds facts, not forecasts.
• The year close writes the hand-over between leave years: a CARRYOVER row (the closed year's balance, capped by the band's carry-over limit; zero when the policy does not carry over) opens the new year, and — when setting 172 is on — a LAPSE row writes off the remainder above the cap.
• Setting 171 ( Leave Accrual Posting Mode ) is honoured: in Manual mode this page's Post button is the only writer. Automatic mode (a background scheduler) is a future phase — the page warns when it is configured, and posting from here still works.

2The posting vocabulary #

Every ledger row carries its movement in PostingMethod :

PostingValueType keeps the legacy direction words ( Opening / Earned add, Deducted subtracts) so balance queries written against the legacy ledger still work; ENCASHMENT is reserved for a later phase (setting 173).

3Your first accrual run, step by step #

1. Make sure the ground is laid: leave policies exist (Leave Policy master, with eligibility bands) and employees have policy ASSIGNMENTS (Employee master's Leave Policies dialog, or Batch Assignment).
2. Leave the as-of date at today (accruals whose period ends by then are due), or set a past date for a historic catch-up.
3. Narrow the scope if you want — one policy, or one employee — or leave both blank for everyone.
4. Press Preview (F2) . Every row says what it is: Due (will post), Already posted (skipped on re-run), Projected (period not finished — preview only). The notes under the grid explain employees that were skipped entirely.
5. Tick year close only when you also want to close leave years that have ended — typically once a year, after the last accrual run of the old year.
6. Press Post (F5) and confirm. Everything writes in ONE transaction; the banner reports honest counts — posted, skipped, carry-overs and lapses.
7. Check the result on the Leave Balance page.

4Field details #

• As-of date — periods ending on or before this date are DUE; later periods of the running leave year show as Projected. Also decides which leave years count as "ended" for the year close.
• Policy / Employee — optional narrowing; blank means every policy / every assigned employee. Clear a pick with the ✕ in the box.
• Year close — posts CARRYOVER (always, even 0 — it doubles as the idempotent "year closed" marker) and LAPSE (only when setting 172 is on) for each scoped employee+policy whose leave year has ended by the as-of date. A year already closed is skipped.
• Period End — the accrual's posting date AND its identity: one ACCRUAL row per employee + policy + period-end date, enforced by the ledger's primary key.
• Value — what the employee's service band earns for that period; the last period before an accrual cap is clamped to the remaining headroom.

5Shortcut keys #

• F2 Preview · F5 Post · Esc Reset the preview.
• Enter moves to the next field.
• Keys belong to the focused copy of the page; a dialog's own keys win while it is open.

6Why is a pick-list empty? #

• Policy lists the Leave Policy master — created on the Leave Policy page (PAY-06). No policies means none were created yet.
• The preview is empty when no assignment matches the scope: assign policies first (Employee master or Batch Assignment), and check the notes — employees without a hire date, or flagged exclude from leave processing , are listed there.

7Rules and integrity #

• One transaction. The post commits or rolls back as a whole.
• Never twice. One ACCRUAL row per employee + policy + period end — the ledger's primary key (employee, date, policy) makes double-posting physically impossible; re-runs skip and say so. The legacy engine instead DELETED and re-inserted the whole window on every run, rewriting history — the port never mutates posted rows.
• Facts only. Projections are preview-only. The legacy wrote Projected rows into the ledger and even counted them into carry-over; the port's year close counts real movements only.
• Caps. MaxAccruedValue caps a year's accrual (opening credit counts against it); MaxCarryOverLimit caps the year-close carry-over; -1 means uncapped. A policy without carry over to next year carries nothing.
• Service bands. The band (by service duration at the period end) decides the per-period value; a first-day joiner matches a 0-based band (the legacy skipped service-duration 0 — fixed here).
• Missing hire date. The employee is skipped with a note (the legacy substituted year 0900 and accrued centuries).
• Deleting a policy with postings is refused by the database; deleting an employee's ledger account deletes the leave history with it.

8If something does not work #