Oracle Cloud HCM: Recovering HDL Files and Troubleshooting Import Errors Using SQL

Introduction

One of the biggest challenges during Oracle Cloud HCM support is troubleshooting an HDL load after it has already been processed.

A common scenario looks like this:

• An HDL was loaded several weeks or months ago.
• The original .dat file is no longer available.
• The consultant who loaded it has left the project.
• A business user reports incorrect data.
• You need to determine exactly what was loaded before preparing a correction HDL.

Since HDL imports are processed through Oracle's internal Import and Load Data framework, many consultants assume there is no way to retrieve the original file contents.

Fortunately, Oracle stores the imported HDL data in several HCM Data Loader tables. With a few SQL queries, you can reconstruct the original HDL file, review each physical line, and analyze errors generated during processing.

In this article, we will look at two practical SQL techniques:

• Reconstructing previously loaded HDL files
• Viewing HDL errors at every processing stage

---

Business Scenario

Imagine receiving the following request from Payroll:

An employee's salary was loaded incorrectly three months ago. We don't have the original HDL file anymore, but we need to understand what was imported before creating a correction.

Without the original HDL file, most teams begin recreating the data manually.

Instead, Oracle already stores every imported HDL line inside the database. With the appropriate SQL query, you can rebuild the original .dat file almost exactly as it was loaded.

---

Recovering Previously Loaded HDL Files

Oracle stores every HDL file line in the HRC_DL_FILE_LINES table.

Using the Data Set and Business Object tables, we can reconstruct the HDL file.

The following SQL returns every line in the HDL file in the original sequence.

SELECT
    hdds.ucm_content_id,
    hdds.data_set_name,
    hddsbo.data_file_name,
    hdfl.seq_num AS line_sequence,
    hdfl.text AS hdl_line_text
FROM hrc_dl_data_sets hdds,
     hrc_dl_data_set_bus_objs hddsbo,
     hrc_dl_file_lines hdfl
WHERE 1 = 1
  AND hdds.data_set_id = hddsbo.data_set_id
  AND hddsbo.data_set_bus_obj_id = hdfl.data_set_bus_obj_id
  -- AND hdds.ucm_content_id = 'UCMFA06411541'
  AND hdds.data_set_name = 'Salary_6278_06302026.zip'
ORDER BY
    hddsbo.data_file_name,
    hdfl.seq_num;

---

Searching by UCM Content ID

If you know the uploaded UCM document ID instead of the zip file name, modify the WHERE clause.

WHERE hdds.ucm_content_id = 'UCMFA06411541'

This is particularly useful when reviewing historical HDL loads from production.

---

Typical Output

UCM Content ID	Data File	Sequence	HDL Line
UCMFA06411541	Salary.dat	1	METADATA...
UCMFA06411541	Salary.dat	2	MERGE...
UCMFA06411541	Salary.dat	3	MERGE...

Because the results are returned in sequence order, they can easily be copied into a new .dat file when preparing correction HDL.

---

Why This Query Is Useful

This query is useful in many implementation and support situations, such as:

• Original HDL file lost
• Reviewing historical data loads
• Building correction HDL files
• Comparing production versus test loads
• Investigating unexpected data changes
• Performing audit activities

Instead of recreating HDL manually, you can extract what Oracle already imported.

---

HDL Error Processing

Recovering the HDL file is only half of the story.

The next challenge is understanding where the import failed.

Many consultants only review the Import and Load Data UI. However, Oracle stores detailed messages throughout every stage of HDL processing.

Understanding these stages makes troubleshooting significantly easier.

---

HDL Processing Stages

Oracle validates HDL through several layers before data reaches the application.

1. Zip File
2. Data File
3. Import Validation
4. Metadata
5. Hierarchy
6. Logical Object
7. Physical Row
8. Service Processing

Each stage validates a different portion of the HDL. Knowing where an error occurs often tells you exactly what needs to be corrected.

---

Understanding Each Error Type

1. Zip File Errors

These occur before Oracle even reads the HDL.

• Invalid ZIP archive
• Corrupted upload
• Unsupported file format

2. Data File Errors

