Saturday, 26 September 2026

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

Friday, 25 September 2026

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.

Time Calculation Rule Configuration and Outputs
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.

Integrating Absence Management with Oracle Time and Labor (OTL)

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.
Edit Absence Type Sick: Enable entry in time card and calendar
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.
Search Time Entry Layout Components: Hours Type Hourly
Figure 2: Locating the 'Hours Type (Hourly)' multiple attribute time card field component.
  1. Open the component definition to configure the Display Value and Attribute Definition.
  2. 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).
Edit Time Card Field: Field Definition - Vacation and Sick mapped to Absence Management Type
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).
Layout Sets search results: Bi-Weekly Hourly Payroll
Figure 4: Selecting the target Layout Set from search results.
  1. 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.
Define Layout Set overview with Time Consumer Set and Layout navigation
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.
Configure Time Entry Layout - Time Card Fields
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.

Thursday, 24 September 2026

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.
Create Absence Plan - Plan Type Donation
Figure 1: Initializing a new Absence Plan with Plan Type set to Donation.
  1. 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
Test Donation Plan Setup - Plan Attributes Tab
Figure 2: Defining General Attributes with Donation Type set to Individual.
  1. 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.

  2. Click Save and Close.
Test Donation Plan - Participation Tab
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.
Edit Absence Plan Sick - Donation Permissions and Limits
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).
Select and Add Plan to Type - Priority 30
Figure 5: Adding Test Donation Plan to Absence Type Sick with Priority 30.
View Type Sick - Plans and Reasons Priority Overview
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.
Enrolling Casey Brown into Test Donation Plan
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.

Curtis Feitty Existing Absences Curtis Feitty Manage Absences and Entitlements Header Curtis Feitty Plan Balances 54 Hours Sick
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
Test Donation Plan Balance - 10 Hours Received
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.

Existing Absences - 9 Hours Sick Completed
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
Test Donation Plan Balance - 1 Hour Remaining Ledger
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.

Wednesday, 23 September 2026

Creating Absence Element(for Accrual Plan) for integrating Absences with Payroll

Absence Management only talks to Payroll through one bridge: an Absence element. Without it, an Accrual Plan can track balances beautifully in the UI, but nothing about a taken absence — the payment, the liability, the eventual payout — ever reaches a payslip. This post walks through creating that element end-to-end, screen by screen, explaining what each field on the Create Element wizard actually controls, and what Oracle silently builds for you underneath it once you submit.

Navigate to Setup and Maintenance → Elements → Create New Element to get started.

Step 1: Choose the Classification

The very first screen decides the entire template the wizard will use for the rest of the setup.

Create Element dialog showing Legislative Data Group, Primary Classification (Absences), Secondary Classification (Vacation)
FieldValue SelectedWhat It Controls
Legislative Data GroupUS Legislative Data GroupScopes the element to a specific country/legislation's payroll rules — here, the US.
Primary ClassificationAbsencesTells the wizard to build an absence-specific element, which is what unlocks the Accrual/Entitlement/Disbursement child-element generation later.
Secondary ClassificationVacationFurther categorizes the absence type (e.g. Vacation vs Sickness) — this drives some of the default behavior and reporting grouping.
CategoryAbsence (auto-populated)Read-only, derived from the classification choice above.

Step 2: Basic Information

Next, the wizard asks for the element's identity and the core rules that shape how the absence plan reports and reconciles with payroll.

Create Element: Basic Information screen for Vacation USA
FieldValue SelectedWhat It Controls
Name / Reporting Name / DescriptionVacation USAThe element's identity throughout the application, payslips, and reports.
Effective Date1/1/51Deliberately set far in the past so the element is available for any employee regardless of hire date — a standard Oracle convention for foundational setup objects.
Input CurrencyUS DollarThe currency used wherever this element carries a monetary value (e.g. payouts, liability).
What calculation units are used for reporting?HoursDecides whether absence duration is reported/stored in Hours or Days for this plan — this must be consistent with how the linked Accrual Plan measures balances.
Work Units Conversion RuleAssignment Working HourTells the system how to convert an employee's working pattern into hours where a conversion between days and hours is needed, based on their assignment's standard schedule.
What type of absence information do you want transferred to payroll?Accrual Balances and AbsencesThe single most important field on this screen. Four options exist: Accrual Balances (only the running balance shows on the payslip, no actual payment), Accrual Balances and Absences (both the balance and the taken absence are transferred, so the employee is actually paid for the leave), Qualification Absences (used for occurrence-tracking, non-monetary plans), and No Entitlement Absences (purely informational, nothing flows to payroll). Selecting Accrual Balances and Absences is what makes this a true payroll-integrated element.

Step 3: Additional Details — Accrual Liability and Balance Payments

This screen configures how unused leave is valued as a financial liability, and how balances get paid out.

