California Straight Time and Unpaid Time calculation - Time Calculation Rule

Oracle Cloud Time & Labor · Fast Formula Deep Dive

California Straight Time & Unpaid Time Rules: Reconciling Weekly Schedules & Shortfalls

Leveraging HWM array iterations to evaluate worked hours against published schedule thresholds and automate unpaid variance tracking

Formula NameOTL_US_CA_STRAIGHT_TIME_FF

Formula TypeTime Calculation Rule

JurisdictionCalifornia (CA Alternative Schedules)

Summation LevelTIMECARD (Period close reconciliation)

1. The California Compliance Context

Under California wage regulations, standard work arrangements often contend with complex Alternative Workweek Schedules (AWS), collective bargaining rules, or nonexempt salaried arrangements (such as 32, 35, or 37.5 scheduled weekly hours). In these setups, straight-time evaluation cannot simply rely on a fixed 40-hour threshold:

• Contractual Straight Time: Regular worked time is protected up to the employee's assigned schedule for that week (e.g., 37.5 hours). Any additional hours worked up to statutory thresholds must be classified as a distinct Straight Time attribute (OUT_MEASURE_STRAIGHT_TIME).
• Absence Credit Protection: Approved absence hours (e.g., California Paid Sick Leave or Vacation) must count toward satisfying the weekly schedule requirement, preventing employees from losing straight time entitlement when taking authorized leaves.
• Unpaid Time Deficit Calculation: When an employee fails to log their full scheduled hours and lacks paid leave to bridge the gap, the unworked shortfall must be quantified as Unpaid Time (OUT_MEASURE_UNPAID_TIME) to facilitate automatic salary docking or compliance tracking.

The formula OTL_US_CA_STRAIGHT_TIME_FF connects with the schedule subroutine XX_UTIL_GET_EMPLOYMENT_SCHEDULE, caching the worker's exact weekly schedule limit as weekly_sch_hrs before processing the time card details.

2. End-to-End 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

📉 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 reduction element, Global Payroll can automate salary docking without manual administrator recalculation.

3. Array Inputs & Outputs Specification

Parameter Name	Classification	Behavior in Calculation
HWM_CTXARY_RECORD_POSITIONS	Context Array	Marks array record phases: HEADER, DETAIL, or END_PERIOD.
PayrollTimeType / AbsenceType	Input Arrays	Distinguishes worked time (Regular Hours) from approved leaves so absences fulfill schedule obligations.
OUT_MEASURE_UNDER	Output Array	Net regular hours per row that remain within the weekly schedule baseline.
OUT_MEASURE_STRAIGHT_TIME	Output Array	Surplus hours over the schedule written at END_PERIOD to the last regular hours row index.
OUT_MEASURE_UNPAID_TIME	Output Array	Deficit measure calculated when reported hours fall below schedule (weekly_sch_hrs − calc_reg_hours_wk).

4. Formula Source Code

/* +======================================================================+
   | Formula Name : OTL_US_CA_STRAIGHT_TIME_FF                            |
   | Formula Type : Time Calculation rule                                 |
   | Jurisdiction : California (CA Alternative / Weekly Threshold)        |
   | 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  

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

measure_period = GET_CONTEXT(HWM_MEASURE_PERIOD, 0)  

/* Rule Header & Parameters */
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) 

/* Initialize Output Array Variables */  
OUT_MEASURE_UNDER         = EMPTY_NUMBER_NUMBER
OUT_MEASURE_STRAIGHT_TIME = EMPTY_NUMBER_NUMBER
OUT_MEASURE_UNPAID_TIME   = EMPTY_NUMBER_NUMBER

/* Workarea Setup */   
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

/* Process Time Card Arrays */
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. Header Evaluation: Fetch California Assigned Schedule */
  IF (aiRecPosition = 'HEADER') THEN (
    weekly_sch_hrs = 0
    IF (STARTTIME.exists(nidx)) THEN ( aiStartTime = STARTTIME[nidx] ) 
    IF (STOPTIME.exists(nidx))  THEN ( aiStopTime  = STOPTIME[nidx] ) 

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

  /* 2. Detail Evaluation: Accumulate 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 Evaluation: Accumulate Authorized Absences */
  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 Close: Reconcile Straight Time or Unpaid Deficit */
  ELSE IF (aiRecPosition = 'END_PERIOD') THEN (
    /* Case 1: Threshold reached and straight time surplus exists */
    IF (calc_reg_hours_wk = weekly_sch_hrs AND st_time > 0) THEN (
      OUT_MEASURE_STRAIGHT_TIME[st_time_idx] = st_time
    ) 
    /* Case 2: Reported hours short of schedule -> calculate unpaid gap */
    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)      
    )
  )

  /* Loop Guard */
  IF (nidx > 1000) THEN (
    ex = raise_error(ffs_id, rule_id, 'Formula ' || ffName || ' terminated: loop limit exceeded.') 
  )     
)

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

