Oracle HCM Absence
Management

• Leave Request Workflows: Employees submit requests through Self Service. Configurable multi-level approval chains (manager → HR → director) via Oracle BPM Worklist ensure the right people review the right requests.
• Automatic Accruals: Calendar-based or service-based accruals run on a scheduled basis — Oracle calculates exactly how much leave is earned each period using Fast Formula logic.
• Balance Consumption & Carryover: As leave is approved, balances are updated in real time. Carryover rules determine how much unused leave moves to the next period and when any forfeiture occurs.
• Payroll Integration: Approved absences automatically create payroll element entries — paid leave creates an earnings element, unpaid leave creates a deduction element — which are picked up in the next payroll run.
• Statutory Compliance: Supports legislated leaves (FMLA in the US, UAE Annual Leave under Decree 33, KSA Labour Law sick leave) with built-in entitlement rules and certification tracking.
• Manager & HR Dashboards: Real-time visibility into team absence patterns, pending approvals, balance exceptions, and accrual projections.

• Absence Plans: The master configuration objects — define accrual method, entitlement limits, carryover rules, and payroll integration for each leave type.
• Absence Types: The specific leave categories employees select when submitting (e.g., Annual Leave, Sick Leave, Emergency Leave) — each linked to an Absence Plan.
• Accrual Fast Formulas: Oracle Fast Formula scripts that calculate exactly how much leave is earned each accrual period, taking service length, FTE, and grade into account.
• Validation Formulas: Formulas that check eligibility rules before a leave request can be submitted — e.g., minimum notice period, probation restrictions.
• Certification Requirements: Document upload rules attached to specific absence types (e.g., medical certificate for sick leave beyond 3 days).
• Approval Workflows: BPM-based rules determining who approves which leave types and under what conditions.
• Balance Definitions: Define what contributes to a balance (accruals, adjustments, carryover) and what consumes it (approved absences, forfeiture).

An Absence Plan is the top-level configuration object that defines the complete policy for a leave type. Think of it as the rulebook for how that leave category works. It contains:

• Classification: Vacation, Sick, Other (determines default behaviours).
• Accrual Method: How leave is earned — Periodic (fixed amount per month/quarter) or Service-Based (increases with tenure).
• Entitlement: Maximum leave allowed per period (e.g., 30 calendar days per year for UAE annual leave).
• Carryover Rules: Maximum days/hours that carry to the next year, expiry date for carried balance.
• Negative Balance: Whether employees can go into deficit (soft warning or hard block).
• Payroll Element Link: Which payroll element is triggered when this leave is approved — ensuring pay is calculated correctly.
• Eligibility: Which employees the plan applies to — configurable by department, grade, employment type, or nationality.

The relationship is hierarchical: the Absence Plan is the overarching policy framework and the Absence Type is the specific employee-facing leave category within it.

For example, a single "Vacation Policy" Absence Plan may contain multiple Absence Types: Paid Annual Leave, Unpaid Annual Leave, and Annual Leave Cash-Out. Each type inherits the plan's accrual and carryover rules but can have its own payroll element, approval workflow, and certification requirements.

From the employee's perspective, they see and select Absence Types in self-service. From the administrator's perspective, they configure the Absence Plan and then define which Types sit beneath it. This separation allows flexible policy design — one plan can cover multiple pay scenarios without duplicating the entire accrual configuration.

Absence Classifications are system-level categories that group leave types by their nature and default behaviours. Oracle provides the following standard classifications:

• Vacation: Standard paid annual leave. Supports accruals, carryover, and encashment.
• Illness: Sick leave — can be paid (full/partial salary) or unpaid. Often requires medical certification.
• Maternity/Paternity: Parental leave with statutory entitlement and payment percentage rules.
• Jury Duty: Statutory leave for court attendance — typically no accrual, just entitlement.
• Bereavement: Short-duration compassionate leave — usually non-accrual with a fixed number of days.
• Training: Authorised learning leave — may be paid or unpaid depending on policy.
• Other: A flexible catch-all for custom leave types not covered by standard classifications.

The classification drives default settings — Oracle pre-configures pay percentage, carryover eligibility, and reporting groupings based on classification. You then customise further within the plan configuration.

Periodic Accrual grants a fixed, consistent amount of leave each period regardless of how long the employee has been with the company. For example, every employee accrues 8 hours per month (= 12 days per year). This is straightforward to administer and is common for sick leave or PTO plans where tenure doesn't change the rate. Oracle runs the accrual process on a schedule and credits the balance directly.

Service-Based Accrual awards increasing entitlement as employees build seniority. For example: 0–2 years = 15 days/year, 3–5 years = 20 days/year, 5+ years = 25 days/year. This requires a Fast Formula that calculates years of service from the hire date, then maps to the corresponding accrual rate. The formula also handles part-time employees by multiplying by the FTE factor. Service-based accruals are more complex but reflect the labour law requirements in many GCC countries and typical retention-reward structures in multinationals.

Carryover rules govern what happens to unused leave at the end of an accrual period (typically year-end). The configuration options are:

• Maximum Carryover: The ceiling on how many days/hours can be rolled forward (e.g., max 10 days). Anything above this is subject to the excess rule.
• Carryover Expiry Date: The date by which carried-over leave must be used (e.g., must be used by 31 March). After expiry, the balance is forfeited or cashed out.
• Forfeit on Expiry: Unused carried-over balance is simply lost — common in "use it or lose it" policies.
• Cash-Out on Expiry: Unused carried balance triggers a leave encashment payment — Oracle creates a payroll element entry for the cash equivalent.
• Unlimited Carryover: No cap — employees can accumulate all unused leave indefinitely (less common; creates large accrued liability for finance).

In UAE, under the Labour Law, employees are entitled to carry forward up to 30 days of annual leave and must use it within 18 months — any configuration should reflect this statutory minimum.

Database Items are Oracle's pre-built variables that give Fast Formulas access to live HCM data without SQL. Key DBIs for absence accrual:

• ASG_HIRE_DATE — Employee's original hire date. Used to calculate years of service and probation period eligibility. Always set a DEFAULT in case the date is missing to prevent formula failures.
• ASG_FTE_VALUE — Full-Time Equivalent (1.0 = full-time, 0.5 = half-time). Multiplied into accrual to prorate leave for part-time employees. A value of 0 will result in zero accrual, which is sometimes the cause of "no accrual" issues.
• ASG_WORK_DAY_HOURS — The standard number of hours in an employee's work day (typically 8). Used to convert between days and hours in the accrual formula.
• ASG_SCHEDULED_HOURS — Weekly scheduled hours. Useful for irregular shift workers where daily hours vary.
• ABSENCE_BALANCE_VALUE — The employee's current absence balance. Can be used in formulas to implement maximum balance caps — if current balance is already at the plan ceiling, stop accruing.

Waiting for the scheduled accrual process to run is impractical during configuration and testing. Oracle provides several ways to test accruals on demand:

• Run Accruals Process (Test Mode): Submit the "Calculate Absence Accruals and Balances" process with the Test Mode flag enabled. This calculates accruals and shows results in the log but does not commit balance updates to the database — ideal for validating formula logic.
• Quick Accrual for Single Employee: From the Absence Administration work area, run "Process Absence Balance" for a specific employee and period. Results can be viewed immediately in the "Absence Accrual Details" report without affecting other employees.
• Fast Formula Test: Navigate to Fast Formulas → select the formula → use the "Test Formula" feature. Input test values for DBIs (hire date, FTE) and verify the formula returns the expected monthly accrual amount.
• Absence Accrual Details Report: After any accrual run (test or live), this OTBI report shows the exact calculation — accrual band triggered, FTE factor applied, and final hours credited — for full auditability.

These two formula types serve entirely different purposes in the absence lifecycle:

Accrual Formula runs during the scheduled accrual process (typically monthly or at period end). Its job is to calculate how much leave to add to the employee's balance. It reads hire date, FTE, service length, and grade — and returns a number (hours or days to credit). It runs in the background, not triggered by the employee at all.

Validation Formula runs at the moment an employee submits a leave request in self-service. Its job is to check whether the request is eligible before it proceeds to the approval workflow. Examples:

• Is the employee still in their probation period? If yes, block annual leave requests.
• Is the requested duration within the maximum consecutive days allowed?
• Has the employee given the required advance notice (e.g., 7 days for vacation)?
• Does the employee have sufficient balance to cover the requested dates?

The validation formula returns a Y/N flag — if N, the request is blocked with an error message shown to the employee.

Absence approval rules are configured through Oracle BPM Worklist accessed via the Manage Absence Approval Rules task. The configuration layers are:

• Rule Conditions: Define which requests trigger which approval path. Conditions can evaluate absence type, duration, employee grade, department, or absence category. Example: IF absence_duration > 5 days AND absence_type = "Annual Leave" THEN require HR approval in addition to manager.
• Approval Stages: Multi-level workflows can be built — Stage 1: Line Manager, Stage 2: Department Head (only triggered for absence > 10 days), Stage 3: HR for statutory leaves.
• Auto-Approve Rules: Short absences (e.g., 1 day sick leave) can be configured to auto-approve, reducing administrative overhead while retaining records.
• Delegation: Managers can delegate approval authority during their own absence — Oracle routes pending requests to the delegate automatically.
• Escalation: If no response within a configured number of days, the request can auto-escalate to the next level or auto-approve depending on policy.
• Notifications: Email and bell notifications are sent to approvers, requesters, and HR at each stage via Oracle Workflow Notification Composer.

A Certification Type defines a supporting document or formal declaration that must be submitted alongside certain absence requests. It is configured under Manage Certification Requirements and attached to an Absence Type. Configuration options include:

• Certification Name: E.g., "Medical Certificate", "Death Certificate", "Court Summons".
• Required For: Triggered based on absence duration (e.g., required if sick leave exceeds 3 consecutive days) or always required regardless of length.
• Upload Method: Employee uploads the document as an attachment through the absence request form. HR can review and validate.
• Submission Deadline: Oracle can enforce a deadline for document submission — for example, medical certificate must be submitted within 3 days of return from sick leave. Overdue submissions trigger reminders.
• Impact on Approval: Absence can be configured to require certification before the approval workflow can complete, preventing final approval until the document is received.
• Periodic Certification: For long-duration absences (e.g., extended sick leave), Oracle can require a new certificate every N days — keeping the medical status current throughout a prolonged absence.

Yes. Oracle provides several mechanisms for bulk absence management from the manager's perspective:

• Manager Dashboard — Team Absence Requests: A dedicated infolet/tile shows all pending absence requests from the manager's team. The manager can select multiple requests and approve or reject them simultaneously with a single action and a bulk comment.
• Absence Calendar View: Before approving, managers can switch to the team calendar to see who else is already on leave during the requested period — critical for managing coverage risk. Colour-coded by person and absence type.
• BPM Worklist Bulk Actions: From the BPM Worklist task list, managers can filter all absence approval tasks and use bulk action to approve multiple items at once.
• HR Administrator Bulk Approval: HR Administrators can process absence requests for a group of employees using the "Manage Absences" task — useful for back-processing historical absences or handling exceptions during migration.
• Mobile Approvals: Oracle Mobile (iOS/Android) supports push notifications for absence approvals — managers can approve on the go without logging into the full application.

An employee's current absence balance at any point is computed as:

Current Balance = Opening Balance (Carryover) + Total Accruals to Date − Total Approved Absences − Any Forfeiture

Oracle maintains several balance components:

• Opening Balance: The carried-over amount from the previous period, subject to the plan's carryover maximum.
• Accrued Balance: Leave earned so far in the current period through the accrual process.
• Consumed Balance: Total approved leave taken in the current period.
• Pending Balance: Leave in submitted-but-not-yet-approved requests — reduces the "Available" balance shown to employees to prevent over-booking.
• Available Balance: What the employee can actually request right now = Accrued − Consumed − Pending.

Balances update in real time when absences are approved or accrual processes run. Employees can view their balance breakdown in Employee Self Service.

Negative Balance control determines whether an employee can submit a leave request that would take their balance below zero. Oracle provides two modes:

Hard Limit (Block): Oracle prevents submission entirely if the requested days exceed available balance. The employee sees an error: "Insufficient balance — you have X days available but requested Y days." This is the default for annual leave in most GCC companies.

Soft Warning (Allow with Note): The system warns the employee that their balance is insufficient but allows submission to continue. The request proceeds through the normal approval workflow. The manager sees the balance deficit flagged on the approval screen. This is common for sick leave — companies don't want to block an employee from calling in sick just because their balance is low.