Oracle validates the contents of each .dat file.

• Missing data file
• Invalid encoding
• File structure issues

3. Import Validation Errors

These occur while Oracle imports individual HDL lines.

• Invalid attribute values
• Invalid dates
• Missing required fields

4. Metadata Errors

Oracle validates every METADATA line.

• Misspelled attribute names
• Incorrect business object
• Unsupported HDL version

5. Hierarchy Errors

Oracle validates parent-child relationships.

• Child record loaded before parent
• Invalid hierarchy sequence
• Missing parent object

6. Logical Object Errors

Logical validation occurs after hierarchy validation.

• Duplicate logical objects
• Missing unique keys
• Invalid HDL object relationships

7. Physical Row Errors

These errors occur at the individual MERGE line level.

• Duplicate source keys
• Invalid effective dates
• Business rule violations

8. Service Errors

These are generated during the final application service call.

• Object validation failures
• Payroll business rule errors
• Security violations
• Unexpected application exceptions

---

A Single Query for Complete Error Analysis

Rather than searching multiple tables individually, you can use a consolidated SQL query that retrieves HDL errors from every processing stage.

The query categorizes messages into:

• Zip File
• Data File
• Import
• Metadata
• Hierarchy
• Logical Object
• Physical Row
• Service Error

It also returns useful details such as:

• Message Type
• Error Message
• Stack Trace
• File Name
• Line Number
• Metadata Line
• HDL File Line
• Request ID
• UCM Content ID

Having all error information in one report makes it much easier to determine exactly where the HDL processing failed.

SELECT 1 orderby
, 'Zip File' err_location
, l.message_type
, l.msg_text
, l.stack_trace
, to_number(null) seq_num
, '' ui_user_key
, '' metadata
, '' file_line
, ds.request_id
, ds.data_set_name
, '' data_file_name
, ds.ucm_content_id
FROM fusion.hrc_dl_message_lines l
, fusion.hrc_dl_data_sets ds
WHERE l.message_source_table_name = 'HRC_DL_DATA_SETS'
AND l.message_source_line_id = ds.data_set_id

UNION

SELECT 2 orderby
, 'Data File' err_location
, l.message_type
, l.msg_text
, l.stack_trace
, to_number('') seq_num
, '' ui_user_key
, '' metadata
, '' file_line
, ds.request_id
, ds.data_set_name
, bo.data_file_name
, ds.ucm_content_id
FROM fusion.hrc_dl_message_lines l
, fusion.hrc_dl_data_set_bus_objs bo
, fusion.hrc_dl_data_sets ds
WHERE l.message_source_table_name = 'HRC_DL_DATA_SET_BUS_OBJS'
AND bo.data_set_bus_obj_id = l.data_set_bus_obj_id
AND ds.data_set_id = bo.data_set_id

UNION

SELECT 3 orderby
, 'Import' err_location
, l.message_type
, l.msg_text
, l.stack_trace
, fl.seq_num
, '' ui_user_key
, '' metadata
, fl.text file_line
, ds.request_id
, ds.data_set_name
, bo.data_file_name
, ds.ucm_content_id
FROM fusion.hrc_dl_message_lines l
, fusion.hrc_dl_data_set_bus_objs bo
, fusion.hrc_dl_data_sets ds
, fusion.hrc_dl_file_lines fl
WHERE l.message_source_table_name = 'HRC_DL_FILE_LINES'
AND bo.data_set_bus_obj_id = l.data_set_bus_obj_id
AND ds.data_set_id = bo.data_set_id
AND fl.line_id = l.message_source_line_id

UNION

SELECT 4 orderby
, 'METADATA' err_location
, l.message_type
, l.msg_text
, l.stack_trace
, fl.seq_num
, '' ui_user_key
, fl.text metadata
, '' file_line
, ds.request_id
, ds.data_set_name
, bo.data_file_name
, ds.ucm_content_id
FROM fusion.hrc_dl_message_lines l
, fusion.hrc_dl_data_set_bus_objs bo
, fusion.hrc_dl_data_sets ds
, fusion.hrc_dl_file_headers fh
, fusion.hrc_dl_file_lines fl
WHERE l.message_source_table_name = 'HRC_DL_FILE_HEADERS'
AND bo.data_set_bus_obj_id = l.data_set_bus_obj_id
AND ds.data_set_id = bo.data_set_id
AND fh.header_id = l.message_source_line_id
AND fl.line_id = fh.line_id

