Oracle HCM Time & Labor —
100 Interview Questions & Answers

Oracle HCM Time & Labor (OTL) is a core module within Oracle HCM Cloud that enables organizations to capture, manage, validate, and process employee time and labor data. It supports both hourly and salaried workers across diverse work schedules and policies.

• Single Platform: OTL shares the same data model as Oracle Core HR and Payroll — time entries flow directly to payroll without manual interfaces
• Key Capabilities: Time card entry (web & mobile), work schedule management, time rules and policies, absence integration, manager approvals, and payroll transfer
• Integration Points: Tightly integrated with Oracle Absence Management, Global Payroll, Project Costing (for project time), and HCM Core HR
• Workforce Coverage: Supports full-time employees, part-time workers, contractors, and shift workers with complex scheduling needs

Oracle Time & Labor consists of several interconnected components:

• Time Cards: The primary mechanism for workers to report time worked, absences, and project allocations
• Work Schedules: Define when and how much an employee is expected to work (shifts, days, hours)
• Time Entry Rules: Business rules that validate, calculate, and transform time entries (e.g., overtime, rounding)
• Time Processing Rules: Rules that apply during payroll time processing to compute pay codes
• Time Consumer Sets: Define which downstream systems (Payroll, Projects) consume the time data
• Approval Workflows: Manager and administrator review and approval of submitted time cards
• HCM Groups: Worker groupings that determine which rules and schedules apply to specific employees

A Time Card is the electronic record through which employees report their time for a specific period (usually weekly or bi-weekly). It is the fundamental unit of time capture in Oracle Time & Labor.

• Time Period: Defined by the Time Card Period (weekly, bi-weekly, semi-monthly, etc.)
• Time Entries: Each row captures date, hours worked, and associated attributes
• Reporting Attributes: Cost Center, Department, Project, Task, Absence Type, Payroll Time Type
• Status Tracking: Draft, Submitted, Approved, Rejected, Transferred to Payroll
• Submission: Via web browser, mobile app, or time clock devices

A Time Consumer Set defines which downstream applications receive and consume time data from Oracle Time & Labor. It acts as the routing mechanism for processed time entries.

• Consumers: Typical consumers include Oracle Global Payroll, Oracle Project Costing, and external third-party systems
• Assignment: Each worker (or HCM Group) is assigned a Time Consumer Set that determines where their time goes
• Transfer Rules: The set governs what time data attributes (Time Type, Cost Center, Absence Code) are passed to each consumer
• Configuration Path: Setup and Maintenance → Time and Labor → Time Consumer Sets

HCM Groups are defined sets of workers who share common time and labor rules, policies, or schedules. They are the primary mechanism for applying different time configurations to different worker populations.

• Purpose: Assign the same time entry rules, work schedules, approval workflows, and time consumer sets to a group of workers
• Membership Criteria: Workers are added based on assignment attributes — Legal Employer, Department, Job, Location, or manually selected
• Types of Usage: Used in Time Entry Rule Groups, Time Processing Rule Groups, and Work Schedule Assignments
• Dynamic Membership: Groups can be dynamically maintained — as workers change assignments, group membership updates automatically
• Configuration Path: My Client Groups → Time Management → HCM Groups

A Time Entry Profile controls the time card layout and behavior for a specific group of workers. It is the primary configuration object governing what workers see and can enter on their time cards.

• Layout: Determines which columns appear on the time card — Time Type, Absence Type, Project, Cost Center, Comments
• Time Capture Method: Duration-based (e.g., 8 hours) vs. Start/Stop (e.g., 08:00–16:00)
• Period Type: Weekly, bi-weekly, or custom time card periods
• Responsive Layout: Configures the mobile-optimized time card view
• Assignment: Linked to workers via Time Collection Device Processing Rules or directly via HCM Group
• Configuration Path: Setup and Maintenance → Manage Time Entry Profiles

• Duration-Based: Worker enters total hours for the day (e.g., 8 hours regular time). Simpler for salaried and office workers. No shift start/end times are captured
• Start/Stop Time Entry: Worker enters clock-in and clock-out times (e.g., 08:00–12:00, 13:00–17:00). Actual worked hours are calculated automatically. Required when break/meal deductions or shift differentials are needed
• Time Clock Integration: Start/stop is common when integrated with physical time clock devices (badge readers, biometric terminals)
• Choice Driver: Workforce type, pay rules, and industry requirements determine the appropriate method

A Time Card Period defines the frequency and boundaries of time card submission. It must align with the payroll frequency to ensure accurate payroll processing.

• Period Types Available: Weekly (Mon–Sun), Bi-Weekly, Semi-Monthly, Monthly, or Custom
• Anchor Date: The start date that anchors the period cycle (e.g., first Monday of the year)
• Configuration Path: Setup and Maintenance → Manage Time Card Periods
• Assignment: Each Time Entry Profile references a Time Card Period
• Best Practice: Align the time card period end date with the payroll period cutoff to avoid split-period processing issues

Payroll Time Types (PTTs) are the values workers select on their time cards to categorize the nature of the hours worked. They map directly to payroll elements for payment calculation.

• Examples: Regular Hours, Overtime Hours, Holiday Hours, On-Call Hours, Shift Differential
• Payroll Element Mapping: Each PTT is linked to a specific payroll element that determines how the hours are compensated
• Configuration: Setup and Maintenance → Manage Payroll Time Types
• Visibility Control: PTTs can be restricted to specific HCM Groups so workers only see relevant types
• System-Generated: Time rules can automatically assign PTTs (e.g., convert Regular to Overtime when threshold exceeded)

Correcting time after payroll runs requires careful handling to avoid duplicate payments or incorrect retro calculations.

• Retroactive Time Entry: If payroll supports retro-pay, corrected time cards trigger retro calculations in the next payroll run automatically
• Unlocking Time Cards: An administrator can unlock a processed time card via My Client Groups → Time Management → Time Cards — mark it as "Needs Correction"
• Retro Processing: Oracle Payroll's retroactive pay engine detects the changed time entries and generates retro adjustments
• Audit Trail: All changes to submitted or processed time cards are logged with user, timestamp, and reason code
• Best Practice: Establish a formal time correction process with approval gates to prevent unauthorized retroactive changes

A Work Schedule defines the expected working days, hours, and shifts for an employee. It is used by Time & Labor to validate time entries and by Absence Management to calculate absence duration in working days/hours.

• Components: Work Schedule → Work Pattern → Day Pattern → Time (start/end)
• Work Pattern: The repeating cycle of days (e.g., Mon–Fri 9–5, rotating 4-day weeks)
• Day Pattern: Defines the actual hours for a specific day type (Regular Day, Rest Day, Holiday)
• Assignment: Workers are assigned a Work Schedule via their Employment record or via a Schedule Assignment in Time Management
• Configuration Path: Setup and Maintenance → Manage Work Schedules

• Day Pattern: The lowest-level building block. Defines the hours for one specific type of day (e.g., Standard Day = 08:00–17:00 with 1 hr unpaid break = 8 working hours). Can also be Rest Day (0 hours) or Holiday
• Work Pattern: A sequence of day patterns forming a repeating cycle. Example: a 5-day work pattern = [Mon: Standard, Tue: Standard, Wed: Standard, Thu: Standard, Fri: Standard, Sat: Rest, Sun: Rest]. Complex shift workers might have a 14-day rotating pattern
• Work Schedule: Wraps the Work Pattern with an effective date and is the object assigned to workers

Rotating shifts require work patterns that span more than one week to represent the full rotation cycle before it repeats.

• Multi-Week Patterns: Build a Work Pattern that represents the full rotation (e.g., 3-week rotation = 21-day work pattern: Week 1 Morning, Week 2 Afternoon, Week 3 Night)
• Day Patterns per Shift: Create separate Day Patterns for each shift variant (Morning: 06:00–14:00, Afternoon: 14:00–22:00, Night: 22:00–06:00)
• Schedule Anchor Date: The effective date of the schedule assignment defines when the rotation cycle begins for each worker
• Schedule Exceptions: Individual shift swaps or changes can be managed via Schedule Exceptions without changing the underlying pattern

Work schedules can be assigned to workers through multiple mechanisms:

• Employment Record: A default work schedule can be set at the assignment level in Core HR
• Schedule Assignment (Time Management): My Client Groups → Time Management → Schedule Assignments — allows assigning a specific schedule with an effective date range
• HCM Group Default: A default schedule can be tied to an HCM Group so all group members share a schedule
• Hierarchy: Schedule Assignment (time-specific) overrides the Employment record schedule, which overrides the HCM Group default
• Mass Assignment: HSDL (HCM Spreadsheet Data Loader) or HCM Data Loader (HDL) can bulk-assign schedules for large populations

