Oracle HCM 26C: Absence Plans & Types Redwood Experience

Oracle Cloud HCM 26C Deep Dive: Absence Plans and Absence Types in Redwood Experience

With Update 26C, Oracle Cloud HCM brings major configuration milestones to Absence Management by introducing the Redwood UI for Absence Types and Absence Plans setup. This release modernizes administrative maintenance, reorganizes classic tabs, deprecates legacy rules, and introduces conditional rule-building while aligning with Visual Builder Studio (VB Studio) business rules.

In this ACE contribution guide, we analyze what moved, what changed across each plan type's configuration screens, the underlying database footprint, known issues, and the pre-enablement checklist to review before enabling these Redwood setup pages.

🎥 Reference Materials & Session Walkthrough

This breakdown accompanies the Oracle Support walkthrough session: Watch Absence Types Redwood Experience Walkthrough and the official release notes: Oracle Readiness 26C: Absence Types Redwood Experience.

---

1. Enabling Redwood Setup Pages (Profile Options)

Both setup pages are delivered disabled by default. Administrators can activate them at the Site level using Manage Administrator Profile Values:

Profile Option Code	Default	Target Setup Page & Description
ORA_ANC_PLANS_VBCS_UI_ENABLED	N	Enables the Redwood VBCS UI for Absence Plans configuration.
ORA_ANC_TYPES_VBCS_UI_ENABLED	N	Enables the Redwood VBCS UI for Absence Types configuration.

---

2. Redwood Absence Plans: Architecture & Key Changes

The Redwood Absence Plan setup introduces dynamic field exposure—rule details and child parameters are revealed only when they functionally apply.

A. Navigation & Header Updates

• Basic Details moves into the plan header.
• History is now directly accessible from the Details tab.

B. Progressive Disclosure for Balance Dispositions

Balance disposition options now control when their related configuration fields appear:

• Rollover positive balance: When selected, the rollover rules section is enabled with: Rollover Rule, Rollover Limit, Rollover Target Plan, and Conversion Factor.
• Transfer positive balance: When selected, the transfer rules section is enabled with: Limit Rule, Limit, Limit Formula, Limit Proration Rule & Formula, Plan Category, and Target Plan Formula.

C. Intuitive Condition Builder for Accrual Matrices

The Add Accrual matrix now includes a more intuitive Condition Builder instead of the legacy expression builder to define criteria.

D. Entries and Balances Defaults

• Transfers and Adjustments options are unchecked by default.
• Year End Disbursements is disabled by default and has been moved under post rollover and carryover in the Year End Processing section of the Accruals tab.

---

3. Absence Plans: Configured Screens & Tabs by Plan Type

Across all absence plan types, Plan Attributes has been renamed to Details, and the legacy Additional Details tab has been reorganized and renamed to Event Processing where applicable. The available tabs and setup screens for each plan type in Redwood include:

Plan Type	Configured Tabs / Screens in Redwood	Structural & Functional Scope
Accrual	Details (Renamed from Plan Attributes) Participation Accruals Entries and Balances Event Processing (Renamed from Additional Details)	Includes the new intuitive Condition Builder for matrix setup and Year End Disbursements under Year End Processing.
Compensatory	Details (Renamed from Plan Attributes) Participation Plan Rules Entries and Balances Event Processing (Renamed from Additional Details)	Replaces the Accruals tab with Plan Rules for managing compensatory time earn/expiry logic and event updates.
Donation	Details (Renamed from Plan Attributes) Participation Entries and Balances Event Processing (Renamed from Additional Details)	Streamlined layout for peer-to-peer or pool recipient ledgers, disposition rules, and event triggers.
Qualification	Details (Renamed from Plan Attributes) Participation Entitlements Entries and Balances	Houses entitlement band matrices evaluated along rolling backward/forward or calendar term definitions.
Agreement	Details (Renamed from Plan Attributes) Entitlements Entries and Balances	Omits the Participation tab; configurations focus directly on agreement terms, entitlements, and balance tracking.
No Entitlement	Details (Renamed from Plan Attributes) Participation Entries and Balances	Pass-through setup for unpaid leaves routing rate reduction entries to payroll without an accrual matrix.

---

4. Redwood Absence Types: What Deserves Immediate Attention in 26C

A. Splitting "Display Features" into Two Dedicated Tabs

In classic UI, attributes and rules were grouped under Display Features. In Redwood, these are split into two dedicated tabs:

• Display Features Tab: Consists of sections and attributes.
• Rules Tab: Consists of all the rules.

B. Supplemental Region → Single Display Value for "Additional Fields"

The legacy Supplemental region is removed and replaced by Additional Fields.

⚠️ Functional Shift: You can now set a single display value for all three user roles (Employee, Manager, and Administrator) for:

• Authorized Absence
• Authorization Status Update
• Blocked Leave Status
• Notification Date
• Condition Start Date

When updating an existing absence type in Redwood, any correction or update to the above fields applies the same display value to all three roles!

C. Entry Display Priority Checkbox

The classic Entry display order field is replaced by the Entry display priority checkbox. Enabling this checkbox prioritizes the absence type in the LOV, sorted alphabetically.

D. Maternity & Childbirth Placement Pattern Governance

Maternity fields will no longer be configured within Absence Type setup. When an absence pattern of Childbirth or placement is selected, these fields are automatically displayed and editable on the Redwood entry page for all three roles:

• Planned absence start date & end date
• Intend not to return to work
• Expected Date of Event & Actual Date of Event
• Matching date (when Event Type is configured as placement)
• Expected week of event

Action Required: In Redwood, previous type-level display controls for maternity fields are ignored. You must use Visual Builder Studio (VB Studio) business rules to configure display and edit properties.

E. Deprecated and Renamed Elements

• Renamed: Advanced absence entry is renamed to Detailed absence entry across both classic and Redwood (no functional impact).
• Deprecated Rule: Late notification evaluation rule is deprecated.
• Removed Fields: Late notification waived, Late notification, Late notification waiver date, Disease code, and Initial reporting organization are removed.

---

5. Technical Architecture: Database Tables (Zero Schema Disruption)

Underlying database tables remain unchanged between Classic and Redwood setups:

