Leave Policy

1Purpose #

• Defines the earning rules for ONE leave type — Annual Leave, Sick Leave, Casual Leave each get their own policy.
• Accrual processing reads the policy to post leave earned; leave requests and settlements read it to know the balance rules.
• It does not give anyone leave by itself: leave is only earned where the policy has been assigned to the employee (the Employee master's Leave Policies action, or Batch Assignment). Shared does not change that — see Field details.

2How a policy works #

Why the service bands exist. Companies rarely give everyone the same leave: entitlement usually grows with years of service or seniority. Rather than one figure per policy, the Service Eligibility Bands table lets you say how much leave each length of employment earns, and every employee on this policy is paid from the band their service length falls in.

A worked example. Take a band with From 3 , To 6 , Duration In Month(s) and Value Accrued 5 . While an employee's service is between three and six months, every accrual period credits 5 to their leave account. Once their service passes six months that band stops matching, and whichever band covers their new service length takes over — so bands of 3-6, 6-12 and 12-99 months step the entitlement up as they stay.

How the pieces chain together.

• You define the policy here: its leave type, how often it accrues, whether it carries over, and the service bands.
• The policy is assigned to an employee (Employee master → Leave Policies, or Batch Assignment). Nothing is earned before this.
• The Leave Accrual Processing page runs the accrual: for each completed period in the leave year it posts one ACCRUAL row of the matching band's Value Accrued, up to that band's Max Accrued. At the year close it posts the CARRYOVER row (capped by Max Carry Over) and, where the settings say so, a LAPSE row for what is not carried.
• Manual Leave Posting is where you add the entries the engine does not produce: an OPENING balance for staff who joined with leave already banked, and ADJUSTMENT corrections either way.
• The Leave Balance page adds it all up for the active leave year: opening + carry-over + accrued − utilized − lapsed + adjustments .
• A leave request spends that balance: on final approval it writes a UTILIZATION row for the approved days, which is the “utilized” term above.

So this page sets the rules, Leave Accrual Processing turns them into entries, Manual Leave Posting fills the gaps, Leave Balance reports the result, and leave requests draw it down.

3Your first leave policy, step by step #

Before starting here, make sure a leave attendance type exists (the Attendance Type master) — a policy's whole point is to feed one, and the Leave Type picker on this page reads from that master.

Suppose staff earn 30 days of annual leave a year, accrued monthly, once they have completed a year of service. The page opens in Add mode.

1. Type Annual Leave Policy into Policy Name . It is required and must be unique — it is the name assignments and postings will carry.
2. Pick the leave's attendance type — say Annual Leave — in Leave Type .
3. Switch Is Accrued ON and pick Accrued Every Month — the eligibility grid's Value Accrued header follows that choice, so it now reads "Value Accrued On Every Month". Accrual Year Begins is meant to say when the leave year and carry-over start, but it is recorded and not acted on — the leave year always runs from each employee's own joining-date anniversary.
4. Decide the year-end: Carry Over To Next Year ON lets unused leave survive into the next year, capped by the band's Max Carry Over.
5. Under Service Eligibility Bands press Add Band : From 1 , To 99 , Duration In Year(s) , Value Accrued 30 , Value Period Year(s) . That reads: from one year of service on, 30 days a year. Add more bands to grow the entitlement with seniority — each band's To must be different.
6. Shared Policy can stay OFF: it only widens the policy pick-list on the old desktop screens and never assigns the policy to anybody.
7. Press Save (F5) and confirm. The policy and its bands are saved together — if anything is wrong, nothing is half-saved.
8. Now assign it — this step is what actually gives leave: open the Employee master, pick an employee, and use the Leave Policies action to add this policy with an effective date (or use Batch Assignment for many at once). No assignment, no accrual, Shared or not.

4How to use it #

1. Find (F2) lists every policy; pick one to load it with its bands.
2. Add (F3) starts a new policy with the cursor in Policy Name.
3. Add Band appends an eligibility band; Remove marks one for deletion on the next save.
4. Save (F5) commits the policy and its bands together in one transaction.

5Field details #

• Policy Name is required and unique — assignments, postings and requests all reference the policy by this name.
• Leave Type is the attendance type this policy feeds, from the Attendance Type master.
• Accrual Year Begins was meant to choose when the leave year and its carry-over start — the legacy caption reads "Start carry over on (1st day of month selected or Anniversary of Date of Join)" — but it is stored and not used . The legacy calculation read the column and then ignored it, and the port mirrors that: the leave year always runs from the employee's joining-date anniversary. Old rows may show From Hire Date — the original default, kept readable.
• Accrued Every is the accrual posting period — Day up to Year. This one is acted on: it is the step the engine walks the leave year by, posting one entry per completed period.
• Is Accrued describes the policy — leave built up period by period rather than granted up front — and is shown as such on the balance and leave-request screens. It is not a gate here: accrual processing posts from the bands regardless, and the balance check on a leave request is governed by payroll setting 174, not by this switch. (The legacy desktop approval form did use it to decide whether to check the balance.)
• Carry Over To Next Year ON: at year close the leftover balance is opened as the next year's balance, capped by the matching band's Max Carry Over (-1 = the whole balance). OFF: the cap is zero, so nothing carries. Whatever is not carried is written off as a lapse only when payroll setting 172 says so; otherwise it simply stays on the closed year's record.
• Carry Over Balance To Next Payroll Period is stored but unused — no calculation, report, stored procedure or view reads it, in this app or the legacy one. It is saved with the policy and nothing else happens.
• Calculate For Balance Days (the legacy caption for the column, kept because it is the clearer one) is about the days left over between two accrual periods. Accrue monthly with the value falling on the 15th, run processing on 10 June, and 26 days sit outside any completed period — 16 in May and 10 in June. The legacy engine credited them as an extra part-period row ("Earned … upto <today>"), prorating the period value by the days elapsed. The port deliberately does not: only completed periods are posted, and the running part-period shows in the accrual preview as Projected instead of entering the ledger. So the switch is stored for the old screens and has no effect in this app . It is hidden when Accrued Every is Day — a daily step leaves no balance days — exactly as the legacy form hid it.
• Bands : From/To bound the service duration (in Duration In units; To 0 = unlimited); Value Accrued is the leave earned per Value Period, and its column header follows Accrued Every ("Value Accrued On Every Month") as the legacy grid did; Max Carry Over caps the carry-over (-1 = entire balance); Max Accrued caps the total (-1 = unlimited).

6Shortcut keys #

• F2 Find · F3 Add · F4 Modify · F5 Save · Esc Cancel.
• Enter moves to the next field; off the last band cell it appends a new band.
• Keys belong to the focused copy of the page; a dialog's own keys win while it is open.

7Why is a pick-list empty? #

• Accrual Year Begins , Accrued Every and the band duration pickers are fixed lists and are never empty.

8Rules and integrity #

• Unique name. Policy Name is the table's primary key, so it is checked before saving and again on the server.
• Unique To-limit. The band table's key is policy + To limit, so the same To value cannot appear on two bands — checked here and on the server with the same message.
• Bands save row by row. Editing a policy does not delete and re-insert its bands, so their identities survive an edit.
• The policy and its bands save in one transaction : if a band fails, the policy changes roll back with it.
• Renames propagate. Assignments, postings, settlement adjustments and the bands all follow a rename automatically — but the database refuses the rename while leave requests or approvals still reference the policy.
• Deletes are guarded. Deleting a policy removes its bands with it, but the database refuses the delete while assignments, postings, requests or settlement adjustments still reference it.