Schedule Management is an operational tool used by supervisors and schedulers to build, publish, and manage actual crew schedules on a day-to-day basis. Work Schedule configuration is the administrative setup of templates.

• Work Schedule Configuration: Defines repeating patterns (templates). Set up once by administrators. Applied automatically to workers over time
• Schedule Management: A visual scheduling workbench where supervisors build specific shift schedules for upcoming weeks, handle shift swaps, manage open shifts, and track coverage
• Open Shifts: Supervisors can post open shifts that workers can bid on or be assigned to
• Schedule Publishing: Schedules are published to workers in advance; workers see their upcoming schedule via Employee Self-Service
• License Consideration: Full Schedule Management is an add-on capability — verify licensing before committing to this feature in an implementation

• Time Entry Rule: Fires at the point of time card submission (or save). Validates the time card against business rules — e.g., "Worker cannot enter more than 16 hours per day," "Project code is mandatory for workers in this department." Provides immediate feedback to the worker
• Time Processing Rule: Fires during the payroll time processing run. Transforms time entries — e.g., calculates overtime by converting Regular Hours to Overtime Hours when weekly total exceeds 40. Produces the final time results that transfer to payroll
• Sequencing Matters: Processing rules execute in a defined order within a Rule Group; the sequence determines which rule fires first on the same time entry

Overtime rules are configured as Time Processing Rules that monitor cumulative hours and reclassify regular hours to overtime when a threshold is crossed.

• Rule Type: Select "Period Hours Worked" or "Daily Hours Worked" as the rule category
• Threshold: Specify the overtime threshold (e.g., daily > 8 hours, or weekly > 40 hours)
• Input Time Type: The rule looks for entries of "Regular Hours"
• Output Time Type: Hours exceeding the threshold are reclassified to "Overtime Hours" Payroll Time Type
• Cascading Overtime: Double-time rules can be layered — e.g., hours over 8 = OT, hours over 12 = Double Time
• Rule Group: The overtime rule is added to a Time Processing Rule Group with the correct sequence and assigned to the relevant HCM Group

A Time Rule Group is a collection of Time Entry Rules or Time Processing Rules that apply together to a set of workers. It is the mechanism for organizing and assigning rules to the workforce.

• Two Types: Time Entry Rule Group (for validation at submission) and Time Processing Rule Group (for payroll calculation)
• Rules within the Group: Multiple rules can be included, each with a defined sequence number governing execution order
• HCM Group Assignment: A Rule Group is assigned to an HCM Group, ensuring all workers in that group have the same set of rules applied
• Effective Dates: Rule groups support effective dating, allowing rules to change for legislative or policy updates without retroactively affecting historical data
• Configuration Path: Setup and Maintenance → Manage Time Rule Groups

Meal break deduction rules automatically reduce paid hours by a defined break duration when certain conditions are met (e.g., shift exceeds a minimum length).

• Rule Type: "Meal Break" or "Auto Deduction" under Time Processing Rules
• Condition: Trigger the deduction only when total hours worked exceed a threshold (e.g., > 6 hours = deduct 30 min)
• Deduction Amount: Fixed duration (e.g., 30 minutes) or variable based on hours worked
• Time Entry Method: Most applicable for start/stop entry where actual clocked time includes breaks; the rule removes unpaid break time automatically
• Override: Rules can be configured to allow or prevent worker override if they waived their break (common in California compliance scenarios)

Time rounding rules normalize raw punch times to predefined intervals, reducing minor clock variations and simplifying payroll calculations.

• Round to Nearest: Punch times rounded to the nearest interval (e.g., nearest 15 minutes). 8:07 → 8:00; 8:09 → 8:15
• Round Up / Round Down: Always move in one direction — often used for clock-in (round up to protect employer) or clock-out (round down)
• 7/8ths Rule (FLSA): Punch within 7 minutes rounds back; punch 8+ minutes past rounds forward — common for 15-minute intervals
• Grace Period: Allow minor early clock-in without paying early (e.g., 5-minute grace before shift)
• Configuration: Rounding rules are configured within Time Processing Rules and linked to the appropriate Rule Group

Oracle Absence Management and Time & Labor are tightly integrated on the same HCM platform, enabling absence entries to automatically populate time cards and ensuring payroll receives both worked and absent time.

• Automatic Time Card Population: When a worker submits an absence (e.g., vacation, sick leave), the approved absence automatically creates time card rows for the absence period
• Absence Payroll Time Types: Each absence type is mapped to a Payroll Time Type (e.g., Sick Leave → Sick Pay element) so payroll processes it correctly
• Work Schedule Awareness: The system uses the worker's work schedule to determine which days and how many hours to populate on the time card
• Overlap Prevention: Entry rules prevent workers from recording both worked time and absence time on the same day

• Absence Type Configuration: The absence type in Oracle Absence Management must have "Allow entry in time" enabled and a Payroll Time Type mapped
• Time Entry Profile: The worker's Time Entry Profile must include the Absence attribute column on the time card layout
• Absence Payroll Time Type: A dedicated PTT (e.g., "Vacation Pay", "Sick Pay") must be created and linked to the absence type
• Integration Enabled: The HCM parameter for Time & Labor / Absence integration must be enabled in implementation options
• Work Schedule: Worker must have an active work schedule so the system can calculate absence hours correctly

Cancellation of an approved absence after time card submission triggers a cascade of updates:

• Time Card Update: The absence rows previously auto-populated on the time card are removed or reversed automatically
• Time Card Status: If the time card was already approved, it is moved back to "Needs Resubmission" status so the worker can re-enter their actual time
• Accrual Reversal: Absence Management reverses the accrual deduction for the cancelled period
• Payroll Impact: If payroll has already processed the time, a retro calculation is triggered in the next payroll run to recover absence pay and replace with worked time (if applicable)

Partial-day absences require both absence and worked time to coexist on the same time card row for the same date.

• Absence Type Configuration: The absence type must support "Allow Partial Day" entry, with duration in hours
• Time Card Behavior: The time card shows both the absence entry (e.g., 2 hrs Sick) and the worked time entry (e.g., 6 hrs Regular) for the same day
• Validation Rule: A time entry rule checks that the sum of absence + worked hours equals the scheduled hours for the day
• Start/Stop Scenarios: For start/stop entry, the worker enters clock-in/out for worked hours; the absence entry fills the gap based on the shift
• Manager Visibility: Managers reviewing the time card see both the absence and worked time in the same view

FMLA (Family and Medical Leave Act) tracking in Oracle requires coordination between Absence Management setup and Time & Labor configuration:

• Absence Plan: A dedicated FMLA absence plan is configured with a 12-week annual entitlement and qualifying reasons (serious health condition, family care, military)
• Leave of Absence Type: FMLA can run concurrently with paid leave (e.g., sick, PTO) — configure the plan to allow concurrent tracking
• Intermittent FMLA: Worker can take FMLA in individual hours or days; the time card must accommodate partial-day FMLA entries
• Payroll Time Types: Map FMLA absence entries to appropriate PTTs — paid leave PTTs when concurrent paid leave is used, or unpaid PTT when leave is exhausted
• Reporting: OTBI dashboards can be configured to track FMLA utilization, eligibility, and remaining entitlement by worker

Time card approval is the workflow-driven process by which submitted time cards are reviewed and approved before they are eligible for payroll processing.

• Worker Submits: Worker completes the time card and clicks Submit — status changes to "Submitted"
• Notification: Manager receives a bell notification and email to review the time card
• Manager Actions: Approve (moves to Approved), Reject (returns to worker with comment), or Request Correction
• Approval Status: Approved time cards are eligible for payroll time processing and transfer
• Admin Override: Time administrators can approve time cards on behalf of unavailable managers

Time card approval workflows are configured using Oracle BPM (Business Process Management) integrated with Time & Labor approval settings.

• Approval Configuration: Setup and Maintenance → Manage Time Card Approval — define the approval routing (Direct Manager, Position Hierarchy, Static List)
• Approval Rules: Condition-based rules can route to different approvers based on attributes (Department, Work Location, Hours Over Threshold)
• Skip Approval: Some worker groups can be configured to auto-approve time cards (e.g., salaried exempt workers with no variable pay)
• Escalation: Define escalation rules — if the manager has not acted within N days, escalate to the manager's manager or HR
• Parallel Approval: Multiple approvers can be required simultaneously (e.g., direct manager AND project manager for project-coded time)