Underlying Database Table	Functional Role & Content
ANC_ABSENCE_PLANS_F	Core setup parameters and definitions for absence plans.
ANC_ACCRUAL_BANDS_F	Accrual plan length-of-service and rate band configuration.
ANC_PLAN_ELIG_PROFILES_F	Eligibility profile linkages associated with absence plans.
ANC_ENTL_BANDS_F / _DTL_F	Qualification plan entitlement bands and banding detail definitions.
ANC_ABSENCE_TYPES_F	Absence type setup records defining entry parameters.
ANC_ABSENCE_TYPE_REGIONS_F	Display Features setup metadata and region configuration.
ANC_ABS_TYPE_RGN_USAGES_F	Absence type display region usages across user roles.
ANC_ABS_USAGE_RULES_F	Display features usage rules linked to specific types.

---

6. Known Behaviors & Roadmap Notes (26D & 27A)

Tracked Behaviors to Keep in Mind:

• Conversion & Validation Formula Display (Fixed in 26D): In Redwood Absence Type setup, Conversion and Validation formulas appeared in Edit mode but did not reflect values in View mode. In 26D+, values remain consistently visible across View, Update, and Correct modes.
• Accrue On Field for Front-Loaded Plans (Fixed in 27A): In Redwood Absence Plan setup, the Accrue On field was visible in View mode for front-loaded accrual plans (despite being hidden in classic UI and update mode). In 27A+, this field is completely suppressed for front-loaded plans.

---

7. Five-Step Pre-Enablement Checklist for 26C

Before switching profile options in production environments, complete these validation milestones:

1. Review High-Volume & Role-Specific Absence Types: Audit any absence type where Authorized Absence, Condition Start Date, or Notification Date had disparate settings between employee and manager roles.
2. Configure VB Studio Business Rules for Maternity: If your organization uses Childbirth or placement absence patterns, define business rules in Visual Builder Studio to enforce appropriate field-level visibility and editability across roles before cutover.
3. Audit Accrual Band Matrices: Check that condition logic in the new Condition Builder matches legacy Expression Builder configurations across all active accrual plans.
4. Verify Rollover & Transfer Balance Dispositions: Confirm that target plans and proration rules correctly resolve under the new progressive disclosure toggles.
5. Perform End-to-End Regression Testing: Run end-to-end tests covering entry, approval routing in Transaction Console, Fast Formula duration evaluation, and scheduled accrual runs (Calculate Accruals and Balances).

🎯 Conclusion & Takeaway

The 26C Redwood release delivers a streamlined, modern administration interface for Absence Plans and Types. By preparing VB Studio rules for maternity patterns early and understanding the single display value behavior for additional fields, functional leads can execute a seamless, zero-downtime transition to Redwood setup.

Troubleshooting Oracle Time and Labor: How to Enable Logging & Trace Time Calculation Rules in Oracle Cloud HCM

In Oracle Cloud Time and Labor (OTL), tracking down why a time calculation rule or validation rule produced unexpected results can be challenging when viewing only the final time card lines. Because OTL processes entries in bulk arrays, determining which condition, limit, or threshold triggered an outcome requires visibility into runtime execution.

Oracle delivers a dedicated diagnostic framework for this: the Analyze Rule Processing Details task. By configuring profile option ORA_HWM_RULES_LOG, instrumenting Fast Formulas with add_rlog(), validating security profiles, and managing log retention via ORA_HWM_RULES_LOG_MONTHS_TO_KEEP, administrators can review rule execution logs, formulas, and rule set processing details to diagnose issues effectively.

📌 Oracle Documentation Technical Profile

Diagnostic Task	Analyze Rule Processing Details
Task Navigation	My Client Groups > Time Management > Tasks panel > Analyze Rule Processing Details
Logging Activation Profile	ORA_HWM_RULES_LOG
Supported Log Levels	Incident, Finest, Finer, Fine
Log Retention Profile	ORA_HWM_RULES_LOG_MONTHS_TO_KEEP (0 to 24 Months)
Required Job Role	Time and Labor Administrator (ORA_HXT_TIME_AND_LABOR_ADMINISTRATOR_JOB)

---

1. Enabling Processing Logs (ORA_HWM_RULES_LOG)

Because logging every rule evaluation generates significant I/O activity, processing logs are disabled by default. You enable them using the administrator profile option ORA_HWM_RULES_LOG.

Navigation: Setup and Maintenance > Tasks panel > Search > Manage Administrator Profile Values

1. Sign in as an application administrator.
2. Search for and select the ORA_HWM_RULES_LOG profile option code.
3. Select the appropriate profile value based on the level of granularity required:

Log Level	Rule Set Logs	Rules Log
Incident	No, unless status is Failed	No, unless status is Failed
Finest	Yes	Yes
Finer	Yes	Yes for time calculation and entry rules No for workforce compliance rules
Fine	Yes for time calculation and entry rule sets No for workforce compliance rule sets	No

---

2. Confirming Security Profiles for Analyze Rule Processing Details

Before an administrator can view rule set and rule processing details, their sign-in credentials must have the proper data role and security profile assignments.

Verification Step: Navigate to My Client Groups > Time Management > Tasks panel > Analyze Rule Processing Details

In the Search section, open the Worker list:

• If the Worker list is empty: The data role is missing or incorrectly configured.
• If the Worker list shows values: Your security is configured properly to view logs.

Setting Up Security (If the Worker List is Empty)

1. Go to Setup and Maintenance > Tasks panel > Search > Manage Data Role and Security Profiles.
2. Create a data role based on Job Role Time and Labor Administrator (Role Code: ORA_HXT_TIME_AND_LABOR_ADMINISTRATOR_JOB).
3. On the Security Criteria page, ensure you select View All across security profiles:
   • In Organization Security Profile, select View All Organizations.
   • In Position Security Profile, select View All Positions.
   • In LDG Security Profile, select View All Legislative Data Groups.
   • In Person Security Profile, select View all People (do not select View all Workers).
4. Submit the data role, assign it to the administrator user account under Manage Job Roles, sign out, and sign back in.

---

3. Fast Formula Code: Adding Logs via add_rlog

Delivered formulas and custom Fast Formulas (such as Time Calculation and Time Entry rules) write diagnostic entries to the execution log using the internal function add_rlog().

To enable add_rlog, extract the two mandatory contexts HWM_FFS_ID and HWM_RULE_ID immediately after the INPUTS block, and wrap all numeric or date variables in TO_CHAR():

Fast Formula Code Snippet: Adding Diagnostic Logs via add_rlog

/* ----------------------------------------------------------------------
 * 1. MANDATORY CONTEXT HOOKS
 * Must be declared immediately after the INPUTS statement
 * ---------------------------------------------------------------------- */