RETURN OUT_MEASURE_UNDER, OUT_MEASURE_STRAIGHT_TIME, OUT_MEASURE_UNPAID_TIME

⚠️ California Architectural Considerations for ACE Reviews

• Index Binding: Both OUT_MEASURE_STRAIGHT_TIME and OUT_MEASURE_UNPAID_TIME are written to st_time_idx (the last processed Regular Hours index). Confirm whether the payroll calculation card mapping expects variances on the final worked row or on a separate summary layout line.
• Absence Interaction: Absences fulfill the schedule requirement (calc_reg_hours_wk += tcMeasure). Because OUT_MEASURE_UNDER is not set for absence rows, native absence plan balances and costing remain managed within Absence Management without duplication.
• Payroll Deduction Integration: When mapping OUT_MEASURE_UNPAID_TIME, ensure the corresponding Time Consumer Set passes this value to a negative earnings or deduction element to automate salary reconciliation.

Oracle Cloud Time & Labor Architecture California Alternative Schedule & Straight Time Pattern

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.

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.

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.

Field	Value Selected	What It Controls
Legislative Data Group	US Legislative Data Group	Scopes the element to a specific country/legislation's payroll rules — here, the US.
Primary Classification	Absences	Tells the wizard to build an absence-specific element, which is what unlocks the Accrual/Entitlement/Disbursement child-element generation later.
Secondary Classification	Vacation	Further categorizes the absence type (e.g. Vacation vs Sickness) — this drives some of the default behavior and reporting grouping.
Category	Absence (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.

Field	Value Selected	What It Controls
Name / Reporting Name / Description	Vacation USA	The element's identity throughout the application, payslips, and reports.
Effective Date	1/1/51	Deliberately 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 Currency	US Dollar	The currency used wherever this element carries a monetary value (e.g. payouts, liability).
What calculation units are used for reporting?	Hours	Decides 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 Rule	Assignment Working Hour	Tells 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 Absences	The 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.

Field	Value Selected	What It Controls
Calculate absence liability?	Yes	Enables 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?	Yes	Allows 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?	Regular	Regular 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?	Yes	Allows 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?	Regular	Same Regular vs Supplemental choice, applied specifically to discretionary cash-outs.
Does this plan enable absence donation to donation pools?	No	Leaves 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.

Field	Value Selected	What It Controls
How do you want to reduce earnings for employees not requiring a time card?	Reduce regular earnings by absence payment	For 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?	Regular	Tax treatment for the ordinary, in-service absence payment itself.
Does this plan enable entitlement payments after termination?	Yes	Allows 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?	No	Controls 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?	No	Excludes 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?	No	Same 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).

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:

Child Element Group	Purpose
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 Only	Feeds 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.

Oracle HCM Absence Design Guide: When Can You Skip the Absence Plan?

During functional and technical design phases of an Oracle Cloud Absence Management implementation, consultants and solution architects frequently encounter a fundamental configuration question: Does every Absence Type mandate an associated Absence Plan?

A frequent anti-pattern across enterprise implementations is the blanket creation of an Absence Plan for every single Absence Type "just to be safe." While this approach might appear harmless during the initial sandbox prototyping stage, it creates substantial technical debt down the line. It causes unnecessary batch processing overhead during scheduled accrual calculations, introduces UI bloat across employee self-service pages, complicates security profiling, and adds administrative maintenance hurdles. Conversely, failing to associate a plan when one is strictly necessary leads to uncalculated salary adjustments, absent ledger tracking, and broken integration handoffs with Global Payroll.

This technical guide provides an exhaustive architectural deep dive into the functional distinctions, underlying data models, Fast Formula impacts, Global Payroll interfaces, and batch performance implications of deploying standalone Absence Types versus plan-linked configurations.

---

1. Deconstructing Core Responsibilities: Absence Types vs. Absence Plans

To establish clean configuration boundaries, it is essential to understand the separate responsibilities each object holds in the Oracle Fusion data schema:

A. Absence Type (The Front-End & Transactional Layer)
The Absence Type serves as the entry portal for the worker and manager. It defines how time off is requested, validated, categorized, and approved. Its functional and technical scope includes:

• Pattern Definition: Classifies the absence into core engine behaviors: Generic Absence, Illness or Injury, or Childbirth or Adoption.
• Duration Units of Measure (UOM): Determines whether the duration is evaluated in Calendar Days, Elapsed Days, Working Days, or Schedule Hours via the employee’s work schedule or work pattern.
• Validation Rules: Enforces minimum and maximum durations per single submission, advance notice periods, waiting periods, and retroactive date entry restrictions.
• Workflow & Approvals: Directly interfaces with the Transaction Console (TAC) and Oracle BPM Worklist to route approval workflows based on line manager, matrix manager, or HR specialist hierarchies.
• User Interface Behavior: Controls attachment requirements, entry reasons, descriptive flexfields (DFFs), and Redwood Express Mode / Visual Builder Studio display rules.

B. Absence Plan (The Back-End Calculation & Financial Ledger)
The Absence Plan operates as the background engine that executes business logic, rules, and mathematical balances. Its functional and technical scope includes:

• Balance Maintenance: Functions as a balance ledger maintaining opening balances, periodic accruals, manual adjustments, forfeitures, carryover expiries, and terminal disbursements.
• Entitlement Matrices: Evaluates service-based tiers (e.g., tenure-based accrual bands or statutory sick leave matrices) via length-of-service banding or user-defined Fast Formulas.
• Payment Band Splitting: Automatically segments a single continuous absence request into multiple payment brackets (such as 100% full pay, 50% half pay, and unpaid days).
• Payroll Calculation Hand-off: Feeds rate definitions and calculation components into Oracle Fusion Global Payroll via employee calculation cards.
• Batch Processing: Evaluated during nightly Enterprise Scheduler Service (ESS) jobs such as Update Accrual Plan Enrollments and Calculate Accruals and Balances.

Key Architectural Rule: The Absence Type captures that a worker is absent from their schedule. The Absence Plan evaluates whether that absence is paid or unpaid, assesses entitlements, updates running balance ledgers, and passes payment calculation directives to payroll engines.

---

2. Detailed Functional Decision Matrix

Use the following matrix during design sessions to map client policy requirements to the correct technical architecture:

Business Scenario / Policy	Plan Required?	Plan Type	Architectural & Configuration Rationale
Informational & Remote Work (WFH, Travel, Training)	No Plan	None	Pure calendar availability tracking. Blocks employee schedules in Time & Labor without balance accrual, ceiling limits, or salary changes.
Statutory Bereavement / Jury Duty (Fixed Non-Cumulative Caps)	No Plan*	None	When policy states "up to 3 consecutive days paid as standard salary per event," enforce validation limits via Type settings without a plan. If an annual cumulative bank must be tracked across multiple events, a plan is required.
Annual / Earned Vacation Leave	Yes	Accrual Plan	Tracks earned units, proration rules, carryover ceilings, vestings, and terminal balance cash-outs upon employment end.
Maternity, Paternity & Long-Term Illness	Yes	Qualification Plan	Splits entry duration into tiered compensation brackets (e.g., 100% pay for first 30 days, 50% for next 30 days, unpaid thereafter) based on tenure and rolling backward/forward evaluation windows.
Unpaid Leave (Leave Without Pay - LWOP)	Yes	No Entitlement Plan	Acts as an unaccrued calculation bridge. Evaluates no running balance, but creates an automated deduction record on payroll calculation cards to dock base pay.
Overtime In Lieu / Compensatory Time (TOIL)	Yes	Compensatory Plan	Stores hours earned through approved overtime (either manually or transferred from Time and Labor) and applies specific expiration policies (e.g., must be redeemed within 90 days).
Leave Donation / Catastrophic Leave Pool	Yes	Donation Plan	Provides the recipient account structure to receive leave hours debited from donating colleagues' accrual plans.

---

3. Technical Mechanics: Global Payroll Integration

One of the most consequential reasons to configure an Absence Plan is the automated transfer of payment calculations into Oracle Fusion Global Payroll. The absence-to-payroll pipeline functions through dedicated objects:

A. Standalone Absence Type Behavior (No Plan Linked)
When an employee books a standalone Absence Type, the application writes entries to the core table ANC_PER_ABSENCE_ENTRIES. However, the system does not generate entries in payroll calculation tables. Unless an administrator manually keys an element entry into the worker's payroll records, the payroll run processes their standard earnings without any deduction or special rate calculation. Therefore, standalone types are unsuitable for leaves that modify earnings or require separate line items on the payslip.