Mass Time Approval allows a manager or administrator to approve multiple time cards simultaneously rather than approving them one by one.

• Access: Available in the manager's Time Management workarea — "Approve Time Cards" page shows all pending submissions for the team
• Filtering: Manager can filter by team, location, pay period, or status before selecting cards to approve
• Bulk Action: Select all or a subset and click Approve to process in bulk
• Use Case: Particularly valuable at period close when payroll deadlines require rapid approval of large teams
• Review Before Approving: Managers can still click into individual cards to review details before approving in bulk

• Delegation: Managers can delegate their approval authority to a colleague for a defined period via Worklist → Preferences → Vacation Rules in the BPM console
• Proxy Access: HR administrators can be granted proxy access to approve time cards on behalf of absent managers
• Escalation Rules: Configure automatic escalation — if no action taken within X days, the notification goes to the manager's manager
• Admin Override: Time administrators can process approvals directly via My Client Groups → Time Management → Time Cards
• Payroll Close Process: At payroll cutoff, a formal process should exist to identify and resolve unapproved time cards before running payroll

• Edit on Behalf: Manager can modify a time card before approving (e.g., correct a wrong project code) if the Time Entry Profile permits manager editing
• Enter Time on Behalf: Manager can create and submit a time card for a worker who failed to submit (useful for workers without computer access)
• Request Correction: Sends the card back to the worker with a specific comment explaining what needs to be fixed
• Override Entry Rule Exceptions: Managers with the Override privilege can approve time cards that triggered validation warnings (not hard errors)
• View History: Managers can see the full audit trail of who changed what on the time card and when

Time data transfer to payroll is a defined process that occurs during the payroll cycle:

• Step 1 — Process Time: Run the "Submit Time Cards" process for the pay period, which applies Time Processing Rules and generates time results
• Step 2 — Transfer to Payroll: Run the "Transfer Time Cards to Payroll" process which loads the processed time results as payroll element entries
• Element Entries Created: Each Payroll Time Type maps to a payroll element; hours are loaded as element entry values
• Payroll Element Processing: Oracle Payroll picks up these element entries during the payroll run and calculates gross pay
• Audit: Transfer logs show which time cards were transferred, any errors, and the resulting element entries

The "Retrieve Latest Results" process updates time cards with the most recent processed time results, ensuring the time card shows the actual hours that will be sent to payroll after all rules have been applied.

• Purpose: Confirms that processing rules (overtime, rounding, breaks) have been applied and shows the worker/manager the final calculated hours
• When to Run: After running the "Submit Time Cards" process and before transferring to payroll
• Visibility: Workers and managers can see the "Calculated Time" section on the time card showing original vs. processed hours
• Discrepancy Resolution: If calculated hours differ from expected, the team can investigate rule configuration before payroll runs

• Payroll Time Type (PTT): The time-layer classification that workers and rules use to categorize hours (e.g., Regular, Overtime, Holiday). Visible on the time card
• Payroll Element: The payroll-layer object that holds the compensation rules — rate, earning category, tax treatment
• Mapping: Each PTT is mapped to one Payroll Element in the Time Consumer Set configuration. When time is transferred to payroll, the system creates element entries based on this mapping
• One-to-One Mapping: Typically each PTT maps to one element, but a PTT can be mapped to multiple elements (e.g., split between regular earnings and a shift differential element)

When time cards fail to transfer to payroll, a structured diagnostic approach resolves most issues:

• Check Transfer Process Log: The "Transfer Time Cards to Payroll" process log shows error details — missing element entries, payroll assignment issues, consumer set problems
• Verify Time Consumer Set: Confirm the worker has a valid Time Consumer Set assigned and it includes a payroll consumer with the correct payroll definition
• Payroll Relationship: Worker must have an active payroll relationship for the period being transferred
• PTT-to-Element Mapping: Verify all PTTs on the time card are mapped to active payroll elements in the consumer set
• Time Card Status: Only Approved time cards are transferred. Check for cards still in Submitted or Draft status
• Element Eligibility: The payroll element must be eligible for the worker's payroll definition and assignment

Oracle Time & Labor integrates with Oracle Project Portfolio Management (PPM) to allow workers to record time against projects, tasks, and expenditure types directly on the time card.

• Project Attributes on Time Card: The Time Entry Profile includes Project, Task, and Expenditure Type columns when project time integration is enabled
• Dual Consumer: The Time Consumer Set is configured with both a Payroll consumer (for pay) and a Project Costing consumer (for cost allocation)
• Transfer to Projects: Separate process "Transfer Time to Projects" sends approved project-coded time to Oracle PPM as expenditure items
• Project Validation: Entry rules validate that project codes are active, the worker is a valid resource on the project, and budgets are available
• Cross-Charge: Project time enables inter-departmental or inter-company cost allocation for accurate project costing

Oracle Time & Labor implementation follows a structured sequence of configuration tasks:

• 1. Enable Time & Labor: Activate the OTL offering in Functional Setup Manager for the relevant Legal Employer(s)
• 2. Define Payroll Time Types: Create all PTTs and map to payroll elements
• 3. Create Day Patterns and Work Patterns: Define the building blocks for work schedules
• 4. Create Work Schedules: Assemble patterns into schedules and assign to workers
• 5. Configure Time Entry Profiles: Define time card layouts, capture methods, and periods
• 6. Define Time Rules: Create entry validation rules and processing (calculation) rules
• 7. Create HCM Groups: Group workers by rule and schedule requirements
• 8. Configure Time Consumer Sets: Map PTTs to payroll elements for each consumer
• 9. Set Up Approval Workflow: Configure approval routing and notifications
• 10. Test and Validate: End-to-end testing — submit, approve, process, and verify payroll transfer

The Time & Labor Offering is the collection of functional areas and setup tasks within Oracle Functional Setup Manager (FSM) that enables and configures the OTL module.

• Access: Setup and Maintenance → Offerings → Time and Labor
• Functional Areas: Includes Time Entry, Work Schedule Management, Absence Integration, Payroll Integration, and Reporting
• Opt In: Each functional area must be opted in before its configuration tasks become available
• Implementation Project: An implementation project can be created from the offering to track task completion and assign tasks to team members
• Scope: The offering is scoped to Legal Employer — different setups can be configured for different legal entities

HCM Data Loader (HDL) is used for bulk loading and migrating Time & Labor configuration and transactional data during implementation.

• Work Schedule Assignment: Bulk assign work schedules to large worker populations via the WorkScheduleAssignment business object
• HCM Group Membership: Load explicit group member assignments in bulk
• Time Card Migration: Historical time cards from legacy systems can be loaded using the TimeCard business object (typically for data conversion projects)
• Validation: HDL validates data against HCM configuration rules before loading — errors are reported in the process output
• Template Generation: HSDL (Spreadsheet Data Loader) provides Excel templates for smaller-volume loading with user-friendly column headers

Lookup Types are configurable lists of valid values used across Oracle HCM, including Time & Labor. They control dropdown menus and validations in time card configuration.

• ORA_HWM_TIME_TYPE: Lists valid Payroll Time Types that appear as selectable options on the time card
• Time Card Status Lookups: Control the valid status transitions for time cards
• Day Pattern Types: Define valid day classifications (Work, Rest, Holiday)
• Configuration: Setup and Maintenance → Manage Common Lookups — search for HWM (Time Management) lookup types
• Extensibility: User-defined lookup values can be added to extensible lookup types to support custom pay codes and work types

Multi-country T&L implementations require careful scoping to manage different legislative requirements, pay rules, and work culture practices across legal entities.

• Legal Employer Scoping: Time & Labor configuration objects (rules, schedules, profiles) can be scoped to specific Legal Employers to ensure isolation
• Separate Rule Groups: Each country or legal entity should have its own Time Processing Rule Groups to handle local overtime laws, break requirements, and holiday rules
• Country-Specific Payroll Time Types: Create PTTs that reflect the specific earning categories for each country's payroll (e.g., French "Heures Supplémentaires" vs US "Overtime")
• Localization: Use translated lookup values and time card labels for workers in non-English speaking countries
• Global Payroll Definitions: Ensure each country's Time Consumer Set references the correct payroll definition and element set for that legal employer
• Testing Strategy: Create separate test scripts per country; involve local HR and legal experts to validate rule correctness

Time Collection Devices (TCDs) are physical or virtual hardware devices (badge readers, biometric terminals, kiosks) that capture worker clock-in/clock-out punches and transmit them to Oracle Time & Labor.