ffs_id  = GET_CONTEXT(HWM_FFS_ID, 0)
rule_id = GET_CONTEXT(HWM_RULE_ID, 0)
ffName  = 'XXGEN_US_CA_STRAIGHT_TIME_FF'

/* Trace entry into the formula */
rLog = add_rlog(ffs_id, rule_id, '>>> Enter - ' || ffName)

/* ----------------------------------------------------------------------
 * 2. LOGGING HEADER & CONTEXT VARIABLES
 * Always wrap numeric and date variables with TO_CHAR()
 * ---------------------------------------------------------------------- */
rLog = add_rlog(ffs_id, rule_id, 
         'Header Resolved | Start: ' || TO_CHAR(aiStartTime) || 
         ' | End: ' || TO_CHAR(aiStopTime) || 
         ' | Weekly Sched Limit: ' || TO_CHAR(weekly_sch_hrs))

/* ----------------------------------------------------------------------
 * 3. LOGGING INSIDE ARRAY LOOPS
 * Output values as each time card line is evaluated
 * ---------------------------------------------------------------------- */
WHILE (nidx < wMaAry) LOOP (
  nidx          = nidx + 1
  aiRecPosition = HWM_CTXARY_RECORD_POSITIONS[nidx]
  tcMeasure     = MEASURE[nidx]
  aiPTT         = PayrollTimeType[nidx]

  rLog = add_rlog(ffs_id, rule_id, 
           'Row ' || TO_CHAR(nidx) || 
           ' | Pos: ' || aiRecPosition || 
           ' | Type: ' || aiPTT || 
           ' | Hours: ' || TO_CHAR(tcMeasure))

  /* Log conditional threshold branches */
  IF (aiRecPosition = 'DETAIL' AND aiPTT = 'Regular Hours') THEN (
    calc_reg_hours_wk = calc_reg_hours_wk + tcMeasure
    
    IF (calc_reg_hours_wk > weekly_sch_hrs) THEN (
      st_time_cur = calc_reg_hours_wk - weekly_sch_hrs
      rLog = add_rlog(ffs_id, rule_id, 
               '--> Threshold Exceeded! Straight Time Split: ' || TO_CHAR(st_time_cur))
    )
  )
)

/* ----------------------------------------------------------------------
 * 4. LOGGING OUTPUT RESULTS & EXIT
 * ---------------------------------------------------------------------- */
rLog = add_rlog(ffs_id, rule_id, 
         'Final Allocation | Straight Time: ' || TO_CHAR(st_time) || 
         ' | Unpaid Deficit: ' || TO_CHAR(unpaid_time))

rLog = add_rlog(ffs_id, rule_id, '<<< Exit - ' || ffName)

---

4. Diagnosing Issues via Analyze Rule Processing Details

Once logging is enabled, security is verified, and a test time card is submitted or saved, open the diagnostic console to trace execution:

1. Navigate to My Client Groups > Time Management > Tasks panel > Analyze Rule Processing Details.
2. Search for the employee and period in question.
3. Inspect execution using the four dedicated diagnostic buttons:
   • Rule Definition: View details of the rule configuration, including parameter inputs and expected outputs.
   • Rule Processing Log: Review the granular execution log for the specific rule to diagnose formula evaluation issues and custom add_rlog trace entries.
   • Rule Set Processing Log: Review the overall processing log for the rule set to see rule execution sequencing and set-level status.
   • Formula Details: View details of the Fast Formula associated with the rule template.
4. Correct any identified issues using the relevant setup tasks (such as Rule Templates, Rules, or Rule Sets).

Sample Rule Processing Log Output

Diagnostic Trace: XXGEN_US_CA_STRAIGHT_TIME_RULE Status: Completed

[INFO]  Rule Set Name: XX_US_CA_WEEKLY_CALC_RULE_SET
[INFO]  Executing Rule: XXGEN_US_CA_STRAIGHT_TIME_RULE (Order: 1)
---------------------------------------------------------------------------------------------------
[TRACE] >>> Enter - XXGEN_US_CA_STRAIGHT_TIME_FF
[TRACE] Header Resolved | Start: 2026-09-14 00:00:00 | End: 2026-09-20 23:59:59 | Weekly Sched Limit: 37.5
[TRACE] Row 1 | Pos: DETAIL | Type: Regular Hours | Hours: 8.0 | Running Total: 8.0
[TRACE] Row 2 | Pos: DETAIL | Type: Regular Hours | Hours: 8.0 | Running Total: 16.0
[TRACE] Row 3 | Pos: DETAIL | Type: Regular Hours | Hours: 8.0 | Running Total: 24.0
[TRACE] Row 4 | Pos: DETAIL | Type: Regular Hours | Hours: 8.0 | Running Total: 32.0
[TRACE] Row 5 | Pos: DETAIL | Type: Regular Hours | Hours: 8.0 | Running Total: 40.0
[TRACE] --> Threshold Exceeded! Straight Time Split: 2.5
[TRACE] Final Allocation | Straight Time: 2.5 | Unpaid Deficit: 0.0
[TRACE] <<< Exit - XXGEN_US_CA_STRAIGHT_TIME_FF
[INFO]  Rule Execution Completed Successfully. Output arrays returned to OTL Engine.

---

5. Managing Log Deletions (ORA_HWM_RULES_LOG_MONTHS_TO_KEEP)

Rule and rule set log files consume significant database storage over time. Oracle provides automatic and manual deletion mechanisms to manage log file lifecycle.

Automatic Log Deletions

1. Navigate to Setup and Maintenance > Tasks panel > Search > Manage Administrator Profile Values.
2. Search for and select profile option code: ORA_HWM_RULES_LOG_MONTHS_TO_KEEP.
3. Enter a site-level profile value from 0 to 24 (the number of months to keep log files before automatic deletion):
   • Entering 0 deletes all entries.
   • Logs older than 24 months are automatically deleted by the application; entering any number greater than 24 automatically adjusts to 24.
4. Click Save and Close.

Manual Log Deletions

To manually purge log files that are older than the retention value set in the profile option but younger than 24 months:

1. Go to My Client Groups > Time Management > Tasks panel > Analyze Rule Processing Details.
2. Select Actions > Delete Older Log Files.

---

🔑 Architectural Best Practices for OTL Diagnostics