UNION

SELECT 5 orderby
, 'Hierarchy' err_location
, l.message_type
, l.msg_text
, l.stack_trace
, fl.seq_num
, '' ui_user_key
, (SELECT hl.text
   FROM hrc_dl_file_lines hl
      , hrc_dl_file_headers fh
  WHERE fh.header_id = fr.header_id
    AND hl.line_id = fh.line_id) metadata
, fl.text file_line
, ds.request_id
, ds.data_set_name
, bo.data_file_name
, ds.ucm_content_id
FROM fusion.hrc_dl_message_lines l
, fusion.hrc_dl_data_set_bus_objs bo
, fusion.hrc_dl_data_sets ds
, fusion.hrc_dl_file_rows fr
, fusion.hrc_dl_file_lines fl
WHERE l.message_source_table_name = 'HRC_DL_FILE_ROWS'
AND bo.data_set_bus_obj_id = l.data_set_bus_obj_id
AND ds.data_set_id = bo.data_set_id
AND fr.row_id = l.message_source_line_id
AND fl.line_id = fr.line_id

UNION

SELECT 6 orderby
, 'Logical Object' err_location
, l.message_type
, l.msg_text
, l.stack_trace
, fl.seq_num
, ll.ui_user_key ui_user_key
, (SELECT hl.text
   FROM hrc_dl_file_lines hl
      , hrc_dl_file_headers fh
  WHERE fh.header_id = fr.header_id
    AND hl.line_id = fh.line_id) metadata
, fl.text file_line
, ds.request_id
, ds.data_set_name
, bo.data_file_name
, ds.ucm_content_id
FROM fusion.hrc_dl_message_lines l
, fusion.hrc_dl_data_set_bus_objs bo
, fusion.hrc_dl_data_sets ds
, fusion.hrc_dl_logical_lines ll
, fusion.hrc_dl_file_rows fr
, fusion.hrc_dl_file_lines fl
WHERE l.message_source_table_name = 'HRC_DL_LOGICAL_LINES'
AND bo.data_set_bus_obj_id = l.data_set_bus_obj_id
AND ds.data_set_id = bo.data_set_id
AND ll.logical_line_id = l.message_source_line_id
AND fr.logical_line_id = ll.logical_line_id
AND fl.line_id = fr.line_id

UNION

SELECT 7 orderby
, 'Physical Row' err_location
, l.message_type
, l.msg_text
, l.stack_trace
, fl.seq_num
, pl.ui_user_key || ' ' || pl.ui_date_from || ' ' || pl.ui_date_to ui_user_key
, (SELECT hl.text
   FROM hrc_dl_file_lines hl
      , hrc_dl_file_headers fh
  WHERE fh.header_id = fr.header_id
    AND hl.line_id = fh.line_id) metadata
, fl.text file_line
, ds.request_id
, ds.data_set_name
, bo.data_file_name
, ds.ucm_content_id
FROM fusion.hrc_dl_message_lines l
, fusion.hrc_dl_data_set_bus_objs bo
, fusion.hrc_dl_data_sets ds
, fusion.hrc_dl_physical_lines pl
, fusion.hrc_dl_file_rows fr
, fusion.hrc_dl_file_lines fl
WHERE l.message_source_table_name = 'HRC_DL_PHYSICAL_LINES'
AND bo.data_set_bus_obj_id = l.data_set_bus_obj_id
AND ds.data_set_id = bo.data_set_id
AND pl.physical_line_id = l.message_source_line_id
AND fr.row_id = pl.row_id
AND fl.line_id = fr.line_id

UNION