• Integration: TCDs connect to Oracle via the Time Collection Device Processing framework or third-party middleware
• Auto Time Card Creation: Punch data from TCDs is processed to automatically create or update time card entries, eliminating manual entry for shop floor workers
• TCD Processing Rules: Configuration controls how raw punches are translated into time entries — which worker, which shift, which PTT
• Common Vendors: Kronos (now UKG), Workforce Software, ADP terminals, custom badge readers
• Exception Handling: Missed punches, unmatched worker IDs, or out-of-schedule punches generate exceptions for supervisor review

Holiday pay rules ensure workers receive appropriate compensation when they work or are absent on public holidays.

• Calendar Events: Public holidays are defined as Calendar Events in Oracle HCM and associated with a Calendar Event Category
• Work Schedule Holiday Days: The Day Pattern for calendar event days is set to "Holiday" with 0 scheduled hours
• Holiday Pay Rule: A Time Processing Rule checks if a worker's time entry falls on a Calendar Event day and reclassifies hours to the Holiday Pay PTT
• Premium Pay for Working Holidays: A separate rule can add a premium PTT (e.g., "Holiday Premium") on top of regular hours when a worker works on a holiday
• Automatic Holiday Entry: Some configurations auto-populate the time card with Holiday Pay hours if the worker doesn't record time on a holiday, avoiding missed pay

Calendar Events represent scheduled non-working days (public holidays, company shutdowns) that affect time calculation and absence accruals.