• Select Appropriate Log Level: Use Finest for full rule-level and rule-set-level traces, or Finer when focusing specifically on time calculation and entry rules without workforce compliance noise.
• Verify Security First: Always verify that the Worker search list in Analyze Rule Processing Details is populated before troubleshooting. If empty, ensure your data role has View all People assigned.
• Use Dedicated Diagnostic Buttons: Leverage Rule Processing Log, Rule Set Processing Log, and Rule Definition on the Analyze Rule Processing Details page to review execution steps.
• Control Log Retention: Manage performance by maintaining ORA_HWM_RULES_LOG_MONTHS_TO_KEEP and running Actions > Delete Older Log Files when needed.

Oracle Cloud Time & Labor Architecture Diagnostics & Troubleshooting Guide

California Straight Time and Unpaid Time calculation - Time Calculation Rule

California overtime is notoriously two-layered: daily overtime (hours over 8 in a day) and weekly overtime (hours over 40 in a week) can both apply to the same timecard, and the two don't always agree on which hours should be paid at which rate. The tricky part shows up with partial weeks—such as a new hire starting mid-week or an employee terminating on a Wednesday—where a rigid "40 hours" weekly baseline no longer reflects what the employee was actually scheduled to work.

This post breaks down a production-tested pair of Oracle Time and Labor (OTL) formulas: XXGEN_US_CA_STRAIGHT_TIME_FF, a Time Calculation Rule that partitions reported hours into regular, straight-time surplus, and unpaid deficit buckets, and its companion helper formula, XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE, which dynamically resolves the employee's true scheduled hours for the period instead of relying on a hardcoded 40-hour limit.

📌 Fast Formula Technical Profile

Primary Formula	XXGEN_US_CA_STRAIGHT_TIME_FF (Time Calculation Rule)
Companion Utility	XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE (Workforce Management Utility)
Summation Level	TIMECARD (Whole period evaluation at submit/save)
Output Mappings	OUT_MEASURE_UNDER, OUT_MEASURE_STRAIGHT_TIME, OUT_MEASURE_UNPAID_TIME

---

Business Context & Architectural Highlights

• Dynamic Schedule Threshold: Instead of comparing worked hours against a flat 40 hours, the formula calls the companion schedule utility at the HEADER record position to resolve the employee's exact scheduled hours for the timecard window.
• Absence Credit Protection: Approved absence hours recorded on the timecard are accumulated alongside worked regular time, ensuring that paid leave reduces the remaining weekly schedule obligation rather than unfairly pushing worked time into uncompensated deficits.
• Unpaid Shortfall Identification: When an employee works fewer hours than contracted and has no approved leave to cover the gap, the formula isolates the unworked shortfall into an unpaid attribute for automated payroll docking or administrative audit.
• Bulk Array Performance: The formula processes the timecard in a single bulk loop across parallel context arrays (HWM_CTXARY_*), providing significant performance advantages over line-by-line recalculations.

Formula Array Inputs

Input Name	Description & Role
HWM_CTXARY_RECORD_POSITIONS	Flags the record type for each array index: HEADER, DETAIL, or END_PERIOD.
HWM_CTXARY_HWM_MEASURE_DAY	Daily measured hours associated with each record position.
measure	The reported duration hours being reclassified.
StartTime / StopTime	Period date-time boundaries passed on the HEADER row to query scheduled hours.
PayrollTimeType	Identifies worked time rows (e.g., Regular Hours) for inclusion in the weekly accumulation.
AbsenceType	Flags absence rows so approved leave credits toward the weekly schedule requirement.

Rule Header & Input Parameters

Parameter	Source	Purpose
hSumLvl	Get_Hdr_Text(rule_id, 'RUN_SUMMATION_LEVEL', 'TIMECARD')	Summation level the rule executes under (defaults to TIMECARD).
hExecType	Get_Hdr_Text(rule_id, 'RULE_EXEC_TYPE', 'CREATE')	Determines hCreateYn, flagging whether this execution is an entry creation run.
pCategoryId	get_rvalue_number(rule_id, 'WORKED_TIME_CONDITION', 0)	Rule parameter identifying which pay time type category represents eligible worked time.
pMaxHrs	get_rvalue_number(rule_id, 'DEFINED_LIMIT', 0)	Static limit configured on the rule. Note: In this dynamic formula, this value is logged for reference, but the schedule-fetched weekly_sch_hrs governs the threshold comparison.

Output Variables

Output Variable	Meaning & Target Classification
OUT_MEASURE_UNDER	Portion of each detail record's regular hours remaining under the schedule threshold (ordinary regular time).
OUT_MEASURE_STRAIGHT_TIME	Surplus hours logged beyond the dynamic weekly schedule, assigned to the last detail line in the period.
OUT_MEASURE_UNPAID_TIME	The deficit calculated when total regular hours and absences fail to reach the contracted schedule baseline.

---

Array Processing Walkthrough

1. Loop Initialization: The formula iterates through the timecard array from nidx = 1 up to wMaAry, evaluating the record position, measure, pay time type, and absence flags for each row.
2. HEADER Phase: Resets weekly_sch_hrs = 0 and calls XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE using the record's start/end boundaries. The returned total becomes the dynamic threshold for the timecard.
3. DETAIL Phase (Regular Hours): Adds the hours to running total calc_reg_hours_wk. If the cumulative sum crosses weekly_sch_hrs, the overflow is carved out as straight time (st_time_cur), the running total is capped, and the net regular portion is assigned to OUT_MEASURE_UNDER.
4. DETAIL Phase (Absence Entries): Approved absence hours also accumulate into calc_reg_hours_wk, ensuring authorized leave fulfills schedule requirements without altering absence balances.
5. END_PERIOD Phase: If accumulated hours met the schedule and straight time was generated, st_time is written to OUT_MEASURE_STRAIGHT_TIME[st_time_idx]. If reported hours fall short of the schedule, the deficit is output to OUT_MEASURE_UNPAID_TIME[st_time_idx].
6. Runaway Safety Guard: A hard stop raises an error if iterations exceed 1000, protecting against endless execution loops on malformed timecards.

Worked Scenarios

📈 SCENARIO A: SCHEDULE MET WITH SURPLUS (STRAIGHT TIME ACCRUAL)

Employee Assigned Schedule: 37.5 Hours. The employee logs 40 Hours of Regular Hours across the week.

Time Line	Reported	Running Total	Formula Outcome
Mon – Thu (4 × 8.0 hrs)	32.0 hrs	32.0 hrs (< 37.5)	OUT_MEASURE_UNDER = 32.0 hrs
Friday (8.0 hrs)	8.0 hrs	40.0 hrs (> 37.5)	Splits: 5.5 Regular (under) + 2.5 Straight Time stored
END_PERIOD Close	Total: 40.0 hrs	Met Schedule	OUT_MEASURE_STRAIGHT_TIME[st_time_idx] = 2.5 hrs