SELECT DISTINCT 8 orderby
, 'Service Error' err_location
, l.message_type
, l.msg_text
, l.stack_trace
, to_number(null)
, ''
, '' metadata
, '' file_line
, ds.request_id
, ''
, '' data_file_name
, ds.ucm_content_id
FROM fusion.hrc_dl_message_lines l
, fusion.hrc_dl_service_requests sr
, fusion.hrc_dl_data_sets ds
WHERE l.message_source_table_name = 'HRC_DL_SERVICE_REQUESTS'
AND l.message_source_line_id = sr.service_call_id;

---

Common Production Support Scenarios

These SQL queries are particularly useful for:

• Recovering lost HDL files
• Investigating failed HDL loads
• Payroll support
• Production issue analysis
• Data conversion validation
• Building correction HDL files
• Audit requests
• Comparing environments

---

Best Practices

When supporting HDL imports, consider the following recommendations:

• Keep the original HDL zip file whenever possible.
• Record the HDL Data Set Name and UCM Content ID for every production deployment.
• Use UCM Content ID as the primary reference when troubleshooting historical loads.
• Review the earliest error in the processing hierarchy before investigating downstream errors.
• Validate correction HDL files in a lower environment before deploying to production.

---

Final Thoughts

Oracle HCM Data Loader stores significantly more information than many consultants realize. By querying the HDL repository tables, implementation teams can recover historical HDL files, reconstruct lost .dat files, and troubleshoot errors at every stage of the load process.

These SQL techniques are very useful during production support, especially when the original HDL files are unavailable or when historical data changes need to be investigated.

Rather than relying only on the Import and Load Data user interface, leveraging the underlying HDL tables provides deeper insight into both the data that was loaded and the exact point where processing failed.

---

Important Tip

One of the first things I recommend after every production HDL deployment is recording the Data Set Name, UCM Content ID, and Request ID.

Even if the original ZIP file is lost months later, these identifiers allow you to reconstruct the HDL contents and investigate errors directly from the HCM Data Loader repository tables, making future support significantly easier.

How to Restrict Global Assignment EFF Values by Employee Legislation in Oracle Fusion HCM

In global Oracle Fusion HCM implementations, one of the more common configuration challenges is supporting local business requirements without fragmenting the overall design. A field may be global in nature, but the values available for that field often need to vary by country or legislation.

A typical example is a custom field on the Global Assignment Extensible Flexfield (EFF). The business may want one common field for all employees, but the list of available values should differ depending on whether the worker belongs to the US, India, Canada, Great Britain, or another legislation.

The good news is that Oracle Fusion HCM supports this requirement quite elegantly through configuration. By combining a custom lookup, a table-validated value set, and a Global Assignment EFF segment, you can create a clean, scalable, and metadata-driven solution.

In this article, I’ll walk through a practical design pattern for restricting Assignment EFF values based on employee legislation.

Business Requirement

Let’s assume the business wants to add a custom Assignment EFF field called Eligibility Type. This field should behave differently depending on the employee’s legislation.

For example:

• an employee with India legislation should see values relevant to India
• an employee with Great Britain legislation should see UK-specific values
• an employee with US legislation should see US-specific values
• some values should remain available to all employees regardless of country

This is a common global design problem: one field, different valid values by legislation.

Instead of creating separate fields or separate contexts by country, we can keep the design centralized and let the value filtering happen dynamically at runtime.

Solution Overview

The solution has three building blocks:

1. create a custom lookup type to store all possible values
2. create a table-validated value set that filters those values based on legislation
3. assign that value set to a Global Assignment EFF segment

The key idea is straightforward: all possible values are maintained in a single lookup, and the Tag field is used to identify country applicability. The value set then reads those values and decides which ones should be displayed based on the employee’s legislation code.

This approach keeps the design simple, maintainable, and easy to extend later.

Step 1: Create a Custom Lookup Type

The first step is to create a custom lookup that will act as the source for the field values.

Navigation
Setup and Maintenance → Manage Common Lookups

Create the following lookup type:

Field	Value
Lookup Type	XX_CUSTOM_ELIGIBILITY
Meaning	XX_CUSTOM_ELIGIBILITY
Description	XX_CUSTOM_ELIGIBILITY
Module	Global Human Resources

Once the lookup type is created, add the lookup codes that will represent the values shown in the EFF.