Create Element: Additional Details screen - Accrual Liability and Balance Payments
FieldValue SelectedWhat It Controls
Calculate absence liability?YesEnables the system to calculate the monetary value of an employee's unused, accrued balance — typically used for GL costing/accounting of leave liability.
Which rate should the liability balance calculation use?(left blank here)Would point to a Rate Definition that determines the per-unit value used in the liability calculation; this is commonly configured after the element is created, once the Rate Definition exists.
Does this plan enable balance payments when enrollment ends?YesAllows the remaining balance to be paid out to the employee when their enrollment in the plan ends (e.g. at termination).
Which rate should the final balance payment calculation use?(left blank here)Same idea as above — the Rate Definition used to value the final payout.
How do you want Payout Amount to be taxed?RegularRegular taxes the payout like normal wages; Supplemental applies a flat supplemental tax rate instead — relevant for US payroll tax treatment.
Does this plan enable partial payment of balance?YesAllows an employee to cash out part of their balance while still employed, rather than only at termination — this is the "discretionary disbursement" scenario.
Which rate should the discretionary disbursement calculation use?(left blank here)The Rate Definition used to value a partial, employee-requested cash-out.
How do you want Cash out amount to be taxed?RegularSame Regular vs Supplemental choice, applied specifically to discretionary cash-outs.
Does this plan enable absence donation to donation pools?NoLeaves leave-sharing/leave-donation functionality disabled for this plan.

Step 4: Absence Payments, Special Rules and Overtime Rules

The final configuration screen covers how absence pay is actually calculated for non-timecard employees, plus a few compliance-related switches.

Absence Payments, Special Rules and Overtime Rules section
FieldValue SelectedWhat It Controls
How do you want to reduce earnings for employees not requiring a time card?Reduce regular earnings by absence paymentFor salaried/exempt staff with no timecard, this decides whether the system simply deducts the standard absence payment from regular earnings, or instead uses a specific rate to calculate the deduction amount.
How do you want Absence Payment to be taxed?RegularTax treatment for the ordinary, in-service absence payment itself.
Does this plan enable entitlement payments after termination?YesAllows any additional entitled amount to still be disbursed after termination processing has occurred — this is what generates the "Entitlement" family of child elements.
Is this element subject to retroactive recoveries?NoControls whether retroactive payroll processing will attempt to recover overpayments associated with this element.
Should this element be included in the earnings calculation of the overtime base rate?NoExcludes absence earnings from the calculation used to determine an employee's overtime base rate (relevant for US FLSA overtime rules).
Should this element be included in the hours calculation of the overtime base rate?NoSame idea, applied to the hours side of the overtime base-rate calculation.

Step 5: Review and Submit

The Review screen lays out every choice made across all previous steps as a Default Option vs Selected Option comparison — a good last checkpoint before committing, especially useful for spotting where you deviated from Oracle's out-of-the-box defaults (for example, note how several "No" defaults were deliberately changed to "Yes" here to enable balance payments, partial payments, and post-termination entitlement payments).

Create Element: Review screen part 1
Create Element: Review screen part 2

What Gets Created Automatically: The Child Elements

Clicking Submit doesn't just create one element — it silently generates an entire family of supporting elements needed to process every scenario configured above. Searching for "Vacation US" in Setup and Maintenance → Elements shows the full set:

Elements search results showing Vacation US child elements part 1
Elements search results showing Vacation US child elements part 2
Child Element GroupPurpose
Vacation US Accrual (+ Calculator, Result)Drives the liability calculation — the monetary value of the employee's unused accrued balance, feeding accounting/GL costing.
Vacation US Discretionary Disbursement (+ Calculator, Earnings Calculator, Earnings Distributor, Earnings Results, Earnings Retro Results, Result, Retro)Handles employee-requested payouts — a partial cash-out of balance while the employee is still active, enabled by the "partial payment of balance" setting.
Vacation US Entitlement (+ Calculator, Earnings Calculator, Earnings Distributor, Earnings Results, Earnings Retro Results, Result, Retro)Supports entitlement payments after termination — generated because that option was set to Yes in Step 4.
Vacation US Final Disbursement (+ Calculator, Earnings Calculator, Earnings Distributor, Earnings Results, Earnings Retro Results, Result, Retro)Handles the termination payout — the full remaining balance paid out when the employee's enrollment ends, per the "balance payments when enrollment ends" setting.
Retro elements (within each group above)Process back-dated payouts — adjustments triggered when a retroactive change affects a disbursement, entitlement, or final payout that was already processed.
Vacation US Overtime OnlyFeeds the overtime base-rate calculation, relevant only if the overtime inclusion questions in Step 4 had been set to Yes.
Tip: You never process these child elements directly. They exist purely so the payroll engine has a dedicated element for each distinct calculation (accrual, disbursement, entitlement, retro) behind the scenes. Your day-to-day interaction stays with the primary "Vacation US" element and the Accrual Plan it's attached to.

Conclusion

A single pass through the Create Element wizard does a lot of invisible work: one set of Yes/No answers about liability, payouts, and termination behavior determines an entire family of supporting elements generated automatically. Understanding what each field actually switches on — rather than accepting the defaults blindly — is the difference between an absence plan that merely tracks a balance and one that correctly pays, liabilities, and reconciles through Oracle Cloud Payroll.