Result: The 2.5 hours worked beyond the 37.5-hour scheduled threshold are reclassified into straight time, while the initial 37.5 hours remain standard regular hours.

📉 SCENARIO B: SCHEDULE SHORTFALL (UNPAID TIME CALCULATION)

Employee Assigned Schedule: 37.5 Hours (7.5 hrs/day). The worker logs 3 days (22.5 Hours) and records no authorized leave for the remaining days.

Time Line	Reported	Running Total	Formula Outcome
Mon – Wed (3 × 7.5 hrs)	22.5 hrs	22.5 hrs (< 37.5)	OUT_MEASURE_UNDER = 22.5 hrs (kept as regular)
Thu – Fri	0.0 hrs	22.5 hrs (Deficit)	No hours entered
END_PERIOD Close	Total: 22.5 hrs	22.5 < 37.5	OUT_MEASURE_UNPAID_TIME[st_time_idx] = 15.0 hrs (37.5 − 22.5)

Result: The engine outputs 15.0 hours of unpaid time. When mapped in the Time Consumer Set to a payroll reduction element, this automates salary docking without manual recalculations.

---

Primary Formula: XXGEN_US_CA_STRAIGHT_TIME_FF

XXGEN_US_CA_STRAIGHT_TIME_FF.ff

/* +======================================================================+
   | Formula Name : XXGEN_US_CA_STRAIGHT_TIME_FF                          |
   | Formula Type : Time Calculation rule                                 |
   | Description  : Calculates straight time and unpaid hours using      |
   |                published weekly schedule as dynamic threshold.       |
   +======================================================================+ */

DEFAULT FOR HWM_CTXARY_RECORD_POSITIONS   is EMPTY_TEXT_NUMBER 
DEFAULT FOR HWM_CTXARY_HWM_MEASURE_DAY    is EMPTY_NUMBER_NUMBER 
DEFAULT FOR measure                       is EMPTY_NUMBER_NUMBER  
DEFAULT FOR StartTime                     is EMPTY_DATE_NUMBER
DEFAULT FOR StopTime                      is EMPTY_DATE_NUMBER
DEFAULT FOR PayrollTimeType               IS EMPTY_TEXT_NUMBER
DEFAULT FOR AbsenceType                   IS EMPTY_NUMBER_NUMBER 

INPUTS ARE 
  HWM_CTXARY_RECORD_POSITIONS,
  HWM_CTXARY_HWM_MEASURE_DAY,
  measure, 
  StartTime,
  StopTime,
  PayrollTimeType,
  AbsenceType  

ffs_id  = GET_CONTEXT(HWM_FFS_ID, 0)
rule_id = GET_CONTEXT(HWM_RULE_ID, 0)  
ffName  = 'XXGEN_US_CA_STRAIGHT_TIME_FF '
rLog    = add_rlog(ffs_id, rule_id, '>>> Enter - ' || ffName) 
 
NullDate     = '01-JAN-1900'(DATE)  
NullDateTime = '1900/01/01 00:00:00'(DATE)   
NullText     = '**FF_NULL**'

measure_period = GET_CONTEXT(HWM_MEASURE_PERIOD, 0)  

hSumLvl   = Get_Hdr_Text(rule_id, 'RUN_SUMMATION_LEVEL', 'TIMECARD') 
hExecType = Get_Hdr_Text(rule_id, 'RULE_EXEC_TYPE', 'CREATE')  
hCreateYn = 'N' 

IF (upper(hExecType) = 'CREATE') THEN ( 
  hCreateYn = 'Y' 
) 

pCategoryId = get_rvalue_number(rule_id, 'WORKED_TIME_CONDITION', 0) 
pMaxHrs     = get_rvalue_number(rule_id, 'DEFINED_LIMIT', 0) 

OUT_MEASURE_UNDER         = EMPTY_NUMBER_NUMBER
OUT_MEASURE_STRAIGHT_TIME = EMPTY_NUMBER_NUMBER
OUT_MEASURE_UNPAID_TIME   = EMPTY_NUMBER_NUMBER

wMaAry            = HWM_CTXARY_RECORD_POSITIONS.count   
nidx              = 0
st_time           = 0
st_time_cur       = 0
st_time_idx       = 0
calc_reg_hours_wk = 0
weekly_sch_hrs    = 0

WHILE (nidx < wMaAry) LOOP (   
  nidx          = nidx + 1  
  tcMeasure     = 0  
  tcMeasureDay  = 0  
  aiPTT         = NullText
  aiAbs         = 0
  aiRecPosition = HWM_CTXARY_RECORD_POSITIONS[nidx] 

  IF (MEASURE.exists(nidx)) THEN ( tcMeasure = MEASURE[nidx] )  
  IF (HWM_CTXARY_HWM_MEASURE_DAY.exists(nidx)) THEN ( tcMeasureDay = HWM_CTXARY_HWM_MEASURE_DAY[nidx] ) 
  IF (PayrollTimeType.EXISTS(nidx)) THEN ( aiPTT = PayrollTimeType[nidx] ) 
  IF (AbsenceType.EXISTS(nidx)) THEN ( aiAbs = AbsenceType[nidx] ) 

  /* 1. Resolve Contractual Schedule at Header */
  IF (aiRecPosition = 'HEADER') THEN (
    weekly_sch_hrs = 0
    IF (STARTTIME.exists(nidx)) THEN ( aiStartTime = STARTTIME[nidx] ) 
    IF (STOPTIME.exists(nidx))  THEN ( aiStopTime  = STOPTIME[nidx] ) 

    ctx_personId    = GET_CONTEXT(HWM_RESOURCE_ID, 0)
    ctx_subResource = GET_CONTEXT(HWM_SUBRESOURCE_ID, 0)
    ctx_start_date  = GET_CONTEXT(HWM_CTX_SEARCH_START_DATE, NullDate)
    ctx_end_date    = GET_CONTEXT(HWM_CTX_SEARCH_END_DATE, NullDate)

    CALL_FORMULA('XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE',
      aiStartTime    > 'start_date_override',
      aiStopTime     > 'end_date_override',
      weekly_sch_hrs < 'TotalHrs' DEFAULT 0)  
  )

  /* 2. Detail Accumulation: Regular Hours */
  ELSE IF (aiRecPosition = 'DETAIL' AND aiPTT = 'Regular Hours') THEN (
    calc_reg_hours_wk = calc_reg_hours_wk + tcMeasure
    IF (calc_reg_hours_wk > weekly_sch_hrs) THEN (
      st_time_cur       = calc_reg_hours_wk - weekly_sch_hrs
      st_time           = st_time + st_time_cur
      calc_reg_hours_wk = weekly_sch_hrs
    ) ELSE (
      st_time_cur = 0
    )
    OUT_MEASURE_UNDER[nidx] = tcMeasure - st_time_cur
    st_time_idx             = nidx
  )

  /* 3. Detail Accumulation: Authorized Leave */
  ELSE IF (aiRecPosition = 'DETAIL' AND aiAbs > 0) THEN (    
    calc_reg_hours_wk = calc_reg_hours_wk + tcMeasure
    IF (calc_reg_hours_wk > weekly_sch_hrs) THEN (
      st_time_cur       = calc_reg_hours_wk - weekly_sch_hrs
      st_time           = st_time + st_time_cur
      calc_reg_hours_wk = weekly_sch_hrs
    ) ELSE (
      st_time_cur = 0
    )
  )

  /* 4. Period Boundary: Reconcile Straight Time or Deficit */
  ELSE IF (aiRecPosition = 'END_PERIOD') THEN (
    IF (calc_reg_hours_wk = weekly_sch_hrs AND st_time > 0) THEN (
      OUT_MEASURE_STRAIGHT_TIME[st_time_idx] = st_time
    ) ELSE IF (calc_reg_hours_wk < weekly_sch_hrs AND calc_reg_hours_wk > 0) THEN (
      OUT_MEASURE_UNPAID_TIME[st_time_idx] = (weekly_sch_hrs - calc_reg_hours_wk)      
    )
  )

  IF (nidx > 1000) THEN (
    ex = raise_error(ffs_id, rule_id, 'Formula ' || ffName || ' terminated due to possible end-less loop.') 
  )     
)