Sample Lookup Codes

Lookup Code	Meaning	Start Date	Tag
GRND_FATHER	Grandfathered in	1/1/1951	+IN
HAZARD_ALLOWANCE	Hazard Allowance	1/1/1951	+GB
ONCALL	On Call	1/1/1951	+US,+CA,+IN
STIPEND_INCENTIVE	Stipend Incentive	1/1/1951	(blank)

Using the Tag Column to Drive Legislation Logic

The Tag column is central to this pattern.

In this configuration:

• +IN means the value is available only for India
• +GB means the value is available only for Great Britain
• +US,+CA,+IN means the value is available for multiple legislations
• a blank tag means the value is available globally

This gives you a very practical mechanism for managing legislation-specific behavior without overcomplicating the EFF structure itself.

It also makes future maintenance easier. If the business wants to add a new value or expand eligibility to another legislation, the update can often be handled directly in the lookup.

Step 2: Create a Table-Validated Value Set

The next step is to create a value set that reads the lookup values and filters them using the legislation code of the employee.

Navigation
Setup and Maintenance → Manage Value Sets

Create the value set with the following definition:

Field	Value
Value Set Code	XX_CUSTOM_ELIGIBILITY_VS
Description	XX_CUSTOM_ELIGIBILITY_VS
Module	Global Human Resources
Validation Type	Table
Value Data Type	Character

Table Validation Details

Field	Value
From Clause	fnd_lookup_values
Value Column Name	meaning
Description Column Name	meaning
ID Column Name	meaning

Where Clause

LOOKUP_TYPE = 'XX_CUSTOM_ELIGIBILITY'
AND (
  DECODE(
    TAG,
    NULL, 'Y',
    DECODE(
      SUBSTR(TAG,1,1),
      '+', DECODE(SIGN(INSTR(TAG, :{PARAMETER.LEGISLATION_CODE_VALUE})), 1, 'Y', 'N'),
      '-', DECODE(SIGN(INSTR(TAG, :{PARAMETER.LEGISLATION_CODE_VALUE})), 1, 'N', 'Y'),
      'Y'
    )
  ) = 'Y'
)
AND LANGUAGE = 'US'

This is the heart of the solution.

How the Value Set Logic Works

At runtime, the value set checks the TAG value for each lookup row.

The logic works like this:

• if the TAG is null, the value is treated as global and shown to everyone
• if the TAG starts with +, the value is shown only if the employee’s legislation code exists in the tag
• if the TAG starts with -, the value is hidden if the employee’s legislation code exists in the tag

This creates a flexible filtering mechanism while keeping the actual list of values centrally managed.

From a design perspective, this is a strong pattern because it separates value maintenance in the lookup, filtering logic in the value set, and user entry in the EFF.

Step 3: Create the Global Assignment EFF Context and Segment

Once the lookup and value set are ready, the next step is to create the Global Assignment EFF segment that uses this value set.

Navigation
Setup and Maintenance → Manage Extensible Flexfields

Search for the Assignment Extensible Flexfield and create a new context and segment.

High-Level Steps

1. open the Assignment EFF
2. create a new context
3. add a new segment
4. assign the value set XX_CUSTOM_ELIGIBILITY_VS
5. save and deploy the flexfield

The segment should be a character-based field configured to display as a list of values.

Important Detail: Legislation Code Parameter

The most important part of this configuration is the parameter referenced in the value set:

:{PARAMETER.LEGISLATION_CODE_VALUE}

This parameter must receive the employee’s legislation code at runtime. That is what enables the value set to determine which rows should be displayed.

If this parameter is not mapped correctly, the LOV may not behave as expected. In most cases, the issue will show up as one of the following:

• all values are displayed
• no values are displayed
• values appear inconsistently for different employees

Because of that, parameter mapping is usually the first thing to verify during testing.

Testing the Configuration

Once the EFF is deployed, test the setup with employees from different legislations.

Based on the sample configuration above, the expected results are:

Employee Legislation	Values Displayed
US	On Call, Stipend Incentive
IN	Grandfathered in, On Call, Stipend Incentive
CA	On Call, Stipend Incentive
GB	Hazard Allowance, Stipend Incentive