Unlimited Advance Leave: Some plans allow advance drawing of future accruals (e.g., an employee can take their full year's entitlement in January even though only 1/12 has accrued). The plan is configured with a maximum advance limit (e.g., max 10 days advance).

When a company goes live on Oracle Absence Management mid-year, employees already have leave balances that must be loaded into the system. This is called Balance Initialization:

• HDL (HCM Data Loader): The primary method for bulk loading. Use the AbsenceBalance business object to load opening balances with the employee ID, plan, effective date, and balance amount. Files are uploaded through the HCM Data Loader UI.
• Spreadsheet Data Loader (SDL): For smaller employee populations, Oracle provides an Excel-based loader template that uploads via the UI without needing to build HDL DAT files — easier for HR teams without technical support.
• Manual Adjustment: For individual adjustments, HR Administrators can use "Manage Absences" → "Adjust Balance" to add or subtract hours/days from a specific employee's plan balance directly in the UI.
• Effective Dating: All initialization entries should be effective-dated to the go-live date to ensure accruals from that date forward are calculated correctly without double-counting.

Inaccurate opening balances are one of the most common post-go-live issues — rigorous validation against the legacy system is essential before cutover.

In the context of balance management, Absence Certifications act as control gates that prevent balance consumption until documentation is verified. Key scenarios:

• Sick Leave Verification: An employee submits 5 days sick leave. Balance is immediately deducted upon approval. However, if the employee fails to submit a medical certificate within the required timeframe, HR can reject the sick leave and convert it to unpaid — triggering a payroll adjustment.
• Periodic Certification for Long Absences: For extended sick leave (e.g., 60 days), Oracle can require a new doctor's note every 30 days. The system triggers a task to the employee and sends reminders. If not submitted, the absence can be flagged for HR review. This prevents a single certificate being used to cover an indefinite absence.
• Certification-Gated Approval: Some plans are configured so that the approval workflow cannot reach the final "Approved" status until the document has been uploaded and HR has marked it as verified — the balance is only consumed after full certification.

The unpaid leave deduction calculation uses this formula:

Deduction Amount = (Monthly Salary ÷ Working Days in Month) × Number of Unpaid Days

Example: Employee earns AED 10,000/month. Month has 22 working days. Employee takes 3 days unpaid leave.
Deduction = (10,000 ÷ 22) × 3 = AED 1,363.64

Oracle generates a negative earnings element (or a dedicated deduction element, depending on configuration) for this amount. The element is picked up in the payroll run and reduces gross pay accordingly. The choice of working days basis (calendar days vs scheduled working days) is configurable per plan and must align with the company's payroll policy. In GCC, many companies use calendar days (30) as the denominator to simplify calculations and align with the standard GCC salary calculation norm.

When Oracle Payroll and Oracle Absence Management are on the same Fusion instance, absence-payroll integration happens automatically through shared data — no extract is needed. However, in a hybrid environment where Oracle Absence Management is used with a third-party payroll system (SAP, ADP, or a regional payroll processor), the Absence to Payroll Extract is required. This process:

• Queries all approved absences within the payroll period that have not yet been sent to payroll.
• Generates a structured output file (XML, CSV, or flat file) containing employee ID, absence type, dates, hours, and the corresponding pay instruction.
• The file is transmitted to the external payroll system via SFTP or API for processing.
• After processing, the extract marks the absences as "sent" to prevent duplicate transmission.

Even in full Oracle environments, some organisations run the extract as an audit file to verify what absence data was included in a specific payroll period.

Oracle HCM has dedicated support for FMLA (US-specific federal leave law) built into the Absence Management module. Key capabilities:

• Eligibility Tracking: Oracle automatically checks the two FMLA eligibility criteria — employee has worked for the employer for at least 12 months, and has worked at least 1,250 hours in the past 12 months — and flags eligibility on the absence request.
• 12-Week Entitlement: The system tracks FMLA consumption against the 12-week annual entitlement. Once exhausted, further requests are automatically coded as non-FMLA.
• Rolling 12-Month Period: Oracle supports all four FMLA calculation methods — calendar year, fixed fiscal year, 12-month period from first FMLA use, or rolling 12-month period — configurable at the plan level.
• Intermittent Leave: FMLA can be taken in small increments (hours, half-days) rather than in one continuous block — Oracle tracks these fragmented uses cumulatively against the 12-week bank.
• Concurrent Leave: FMLA typically runs simultaneously with company-sponsored parental or medical leave — Oracle manages the concurrent counting so total entitlement is not exceeded.
• Notice and Certification: The system generates FMLA designation notice templates and tracks employee certification submission deadlines.

Parental leave configuration in Oracle involves:

• Statutory Entitlement: Defined per country legislation. In UAE, maternity leave is 60 days (45 days full pay + 15 days half pay under Decree 33). In KSA, 10 weeks for working mothers. The plan configuration reflects these statutory minimums as the entitlement.
• Payment Phases: Maternity pay often changes across the leave duration. Oracle supports tiered payment percentages — e.g., 100% salary for weeks 1–6, 60% for weeks 7–12. Each phase is configured as a separate element entry with its own pay percentage, or via a fast formula that checks elapsed duration and returns the correct payment amount.
• Certification Required: A birth certificate or expected delivery certificate is typically required. Oracle enforces document submission before final leave approval.
• Paternity Leave: Typically shorter (5 days in UAE, 3 days in KSA). Configured as a separate absence plan/type with its own entitlement and pay rules.
• Keep-in-Touch: Oracle supports recording "keeping in touch" days where an employee on maternity leave can work a limited number of days without forfeiting their leave entitlement.
• Return-to-Work: The system tracks expected return dates and can trigger tasks to HR for role reinstatement and any flexible working arrangements.

Oracle's UAE-localised absence configuration should reflect Federal Decree Law No. 33 of 2021:

• First Year: Employees who complete 6 months of service are entitled to annual leave on a pro-rata basis.
• Full Entitlement: 30 calendar days of paid annual leave per year once the first year is completed.
• Minimum Entitlement: During the first year (after 6 months), leave is pro-rated based on months worked.
• Salary During Leave: Decree 33 specifies that the employee must receive their salary before commencing annual leave — this affects the payroll element timing (advance pay may need to be configured as an off-cycle element).
• Carryover: Unused leave can be carried forward, but must be used within the period agreed with the employer. The employer cannot forfeit leave without compensation.
• Leave Encashment at Termination: All accrued, unused annual leave must be paid out at termination based on the last basic salary (or gross wage, per company policy).

The absence plan for UAE annual leave should have: 30-day entitlement, 6-month probation restriction on the validation formula, and a payroll link for both paid leave and encashment.

When two statutory leaves apply simultaneously — for example, an employee is on FMLA and company parental leave at the same time — Oracle manages this through concurrent leave tracking and priority rules:

• Plan Precedence: The Absence Plan can be configured to run concurrently with another plan. When both plans are triggered, Oracle tracks consumption against each separately but ensures the employee is not paid twice for the same calendar day.
• FMLA Concurrency: US FMLA regulations require that qualifying company leave run concurrently with FMLA — Oracle ensures the 12-week FMLA bank is consumed even when the employee is on a paid company-sponsored plan.
• Pay Coordination: When multiple plans overlap, payroll integration must account for the combined payment. Oracle's element priority and costing rules ensure the correct net pay is computed — typically the higher of the two entitlements, not the sum.
• Reporting Compliance: The system generates combined absence history showing both plans active simultaneously — important for compliance reporting and HR record-keeping.

Absence Patterns are a configuration feature for employees who require recurring, intermittent time off on a regular schedule — as opposed to discrete individual leave requests. Common use cases include:

• Medical Treatment: An employee undergoing weekly chemotherapy needs every Tuesday afternoon off. Rather than submitting individual requests, a single Absence Pattern records this as a recurring absence — reducing administrative overhead and ensuring balances are correctly consumed over time.
• Intermittent FMLA: US employees on intermittent FMLA often have predictable medical appointment schedules. Patterns capture these recurring blocks and accumulate them against the 12-week bank automatically.
• Part-Time Work Arrangements: An employee approved for a temporary reduced-hours arrangement (e.g., 3 days/week during parental transition) can have this reflected as a recurring absence pattern rather than manually requesting every absent day.

Patterns define the recurring schedule (daily, weekly, specific days of the week), the hours per occurrence, and the duration of the pattern (start/end date). Oracle processes the pattern through the standard accrual and balance consumption logic.

Oracle Absence Management uses the employee's assigned Work Schedule to accurately calculate the duration of absences and accruals:

• Duration Calculation: When an employee submits a leave request for a date range, Oracle calculates the actual working hours/days within that range based on their work schedule — weekends and non-working days are automatically excluded. This prevents situations where an employee's 5-day vacation spans a weekend and gets charged 7 days.
• Part-Time Proration: Employees on 50% schedules (e.g., 4 hours/day) consume their leave balance at half the rate of full-time employees — the work schedule drives this automatically through the ASG_FTE_VALUE and ASG_SCHEDULED_HOURS DBIs.
• Shift Workers: Employees on rotating shifts may have variable daily hours. Oracle uses the actual scheduled hours for each day of absence from the shift calendar rather than a fixed standard hours value.
• Work Schedule Changes: When an employee moves from full-time to part-time mid-year, Oracle's effective-dating ensures their future accruals are prorated from the schedule change date, and past accruals remain unchanged.

A Holiday Calendar (or Work Calendar) in Oracle defines official public holidays and company-wide non-working days. Its integration with Absence Management determines whether public holidays falling within a leave period are counted against the employee's balance:

• Public Holidays Excluded: Most companies configure absence plans so that if a public holiday falls within an approved leave period, that day is not deducted from the leave balance. Example: an employee takes 5 days annual leave that includes a national holiday — Oracle only deducts 4 days from the balance.
• Public Holidays Included: Some plans (particularly for shift-based industries) count all calendar days including holidays. The plan configuration determines this behaviour.
• Country-Specific Calendars: In a multi-country deployment, different holiday calendars apply per LDG or legal entity — UAE national day doesn't affect KSA employees and vice versa. Oracle routes the correct calendar based on the employee's assigned work location and legal employer.
• Ad-Hoc Company Holidays: One-time company holidays (e.g., an additional day declared by the CEO) can be added to the calendar and are immediately reflected in absence duration calculations for any future approved leave that spans that date.

Oracle Transactional Business Intelligence (OTBI) provides three primary subject areas for absence reporting:

• Workforce Management — Absence Real Time: The most commonly used subject area. Covers absence requests (status, type, dates, duration), approval history, and current balances per employee. Used to build request status dashboards, pending approval reports, and absence frequency analysis.
• Workforce Management — Absence Accrual Real Time: Focuses on accrual details — how much was accrued per period, by which formula, for which plan. Used to audit accrual calculations, verify FTE adjustments, and investigate balance discrepancies.
• Workforce Management — Workforce Absence: A broader subject area that joins absence data with assignment and employment attributes — department, grade, job, manager hierarchy. Enables cross-dimensional analysis: "Which departments have the highest absence rate?" or "What is the average sick leave by grade?"

OTBI reports are ad-hoc and real-time — no scheduled extract required. They can be exposed on HCM dashboards as tiles or shared as scheduled report subscriptions.

• Absence Balance Report: Shows each employee's current accrued, consumed, and available balance for every enrolled plan. Used by HR for year-end audits and employee queries. Available per employee or in bulk for a full department.
• Absence Calendar (Team View): Visual calendar showing all approved absences across a team for a month. Used by managers for planning coverage. Can be overlaid with public holidays and scheduled headcount requirements.
• Absence Liability Report: Used by Finance — calculates the monetary value of all accrued but unused leave across the organisation. Formula: unused_days × daily_salary per employee, summed to department and total. Critical for annual financial provisioning and audit compliance.
• Absence Frequency Analysis: Identifies patterns — employees with frequent 1-day absences, absence clustering around weekends (Monday/Friday absenteeism). Used by HR to flag potential absence management concerns.
• Accrual Audit Report: Shows the detailed accrual calculation for each employee and period — formula band triggered, FTE factor, hours credited. Used to investigate balance disputes.
• FMLA Tracking Report (US): Compliance report showing FMLA-eligible employees, hours consumed, remaining entitlement, and certification status — required for DOL audit readiness.

Oracle HCM provides a configurable Absence Management Dashboard with pre-built infolets that give real-time visibility at a glance:

• Absence Requests Pending Approval: A count of requests awaiting the manager's action, with a quick-link to the approval queue. Displayed on both the manager's home page and the HR specialist's dashboard.
• Team Absence Summary: A visual indicator of how many team members are currently on leave — critical for managers monitoring daily coverage. Drill-down shows names, absence type, and return date.
• Leave Balance Exceptions: Flags employees whose accrued balance has hit the plan maximum (and is being forfeited), employees with zero balance who have submitted requests, or employees approaching carryover expiry with large unused balances.
• Accrual Projections: Shows what an employee's balance will be by year-end if current usage patterns continue — useful for proactive leave planning conversations between managers and employees.
• Certification Overdue: Lists employees who have approved absences with overdue certification submissions — enabling HR to follow up before payroll runs.

Infolets are personalised per role — employees see only their own data, managers see their team, and HR sees the full organisation.

The Absence Plan is the policy framework — it defines the rules for accrual method, entitlement limits, carryover, payroll integration, and eligibility. It is the "engine" behind a leave category. An employee is enrolled in a Plan.

The Absence Type is the employee-facing label they select in self-service (e.g., "Annual Leave", "Sick Leave", "Emergency Leave"). Multiple Types can sit under one Plan — for example, "Paid Annual Leave" and "Unpaid Annual Leave" both belong to the "Annual Leave Plan" but behave differently at the payroll integration level.

The practical implication: if you need to change accrual rules for all leave types under a plan, you update the Plan once. If you need to change which document is required for one specific leave type, you update that Type's certification configuration without touching the Plan.

Pro-rated accruals for mid-year joiners are handled through the Accrual Fast Formula, which checks the employee's hire date and adjusts the accrual accordingly. There are two common approaches:

1. Enrollment Date Proration (Recommended): The plan is configured to start accruing from the enrollment date (= hire date). The formula uses MONTHS_BETWEEN(TRUNC(TODAY()), ASG_HIRE_DATE) to determine how many months of the year remain and accrues accordingly. An employee hired on 1 July in a 21-days/year plan would receive 21/12 × 6 = 10.5 days by year-end.

2. First Full Period Method: The employee starts accruing from the first full accrual period after hire (e.g., 1st of next month). No partial month is credited. Simpler but slightly less precise.

The Fast Formula should include DEFAULT FOR ASG_HIRE_DATE IS '1900-01-01' and a conditional check — if the current accrual date is before the hire date, return zero to prevent retroactive accruals.

A department transfer in Oracle HCM is an assignment change — it does not automatically affect absence plan enrollment or balances. The outcome depends on whether the new department has different absence policies:

Same Plan applies in both departments: The balance is completely unaffected. The employee's accruals continue seamlessly. No action needed.

Different plan in new department: The employee may need to be un-enrolled from the old plan and enrolled in the new plan as of the transfer date. Oracle supports a Balance Transfer function — HR can move the remaining balance from the old plan to the new plan, preventing the employee from losing accrued leave earned before the transfer. This is configured via "Manage Absence Balances" → "Transfer Balance."

Acquisition or Company Transfer: In corporate acquisitions, bulk balance transfers between plans are handled via HDL — loading the transferred balance as an opening adjustment on the new plan with an effective date matching the transfer date.

The integration between Oracle Absence Management and Oracle Payroll for unpaid leave works as follows:

• Absence Plan Setup: The unpaid leave Absence Plan is linked to a Payroll Deduction Element (e.g., "Unpaid Leave Deduction"). This element is configured with classification "Voluntary Deductions" and a calculation rule driven by a fast formula.
• Element Entry Created: When the unpaid leave is approved, Oracle creates an element entry for the deduction element, populating input values: Number of Unpaid Days and the applicable pay period date.
• Payroll Calculation: During the payroll run, the element's fast formula calculates (Monthly Salary / Working Days) × Unpaid Days and returns the deduction amount. This is subtracted from gross pay in the gross-to-net calculation.
• Payslip Display: The deduction appears as a named line item on the payslip (e.g., "Unpaid Leave - 3 days: -AED 1,364") — providing full transparency to the employee.
• Timing: The absence must be approved and the element entry created before the payroll period closes — late approvals may need to be processed in a correction run or the next cycle with a retro adjustment.

Yes — employees can and typically do have concurrent enrollments in multiple Absence Plans. Common scenarios:

• A full-time employee may be enrolled in: Annual Leave Plan, Sick Leave Plan, Emergency Leave Plan, and Maternity/Paternity Plan — all at the same time. Each plan has its own independent balance.
• In GCC, employees might have both a company vacation plan (30 days/year) and a statutory national holiday plan tracked separately for compliance reporting.
• US employees may be simultaneously enrolled in a company PTO plan, a FMLA plan (which runs concurrently with company leave when applicable), and a short-term disability plan.

Each plan's balance is tracked independently. When an employee submits a leave request, they select the Absence Type — Oracle automatically identifies which Plan governs that type and deducts from the correct balance. If FMLA concurrency rules apply, Oracle can simultaneously consume both the company plan and the FMLA entitlement for the same days.

Carryover expiration is configured within the Absence Plan's Balance section:

• Maximum Carryover Value: Set the ceiling — e.g., 10 days maximum. Any balance above this at year-end is subject to the excess handling rule (forfeit or cash-out).
• Expiry Date: Define when the carried-over balance expires if unused — e.g., 31 March of the following year. Oracle evaluates this during the year-end balance rollover process.
• Forfeit on Expiry: If the employee hasn't used the carried balance by the expiry date, Oracle sets it to zero. A notification can be configured to alert employees before the expiry date.
• Cash-Out on Expiry: Instead of forfeiture, Oracle can trigger a payroll element entry for the monetary equivalent of the expiring carried balance. This runs through payroll as a leave encashment earning.
• Year-End Process: The "Calculate Absence Accruals and Balances" process must be run as part of year-end processing to apply carryover and expiry rules. This is a scheduled task typically run on or just after the last day of the accrual period.
• Pre-Expiry Notifications: Configure Oracle workflow notifications to remind employees of expiring carried balance 30 and 14 days before the expiry date — encouraging them to plan and take the leave in time.

Leave encashment is the conversion of unused leave balance into a monetary payment. Oracle handles this in two scenarios:

Termination Encashment: When an employee is terminated, HR or the payroll team runs the "Process Termination Leave Encashment" task. Oracle reads the employee's final leave balance (accrued minus consumed as of termination date), calculates the value using their last basic salary daily rate, and creates a one-time Leave Encashment Earnings element entry. This is included in the termination off-cycle payroll run.

Annual Cash-Out (Optional Policy): Some companies allow employees to cash out a portion of their leave balance annually (e.g., encash up to 5 days per year). Oracle supports this through a configurable "Cash-Out" option on the plan — HR runs the encashment process, Oracle identifies employees eligible for cash-out, calculates the amount, and creates element entries for the batch.

The encashment calculation: Encashed Days × (Monthly Basic Salary / 30) in GCC contexts, or based on average daily earnings per the applicable legislation.

The half-day rule allows employees to take partial-day absence (typically morning or afternoon) rather than having to book a full day. Configuration involves:

• Unit of Measure: The Absence Plan must use Hours as the unit (not Days) to support sub-day granularity. If the plan uses Days, only whole-day requests are possible.
• Half-Day Options: The Absence Type can be configured to display options: "Full Day", "Morning (AM)", "Afternoon (PM)". Oracle determines the hour count for each based on the employee's work schedule — morning = first 4 hours, afternoon = last 4 hours of the standard 8-hour day.
• Balance Impact: A half-day request deducts 0.5 days (or the equivalent hours) from the balance rather than a full day.
• Payroll: For unpaid half-day absences, the payroll deduction is proportional — (daily salary / 2) is deducted for one half-day of unpaid leave.
• Shift Workers: For employees with non-standard hours (e.g., a 6-hour shift), the half-day is derived from their actual schedule rather than a fixed 4 hours.

Retroactive absence approvals occur when leave is submitted and approved after the fact — for example, an employee was sick and couldn't submit a request until they returned, or a manager's approval was delayed past the leave dates. Oracle handles this as follows:

• Past-Dated Submission: Oracle allows absence requests with start dates in the past. The system processes these normally through the approval workflow regardless of whether the dates have already passed.
• Balance Adjustment: Once approved, Oracle adjusts the employee's balance retroactively from the effective date of the absence — not from the approval date. The balance history shows the consumption as if it occurred on the original dates.
• Payroll Retro Trigger: If the absence was unpaid and the relevant payroll period has already closed, Oracle can trigger a retro payroll notification. The unpaid deduction element entry is created for the historical period, and the retro processing engine picks up the delta in the current payroll run.
• Audit Trail: Oracle records both the absence effective dates and the submission/approval dates separately, maintaining a complete audit trail for HR compliance.
• Restriction: Retroactive approvals can be restricted by plan — you can configure that absences cannot be back-dated more than 30 days to prevent misuse.

When an employee's leave balance is not increasing as expected, follow this systematic investigation:

• Step 1 — Check Enrollment: Navigate to the employee's Absence Plans page. Confirm they are enrolled in the correct plan and the enrollment effective date has passed. An enrollment date in the future means accruals haven't started yet.
• Step 2 — Check Plan Status: Ensure the Absence Plan itself is in Active status. A draft or inactive plan will not process accruals even for enrolled employees.
• Step 3 — Check Accrual Formula: Navigate to the Fast Formula linked to the plan and test it for the employee. Pay particular attention to: Is ASG_FTE_VALUE returning 0? (No accrual for zero FTE.) Is ASG_HIRE_DATE defaulting to '1900-01-01' because the date is missing — causing the years_of_service calculation to return an unexpectedly large value that may push into a zero-accrual band?
• Step 4 — Check Assignment Status: If the employee's assignment is suspended or has an end date, accruals may stop. Confirm the assignment is active for the accrual period.
• Step 5 — Run Accruals Manually: Submit the "Calculate Absence Accruals and Balances" process for the employee manually for the affected period. Review the process log for any errors or "skipped" messages with a reason code.
• Step 6 — Review Accrual Audit Report: Run the Absence Accrual Details OTBI report for the employee and period — it shows exactly what the formula returned for each accrual run and whether any adjustments were applied.

This is one of the most common employee-reported issues. The disconnect between what the employee sees and what Oracle is enforcing usually has one of these causes:

• Unit Mismatch: The plan balance is in hours but the employee is requesting in days (or vice versa). A balance of 40 hours shows as "40" — but a request for 5 days is being evaluated as 5 hours. Verify the plan's unit of measure and how the employee-facing request form displays the balance.
• Pending Requests Consuming Balance: An earlier unprocessed or pending-approval request may be reserving balance. Oracle deducts pending requests from the "available" balance even before they are approved. Ask the employee to check their absence history for any draft or pending submissions they may have forgotten about.
• Plan Hard Limit on Balance: The plan may have a "maximum balance" cap and a rule that prevents requests exceeding a certain consecutive duration regardless of balance. Check the plan's Restriction settings.
• Available vs Plan Balance: The employee's "Plan Balance" is the total they have earned. The "Available Balance" = Plan Balance − Consumed − Pending. If significant leave is pending approval, available balance may be far lower than plan balance. The employee sees plan balance, the system enforces available balance.
• Accrual Not Yet Run: If the employee is expecting accrual from this month but the accrual process hasn't run yet, their balance won't reflect the new month's entitlement. Run the accrual process or check the scheduled accrual job status.

When a leave request sits in "Pending Approval" indefinitely without the manager receiving a notification, follow this resolution path:

• Check Manager Assignment: The most common cause — the employee has no line manager assigned in their HR work relationship. Oracle cannot route the approval if the approver is undefined. Navigate to the employee's Work Relationships and confirm the manager is populated and active.
• Check Manager's Account Status: The manager themselves may have been terminated or their account locked. An inactive approver causes the workflow to stall. If this is the case, reassign the employee to an active manager, or use BPM Worklist admin tools to manually reassign the specific pending task.
• Check BPM Worklist: Navigate to the manager's BPM Worklist in Oracle Notifications. The task should appear there. If it's not in the worklist, the BPM routing rule may have a configuration issue — check "Manage Absence Approval Rules" for the relevant rule and verify the assignee expression is correct.
• Reassign via Admin: HR or IT administrators can access the BPM Worklist Administration console, search for the stuck task by process ID, and manually reassign it to the correct approver or escalate it to HR.
• Escalation Configuration: If requests are frequently getting stuck due to manager unavailability, configure an escalation rule — after N days without action, automatically escalate to the manager's manager or HR.

When an employee has approved unpaid leave but their payslip shows no deduction, work through this checklist:

• Check Payroll Element Link: Verify the Absence Plan's payroll integration tab shows a linked payroll element for unpaid leave. If the link is missing or the element is inactive, no entry will be created.
• Check Element Entry Creation: Navigate to the employee's element entries for the relevant pay period. Look for the "Unpaid Leave Deduction" entry. If it doesn't exist, the absence-to-payroll integration didn't fire — possible reasons include the absence being approved after payroll closed, or the element link being added to the plan after the absence was submitted.
• Check Absence Effective Dates: The absence dates must fall within the payroll period that has been processed. An absence approved with dates in the prior period won't appear in a current-period payroll run unless retro processing is triggered.
• Run Absence to Payroll Extract (if applicable): In hybrid environments, manually run the Absence Information for Payroll extract process and verify the output includes the employee's unpaid absence data.
• Check Payroll Messages: Review the payroll run messages for the employee — a missing cost code, inactive element link, or formula error may have caused the deduction element to error silently and produce zero.

If a part-time employee (FTE < 1.0) is accruing the same amount as full-time employees, the accrual formula is not applying the FTE adjustment. Root causes:

• Missing FTE Multiplication in Formula: The formula must include the line result = monthly_accrual_hours * ASG_FTE_VALUE. If this is absent or the FTE variable is not being referenced, the full entitlement is accrued regardless of work pattern.
• FTE Value is Zero or Missing: Navigate to the employee's assignment and check the FTE field. If it's blank or zero, Oracle defaults it to whatever is set in the formula's DEFAULT statement (typically 1.0). An FTE of 1.0 on a part-time assignment means full accrual. Update the FTE on the assignment to 0.5 (or the correct fraction) and rerun accruals.
• FTE on Wrong Assignment: For employees with multiple assignments, verify the FTE is populated on the specific assignment that is enrolled in the absence plan, not just a secondary assignment.
• Reprocess After Fix: After correcting the FTE, roll back the incorrect accrual entries for the affected periods (via balance adjustment) and rerun the accrual process. Adjust balances to reflect the correct prorated amounts retrospectively.

• Start with Statutory Leaves: Configure country-mandated leaves first (annual leave, sick leave, maternity) — these have fixed legal minimums that constrain your plan design. Company discretionary leaves come after.
• Design Formula Before Building: Map out the complete accrual logic on paper first — tenure bands, FTE factors, probation rules — before writing a single line of Fast Formula. Missed edge cases are much harder to fix after go-live.
• Test with Historical Data: Use actual employee hire dates and historical leave records to validate accrual formulas. Theoretical test cases miss the edge cases that real data exposes (e.g., employees with very long service, employees hired on 1 January vs 31 December).
• Set Up Holiday Calendars Early: Holiday calendars affect absence duration calculations from day one. Ensure all country-specific public holiday calendars are loaded before any absence plans go live.
• Train Managers Thoroughly: The biggest user adoption risk is manager non-compliance with the approval workflow. Dedicated training on the team calendar, bulk approvals, and delegation setup pays dividends immediately after go-live.
• Validate Opening Balances Independently: Cross-reference HDL-loaded opening balances against the legacy system for a sample of employees before cutover. Balance errors surface months later as discrepancies in termination settlements — by which point they are complex to investigate and costly to correct.
• Document All Custom Formulas: Every custom Fast Formula should have inline comments explaining the business rule, who requested it, and the date it was written. This is invaluable for maintenance when the original implementor has moved on.

Focus areas for the certification exam, ranked by typical weight:

• Fast Formula (High Weight): Know the common DBIs for absence (ASG_HIRE_DATE, ASG_FTE_VALUE, ABSENCE_BALANCE_VALUE), understand DEFAULT FOR usage, and be able to trace through sample accrual formula logic. Exam questions often present a formula snippet and ask what it returns for a given input.
• Absence Plan Configuration (High Weight): Understand the difference between Periodic and Service-Based accrual, how carryover is configured, and what each plan setting controls.
• Payroll Integration (Medium Weight): Know how the absence-to-element link works, the difference between paid leave earnings and unpaid leave deductions, and the role of the Absence to Payroll extract.
• Statutory Leaves (Medium Weight): FMLA eligibility criteria, intermittent leave tracking, and concurrent leave rules are frequently tested.
• Troubleshooting Scenarios (Medium Weight): "An employee's balance is not accruing — what do you check first?" type questions. Memorise the diagnostic sequence.
• OTBI Reporting (Lower Weight): Know the three absence subject areas and what data each one contains.

Practice in Oracle's learning sandbox environment is strongly recommended — hands-on experience configuring a plan end-to-end is more valuable than memorising documentation.