rLog = add_rlog(ffs_id, rule_id, '<< Exit - ' || ffName) 

RETURN OUT_MEASURE_UNDER, OUT_MEASURE_STRAIGHT_TIME, OUT_MEASURE_UNPAID_TIME

---

Companion Formula: XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE

This helper utility is what enables dynamic thresholds: it inspects the employee's assigned work schedule for the exact period range and aggregates scheduled hours while filtering out non-working holiday entries (objType <> 'CAL').

XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE.ff

/* +======================================================================+
   | Formula Name : XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE                    |
   | Formula Type : WORKFORCE_MANAGEMENT_UTILITY                          |
   | Description  : Aggregates employee work schedule with holidays       |
   |                excluded to yield dynamic period threshold.           |
   +======================================================================+ */

DEFAULT FOR start_date_override(Date) IS '01-JAN-1900'(DATE)  
DEFAULT FOR end_date_override(Date)   IS '01-JAN-1900'(DATE)  

DEFAULT_DATA_VALUE FOR HWM_EMP_SCHD_MEASURE           IS 0 
DEFAULT_DATA_VALUE FOR HWM_EMP_SCHD_START_DATE_TIME   IS '01-JAN-1900'(DATE)  
DEFAULT_DATA_VALUE FOR HWM_EMP_SCHD_END_DATE_TIME     IS '01-JAN-1900'(DATE)  
DEFAULT_DATA_VALUE FOR HWM_EMP_SCHD_AVAILABILITY_CODE IS 'NA'
DEFAULT_DATA_VALUE FOR HWM_EMP_SCHD_OBJECT_TYPE       IS 'NA'

INPUTS ARE   
  start_date_override(DATE),
  end_date_override(DATE) 

ffs_id  = GET_CONTEXT(HWM_FFS_ID, 0) 
rule_id = GET_CONTEXT(HWM_RULE_ID, 0) 
ffName  = 'XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE'  

NullDate = '01-JAN-1900'(DATE)  
NullText = '**FF_NULL**' 

ctx_personId    = GET_CONTEXT(HWM_RESOURCE_ID, 0)
ctx_subResource = GET_CONTEXT(HWM_SUBRESOURCE_ID, 0)
ctx_start_date  = GET_CONTEXT(HWM_CTX_SEARCH_START_DATE, NullDate)
ctx_end_date    = GET_CONTEXT(HWM_CTX_SEARCH_END_DATE, NullDate) 

stDate  = trunc(start_date_override)
endDate = trunc(end_date_override) 

IF (start_date_override WAS DEFAULTED) THEN (
  stDate = trunc(ctx_start_date)
)  
IF (end_date_override WAS DEFAULTED) THEN (
  endDate = trunc(ctx_end_date)
)  
endDate = ADD_DAYS(trunc(endDate), 1)

max_loop  = 5000
EmpHrs    = 0 
TotalHrs  = 0
HrsSource = NullText
nidx      = 1

CHANGE_CONTEXTS(HWM_CTX_SEARCH_START_DATE = stDate, HWM_CTX_SEARCH_END_DATE = endDate) (  
  nidx      = 1
  HrsSource = 'EMP'
  
  WHILE (HWM_EMP_SCHD_MEASURE.EXISTS(nidx)) LOOP (
    EmpHrs  = HWM_EMP_SCHD_MEASURE[nidx] 
    SchAvl  = HWM_EMP_SCHD_AVAILABILITY_CODE[nidx]
    objType = HWM_EMP_SCHD_OBJECT_TYPE[nidx]
    
    /* Exclude unavailable days and public holidays */
    IF (SchAvl <> 'NVL' AND objType <> 'CAL') THEN (
      TotalHrs = TotalHrs + EmpHrs 
    )
    
    nidx = nidx + 1
    IF (nidx > max_loop) THEN ( 
      ex = raise_error(ffs_id, rule_id, 'Schedule query exceeded loop ceiling.')
    )  
  )
)   

RETURN TotalHrs, HrsSource

---

Rule Configuration in Time and Labor

The primary formula is attached to a Time Calculation Rule with summation set to Time Card. The companion formula XXGEN_UTIL_GET_EMPLOYMENT_SCHEDULE must be compiled first so the subroutine call resolves seamlessly during execution.

Figure 1: Configuring Time Calculation Rule parameters and mapping output groups to payroll time types.

Validation & Test Checklist

• Standard Full Week: Verify that hours exceeding the contractual schedule cleanly spill into OUT_MEASURE_STRAIGHT_TIME.
• Partial-Week Proration: Simulate mid-week new hires or terminations to confirm that weekly_sch_hrs evaluates against the active work window rather than a blanket 40 hours.
• Absence Combination: Log a combination of worked days and vacation/sick leave to ensure leaves correctly absorb the scheduled threshold requirement.
• Public Holiday Verification: Verify that holiday entries (objType = 'CAL') are correctly excluded from total scheduled hours.