This confirms that the same field can support different value sets depending on employee context, without requiring country-specific duplication in the flexfield design.

US Employee

India Employee

Canada Employee

GB Employee - redwood UI

Why This Design Works Well

What makes this approach especially useful in global implementations is its balance between flexibility and simplicity.

Rather than designing multiple country-specific fields or managing complex configurations in several places, you keep the setup centralized:

• the lookup stores all available values
• the Tag defines country applicability
• the value set handles runtime filtering
• the EFF consumes the filtered result

This makes the solution easier to maintain, easier to explain, and easier to extend over time.

It also aligns well with a broader Oracle HCM design principle: whenever possible, solve requirements through configurable metadata rather than proliferating structures.

Final Thoughts

For global Oracle Fusion HCM implementations, legislation-sensitive value restriction is a requirement that comes up often. The combination of a custom lookup, country-tagged values, a table-validated value set, and a Global Assignment EFF provides a neat and reusable way to address it.

It keeps the configuration centralized, supports local variation, and avoids unnecessary duplication in your flexfield design.

If you are working on a global HCM rollout and need different LOV values for the same field across legislations, this is a pattern well worth keeping in your implementation toolkit.

Key Takeaways

• a single Assignment EFF field can support different values by legislation
• the lookup Tag column is a simple way to define country applicability
• a table-validated value set can dynamically filter values at runtime
• this pattern is scalable, maintainable, and well suited for global HCM implementations

Fusion HCM New Hire Process - USA

Important Points -

(1) Address

All employees attached to a payroll must have a home address throughout their period of employment.Also, if you enter the ZIP Code first, the city, state, and county fields are automatically populated.

(2) Marital Status, Ethnicity, and Veteran fields in the Legislative Information section

Note: The Ethnicity and Veteran fields are required for EEO and VETS reporting.

(3)  On the Employment Information page, provide the necessary work relationship, payroll relationship, assignment, job, manager, payroll, and salary details.

Note: Use the Payroll Details section to associate a TRU and payroll with the employee. If you opt not to, this employee would not automatically receive an Employee Withholding Certificate, and you would have to create it manually. See Manual Tax Card Creation for more instructions.
.
Once a TRU is attached to an employee, the W-4 Federal Tax Card is generated. The association to the TRU is also generated. Additionally, the US taxation element is automatically added to the employee’s element entry once the association to the TRU is done. This tax card is not created for HR-only customers.

= = = = = =

Verifying Employee New Hire Status in Work Relationship Details

When hiring or rehiring employees, the New Hire Status field indicates whether they are to be included or excluded from new hire reporting. Find this field in the Work Relationship Details of the Employment Information page.

Field Name Description :
New Hire Status

- Identifies the employee’s employment status as pertains to the New Hire report:

Different Values

(1) Include in the New Hire report :Employee is to be included in the next run of the New Hire Report.
(2) Already reported: Employee has already been included in a previous run of the New Hire Report.
      The New Hire Report process automatically sets all included employees to this status upon                 completion in final mode.
(3) Excluded from the New Hire report : Employee is not included in the report.


= = = =

Adding a Second Assignment

To add an additional assignment to an employee’s employment information: 1. Follow steps 1 through 3 under Maintaining Employment Information above.

2. Select Edit > Update.

3. Enter an Effective Start Date (or accept the default).

4. Select Add Assignment.

5. Click OK.

6. Enter employment information.

7. Click Next.

8. Enter compensation details.

9. Click Next.

10. Add or delete roles as needed.

11. Click Next.

12. Review the information and click Submit.

13. Click Yes.

You can view and access the new assignment from the Employment Tree. The last assignment added is the one first displayed in the Manage Employment UI when it is initially accessed. The other assignments may be accessed using this tree hierarchy.

====

There are several factors that make up the payroll processing.

Taxation Within Fusion Payroll

Vertex provides all the statutory compliance for the Oracle Fusion Global Payroll engine, but it is important for you to understand how the payroll process handles US taxation.

Managing the Employee Withholding Certificate