B. Plan-Linked Absence Behavior (Via Calculation Cards)
When an Absence Plan is associated with a Payroll Element, the end-to-end interface operates as follows:

• The plan is linked to a pre-configured Payroll Element with the primary classification Absences.
• When an absence entry is submitted and approved, the absence engine creates a record under the worker’s Calculation Card: Calculation Component - Absence.
• The payroll run checks the calculation component, fetches the absence units, applies the assigned Rate Definition (e.g., standard basic pay rate, 50% band rate, or average earnings rate), and executes the payroll formula.
• For unpaid leaves, a No-Entitlement Plan sends deduction units into payroll, cleanly reducing standard gross wages without requiring manual HR input.

---

4. Engine Overhead: Fast Formulas & Batch Processing Performance

A frequently neglected area during implementation is system performance. Enrolling thousands of workers into unnecessary plans introduces severe overhead into daily and monthly scheduled processes.

A. Fast Formula Execution Cycle
Every plan enrolled to an employee evaluates complex Fast Formula hooks, including:

• Global Absence Accrual: Runs to calculate repeating earned amounts, length-of-service banding, and step progressions.
• Global Absence Proration: Calculates partial-period earnings during hire, mid-period tenure changes, or assignment status changes.
• Global Absence Ceiling: Enforces maximum balance limits at accrual time or term ends.
• Global Absence Carryover: Evaluates unused balance transfers and manages balance expiration dates.

B. Impact on ESS Batch Processes
Enterprise scheduled jobs evaluate these plans across your entire workforce:

• Update Accrual Plan Enrollments: Evaluates eligibility profiles and formulas for every enrolled worker to confirm plan participation.
• Calculate Accruals and Balances: Processes all plan formulas and calculates balance adjustments across assignments.

Performance Takeaway: In an enterprise with 50,000 employees, creating an unnecessary plan for a purely informational absence adds 50,000 extra formula evaluations to nightly and weekend ESS maintenance jobs. Keeping informational absences as standalone Absence Types eliminates this processing overhead.

---

5. User Experience: Redwood UI Differences

Oracle HCM's Redwood user interface dynamically alters the front-end layout based on whether an Absence Type has an underlying Absence Plan attached:

• Standalone Absence Type Experience: When the employee selects a standalone type, the interface presents a simplified form showing date selectors, duration totals, reason picklists, and comment/attachment cards. The page does not render balance tiles, projected balances, or accrual warnings. This creates a clean experience for quick tasks like recording work-from-home or training days.
• Plan-Linked Experience: When the employee selects a plan-linked type, the interface dynamically displays balance metrics. It calculates and renders the current available balance, balance at the date of absence, projected accruals, pending approvals, and carryover expiry warnings. For Qualification Plans, it outlines remaining entitlement bands (e.g., displaying how many days remain at full pay vs. half pay).

---

6. Architecture Checklist & Troubleshooting Guide

Before creating a new plan in your setup workbook, walk through these evaluation criteria:

1. Balance Ledger Needed? Does HR need a persistent record of accrued, used, and remaining units over time?
   → Yes: Configure an Accrual Plan.
2. Tiered Compensation Rules? Does payment change across the leave period based on tenure or statutory rules?
   → Yes: Configure a Qualification Plan.
3. Direct Payroll Reductions? Must taking this absence automatically dock the employee's base salary via element entries?
   → Yes: Configure a No-Entitlement Plan linked to an Absence Element.
4. Simple Visibility & Approval? Does the business only need calendar blocking and line-manager workflow approvals?
   → Yes: Keep it as a Standalone Absence Type.

Troubleshooting Common Setup Traps:

• "Unpaid leave was entered, but employee received full salary." This happens when Unpaid Leave is configured as a standalone type without a No-Entitlement plan, preventing rate reduction components from reaching the payroll calculation card.
• "The employee cannot see balance cards on the Redwood Time Off page." Verify that the Absence Plan is linked directly to the Absence Type in the Type > Plans and Reasons setup tab, and that the worker is actively enrolled in the plan.
• "Accrual batch job execution times are growing rapidly." Audit your configuration for informational absences inadvertently tied to accrual plans. Unlink unnecessary plans to reduce formula evaluation cycles.

Designing absence management setups around these principles helps keep your configurations clean, your batch maintenance runs fast, and your payroll integrations dependable across your Oracle Cloud HCM deployment.