• Configuration: Setup and Maintenance → Manage Calendar Events — create events by date, name, and category
• Calendar Event Category: Groups of similar events (e.g., "US Federal Holidays", "UK Bank Holidays") assigned to specific countries or legal employers
• Work Schedule Impact: When a calendar event falls on a scheduled work day, the system recognizes it as a holiday, affecting absence duration calculations
• Time Rule Integration: Time Processing Rules reference calendar event categories to identify holiday dates and apply appropriate pay codes
• Absence Management: Absence plans can use calendar events to exclude holidays from absence day counts (worker on leave over a public holiday doesn't lose an absence day)

Shift differentials compensate workers with premium pay for working evening, night, or weekend shifts. They require a combination of time rules and payroll element configuration.

• Define Shift PTTs: Create distinct Payroll Time Types for each differential category (e.g., "Evening Shift", "Night Shift", "Weekend Premium")
• Time Processing Rule — Shift Classification: Rule checks the start/stop time of entries against time windows (e.g., entries between 18:00–22:00 = Evening Shift PTT)
• Payroll Element: Map each shift PTT to a payroll element with the premium rate formula (e.g., base rate × 1.15 for 15% night premium)
• Sequencing: Ensure the shift differential rule fires after the basic overtime rule to handle overlapping shift + overtime scenarios correctly
• Week Part Rules: Separate rules can identify Saturday/Sunday hours and apply weekend differential PTTs based on the day of week attribute

• Test Script Design: Create test cases for each business scenario — standard week, overtime week, public holiday, absence overlap, rotating shift, shift differential
• Time Card Scenarios: Test duration entry, start/stop entry, mobile entry, manager entry, and TCD punch scenarios
• Rule Testing: Submit time cards with threshold-crossing entries and verify processing rules produce correct PTT reclassification
• Payroll Transfer Testing: Complete end-to-end — submit → approve → process → transfer → verify payroll element entries in test payroll run
• Absence Integration Testing: Submit absences and verify they auto-populate time cards with correct hours and PTTs
• Negative Testing: Test entry rule violations — submit over-hour time cards, wrong project codes, missing mandatory fields — verify error messages
• Retro Testing: Make time card corrections after a test payroll run and verify retro adjustments are correctly generated

• Time Card Summary: Lists all time cards for a given period, showing worker, status, total hours by type
• Time Card Detail: Line-level view of every entry on each time card with calculated results
• Unapproved Time Cards: Identifies time cards that have been submitted but not yet approved — critical for payroll close
• Missing Time Cards: Lists workers who have not submitted a time card for the current period
• Overtime Summary: Aggregates overtime hours by worker, department, or cost center for a period
• Time Transfer Audit Report: Shows which time cards were transferred to payroll and any errors encountered

Oracle Transactional Business Intelligence (OTBI) provides several subject areas for Time & Labor analytics:

• Time and Labor — Time Cards Real Time: Reports on time card headers, entry lines, calculated results, and statuses
• Time and Labor — Calculated Time Real Time: Shows processed time results after rules have been applied — useful for verifying overtime and rounding calculations
• Time and Labor — Time Processing Results Real Time: Detailed results from time processing rule execution
• Worker Schedule Real Time: Provides work schedule assignments and expected scheduled hours per worker
• Absence Management Real Time: Cross-subject area analysis combining absence entries with time card data

• Subject Area: Use Time and Labor — Time Cards Real Time combined with Workforce Management — Worker Assignment Real Time
• Logic: Start with all active workers in the relevant time-eligible population, then perform an outer join to time cards for the target period; workers with no matching time card appear with null card status
• Key Filters: Active employment status, Time Consumer Set = Payroll (to exclude non-time workers), Time Card Period = current period
• Output Columns: Worker Name, Employee Number, Department, Manager, Last Submitted Date
• Scheduling: Schedule this report to run daily during the last week of each pay period and distribute to payroll admins and HR managers

• Subject Area: Time and Labor — Calculated Time Real Time — contains processed time type, hours, and worker/assignment details
• KPIs: Total Overtime Hours, Overtime % of Total Hours, Overtime Cost (linked to payroll element rate), Workers Exceeding Threshold
• Dimensions: Drill by Department → Team → Worker; filter by Legal Employer, Time Period, Location
• Trend View: Week-over-week overtime trend chart helps identify chronic overtime in specific departments
• Alert Tiles: Add a tile for "Workers with OT > 10 hrs this week" with traffic light indicator (green/amber/red)
• Integration with Workforce Management: Cross-join headcount data to show overtime per FTE — a more meaningful metric than raw hours for benchmarking

The Time Card Audit Report captures the full change history of time card entries, providing transparency and accountability for all modifications made to time records.

• What It Captures: Original entry, updated value, who made the change (worker, manager, or admin), timestamp, and the reason/comment provided
• Use Cases: Labour law compliance audits, payroll dispute resolution, internal audit reviews, fraud investigation
• Subject Area: Audit data can be accessed via HCM Audit framework reports or OTBI if audit history is enabled
• Enabling Audit: Setup and Maintenance → Manage Audit Policies → HCM → Time Card — select which attributes to audit (Hours, Time Type, Cost Center, Status)
• Retention: Audit data is retained per the organization's data retention policy; ensure this aligns with local labor law requirements (some jurisdictions require 3+ years of time records)

"Needs Resubmission" is a time card status indicating that the card was previously approved but a subsequent event has invalidated it, requiring the worker to review and resubmit.

• Triggers: Absence cancellation, work schedule change, retroactive assignment change affecting time reporting attributes
• Worker Action Required: The worker receives a notification to review the time card, make necessary corrections, and resubmit
• Payroll Impact: Cards in "Needs Resubmission" status cannot be transferred to payroll until they are re-approved
• Admin Visibility: Time admins can view all cards in this status via the Time Cards workarea and follow up with workers to resolve

Mid-period department transfers require the time card to accurately reflect time charged to each department for costing purposes.

• Split Time Card: The worker enters time with the old department code for dates before the transfer and the new department code for dates after — using the Cost Center or Department attribute on each time card row
• Automatic Assignment Mapping: If Cost Center is derived from the assignment, the system may automatically propose the correct cost center based on the effective date of the assignment change
• Rule Group Update: If the new department has different time rules (different HCM Group), the new rules apply from the effective date of the transfer
• Work Schedule Update: Update the schedule assignment effective date to match the transfer date if the new department has different working hours

• Hard Rule (Error): Blocks submission. The worker cannot submit the time card until the violation is resolved. Example: "Daily hours cannot exceed 16" — an error stops submission
• Soft Rule (Warning): Generates a warning message but still allows submission. Example: "You have entered more hours than scheduled — are you sure?" — the worker can acknowledge and submit anyway
• Manager Override: Some soft rules can only be overridden by a manager, not the worker — the card is submitted with a warning flag that the manager must explicitly acknowledge during approval
• Configuration: When creating a time entry rule, the "Rule Outcome" field determines whether it raises an Error (hard stop) or Warning (soft alert)

• On-Call PTT: Create a Payroll Time Type specifically for "On-Call" or "Standby" hours, mapped to a payroll element with the on-call flat rate or hourly rate
• Time Card Entry: Workers record on-call hours separately from worked hours using the On-Call PTT. Since on-call hours may overlap with rest periods, ensure the time card layout accommodates this (e.g., separate rows for the same date)
• Callback Scenario: If a worker is called in during on-call, a separate "Call-Back Premium" PTT handles the minimum callback pay (e.g., minimum 4 hours pay even if only 1 hour worked)
• Overtime Exclusion: Configure processing rules to exclude on-call hours from overtime threshold calculations if legally permissible

Compensatory time (Comp Time) allows workers to bank overtime hours for future time off instead of receiving overtime pay.

• Absence Plan for Comp Time: Create a Comp Time absence plan in Oracle Absence Management with an accrual formula that adds hours when overtime is worked
• Time Processing Rule: An overtime processing rule reclassifies excess hours to a "Comp Time Earned" PTT instead of an overtime pay PTT
• Accrual Feed: The "Comp Time Earned" PTT triggers an accrual transaction in the Absence Plan, adding the banked hours to the worker's balance
• Usage: Workers submit an absence of type "Comp Time Off" which draws from their comp time balance — these populate the time card as absence hours
• Cap and Expiry: Configure the absence plan with a maximum accrual cap and expiry rules to comply with labor law limits on comp time banking

• Integration vs Native: Oracle T&L is natively embedded in HCM Cloud — no interfaces needed to HCM or payroll. Third-party systems require integration connectors, which introduce latency, errors, and maintenance
• Scheduling Depth: Kronos/UKG has historically had deeper scheduling, workforce forecasting, and labor optimization features. Oracle's Schedule Management is improving but may lag for complex operations (healthcare, retail with predictive scheduling)
• Rule Complexity: Legacy Kronos customers with complex rule sets (multi-state, union contracts) often find replicating every rule in Oracle T&L challenging — a rule gap analysis is critical during scoping
• Device Ecosystem: Third-party TCD vendors have broader physical device ecosystems; Oracle relies on certified TCD partner integrations
• Total Cost: Eliminating a third-party time system reduces licensing, integration, and maintenance costs — a common ROI driver for Oracle T&L adoption

The "Submit Time Cards" scheduled process is the payroll-side process that applies Time Processing Rules to approved time card entries and produces processed time results ready for payroll transfer.

• Input: Approved time cards for the specified pay period and legal employer
• Processing: Applies all Time Processing Rules (overtime, rounding, shift differentials, meal deductions) in the sequence defined in the Rule Group
• Output: Calculated time results — transformed PTTs with final hours that map to payroll elements
• Frequency: Typically run once per pay period, though it can be run multiple times if cards are added or corrected
• Access: Payroll → Submit a Process → Submit Time Cards or scheduled via a payroll flow

Split cost center charging allows workers to distribute their hours across multiple cost centers in the same pay period — common for shared services workers or project-based charging.

• Time Card Layout: Add a Cost Center (or Department) attribute column to the Time Entry Profile
• Multiple Rows per Day: Workers enter multiple rows for the same date, each with a different cost center and corresponding hours (e.g., 4 hrs to Cost Center A, 4 hrs to Cost Center B)
• Validation Rule: An entry rule verifies the total daily hours across all cost center rows equals the scheduled hours, preventing over/under-charging
• Payroll Costing: The cost center attribute on each time entry flows through to payroll element entries, driving the Oracle Payroll costing allocation to the correct GL accounts

Time & Labor Implementation Options are global settings that govern overall system behavior and integration enablement across the OTL module.

• Absence Integration: Toggle to enable/disable the automatic population of time cards from approved absences
• Project Time Integration: Enable Oracle PPM (Project Costing) as a time consumer
• Default Time Card Period: Set the system-wide default period type if not overridden at the profile level
• Overtime Thresholds: System-level defaults for standard hours that time rules can reference
• Configuration Path: Setup and Maintenance → Manage Time and Labor Implementation Options

• Parallel Run: Run both systems simultaneously for one or two pay periods, comparing outputs to validate Oracle T&L produces correct results before decommissioning legacy
• Historical Data Migration: Determine what historical time data needs migrating (typically 12–24 months for reporting continuity); use HDL TimeCard objects or Payroll Balances Initialization
• Rule Gap Analysis: Document every pay rule in the legacy system and map each to an Oracle T&L configuration. Gaps must be resolved before go-live
• Device Cutover: For TCD environments, plan device re-programming or replacement to point to Oracle T&L on cutover date
• Training: Train workers, managers, and payroll admins on new processes — provide quick reference cards and sandbox access for practice
• Hypercare Period: Plan for 2–4 weeks of hypercare support post go-live with dedicated resources to resolve issues quickly

The Oracle HCM Mobile app (available on iOS and Android) provides workers and managers with access to Time & Labor functions from their smartphones.

• Worker Features: Enter and submit time cards, view time card history, record absences, receive approval notifications
• Manager Features: Approve or reject team member time cards, view team time card status, enter time on behalf of workers
• Responsive Time Card: The mobile time card layout is configured separately from the web layout within the Time Entry Profile — it is optimized for smaller screens with simplified entry
• Offline Capability: Limited offline entry is supported; entries sync when connectivity is restored — important for field workers in low-connectivity environments

• Purpose: Moves approved, processed time card results into Oracle Global Payroll as element entries, making them available for the payroll run
• Key Parameters: Legal Employer, Payroll Definition, Time Period Start/End Date, and optionally a specific worker or HCM Group
• Prerequisites: Time cards must be Approved; Submit Time Cards process must have run successfully for the period
• Output: Creates element entries in Global Payroll; generates a transfer report listing all processed time cards and any errors
• Error Handling: Cards with mapping errors or missing payroll relationships are listed in the error log — resolve and re-run the transfer for affected workers
• Access: Payroll → Submit a Process → Transfer Time Cards to Payroll

Collective Bargaining Agreement (CBA) rules often include complex overtime thresholds, premium pay, rest period requirements, and seniority-based provisions that require careful T&L setup.

• Union-Specific HCM Groups: Create separate HCM Groups for each bargaining unit to ensure union-specific rules apply only to those workers
• Custom Overtime Rules: Some CBAs have daily overtime (e.g., over 8 hrs/day) AND weekly overtime (over 40 hrs/week) AND 7th-day rules — build each as a separate processing rule in the correct sequence
• Rest Period Validation: Entry rules can enforce minimum rest periods between shifts (e.g., 8-hour gap required between end of one shift and start of next)
• Consecutive Day Premium: Processing rules can detect 6th and 7th consecutive workday entries and apply premium PTTs
• Rule Testing with Union Steward: Test scenarios with union representatives to validate calculations match the CBA precisely before go-live

• Employee (ORA_PER_EMPLOYEE_ABSTRACT): Can enter, save, and submit their own time cards
• Line Manager (ORA_PER_LINE_MANAGER_ABSTRACT): Can view, approve, reject, and edit time cards for direct reports
• Time and Labor Manager (ORA_HWM_TIME_AND_LABOR_MANAGER_JOB): Administrative access — can manage time cards for all workers, run processes, configure rule groups
• Time and Labor Administrator: Full configuration access — creates schedules, rules, entry profiles, consumer sets
• Payroll Manager: Can run the Submit and Transfer time card processes within the payroll flow
• Custom Roles: Organizations often create custom roles to restrict access by Business Unit or Legal Employer

A Payroll Flow is a configurable sequence of payroll tasks (processes) that run in a defined order. In the context of T&L, it automates the end-of-period time processing steps.

• T&L Steps in a Flow: A typical payroll flow includes: Submit Time Cards → Transfer Time to Payroll → Calculate Payroll → Review → Prepayments → Archive → Payments
• Orchestration: The flow ensures time steps complete successfully before payroll calculation begins, preventing payroll from running on incomplete time data
• Conditional Steps: If Submit Time Cards reports errors, the flow can pause and alert the payroll admin before proceeding
• Reusable: The same flow template runs each pay period; only the period parameters change
• Access: Payroll → Payroll Flow Patterns → Configure Flow

• Worker Time Zone Preference: Workers set their time zone in HCM profile preferences; the time card displays in the worker's local time zone
• Work Schedule Time Zone: The work schedule is defined in the worker's local time zone — shift start/end times reflect local time
• Start/Stop Entries: For start/stop time entry, time is captured in the worker's local time zone and stored in UTC; rules process based on local time
• Cross-Midnight Shifts: Night shifts that cross midnight (e.g., 22:00–06:00) must be handled by configuring the Day Pattern to span two calendar days or use a single-day 8-hour pattern with the correct anchor
• Payroll Time Zone: The payroll definition operates in the legal employer's time zone; ensure the time card periods align correctly when workers are in significantly different time zones from payroll

• Skipping Rule Gap Analysis: Not documenting legacy pay rules comprehensively leads to post-go-live payroll errors. Always map every rule from the old system before building in Oracle
• Missing Time Consumer Set Assignments: Workers without a consumer set can't have time transferred to payroll. Validate 100% of workers have valid assignments before go-live
• Processing Rule Sequence Errors: Rules that fire in the wrong order (e.g., shift differential before rounding) produce incorrect results. Always test full-cycle scenarios in sequence
• Not Aligning Time Card and Payroll Periods: Misaligned period cutoffs cause split-week processing issues. Design these together from the start
• Insufficient UAT for Overtime Scenarios: Overtime is the highest-risk calculation area. Test weekly, daily, and consecutive-day overtime with real worker data
• Ignoring Absence Integration Timing: If absence approvals happen after time card submission, time cards need to be unlocked and resubmitted. Build the process to accommodate this workflow

The Time and Labor Manager is an operational administrator role that manages day-to-day time card activities across the workforce.

• Time Card Management: View, edit, submit, and approve time cards for any worker within their data security scope
• Process Management: Run Submit Time Cards and Transfer Time Cards to Payroll processes
• Exception Management: Review and resolve time card errors, TCD punch exceptions, and missing time card alerts
• Schedule Management: Assign and modify work schedules for workers
• Reporting: Access all T&L reports and OTBI dashboards for their worker population
• Scope: Unlike the T&L Administrator (who configures the system), the T&L Manager operates within the configured system — they don't change rules or profiles

• FLSA Compliance (US): Configure overtime rules to comply with FLSA 40-hour weekly threshold; exclude certain exempt classifications from overtime via HCM Group separation
• Comp Time for Public Sector: FLSA Section 7(o) allows public agencies to grant comp time instead of overtime pay — configure as described in the Comp Time scenario
• Position-Based Time Reporting: Government organizations often track time by funded position — add Position attribute to time card layout for cross-charge to funded programs
• Grant and Fund Tracking: Use project time integration to capture time against federal grants and comply with OMB Circular A-87 requirements for grant time reporting
• Audit Requirements: Enable comprehensive time card audit trails and configure extended data retention to meet government audit requirements

Hospitals represent one of the most complex T&L configurations due to rotating shifts, multiple job codes, union rules, and strict regulatory requirements.

• Shift Patterns: Configure 8-hour (3 shifts/day), 10-hour (overlapping shifts), and 12-hour (Baylor schedule) Day Patterns. Build multi-week rotating Work Patterns for rotating crews
• Differential Pay: Evening (15–23:00), Night (23–07:00), Weekend, and Charge Nurse differentials — each as separate PTTs with distinct payroll elements
• Union Rules: Typically multiple bargaining units (RNs, technicians, support staff) — separate HCM Groups and Rule Groups per union
• Overtime: California hospitals: 8/40 rule plus double time over 12 hrs/day or 8th consecutive day. Build cascading processing rules with correct sequence
• Staffing Ratios: Use Schedule Management to track scheduled vs. actual staffing against ratios; integrate with workforce management module for predictive scheduling
• PTO and Call-Off: Complex interactions between scheduled time, voluntary call-off (reduced pay), mandatory overtime, and PTO require careful entry and processing rule design

The Time Processing Results page shows the output of the Submit Time Cards process for a specific worker and period, displaying how time rules have transformed the original time entries.

• Access: From the Time Card detail page, a "View Processing Results" link appears after the Submit Time Cards process has run
• Information Shown: Original PTTs and hours entered, rules that fired, resulting PTTs and hours after transformation
• Debugging: If a worker's payslip shows incorrect overtime or differential, start with the Time Processing Results to see which rules fired and in what order
• Payroll Element Entries: Can navigate from here to the resulting payroll element entries created after transfer to payroll

Minimum hours guarantee rules ensure workers receive pay for a minimum number of hours even if they worked fewer hours (e.g., "Reporting Pay" or "Show-Up Pay").

• Rule Type: "Minimum Hours" Time Processing Rule
• Condition: If total daily or shift hours are greater than zero but less than the minimum threshold (e.g., less than 4 hours but worker showed up)
• Action: Generate a "Minimum Pay Guarantee" PTT entry for the difference between actual hours and the guaranteed minimum
• Payroll Element: The Minimum Pay PTT maps to a payroll element that calculates the guarantee amount
• Exclusion: Workers who called in sick or were pre-scheduled for partial shifts may be excluded from the guarantee rule — use conditions to filter correctly

Oracle Fast Formula is Oracle HCM's proprietary programming language used to create custom calculation logic and validation formulas that extend standard functionality.

• Time Entry Rules via Fast Formula: Complex entry validations that can't be configured with standard rule parameters can be written as Fast Formula — e.g., cross-attribute validation checking multiple time card fields simultaneously
• Time Processing Calculations: Custom pay calculations involving dynamic rates, employee tenure, or grade-based thresholds can be implemented as Fast Formula in processing rules
• Work Schedule Formulas: Custom schedule generation for non-standard patterns can use Fast Formula to calculate expected hours dynamically
• Syntax: Proprietary language with access to HCM database objects, input and output variables, and conditional logic (IF/THEN/ELSE, loops)
• Testing: Use the Fast Formula testing interface in Setup and Maintenance to validate formulas before associating with rules; errors in Fast Formula can cause time card submission failures

California has strict meal and rest break requirements that employers must configure carefully in Oracle Time & Labor to avoid wage theft liability.

• Meal Period Rule: Workers working over 5 hours must receive a 30-minute unpaid meal break. Configure a Meal Break deduction rule: if hours > 5 and no manual break entered, deduct 30 minutes
• Second Meal Period: Workers over 10 hours must receive a second 30-minute meal break — add a second deduction rule triggering when hours > 10
• Meal Period Waiver: Workers can waive breaks in certain conditions. Configure an override flag on the time card for workers who waive their meal period (requires written waiver process)
• Premium Pay for Missed Breaks: If a meal break is not provided, the employer owes 1 hour of premium pay — configure a "Meal Penalty" PTT that triggers when break conditions aren't met
• Rest Breaks: 10-minute paid rest breaks for every 4 hours are typically not tracked in T&L (paid time) but can be logged for compliance proof if required

• Responsive Time Card Layout: Design a simplified mobile layout in the Time Entry Profile — fewer columns, streamlined date/hours entry, large touch targets
• Geolocation Capture: Oracle HCM Mobile can capture GPS coordinates at clock-in/out. Configure geofencing entry rules that warn or block time entries submitted from outside approved locations
• Offline Mode: Train workers on offline entry capability — entries cache on the device and sync when connectivity is restored (critical for construction sites, rural locations)
• Photo Capture: For compliance-sensitive environments, mobile time capture can require a selfie at clock-in (anti-buddy-punching) — requires third-party integration or facial recognition TCD
• Push Notifications: Configure reminder notifications through Oracle HCM Mobile for workers who haven't submitted time cards as the deadline approaches

• Time Card Period: The frequency at which workers submit time cards (e.g., weekly, bi-weekly). Defined in the Time Entry Profile
• Payroll Period: The pay cycle frequency defined in Oracle Global Payroll (e.g., bi-weekly, semi-monthly, monthly)
• Alignment Requirement: The time card period must align with the payroll period OR the time card period must be a subdivision of the payroll period. A weekly time card works with a bi-weekly payroll (two cards per pay period). A bi-weekly time card cannot easily work with a semi-monthly payroll without period-splitting logic
• Best Practice: Keep them aligned to avoid complex split-period processing — design both together during implementation planning

• Read the Error Message: Entry rule error messages include the rule name and the violated condition — share with the worker to explain the issue
• Identify the Rule: Navigate to Setup and Maintenance → Manage Time Entry Rules and locate the rule by name to review its configuration
• Check HCM Group Assignment: Verify the worker is in the intended HCM Group and that the Rule Group containing the error rule is correctly assigned
• Rule Conditions: Review the rule conditions carefully — sometimes rules fire incorrectly due to overlapping conditions or incorrect attribute references
• Test with a Different Worker: If only one worker hits the error, compare their attributes (assignment, schedule, department) to workers who don't — the difference often reveals the issue
• Temporary Exemption: For urgent payroll close situations, an admin can temporarily remove the worker from the HCM Group to bypass the rule — add them back after investigation

Workers who worked in two different roles or locations with different rates in the same period (e.g., acting up into a higher grade temporarily) require careful time and payroll setup.

• Dual Assignment Scenario: If the worker has two active assignments for the period, time cards can be split between assignments — each row on the time card has an Assignment attribute
• Temporary Assignment Override: Use Oracle's temporary assignment functionality to create the higher-grade assignment for the acting-up period; time entries against this assignment attract the higher rate element
• Separate PTTs per Rate: Create distinct PTTs mapped to different payroll elements with different rate formulas (e.g., "Regular Rate A" and "Regular Rate B")
• Time Entry Rule: Validate that workers use the correct PTT/Assignment combination to prevent incorrect rate application
• FLSA Blended Rate: In US contexts, overtime for a dual-rate week may require a blended rate calculation — ensure the overtime payroll element formula accounts for this

• Worker Assignment: T&L reads worker assignment data (Department, Job, Grade, Location) for time card attribute defaulting and costing allocation
• Work Schedule Assignment: Core HR stores the default work schedule on the employment record; T&L reads this for schedule-based validations
• Organization Hierarchy: Manager relationships from Core HR drive time card approval routing
• New Hire / Termination: When a worker is hired, they automatically become eligible for time entry; when terminated, their time access is revoked per the termination date
• HCM Group Membership: Group membership is often based on Core HR assignment attributes — changes to an employee's assignment can trigger automatic group membership changes, affecting which rules apply

• Contingent Worker Record: Contingent workers in Oracle HCM (Pending Worker type) can be set up with time capture capability — they submit time cards like regular employees
• Limited Access Time Entry Profile: Create a simplified Time Entry Profile for contingent workers — fewer attributes, project-only coding, no absence capability
• No Payroll Integration: Contingent workers are typically paid through Accounts Payable or a staffing agency — the Time Consumer Set for contingent workers points to a project or external consumer, not Oracle Payroll
• Manager Approval: Contingent worker time cards are approved by the hiring manager who is also the accounts payable approver for invoice reconciliation
• Rate Management: If hourly rates for contingents are tracked in Oracle, map to appropriate elements or use project billing rates to calculate the engagement cost

The Calculated Time section appears on the time card after the Submit Time Cards process has run. It shows the results of time processing rules applied to the worker's entries.

• Content: Lists the output time types and calculated hours — showing the transformation from entered hours to processed hours (e.g., 45 Regular hours entered → 40 Regular + 5 Overtime in Calculated Time)
• Visibility: Both workers and managers can see this section; it provides transparency into how pay will be calculated
• Before vs After: The "Reported Time" section shows what the worker entered; the "Calculated Time" section shows what actually transfers to payroll after rules are applied
• Discrepancy Resolution: If a worker questions their pay, the Calculated Time section is the first place to investigate

For workers with consistent schedules who always work the same hours, Oracle T&L offers time card templates and auto-generation features to reduce manual entry.

• Time Card Template: Workers can save a completed time card as a template and apply it to future periods with one click — ideal for fixed 9–5 office workers
• Copy Previous Period: Workers can copy last period's time card as a starting point, then make adjustments for any days that differed
• Auto-Population from Schedule: If configured, Oracle can pre-populate the time card with expected hours based on the worker's work schedule — the worker only needs to confirm and submit
• Appropriate Use: Best for workers with truly consistent schedules; not appropriate where hours vary significantly, as pre-populated incorrect hours could go unnoticed

• Spring Forward (Short Shift): Workers on overnight shifts during spring forward work only 7 hours instead of 8. Oracle T&L calculates actual hours based on stored UTC timestamps — the system naturally produces the correct 7-hour result
• Fall Back (Long Shift): Workers on overnight shifts during fall back work 9 hours. Start/stop time entries capture the actual clock times; the system calculates 9 hours worked
• Duration Entry: For duration-based time entry, workers manually enter actual hours (7 or 9) — the system doesn't auto-adjust based on DST for duration entries
• Shift Differential Rules: Ensure rules reference the local time of the shift (not UTC) when evaluating evening/night differential windows during DST transition weeks
• Communication: Notify workers and managers of the expected DST impact on time cards to prevent unexpected overtime or under-reporting

The Time Card Exception Report identifies time cards that have triggered validation warnings or are in an unusual state, enabling proactive management of potential issues before payroll processing.

• Exceptions Captured: Soft rule warnings (over-hours, under-hours), missing manager approval, cards rejected and not resubmitted, TCD punch exceptions
• When to Use: Run this report 2–3 days before payroll cutoff to identify and resolve issues with enough time to correct and re-approve
• Audience: Shared with payroll administrators, HR business partners, and department managers for action
• Automation: Schedule to run and auto-email to distribution lists as part of the payroll close checklist

• Data Minimization: Only capture time attributes necessary for payroll and operational reporting — avoid optional biometric or location data unless specifically required and consented
• Access Control: Implement data security profiles in Oracle HCM to restrict time card data access to authorized roles within specific Legal Employers or countries
• Geolocation Data: If geolocation is captured during mobile time entry, ensure workers have provided explicit consent and that data is stored and processed according to GDPR
• Retention Policy: Oracle HCM supports data archiving and purging policies — configure time card data retention rules to align with GDPR's data minimization principles and relevant labor law retention requirements
• Subject Access Requests: HCM's person data export tools allow exporting a worker's complete time and labor data to fulfill DSAR (Data Subject Access Requests)
• Audit Logging: GDPR requires demonstrating data access governance — enable attribute-level audit on sensitive time data fields

Oracle provides a Time Collection Device (TCD) processing framework that receives raw punch data from physical clocking devices and converts it into Oracle time card entries.

• TCD Processing Rules: Define how raw punch data (badge scan, biometric read) is converted to time entries — worker identification, shift determination, PTT assignment
• Exception Handling: Missed punches, unknown badge numbers, out-of-schedule punches generate exceptions in a worklist for supervisor review
• Push vs Pull: Oracle can receive pushed punch files from devices or poll device middleware at scheduled intervals
• Certified Partners: Oracle maintains a list of certified TCD vendors and integration methods (REST API, file-based) for connecting physical devices
• Auto Time Card Creation: Once punches are validated and matched to workers, time card entries are created automatically — workers do not need to manually enter time

When using a bi-weekly time card, weekly overtime rules must evaluate each 7-day week within the 14-day period independently, not the cumulative 14-day total.

• Rule Period Setting: Configure the Time Processing Rule with "Period = Weekly (7 days)" threshold calculation — not the full bi-weekly card period
• Week Boundary: Define the start-of-week day (e.g., Monday) in the rule configuration to ensure the correct 7-day window is evaluated
• Two-Week Card Scenario: The rule engine evaluates Week 1 (Days 1–7) separately from Week 2 (Days 8–14). A worker can have overtime in Week 1 and none in Week 2 even on a bi-weekly card
• Testing: Test with a worker who worked exactly 40 hours in Week 1 and 48 hours in Week 2 — verify Week 2 shows 8 OT hours and Week 1 shows zero

• Schedule Exceptions: Managers can add individual schedule exceptions for a specific worker on a specific date — changing the hours, shift, or rest day for that day only without affecting the master schedule pattern
• Access: My Client Groups → Time Management → Worker Schedules → Add Exception
• Exception Types: Add an extra shift, remove a scheduled shift, change shift times, mark a scheduled day as a rest day
• Temporary Override: Exception has an effective date and optionally an end date — the master schedule resumes after the exception period
• Absence Awareness: Schedule exceptions are considered by Absence Management when calculating absence duration — an exception removing a work day means an absence on that day doesn't consume leave balance

Oracle's Redwood design system and HCM Extensions toolkit allow organizations to customize and enhance the T&L user experience without customization of core application code.

• Redwood Time Card: Oracle's next-generation time card UI built on the Redwood design system offers improved usability, cleaner layouts, and better mobile responsiveness
• Page Composer / Application Composer: Administrators can add, hide, or rearrange fields on time card pages without coding — using drag-and-drop page configuration tools
• Guided Learning Integration: Oracle Guided Learning can overlay step-by-step instructions on the time card UI to guide workers through first-time or complex entries
• Personalization: Workers can personalize their time card column layout (show/hide optional attributes) within administrator-defined bounds

• Two HCM Groups: Create separate HCM Groups for FLSA Exempt and FLSA Non-Exempt workers — each group gets different time rules and potentially different time card layouts
• Non-Exempt Workers: Full T&L configuration — start/stop or duration entry, 40-hour weekly overtime processing rule, meal break validation, all PTTs (Regular, OT, Holiday, etc.)
• Exempt Workers: Simplified time card — often duration-based with only a "Regular" PTT (or project-coding PTTs for project allocation). No overtime rules. May use auto-populated or template-based cards
• Approval: Non-exempt time cards require manager approval before payroll transfer (compliance requirement). Exempt cards may use auto-approval to reduce administrative burden
• Misclassification Risk: Ensure the HCM Group assignment logic correctly identifies exempt vs non-exempt status based on the FLSA classification in the employment record

• Setup and Maintenance: All functional configuration — rules, profiles, schedules, consumer sets, lookups
• My Client Groups → Time Management: Operational tasks — manage time cards, assignments, schedules, exceptions for the managed worker population
• Payroll (or HR Administration) → Submit a Process: Run Submit Time Cards and Transfer Time Cards to Payroll scheduled processes
• Reports → OTBI: Build and run time and labor analytics reports and dashboards
• Data Exchange: For HDL/HSDL file-based data loading of bulk schedule assignments or time card data

Time card certification requires workers or managers to formally attest to the accuracy of time entries before the card is considered complete — common in healthcare, government, and compliance-heavy industries.

• Certification Text: Configure a certification statement that workers must acknowledge at time of submission (e.g., "I certify that the time entries on this card are a true and accurate representation of hours worked")
• Mandatory Acknowledgment: The time card cannot be submitted until the worker clicks "I Certify" — enforced via a hard entry rule
• Manager Certification: Similarly, managers can be required to certify time during the approval action
• Audit Record: Certification acknowledgments are stored with timestamp and user for legal audit purposes
• Configuration: Certification requirements are set within the Time Entry Profile and optionally enforced via an entry rule

When a time card is corrected after a payroll has been finalized, Oracle's retroactive pay engine handles the recalculation automatically in the next payroll run.

• Trigger: A time card correction (new PTT, changed hours) creates a Retro Notification in the system
• Retro Process: During the next payroll run, the "Calculate Retroactive Pay" process detects the change, re-processes the prior period's time with the corrected data, and calculates the delta
• Retro Element: The delta (overpayment or underpayment) is paid via Retro Elements — dedicated payroll elements that Oracle creates during retro processing
• Worker Communication: The payslip shows both the current period pay and the retro adjustment as separate line items
• Retro Limit: Configure retro calculation limits (how far back retro can look) to prevent system performance issues from very old corrections

Time Entry Attributes are the additional dimensions beyond hours that workers capture on their time cards to provide context for costing, reporting, and payroll allocation.

• Standard Attributes: Date, Time Type (PTT), Hours/Start-Stop, Absence Type, Project, Task, Cost Center, Department, Assignment
• Custom Attributes: Organizations can add custom attributes (e.g., Customer Code, Job Order Number, Activity Code) via descriptive flexfields on the time card
• Layout Control: The Time Entry Profile controls which attributes appear, their column order, mandatory status, and default values
• Costing Downstream: Attributes like Cost Center and Project flow through to payroll element costing and project expenditure creation
• Validation: Entry rules can validate attribute values — checking that a Project Code is active or a Cost Center is valid for the worker's Business Unit

• No Fixed Schedule: Variable-hour workers have no fixed schedule — use a minimal "availability-based" work pattern (or no pattern assignment) rather than a rigid schedule
• Start/Stop Entry: Use start/stop time entry to capture actual clocked hours without schedule comparison validation
• Overtime Rules: Standard daily and weekly overtime rules still apply — configure for applicable state laws (CA daily OT vs federal weekly only)
• Predictive Scheduling Laws: Several US cities (Seattle, Chicago, NYC) require advance schedule posting and premium pay for last-minute changes. Map these premiums to specific PTTs and configure manager-triggered entries
• Multiple Locations: Retail workers often work across stores — the Location attribute on the time card enables store-level labor cost tracking and compliance with location-specific pay rules
• Split Shifts: Configure split shift premium PTTs for workers who have a break of more than a defined gap between shifts in the same workday

• Final Time Card: The worker must submit a final time card covering their last days of employment before or on the termination date
• Access Revocation: After the termination effective date, the worker loses access to the time entry self-service page
• Manager Entry: If the worker fails to submit before termination, the manager or time administrator must enter and submit the final time card on their behalf
• Final Pay: Final time card must be approved and transferred to payroll before running the final pay calculation — particularly critical in US states with strict final pay timing laws
• Historical Access: Terminated workers cannot access their own time card history, but administrators retain full access for audit and reporting purposes

• Calendar Event Categories: Create separate Calendar Event Categories per country (e.g., "US Federal Holidays", "UK Bank Holidays", "IN National Holidays")
• Calendar Events: Add specific dates to each category annually — Oracle requires manual entry of holiday dates (or file loading via HDL) for each year
• Country Assignment: Calendar Event Categories are associated with Legal Employers or Countries in the system parameters
• Work Schedule Impact: Workers inherit the holiday schedule applicable to their Legal Employer's country
• Regional Variations: Countries with regional holidays (India state holidays, US state holidays) require sub-categories or additional categories per region with distinct HCM Group assignments
• Annual Maintenance: Budget time at year-end to update holiday calendars for the coming year before the first payroll of the new year

The EU Working Time Directive (WTD) sets maximum working time limits, minimum rest periods, and break requirements across EU member states.

• 48-Hour Weekly Maximum: Configure a Time Entry Rule (hard or soft) that warns or blocks submission when a worker's weekly total exceeds 48 hours (unless opt-out documented)
• Daily Rest Period (11 hours): Entry rule validates that the gap between clock-out and next clock-in is at least 11 hours for start/stop entry workers
• Weekly Rest (24 hours): Processing rule or entry rule checks that workers have at least 1 day with 0 hours in every 7-day period
• Annual Leave Minimum: The 20-day minimum annual leave is managed in Oracle Absence Management — T&L ensures absence entries count correctly against the entitlement
• Reference Period Tracking: WTD allows a 17-week (or up to 52-week with agreement) reference period for averaging. OTBI reports can track 17-week rolling average hours per worker
• Opt-Out Tracking: Workers who opt out of the 48-hour limit need a documented record in HCM; T&L rules can be configured to exclude opt-out workers from the 48-hour validation

• No Direct Migration: There is no automated migration path — T&L configuration must be rebuilt from scratch in Oracle HCM Cloud using the new configuration model
• Rule Model Differences: E-Business Suite's "Time Entry Rules" and "Time Building Rules" have a different architecture to HCM Cloud's Entry/Processing Rules. Each rule must be analyzed and redesigned — not just renamed
• Element Mapping: E-Business Suite time elements map to Oracle Payroll (EBS). In Cloud, Payroll Time Types map to Cloud Global Payroll elements — a complete remap is required
• TCD Recertification: Physical time clocking devices integrated with OTL EBS require new integration configuration to connect to HCM Cloud T&L
• Historical Data: Typically load 12–24 months of historical time summary data (not full time card detail) to support reporting continuity
• User Retraining: The self-service interface is completely different — invest heavily in end-user training and change management
• Parallel Run: Given the complexity of rule rebuilding, run at least two full parallel payrolls before cutover to validate parity with EBS results

A successful Oracle T&L implementation combines technical precision with strong business engagement and disciplined project governance.

• 1. Start with a Business Rule Inventory: Document every pay rule, policy, and exception in the current environment before touching configuration. Incomplete rule documentation is the #1 cause of go-live failures
• 2. Align Time Cards and Payroll Periods from Day One: Involve the payroll architect in the time card period design; misalignment here creates persistent problems
• 3. Design HCM Groups Carefully: Over-complicating group structures leads to maintenance nightmares. Use the minimum number of groups that correctly separates rule populations
• 4. Test Overtime Exhaustively: Overtime is the highest-risk area. Create test cases for every overtime scenario — daily, weekly, consecutive days, multi-state workers
• 5. Validate End-to-End in Every Sprint: Don't wait until SIT to run the full cycle. From day one of configuration, run submit→approve→process→transfer cycles to catch issues early
• 6. Engage Payroll in T&L Design: Payroll Time Types and Consumer Sets directly impact payroll element creation and costing. Payroll must co-own the design
• 7. Plan for Cut-Over Carefully: T&L cut-over is high-stakes — workers must not miss pay. Have a detailed day-by-day cut-over runbook and a rollback plan
• 8. Invest in End-User Training: Workers who don't understand how to submit or correct time cards create operational burden and payroll errors. Quick reference cards and sandbox access are minimum requirements