The Employee Withholding Certificate is the default tax card. For most employees, it is created automatically during the New Hire process. The Employee Withholding Certificate provides information used in taxation. Items such as filing status, number of allowances, and exemptions from taxes are specified on the card. If no values are entered, during tax calculations, a default value of Single for filing status and zero allowances will be used.

Setting Up Automatic Tax Card Creation

To ensure that new workers get an Employee Withholding Certificate:

1. Set the PAYROLL_LICENSE process configuration parameter to either PAYROLL or PAYROLL_INTERFACE, as appropriate to your implementation.

2. Confirm that element eligibility has been created for the US Taxation element. This element is automatically added to employee’s element entry when the association to the Tax Reporting Unit is completed.

Manual Tax Card Creation

There are cases where an employee would not have their tax card automatically created, such as if they were loaded through the File Based Loader utility.

For these employees, to create an Employee Withholding Certificate:

1. Navigate to the Payroll Calculations work area.

2. Start the Manage Calculation Cards task.

3. Search for and select the person record.

4. Click Create.

5. Enter an appropriate Effective-As-of-Date, and select Employee Withholding Certificate for Name.

6. Enter employee information as appropriate at the Federal level.

7. Click Save.

8. Select the Regional link under the Component Groups tree.

9. Enter employee information as appropriate for the Regional level.

10. Click Save.

11. Select the Associations link under the Component Groups tree.

12. Under Associations, click Create.

13. Select the Tax Reporting Unit, and click OK.

14. Click Save. This creates the US Taxation Component and is displayed in the Calculation Component column after saving.

15. Under Association Details, click Create.

16. Select the Employment Terms or Assignment Number and the Calculation Component created in prior steps, and click OK.

17. Click Save. 

18. Upon tax card association creation, the following fields are autopopulated with default values on the federal-level employee withholding certificate and should be verified:

 State for Unemployment Calculation

 State for Disability Calculation

 Primary Work Address

Changing the TRU for an Assignment:

To change the TRU for a preexisting assignment on the Employee Withholding Certificate:

1. Navigate to the Payroll Calculations work area.
2. Select Manage Calculation Cards.
3. Search for and select the person record.
4. Click Employee Withholding Certificate.
5. Click Associations under the Component Groups tree.
6. Select the Tax Reporting Unit under Associations for which the assignment currently exists.
If the association for the TRU for the new assignment does not already exist, create it now.
7. Select the assignment number to change under Association Details.
8. Click Edit>Update.
9. Select the Calculation Component for the new TRU.
10. Click Save and Close.
This end dates the record for the assignment associated with the previous TRU and creates a new record for the new TRU.

Manage Tax Withholding in My Portrait

Employees can update their own withholding information in Portrait using the Manage Tax Withholding action: 

1. Select Manage Tax Withholding action in the left panel under Actions.

    This displays the Employee Withholding Certificate page.

2. Click Edit. This is available for both the federal and state level.

When the federal employee withholding certificate is accessed, the system displays the federal W-4 editable PDF form. For those states that do follow federal, the state name is stamped on the editable federal PDF form. For those states that do not follow federal, the specific state’s editable PDF form will be displayed. The employee can perform their updates on these forms for both federal and state withholding. When the form is submitted, the data is saved to the system. See Appendix C for information on accessing the PA Residency Certificate in My Portrait.

Tax Calculation:

Oracle Fusion Global Payroll automatically calculates your taxes when you perform a payroll run. The following describes the rules it uses when doing so.

Payroll Processing

When you perform a payroll run, the payroll process:

1. Determines the resident and work tax addresses based on the following hierarchy:

Address Type                                                 ---- Priority

Location address                                            ----   4
Location override address                              ----   3
Assignment-level location override               ----   3
Work at home flag = Yes                               ----   1 (overrides assignment, location override, and                                                                                           location)

Higher priorities override the lower ones.
The process derives the resident tax address from the home address, and the work tax address is derived from the work location or, if the work-at-home flag is enabled, it uses the home address.
2. Determines the related withholding status and any additional information from the tax calculation card.
3. Passes this information to Vertex for calculation.