Conclusion

Flat weekly thresholds fail whenever nonexempt staff, alternative schedules, or partial-week events occur. By combining a bulk Time Calculation Rule with a schedule-query utility, organizations achieve fair, auditable straight time allocations and automated unpaid shortfall deductions across all workforce variations.

Steps for allowing updation of absences in Timecard

A common enterprise requirement in Oracle Cloud HCM is enabling workers to record or view their absence time (such as Vacation, Sick, or Holiday) directly on their daily or weekly time cards. Harmonizing Oracle Fusion Absence Management with Oracle Time and Labor (OTL) gives employees a single unified surface for tracking all presence and absence events while preventing conflicting schedule entries.

In this technical guide, we walk through the setup required to surface Absence types within Time Card layouts: enabling the absence type for time cards, configuring the multi-attribute layout component, binding the fields in the layout set, and verifying time entry configuration.

---

Step 1: Enable the Absence Type for Time Card and Calendar Entry

Before an absence type can be exposed to OTL time cards, it must be explicitly configured to allow time entry within the Absence Management setup.

Navigation: My Client Groups > Absences > Absence Types > Edit Absence Type (e.g., Sick)

Under the Absence Record Maintenance region, locate the setting Enable entry in time card and calendar:

• Don't show: The absence type cannot be viewed or recorded via time cards.
• View only: Absences booked via Absence Management display on the time card for reference, but cannot be modified directly in OTL.
• Editable: Allows workers and managers to record, edit, and submit absence hours directly within the time card interface.

Figure 1: Setting 'Enable entry in time card and calendar' to Editable on the Absence Type.

---

Step 2: Configure Layout Components with Absence Management Types

Time cards utilize layout components to display attributes like Payroll Time Type and Absence Management Type within a single picklist or across multiple dependent fields.

Navigation: My Client Groups > Time Management > Time Entry Layout Components

1. Search for the targeted layout component, such as Hours Type (Hourly).
2. Confirm the Layout Component Type is configured as a Multiple attribute time card field to support both payroll and absence mappings.

Figure 2: Locating the 'Hours Type (Hourly)' multiple attribute time card field component.

3. Open the component definition to configure the Display Value and Attribute Definition.
4. Map each user-facing Display Value to its corresponding backend attribute:
   • Map regular work hours to the relevant Payroll Time Type (e.g., Regular Hours US, Overtime TL US).
   • Map absence entries to the corresponding Absence Management Type (e.g., Vacation, Sick).
   • Set appropriate worker and manager action permissions (e.g., Worker Allowed Action = Edit, Line Manager Allowed Action = Read only for Sick leave).

Figure 3: Defining field mappings, linking Sick and Vacation to Absence Management Types.

---

Step 3: Define and Assign Layout Sets

Layout sets determine how fields and pages appear to workers across multiple time collection interfaces, including Time Entry, Web Clock, and Shift layouts.

Navigation: My Client Groups > Time Management > Layout Sets

1. Locate the target layout set (e.g., Bi-Weekly Hourly Payroll).

Figure 4: Selecting the target Layout Set from search results.

2. Click Edit to review the layout set configuration. Ensure the appropriate Time Consumer Set is selected (e.g., Payroll) and click into the configuration chevron for Time Entry Layout.

Figure 5: Define Layout Set overview with Time Consumer Set and Layout navigation.

---

Step 4: Configure Time Card Fields in Time Entry Layout

Inside the layout configuration wizard, verify that the absence-enabled layout component is actively placed on the time card grid.

1. Navigate to Step 2 of the train: Time Card Fields.
2. Ensure the field Hours Type (Hourly) is positioned in the field sequence and flagged as a Time Entry Identifier.
3. Review the targeted user population permissions (Worker, Line Manager) to ensure smooth entry and validation.
4. Click Save and Close.

Figure 6: Configuring Time Card Fields and enabling 'Hours Type (Hourly)' as a Time Entry Identifier.

---

Key Implementation Architectural Takeaways

• Dual-Action Absence Setup: Always coordinate the Absence Type's "Enable entry in time card and calendar" setting with the component's Worker/Manager Allowed Actions. If either is set to view-only, the worker cannot enter absence hours on the time card.
• Consumer Set Validation: Ensure your Time Consumer Set rules properly validate absence units against absence entitlement rules and avoid duplicate processing into Global Payroll.
• Unified Experience: Using a multi-attribute field simplifies daily self-service by displaying regular hours, overtime, and absence types in a single dropdown.

Configuring Individual Leave Donation in Oracle Fusion HCM Absence Management: An End-to-End Walkthrough

Leave donation programs provide a vital support structure within organizations, allowing employees to assist colleagues facing personal emergencies, prolonged medical treatments, or catastrophic events. In Oracle Cloud HCM Absence Management, organizations can implement leave donation through two distinct architectural models:

• Donation Pool: Employees surrender accrued time into an anonymized central organizational bucket, which is later distributed to approved applicants via committee review.
• Individual Donation (Direct Peer-to-Peer): A donor transfers leave balances directly from their personal accrual balance into a specific colleague’s dedicated donation plan account.

In this guide, we walk through the setup and runtime mechanics of Individual Donation: defining the receiving donation plan, enabling donation rules on donor accrual plans, linking plans to absence types with cascading priority sequencing, enrolling the recipient worker, and validating balance debits and credits across donor and recipient accounts.

---

📌 Business Scenario & Test Parameters

Donor	Curtis Feitty (Initial Sick balance: 64 Hours. Curtis can only donate from his Sick plan; other plans such as Vacation or Volunteering do not permit donations).
Recipient	Casey Brown (Primary Sick balance is exhausted at 0 Hours; actively enrolled in Test Donation Plan).
Transfer Event	Curtis donates 10 Hours from his Sick balance directly to Casey Brown. Curtis's balance is debited from 64 to 54 Hours.
Absence Usage	Casey records a 9-Hour Sick absence. The engine bypasses the 0-balance Sick plan and decrements 9 hours from Test Donation Plan, leaving 1 Hour remaining.

Step 1: Create the Receiving Absence Plan (Test Donation Plan)

The receiving plan functions as a dedicated ledger to receive and maintain hours transferred to an individual recipient.

Navigation: My Client Groups > Absences > Absence Plans

1. Click Create.
2. In the modal dialogue, enter the baseline header details:
   • Effective As-of Date: 1/1/51
   • Legislation: United States
   • Plan Type: Donation
   Click Continue.

Figure 1: Initializing a new Absence Plan with Plan Type set to Donation.

3. On the Plan Attributes tab, specify:
   • Plan: Test Donation Plan
   • Legislative Data Group: US Legislative Data Group
   • Status: Active
   • Donation Type: Individual (Critical: Configures direct peer transfers rather than pool routing)
   • Plan UOM: Hours
   • Balance Reporting Frequency: Person primary frequency
   • Ceiling Rule: No limit

Figure 2: Defining General Attributes with Donation Type set to Individual.

4. Navigate to the Participation tab:

   Review Balance Disposition Rules for worker separation. For peer-to-peer gifts, leave Disburse positive balance, Recover negative balance, and Return positive balance to pool unchecked.

5. Click Save and Close.

Figure 3: Reviewing Balance Disposition Rules under the Participation tab.

---

Step 2: Enable Donation on the Source Plan (Sick Only)

To permit hours to be transferred out of the donor's balance, the source plan (Sick) must explicitly authorize deductions for donations. Because donation rules are not configured on Vacation or Volunteering plans, Curtis is restricted to donating solely from his Sick balance.

Navigation: My Client Groups > Absences > Absence Plans > Search and Edit 'Sick'

1. Select the Entries and Balances tab.
2. Scroll to the Donation configuration section:
   • Check Enable for administrator
   • Check Enable for manager
   • Check Enable for worker (allows employee self-service transfers)
   • Donation Rule: Flat amount
   • Minimum: 1 Hours
   • Maximum: 100 Hours
   • Increment: 1 Hours
3. Click Save and Close.

Figure 4: Enabling role permissions and transaction thresholds under the Donation section of the Sick plan.

---

Step 3: Link Plans to Absence Type & Configure Priority

When an employee books a Sick absence, the calculation engine must exhaust primary accrued hours first. Once that balance hits zero, it should waterfall to the donated balance. This consumption sequence is governed by Priority on the Absence Type.

Navigation: My Client Groups > Absences > Absence Types > Edit 'Sick' > Plans and Reasons Tab

1. Under Absence Plans, click Select and Add.
2. Add Test Donation Plan and set priority:
   • Sick: Priority 20
   • Test Donation Plan: Priority 30
   • Concurrent: No
3. Click OK and then Save and Close.

💡 How Plan Priority Operates: The absence calculation engine always exhausts the plan with the lower priority number first (Priority 20: Sick). When that balance is depleted, any remaining duration cascades to the next plan in numeric order (Priority 30: Test Donation Plan).

Figure 5: Adding Test Donation Plan to Absence Type Sick with Priority 30.

Figure 6: Absence Type 'Sick' configured with Sick (Priority 20) and Test Donation Plan (Priority 30).

---

Step 4: Enroll Recipient (Casey Brown) into Test Donation Plan

Before a recipient can receive donated hours or consume them against an absence type, they must have an active enrollment in the receiving donation plan.

Navigation: My Client Groups > Absences > Plan Participation > Enrollments and Adjustments

1. Search for and select recipient Casey Brown.
2. Under the Plan Participation section, click Enrollments and Adjustments > Add Enrollment.
3. Select Test Donation Plan as the plan name.
4. Set the Enrollment Start Date to 9/1/26 (or the effective date when the employee becomes eligible to receive donations).
5. Click Submit. Once completed, Casey will show an active enrollment in Test Donation Plan alongside her existing plans.

Figure 7: Enrolling Casey Brown into Test Donation Plan under Manage Absences and Entitlements.

---

Step 5: Verify Plan Balances & Plan Enrollments

Before executing the transfer, review the standing balances under Manage Absences and Entitlements:

1. Curtis Feitty (Donor):
Curtis had an initial Sick balance of 64 Hours. Because donation is enabled strictly on the Sick plan, Curtis can only donate from Sick (and not from his 200 hours of Volunteering or 210 hours of Vacation). Following a 10-hour donation transfer, Curtis's Sick balance reflects 54 Hours.

Figure 8: Curtis Feitty's active balances showing 54 hours remaining in the Sick plan after a 10-hour transfer.

2. Casey Brown (Recipient):
Casey is enrolled in the Test Donation Plan (effective 9/1/26), and her primary Sick balance is fully exhausted at 0 Hours.

---

Step 6: Process the Peer-to-Peer Donation

Curtis transfers 10 Hours from his Sick balance directly to Casey Brown.

Checking Casey's Test Donation Plan details confirms the ledger entry:

• Recipient Alias: CaseyBrown
• Description: Donation
• Hours Credited: 10 Hours
• Total Available Balance: 10 Hours

Figure 9: Casey Brown's Test Donation Plan credited with 10 Hours from Curtis.

---

Step 7: Submit Sick Leave & Verify Cascading Balance Consumption

Casey submits a Sick leave absence for 9 Hours on date 9/18/26.

Figure 10: Absence transaction submitted and completed for 9 hours of Sick Leave.

Processing Sequence:

1. The calculation engine checks Priority 20 (Sick Plan). The balance is 0, so 0 hours are deducted.
2. The engine cascades to Priority 30 (Test Donation Plan).
3. It identifies 10 hours available, decrements 9 Hours, and sets the transaction status to Completed.

Inspecting Casey's Donation Plan Balance summary ledger confirms the updated balance:

• Donation: +10 Hours
• Absence: -9 Hours
• Net Available Balance: 1 Hour

Figure 11: Casey Brown's Test Donation Plan balance ledger showing 1 Hour remaining after consuming 9 hours.

---

🔑 Implementation Takeaways

• Plan Type Selection: Choose Individual on the donation plan to support direct peer-to-peer transfers with recipient aliases.
• Plan-Level Restriction: Donations must be explicitly enabled per plan. Since only Sick was configured, Curtis can only donate Sick hours, protecting other balances (such as Vacation).
• Recipient Enrollment: The recipient must be actively enrolled in the Donation Plan before transfers can occur or absence deductions can resolve against the plan.
• Priority Ordering: Ensure the primary accrual plan has a lower numeric priority than the donation plan (e.g., 20 vs 30) so personal balances are exhausted before donated hours are consumed.
• Auditability: Transferred hours and absence deductions are recorded in ANC_PER_ACCRUAL_ENTRIES under distinct transaction types (Donation and Absence), simplifying audit tracking in OTBI and BI Publisher.