Browser version scriptSkip Headers

Oracle® Fusion Applications Compensation Management Implementation Guide
11g Release 1 (11.1.1.5.0)
Part Number E20376-01
Go to contents  page
Contents
Go to Previous  page
Previous
Go to previous page
Next

6 Common Applications Configuration: Define Enterprise Structures for Human Capital Management

This chapter contains the following:

Define Initial Configuration

Define Reference Data Sharing

Define Legal Jurisdictions and Authorities for Human Capital Management

Define Legal Entities for Human Capital Management

Define Business Units for Human Capital Management

Define Workforce Structures: Define Organization Structures

Define Workforce Structures: Define Grades

Define Workforce Structures: Define Jobs and Positions

Define Workforce Structures: Define Worker Directory

Define Initial Configuration

Enterprise Structures: Overview

Oracle Fusion Applications have been designed to ensure your enterprise can be modeled to meet legal and management objectives. The decisions about your implementation of Oracle Fusion Applications are affected by your:

Every enterprise has three fundamental structures, legal, managerial, and functional, that are used to describe its operations and provide a basis for reporting. In Oracle Fusion, these structures are implemented using the chart of accounts and organizations. Although many alternative hierarchies can be implemented and used for reporting, you are likely to have one primary structure that organizes your business into divisions, business units, and departments aligned by your strategic objectives.

This figure is a grid in the shape
of a cube with the Business Axis representing the enterprise division,
Legal Axis representing the companies, and the Functional Axis representing
the business functions.

Legal Structure

The figure above shows a typical group of legal entities, operating various business and functional organizations. Your ability to buy and sell, own, and employ comes from your charter in the legal system. A corporation is a distinct legal entity from its owners and managers. The corporation is owned by its shareholders, who may be individuals or other corporations. There are many other kinds of legal entities, such as sole proprietorships, partnerships, and government agencies.

A legally recognized entity can own and trade assets and employ people in the jurisdiction in which it is registered. When granted these privileges, legal entities are also assigned responsibilities to:

Many large enterprises isolate risk and optimize taxes by incorporating subsidiaries. They create legal entities to facilitate legal compliance, segregate operations, optimize taxes, complete contractual relationships, and isolate risk. Enterprises use legal entities to establish their enterprise's identity under the laws of each country in which their enterprise operates.

In the figure above, a separate card represents a series of registered companies. Each company, including the public holding company, InFusion America, must be registered in the countries where they do business. Each company consists of various divisions created for purposes of management reporting. These are shown as vertical columns on each card. For example, a group might have a separate company for each business in the United States (US), but have their United Kingdom (UK) legal entity represent all businesses in that country. The divisions are linked across the cards so that a business can appear on some or all of the cards. For example, the air quality monitoring systems business might be operated by the US, UK, and France companies. The list of business divisions is on the Business Axis. Each company's card is also horizontally striped by functional groups, such as the sales team and the finance team. This functional list is called the Functional Axis. The overall image suggests that information might, at a minimum, be tracked by company, business, division, and function in a group environment. In Oracle Fusion Applications, the legal structure is implemented using legal entities.

Management Structure

Successfully managing multiple businesses requires that you segregate them by their strategic objectives, and measure their results. Although related to your legal structure, the business organizational hierarchies do not need to be reflected directly in the legal structure of the enterprise. The management structure can include divisions, subdivisions, lines of business, strategic business units, and cost centers. In the figure above, the management structure is shown on the Business Axis. In Oracle Fusion Applications, the management structure is implemented using divisions and business units.

Functional Structure

Straddling the legal and business organizations is a functional organization structured around people and their competencies. For example, sales, manufacturing, and service teams are functional organizations. This functional structure is represented by the Functional Axis in the figure above. You reflect the efforts and expenses of your functional organizations directly on the income statement. Organizations must manage and report revenues, cost of sales, and functional expenses such as research and development (R&D) and selling, general, and administrative (SG&A) expenses. In Oracle Fusion Applications, the functional structure is implemented using departments and organizations, including sales, marketing, project, cost, and inventory organizations.

Global Enterprise Configuration: Points to Consider

Start your global enterprise structure configuration by discussing what your organization's reporting needs are and how to represent those needs in the Oracle Fusion Applications. Consider deployment on a single instance, or at least, on as few instances as possible, to simplify reporting and consolidations for your global enterprises. The following are some questions and points to consider as you design your global enterprise structure in Oracle Fusion.

Enterprise Configuration

What is the level of configuration needed to achieve the reporting and accounting requirements? What components of your enterprise do you need to report on separately? Which components can be represented by building a hierarchy of values to provide reporting at both detail and summary levels? Where are you on the spectrum of centralization versus decentralization?

Business Unit Management

What reporting do I need by business unit? How can you set up your departments or business unit accounts to achieve departmental hierarchies that report accurately on your lines of business? What reporting do you need to support the managers of your business units, and the executives who measure them? How often are business unit results aggregated? What level of reporting detail is required across business units?

Security Structure

What level of security and access is allowed? Are business unit managers and the people that report to them secured to transactions within their own business unit? Are the transactions for their business unit largely performed by a corporate department or shared service center?

Compliance Requirements

How do you comply with your corporate external reporting requirements and local statutory reporting requirements? Do you tend to prefer a corporate first or an autonomous local approach? Where are you on a spectrum of centralization, very centralized or decentralized?

Modeling Your Enterprise Management Structure in Oracle Fusion: Example

This example uses a fictitious global company to demonstrate the analysis that can occur during the enterprise structure configuration planning process.

Scenario

Your company, InFusion Corporation, is a multinational conglomerate that operates in the United States (US) and the United Kingdom (UK). InFusion has purchased an Oracle Fusion enterprise resource planning (ERP) solution including Oracle Fusion General Ledger and all of the Oracle Fusion subledgers. You are chairing a committee to discuss creation of a model for your global enterprise structure including both your US and UK operations.

InFusion Corporation

InFusion Corporation has 400 plus employees and revenue of $120 million. Your product line includes all the components to build and maintain air quality monitoring (AQM) systems for homes and businesses. You have two distribution centers and three warehouses that share a common item master in the US and UK. Your financial services organization provides funding to your customers for the start up costs of these systems.

Analysis

The following are elements you need to consider in creating your model for your global enterprise structure.

Global Enterprise Structure Model

The following figure and table summarize the model that your committee has designed and uses numerical values to provide a sample representation of your structure. The model includes the following recommendations:

InFusion Corporation is the enterprise
and has two division , InFusion United States (US) and InFusion United
Kingdom (UK). InFusion US has two legal entities, InFusion America,
Inc. and InFusion Financial Services, Inc. each with its own ledger.
InFusion UK has one legal entity, Infusion UK Systems, Inc. which
has on primary ledger in Great Britain Pounds (GBP) and a Reporting
Currency representation in United States Dollar (USD). Each legal
entity has its own business unit (BU). InFusion America also has a
BU that processes general and administrative transactions across all
legal entities. InFusion Corporation has a US and a UK distribution
centers with three associated warehouses. InFusion Corporation shares
one common item master.

The table indicates if the enterprise
structure entities are mandatory or optional.

In this chart, the green globe stands for mandatory and gold globe stands for optional setup. The following statements expand on the data in the chart.

Note

Some Oracle Fusion Human Capital Management (HCM) and Customer Relationship Management (CRM) implementations do not require recording of accounting transactions and therefore, do not require implementation of a ledger.

Note

The InFusion Corporation is a legal entity but is not discussed in this example.

Designing an Enterprise Configuration: Example

This example illustrates how to set up an enterprise based on a global company operating mainly in the US and the UK with a single primary industry.

Scenario

InFusion Corporation is a multinational enterprise in the high technology industry with product lines that include all the components that are required to build and maintain air quality monitoring (AQM) systems for homes and businesses. Its primary locations are in the US and the UK, but it has smaller outlets in France, Saudi Arabia, and the United Arab Emirates (UAE).

Enterprise Details

In the US, InFusion employs 400 people and has a company revenue of $120 million. Outside the US, InFusion employs 200 people and has revenue of $60 million.

Analysis

InFusion requires three divisions. The US division will cover the US locations. The Europe division will cover the UK and France. Saudi Arabia and the UAE will be covered by the Middle East division.

InFusion requires legal entities with legal employers, payroll statutory units, tax reporting units, and legislative data groups for the US, UK, France, Saudi Arabia, and UAE, in order to employ and pay its workers in those countries.

InFusion requires a number of departments across the enterprise for each area of business, such as sales and marketing, and a number of cost centers to track and report on the costs of those departments.

InFusion requires business units for human capital management (HCM) purposes. Infusion has general managers responsible for business units within each country. Those business units may share reference data. Some reference data can be defined within a reference data set that multiple business units may subscribe to. Business units are also required for financial purposes. Financial transactions are always processed within a business unit.

Resulting Enterprise Configuration

Based on this analysis, InFusion requires an enterprise with multiple divisions, ledgers, legal employers, payroll statutory units, tax reporting units, legislative data groups, departments, cost centers, and business units.

This figure illustrates the enterprise configuration that results from the analysis of InFusion Corporation.

A figure of an enterprise configuration

Establishing Enterprise Structures Using the Enterprise Structures Configurator: Explained

The Enterprise Structures Configurator is an interview-based tool that guides you through the process of setting up a basic enterprise structure. By answering questions about your enterprise, the tool creates a structure of divisions, legal entities, business units, and reference data sets that reflects your enterprise structure. After you create your enterprise structure, you also follow a guided process to determine whether or not to use positions, and whether to set up additional attributes for jobs and positions. After you define your enterprise structure and your job and position structures, you can review them, make any necessary changes, and then load the final configuration.

This figure illustrates the process to configure your enterprise using the Enterprise Structures Configurator.

A figure that shows the process to
create an enterprise configuration using the ESC

To be able to use the Enterprise Structures Configurator, you must select the Enterprise Structures Guided Flow feature within the offerings in the Functional Setup Manager (FSM). If you do not select this feature, then you must set up your enterprise structure using individual tasks provided elsewhere in the offerings, and you cannot create multiple configurations to compare different scenarios.

Establish Enterprise Structures

To define your enterprise structures, you use the guided flow within the Establish Enterprise Structures task to enter basic information about your enterprise, such as the primary industry and the location of your headquarters. You then create divisions, legal entities, business units, and reference data sets. The Establish Enterprise Structures task enables you to create multiple enterprise configurations so that you can compare different scenarios. Until you load a configuration, you can continue to create and edit multiple configurations until you arrive at one that best suits your enterprise.

Establish Job and Position Structures

In addition to using the Establish Enterprise Structures task to create the basic structure of your enterprise, you also use a guided process to determine whether you want to use jobs only, or jobs and positions. The primary industry that you select in the Establish Enterprise Structures task provides the application with the information needed to make an initial recommendation. You can either accept the recommendation, or you can answer additional questions about how you manage people in your enterprise, and then make a selection. After you select whether to use jobs or positions, the guided process prompts you to set up a descriptive flexfield structure for jobs, and for positions if you have chosen to use them. Descriptive flexfields enable you to capture additional information when you create jobs and positions.

Review Configuration

After you create enterprise configurations and job and position structures, you can review a summary of the results of the two interview processes. For each configuration, the online summary lists the divisions, legal entities, business units, reference data sets, and job and position structures that the application will create when you load the configuration.

For a more detailed analysis of a configuration, you can access the Technical Summary Report. This report lists the same information as the online summary, but also lists the following information that will be created by the application when you load the configuration, based on your configuration:

The Technical Summary report also lists the default settings that will be loaded for these fields, which you access from the Manage Enterprise HCM Information task: Worker Number Generation, Employment Model and Allow Employment Terms Override. You can print the Technical Summary Report for each of your configurations and compare each scenario.

Load Configuration

You can load only one configuration. When you load a configuration, the application creates the divisions, legal entities, business units, and so on. After you load the configuration, you then use individual tasks to edit, add, and delete enterprise structures.

Configuration Workbench: Explained

The Oracle Fusion Enterprise Structures Configurator (ESC) is an interview based tool to help you analyze how to represent your business in the Oracle Fusion Applications. The interview process poses questions about the name of your enterprise, legal structure, management reporting structure, and primary organizing principle for your business. Based on your answers, the applications suggest the best practices to use to implement business units in your enterprise. You can use or modify these answers to ensure that both your reporting and administrative goals are met in your Oracle Fusion deployment.

Division: Explained

Managing multiple businesses requires that you segregate them by their strategic objectives and measure their results. Responsibility to reach objectives can be delegated along the management structure. Although related to your legal structure, the business organizational hierarchies do not need to reflect directly the legal structure of the enterprise. The management entities and structure can include divisions and subdivisions, lines of business, and other strategic business units, and include their own revenue and cost centers. These organizations can be included in many alternative hierarchies and used for reporting, as long as they have representation in the chart of accounts.

Divisions

A division refers to a business oriented subdivision within an enterprise, in which each division organizes itself differently to deliver products and services or address different markets. A division can operate in one or more countries, and can be comprised of many companies or parts of different companies that are represented by business units.

A division is a profit center or grouping of profit and cost centers, where the division manager is responsible for attaining business goals including profit goals. A division can be responsible for a share of the company's existing product lines or for a separate business. Managers of divisions may also have return on investment goals requiring tracking of the assets and liabilities of the division. The division manager reports to a top corporate executive.

By definition a division can be represented in the chart of accounts. Companies may choose to represent product lines, brands, or geographies as their divisions: their choice represents the primary organizing principle of the enterprise. This may coincide with the management segment used in segment reporting.

Oracle Fusion Applications supports a qualified management segment and recommends that you use this segment to represent your hierarchy of business units and divisions. If managers of divisions have return on investment goals, make the management segment a balancing segment. Oracle Fusion applications allows up to three balancing segments. The values of the management segment can be comprised of business units that roll up in a hierarchy to report by division.

Historically, divisions were implemented as a node in a hierarchy of segment values. For example, Oracle E-Business Suite has only one balancing segment, and often the division and legal entity are combined into a single segment where each value stands for both division and legal entity.

Use of Divisions in Oracle Fusion Human Capital Management (HCM)

Divisions are used in HCM to define the management organization hierarchy, using the generic organization hierarchy. This hierarchy can be used to create organization based security profiles.

Legal Entities: Explained

A legal entity is a recognized party with rights and responsibilities given by legislation.

Legal entities have the right to own property, the right to trade, the responsibility to repay debt, and the responsibility to account for themselves to regulators, taxation authorities, and owners according to rules specified in the relevant legislation. Their rights and responsibilities may be enforced through the judicial system. Define a legal entity for each registered company or other entity recognized in law for which you want to record assets, liabilities, and income, pay transaction taxes, or perform intercompany trading.

A legal entity has responsibility for elements of your enterprise for the following reasons:

The Role of Your Legal Entities

In configuring your enterprise structure in Oracle Fusion Applications, you need to understand that the contracting party on any transaction is always the legal entity. Individual legal entities own the assets of the enterprise, record sales and pay taxes on those sales, make purchases and incur expenses, and perform other transactions.

Legal entities must comply with the regulations of jurisdictions, in which they register. Europe now allows for companies to register in one member country and do business in all member countries, and the US allows for companies to register in one state and do business in all states. To support local reporting requirements, legal reporting units are created and registered.

You are required to publish specific and periodic disclosures of your legal entities' operations based on different jurisdictions' requirements. Certain annual or more frequent accounting reports are referred to as statutory or external reporting. These reports must be filed with specified national and regulatory authorities. For example, in the United States (US), your publicly owned entities (corporations) are required to file quarterly and annual reports, as well as other periodic reports, with the Securities and Exchange Commission (SEC), who enforces statutory reporting requirements for public corporations.

Individual entities privately held or held by public companies do not have to file separately. In other countries, your individual entities do have to file in their own name, as well as at the public group level. Disclosure requirements are diverse. For example, your local entities may have to file locally to comply with local regulations in a local currency, as well as being included in your enterprise's reporting requirements in different currency.

A legal entity can represent all or part of your enterprise's management framework. For example, if you operate in a large country such as the United Kingdom or Germany, you might incorporate each division in the country as a separate legal entity. In a smaller country, for example Austria, you might use a single legal entity to host all of your business operations across divisions.

Creating Legal Entities in the Enterprise Structures Configurator: Points to Consider

Using the Enterprise Structures Configurator (ESC), you can create legal entities for your enterprise automatically, based on the countries in which divisions of your business operate, or you can upload a list of legal entities from a spreadsheet.

Automatically Creating Legal Entities

If you are not certain of the number of legal entities that you need, you can create them automatically. To use this option, you first identify all of the countries in which your enterprise operates. The application opens the Map Divisions by Country page, which contains a matrix of the countries that you identified, your enterprise, and the divisions that you created. You select the check boxes where your enterprise and divisions intersect with the countries to identify the legal entities that you want the application to create. The enterprise is included for situations where your enterprise operates in a country and acts on behalf of several divisions within the enterprise and is a legal employer in a country. If you select the enterprise for a country, the application creates a country holding company.

The application automatically creates the legal entities that you select, and identifies them as payroll statutory units and legal employers. For each country that you indicated that your enterprise operates in, and for each country that you created a location for, the application also automatically creates a legislative data group.

Any legal entities that you create automatically cannot be deleted from the Create Legal Entities page within the Enterprise Structures Configurator. You must return to the Map Divisions by Country page and deselect the legal entities that you no longer want.

Example: Creating Legal Entities Automatically

InFusion Corporation is using the ESC to set up their enterprise structure. They have identified two divisions, one for Lighting, and one for Security. The Lighting division operates in Japan and the US, and the Security division operates in the UK and India.

This figure illustrates InFusion Corporation's enterprise structure.

A figure that shows an enterprise with
divisions and countries in which the divisions operate

This table represents the selections that InFusion Corporation makes when specifying which legal entities to create on the Map Divisions by Country page.


Country

Enterprise

InFusion Lighting

InFusion Security

Japan

No

Yes

No

US

No

Yes

No

UK

No

No

Yes

India

No

No

Yes

Based on the selections made in the preceding table, the ESC creates the following four legal entities:

Creating Legal Entities Using a Spreadsheet

If you have a list of legal entities already defined for your enterprise, you can upload them from a spreadsheet. To use this option, you first download a spreadsheet template, then add your legal entity information to the spreadsheet, and then upload directly to your enterprise configuration. You can export and import the spreadsheet multiple times to accommodate revisions.

Legal Entity in Oracle Fusion: Points to Consider

Oracle Fusion Applications support the modeling of your legal entities. If you make purchases from or sell to other legal entities, define these other legal entities in your customer and supplier registers, which are part of the Oracle Fusion Trading Community Architecture. When your legal entities are trading with each other, you represent both of them as legal entities and also as customers and suppliers in your customer and supplier registers. Use legal entity relationships to determine which transactions are intercompany and require intercompany accounting. Your legal entities can be identified as legal employers and therefore, are available for use in Human Capital Management (HCM) applications.

There are several decisions that need to be considered in creating your legal entities.

The Importance of Legal Entity in Transactions

All of the assets of the enterprise are owned by individual legal entities. Oracle Fusion Financials allow your users to enter legal entities on transactions that represent a movement in value or obligation.

For example, the creation of a sales order creates an obligation for the legal entity that books the order to deliver the goods on the acknowledged date, and an obligation of the purchaser to receive and pay for those goods. Under contract law in most countries, damages can be sought for both actual losses, putting the injured party in the same state as if they had not entered into the contract, and what is called loss of bargain, or the profit that would have made on a transaction.

In another example, if you revalued your inventory in a warehouse to account for raw material price increases, the revaluation and revaluation reserves must be reflected in your legal entity's accounts. In Oracle Fusion Applications, your inventory within an inventory organization is managed by a single business unit and belongs to one legal entity.

Legal Entity and Its Relationship to Business Units

A business unit can process transactions on behalf of many legal entities. Frequently, a business unit is part of a single legal entity. In most cases the legal entity is explicit on your transactions. For example, a payables invoice has an explicit legal entity field. Your accounts payables department can process supplier invoices on behalf of one or many business units.

In some cases, your legal entity is inferred from your business unit that is processing the transaction. For example, your business unit A agrees on terms for the transfer of inventory to your business unit B. This transaction is binding on your default legal entities assigned to each business unit. Oracle Fusion Procurement, Oracle Fusion Projects, and Oracle Fusion Supply Chain applications rely on deriving the legal entity information from the business unit.

Legal Entity and Its Relationship to Divisions

The division is an area of management responsibility that can correspond to a collection of legal entities. If desired, you can aggregate the results for your divisions by legal entity or by combining parts of other legal entities. Define date-effective hierarchies for your cost center or legal entity segment in your chart of accounts to facilitate the aggregation and reporting by division. Divisions and legal entities are independent concepts.

Legal Entity and Its Relationship to Ledgers

One of your major responsibilities is to file financial statements for your legal entities. Map legal entities to specific ledgers using the Oracle Fusion General Ledger Accounting Configuration Manager. Within a ledger, you can optionally map a legal entity to one or more balancing segment values.

Legal Entity and Its Relationship to Balancing Segments

Oracle Fusion General Ledger supports up to three balancing segments, Best practices recommend that one of these segments represents your legal entity to ease your requirement to account for your operations to regulatory agencies, tax authorities, and investors. Accounting for your operations means you must produce a balanced trial balance sheet by legal entity. If you account for many legal entities in a single ledger, you must:

  1. Identify the legal entities within the ledger

  2. Balance transactions that cross legal entity boundaries through intercompany transactions

  3. Decide which balancing segments correspond to each legal entity and assign them in Oracle Fusion General Ledger Accounting Configuration Manager. Once you assign one balancing segment value in a ledger, then all your balancing segment values must be assigned. This recommended best practice facilitates reporting on assets, liabilities, and income by legal entity.

Represent your legal entities by at least one balancing segment value. You may represent it by two or three balancing segment values if more granular reporting is required. For example, if your legal entity operates in multiple jurisdictions in Europe, you might define balancing segment values and map them to legal reporting units. You can represent a legal entity by more than one balancing segment value, do not use a single balancing segment value to represent more than one legal entity.

In Oracle Fusion General Ledger, there are three balancing segments. You can use separate balancing segments to represent your divisions or strategic business units to enable management reporting at the balance sheet level for each division or business unit. For example, use this solution to empower your business unit and divisional managers to track and assume responsibility for their asset utilization or return on investment. Using multiple balancing segments is also useful when you know at the time of implementation that you are disposing of a part of a legal entity and need to isolate the assets and liabilities for that entity.

Note

Implementing multiple balancing segments requires every journal entry that is not balanced by division or business unit, to generate balancing lines. Also, you cannot change to multiple balancing segments easily after you have begun to use the ledger because your historical data is not balanced by the new multiple balancing segments. Restating historical data must be done at that point.

To use this feature for disposal of a part of a legal entity, implement multiple balancing segments at the beginning of the legal entity's corporate life or on conversion to Oracle Fusion.

If you decided to account for each legal entity in a separate ledger, there is no requirement to identify the legal entity with a balancing segment value within the ledger.

Note

While transactions that cross balancing segments don't necessarily cross legal entity boundaries, all transactions that cross legal entity boundaries must cross balancing segments. If you make an acquisition or are preparing to dispose of a portion of your enterprise, you may want to account for that part of the enterprise in its own balancing segment even if it is not a separate legal entity. If you do not map legal entities sharing the same ledger to balancing segments, you will not be able to distinguish them using the intercompany functionality or track their individual equity.

Legal Entity and Its Relationship to Consolidation Rules

In Oracle Fusion Applications you can map legal entities to balancing segments and then define consolidation rules using your balancing segments. You are creating a relationship between the definition of your legal entities and their role in your consolidation.

Legal Entity and its Relationship to Intercompany Transactions

Use Oracle Fusion Intercompany functionality for automatic creation of intercompany entries across your balancing segments. Intercompany processing updates legal ownership within the enterprise's groups of legal entities. Invoices or journals are created as needed. To limit the number of trading pairs for your enterprise, set up intercompany organizations and assign then to your authorized legal entities. Define processing options and intercompany accounts to use when creating intercompany transactions and to assist in consolidation elimination entries. These accounts are derived and automatically entered on your intercompany transactions based on legal entities assigned to your intercompany organizations.

Intracompany trading, in which legal ownership isn't changed but other organizational responsibilities are, is also supported. For example, you can track assets and liabilities that move between your departments within your legal entities by creating departmental level intercompany organizations.

Note

In the Oracle Fusion Supply Chain applications, model intercompany relationships using business units, from which legal entities are inferred.

Legal Entity and Its Relationship to Worker Assignments and Legal Employer

Legal entities that employ people are called legal employers in the Oracle Fusion Legal Entity Configurator. You must enter legal employers on worker assignments in Oracle Fusion HCM.

Legal Entity and Payroll Reporting

Your legal entities are required to pay payroll tax and social insurance such as social security on your payroll. In Oracle Fusion Applications, you can register payroll statutory units to pay and report on payroll tax and social insurance on behalf of many of your legal entities. As the legal employer, you might be required to pay payroll tax, not only at the national level, but also at the local level. You meet this obligation by establishing your legal entity as a place of work within the jurisdiction of a local authority. Set up legal reporting units to represent the part of your enterprise with a specific legal reporting obligation. You can also mark these legal reporting units as tax reporting units if the legal entity must pay taxes as a result of establishing a place of business within the jurisdiction.

Creating Business Units in the Enterprise Structures Configurator: Points to Consider

Business units are used within Oracle Fusion applications for management reporting, processing of transactions, and security of transactional data. Using the Enterprise Structures Configurator (ESC), you create business units for your enterprise either automatically or manually.

Automatically Creating Business Units

To create business units automatically, you must specify the level at which to create business units. Business units within your enterprise may be represented at the business function level, such as Sales, Consulting, Product Development, and so on, or they may be represented at a more detailed level, where a business unit exists for each combination of countries in which you operate and the functions in those countries.

You can automatically create business units at the following levels:

Select the option that best meets your business requirements, but consider the following:

After you select a business unit level, the application generates a list of business units, and you select the ones you want the application to create. If you select a level that has two components, such as country and division, then the system displays a table listing both components, and you select the check boxes at the intersections of the components.

The business units listed by the application are suggestions only, and are meant to simplify the process to create business units. You are not required to select all of the business units suggested. When you navigate to the next page in the ESC guided flow, which is the Manage Business Units page, you cannot delete any of the business units that were created automatically. You must return to the Create Business Units page and deselect any business units that you no longer want.

Example: Selecting Business Unit Levels

InFusion Corporation is using the Enterprise Structures Configurator to set up their enterprise structure. They have identified two divisions, one for Lighting, and one for Security. They operate in four countries: US, UK, Japan, and India, and they have created a legal entity for each of the countries. The sales and marketing functions are based in both India and Japan, while the US and the UK have only the sales function.

This figure illustrates InFusion Corporation's enterprise structure.

A figure of an enterprise with divisions,
legal entities, and functions

The following table lists the options for business unit levels and the resulting business units that the application suggests for InFusion Corporation.


Business Unit Level

Suggested Business Units

Country

  • US

  • UK

  • Japan

  • India

Country and Division

  • InFusion Lighting: Japan

  • InFusion Lighting: US

  • Infusion Security: UK

  • Infusion Security: India

Country and business function

  • Sales: Japan

  • Marketing: Japan

  • Sales: US

  • Sales: UK

  • Marketing: India

  • Sales: India

Division

  • InFusion Lighting

  • InFusion Security

Division and Legal Entity

  • InFusion Lighting: Japan

  • InFusion Lighting: US

  • Infusion Security: UK

  • Infusion Security: India

Division and Business Function

  • InFusion Lighting, Sales

  • InFusion Lighting, Marketing

  • InFusion Security, Sales

  • InFusion Security, Marketing

Business Function

  • Sales

  • Marketing

Legal Entity

  • Legal Entity: Japan

  • Legal Entity: US

  • Legal Entity: UK

  • Legal Entity India

Legal Entity and Business Function

  • Legal Entity: Japan, Sales

  • Legal Entity: Japan, Marketing

  • Legal Entity: US, Sales

  • Legal Entity: UK, Sales

  • Legal Entity India, Marketing

  • Legal Entity India, Sales

Manually Creating Business Units

If none of the levels for creating business units meets your business needs, you can create business units manually, and you create them on the Manage Business Units page. If you create business units manually, then no reference data sets are created automatically. You must create them manually as well.

Business Units: Explained

A business unit is a unit of an enterprise that performs one or many business functions that can be rolled up in a management hierarchy. A business unit can process transactions on behalf of many legal entities. Normally, it will have a manager, strategic objectives, a level of autonomy, and responsibility for its profit and loss. Roll business units up into divisions if you structure your chart of accounts with this type of hierarchy. In Oracle Fusion Applications, you assign your business units to one primary ledger. For example, if a business unit is processing payables invoices they will need to post to a particular ledger. This assignment is mandatory for your business units with business functions that produce financial transactions.

In Oracle Fusion Applications, use business unit as a securing mechanism for transactions. For example, if you run your export business separately from your domestic sales business, secure the export business data to prevent access by the domestic sales employees. To accomplish this security, set up the export business and domestic sales business as two separate business units.

The Oracle Fusion Applications business unit model:

Business units process transactions using reference data sets that reflect your business rules and policies and can differ from country to country. With Oracle Fusion Application functionality, you can choose to share reference data, such as payment terms and transaction types, across business units, or you can choose to have each business unit manage its own set depending on the level at which you wish to enforce common policies.

In countries where gapless and chronological sequencing of documents is required for subledger transactions, define your business units in alignment with your ledger definition, because the uniqueness of sequencing is only ensured within a ledger. In these cases, define a single ledger and assign one legal entity and business unit.

In summary, use business units in the following ways:

Brief Overview of Business Unit Security

Business units are used by a number of Oracle Fusion Applications to implement data security. You assign data roles to your users to give them access to data in business units and permit them to perform specific functions on this data. When a business function is enabled for a business unit, the application can trigger the creation of data roles for this business unit base on the business function's related job roles.

For example, if a payables invoicing business function is enabled, then it is clear that there are employees in this business unit that perform the function of payables invoicing, and need access to the payables invoicing functionality. Therefore, based on the correspondence between the business function and the job roles, appropriate data roles are generated automatically. Use Human Capital Management (HCM) security profiles to administer security for employees in business units.

Creating Reference Data Sets in the Enterprise Structures Configurator: Explained

If you created business units automatically, then the Enterprise Structures Configurator automatically creates reference data sets for you. The Enterprise Structures Configurator creates one reference data set for each business unit. You can add additional sets, but you cannot delete any of the sets that were created automatically.

A standard set called the Enterprise set is predefined.

Common Set

The common set is a predefined set that enables you to share reference data across business units. When you select set-enabled data at the transaction level, the list of values includes data in both the common set and the set associated with the data type for the business unit on the transaction. For example, when you create an assignment, the list of values for grades will include both grades in the common set and in the set that is assigned to grades for the business unit in which you creating the assignment.

Reference Data Sets and Sharing Methods: Explained

Oracle Fusion Applications reference data sharing feature is also known as SetID. The reference data sharing functionality supports operations in multiple ledgers, business units, and warehouses, thereby reducing the administrative burden and decreasing the time needed to implement new business units. For example, you can share sales methods, transaction types, or payment terms across business units or selected other data across asset books, cost organizations, or project units.

The reference data sharing features use reference data sets to which reference data is assigned. The reference data sets group assigned reference data. The sets can be understood as buckets of reference data assigned to multiple business units or other application components.

Reference Data Sets

You begin this part of your implementation by creating and assigning reference data to sets. Make changes carefully as changes to a particular set will affect all business units or application components using that set. You can assign a separate set to each business unit for the type of object that is being shared. For example, assign separate sets for payment terms, transaction types, and sales methods to your business units.

Your enterprise can decide that some aspects of corporate policy should affect all business units and leave other aspects to the discretion of the business unit manager. This allows your enterprise to balance autonomy and control for each business unit. For example, if your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level, you can let managers define their own sales methods, but define payment terms centrally. In this case, each business unit would have its own reference data set for sales methods, and there would be one central reference data set for payment terms assigned to all business units.

The reference data sharing is especially valuable for lowering the cost of setting up new business units. For example, your enterprise operates in the hospitality industry. You are adding a new business unit to track your new spa services. The hospitality divisional reference data set can be assigned to the new business unit to quickly setup data for this entity component. You can establish other business unit reference data in a business unit specific reference data set as needed

Reference Data Sharing Methods

There are variations in the methods used to share data in reference data sets across different types of objects. The following list identifies the methods:

Note: Oracle Fusion Applications contains a reference data set called Enterprise. Define any reference data that affects your entire enterprise in this set.

Business Units and Reference Data Sets: How They Work Together

Reference data sharing is a feature within Oracle Fusion that enables you to group set-enabled reference data such as jobs or grades so that the data can be shared across different parts of the organization. Sets also enable you to filter reference data at the transaction level so that only data that has been assigned to certain sets is available to select. To filter reference data, Oracle Fusion Human Capital Management (HCM), applications use the business unit on the transaction. To set up reference data sharing in Oracle Fusion HCM, you create business units and sets, and then assign the sets to the business units.

Common Set Versus Specific Sets

Some reference data in your organization may be considered global, and should therefore be made available for use within the entire enterprise. You can assign this type of data to the Common Set, which is a predefined set. Regardless of the business unit on a transaction, reference data that has been assigned to the Common Set will always be available, in addition to the reference data that has been assigned to the set that corresponds to the business unit on the transaction.

Other types of reference data may be specific to certain business units, so you want to restrict the use of the data to those business units. In this case, you can create sets specifically for this type of data, and assign the sets to the business units.

Business Unit Set Assignment

When you assign reference data sets to business units, you assign a default reference data set that will be used for all reference data types for that business unit. You can override the set assignment for one or more data types.

Example: Assigning Sets to Business Units

InFusion Corporation has two divisions: Lighting and Security, and the divisions each have two locations. Each location has one or more business functions.

The following figure illustrates the structure of InFusion Corporation.

A table that illustrates an enterprise
structure

When deciding how to create business units, InFusion decides to create them using the country and business function level. Therefore, they created the following business units:

Because locations, departments, and grades are specific to each business unit, InFusion does not want to share these types of reference data across business units. They will create a reference data set for each business unit so that data of those types can be set up separately. Because the jobs in the Sales business function are the same across many locations, InFusion decides to create one additional set called Jobs and they will override the set assignment for the Jobs reference data group and assign it to the Jobs set. Based on these requirements, they create the following sets:

InFusion assigns business units to sets as follows:


Business Unit

Default Set Assignment

Set Assignment Overrides

Sales_Japan

Sales_Japan_Set for grades, departments, and locations

Jobs set for jobs

Marketing_Japan

Mktg_Japan_Set for grades, departments, and locations

None

Sales_US

Sales_US_Set for grades, departments, and locations

Jobs set for jobs

Sales_UK

Sales_UK_Set for grades, departments, and locations

Jobs set for jobs

Marketing_India

Mktg_India_Set for grades, departments, and locations

None

Sales_India

Sales_India_Set for grades, departments, and locations

Jobs set for jobs

When setting up grades, departments, and locations for the business units, InFusion will assign the data to the default set for each business unit. When setting up jobs, they will assign the Jobs set and will assign the Common Set to any jobs that may be used throughout the entire organization.

When using grades, departments, and locations at the transaction level, users will be able to select data from the set that corresponds to the business unit that they enter on the transaction, and any data that was assigned to the Common Set. For example, for transactions for the Marketing_Japan business unit, grades, locations, and departments from the Mktg_Japan_Set will be available to select, as well as from the Common Set.

When using jobs at the transaction level, users will be able to select jobs from the Jobs set and from the Common Set when they enter one of the Sales business units on the transaction. For example, when a manager hires an employee for the Sales_India business unit, the list of jobs will be filtered to show jobs from the Jobs set and from the Common Set.

The following figure illustrates what sets of jobs can be accessed when a manager creates an assignment for a worker.

A figure that shows the jobs that can
be accessed

Jobs and Positions: Critical Choices

Jobs and positions represent roles that enable you to distinguish between tasks and the individuals who perform those tasks. The key to whether to use jobs or positions is how each is used. Positions offer a well-defined space independent of the person performing the job. Jobs are a space defined by the person. A job can be defined globally in the Common Set, whereas a position is defined within one business unit.

You can update the job and department of a position at any time. This is useful if you hire someone into a new role and want to transfer the position to another department.

During implementation, one of the earliest decisions you will make is whether to use jobs or a combination of jobs and positions. The determinants for this decision are:

Primary Industry of Your Enterprise

Primary industries and how they usually set up their workforce are listed in the table below.


Primary Industry

Workforce Setup

Mining

Positions

Utilities

Positions

Manufacturing

Positions

Retail Trade

Positions

Transportation and Warehousing

Positions

Educational Services

Positions

Public Transportation

Positions

Agriculture, Forestry, Fishing, and Hunting

Jobs

Construction

Jobs

Wholesale Trade

Jobs

Information

Jobs

Finance and Insurance

Jobs

Professional, Scientific, and Technical Services

Jobs

Management of Companies and Enterprises

Jobs

Administrative and Support and Waste Management and Remediation Services

Jobs

Arts, Entertainment, and Recreation

Jobs

Accommodation and Food Services

Jobs

Other Services (Except Public Administration)

Jobs

Management of People

The following table displays suggestions of whether to use jobs or a combination of jobs and positions based on your industry and how you manage your employees when there is turnover.


Industry

We always replace employees by rehiring to same role

We replace the head count, but the manager can use the head count in a different job

We rehire to the same position, but the manager can request a reallocation of budget to a different post

Project (An industry that supports project-based forms of organization in which teams of specialists from both inside and outside the company report to project managers.)

Positions

Jobs

Jobs

Controlled (An industry that is highly structured in which all aspects of work and remuneration are well organized and regulated.)

Positions

Positions

Positions

Manufacturing

Positions

Jobs

Positions

Retail

Positions

Jobs

Positions

Education

Positions

Jobs

Positions

Other

Positions

Jobs

Jobs

Job and Position Structures: Explained

Job and position structures identify the descriptive flexfield structure that enables you to specify additional attributes that you want to capture when you define jobs and positions. Job and position attributes provide further detail to make jobs and positions more specific. You also use attributes to define the structure of your jobs and positions. You can specify attributes at the enterprise level for jobs and positions, at the business unit level for positions, and at the reference data set level for jobs. Job and position structures are optional.

Enterprise-Level Job Attributes

When you define a job, you enter a value for the name of the job. To make job names more specific, set up attributes that enable you to identify additional details about the job, such as the nature of the work that is performed or the relative skill level required for the job. If these attributes apply to all jobs within your enterprise, set up enterprise-level job attributes. Standard capabilities mean that you can use the different segments of the name to identify common jobs or job holders for analysis or compensation, or for grouping records in reports, for example, to find all jobs of a specific job type. You should not use attributes with values that change regularly, for example, salary ranges or expense approval levels that change every year.

This figure illustrates how job type and job level provide further details for the HR Application Specialist job.

A figure that illustrates additional
attributes for a job

Enterprise-Level Position Attributes

Position attributes at the enterprise level are similar to those for jobs. Each position that you define identifies a specific role in the enterprise, which you can manage independently of the person in the position, and it will belong to one specific department or organization. The name of each position must be unique. To simplify the process of managing unique names for positions, set up enterprise-level attributes to identify separate components of the position name. For example, you can set up an attribute for position title and one for position number. When defining the attributes that make up the structure of a position name you should also consider if any of your attributes are part of the definition of a common job type. Using job types for a position can help you manage common information that applies to many different positions. For example you can define a job type of Manager.Level 1 and use this for comparison of positions across departments or lines or business, or for setting common job requirements. You can then define multiple manager type positions in your HR department, each of which has responsibility for a different management function or group.

This figure illustrates how title and position number provide further details for the manager position.

A figure that illustrates additional
attributes for a position

Business Unit-Level Attributes for Positions

If you have information that you want to capture for positions that is specific to each business unit, then you can define attributes at the business unit level for positions. When you create positions, these attributes appear in addition to any enterprise-level attributes. For example, you may want to identify the sales region for all positions in the sales business unit. You can set up a text attribute called Sales Region and use it to enter the necessary information when creating positions for the sales business unit.

Reference Data Set-Level Attributes for Jobs

If you have information for jobs that applies to specific reference data sets, set up attributes for jobs at the reference data set level. When you create jobs, these attributes appear in addition to any enterprise-level attributes. For example, you may want to identify all information technology (IT) jobs within a specific set. You can set up a text attribute called Function and use it to enter IT in jobs that you create that perform an IT function within a specific set.

Jobs: Example

Jobs are typically used without positions by service industries where flexibility and organizational change are key features.

Software Industry

For example, XYZ Corporation has a director over the departments for developers, quality assurance, and technical writers. Recently, three developers have left the company. The director decides to redirect the head count to other areas. Instead of hiring all three back into development, one person is hired to each department, quality assurance, and technical writing.

In software industries, the organization is fluid. Using jobs gives an enterprise the flexibility to determine where to use head count, because the job only exists through the person performing it. In this example, when the three developers leave XYZ Corporation, their jobs no longer exist, therefore the corporation has the flexibility to move the headcount to other areas.

This figure illustrates the software industry job setup.

Jobs setup example

Positions: Examples

Positions are typically used by industries that use detailed approval rules, which perform detailed budgeting and maintain head counts, or have high turnover rates.

Retail Industry

ABC Corporation has high turnover. It loses approximately 5% of their cashiers monthly. The job of cashier includes three positions: front line cashier, service desk cashier, and layaway cashier. Each job is cross trained to take over another cashier position. When one cashier leaves from any of the positions, another existing cashier from the front line, service desk or layaway can assist where needed. . But to ensure short lines and customer satisfaction, ABC must replace each cashier lost to turnover.

Since turnover is high in retail it is better for this industry to use positions. There is an automatic vacancy when an employee terminates employment. The position exists even when there are no holders. This is important if the person who leaves the company is a manager or supervisor with direct reports. All direct reports continue reporting to the position even if it is empty. You do not need to reassign these employees to another manager or supervisor; the replacement manager is assigned to the existing position.

Also, an advantage to using positions is that when you hire somebody new many of the attributes are defaulted in from the position. This speeds up the hiring process.

This figure illustrates the retail position setup.

Position example set up for retail
industry

Health Care Industry

The hospital has a structured head count and detailed budgeting. For example, a specific number of surgeons, nurses, and interns of various types are needed. These positions need to be filled in order for the hospital to run smoothly. Use jobs and positions if you need to apply detailed head count rules.

Health care is an industry that needs to regulate employment, roles, and compensation according to strict policies and procedures. Fixed roles tend to endure over time, surviving multiple incumbents. Industries that manage roles rather than individuals, where roles continue to exist after individuals leave, typically model the workforce using positions.

This figure illustrates the hospital position setup.

Position example set up for a health
care industry

FAQs for Define Initial Configuration

What happens if I don't use the Enterprise Structures Configurator to set up my enterprise structures?

The Enterprise Structures Configurator is an interview-based tool that guides you through setting up divisions, legal entities, business units, and reference data sets. The tool also enables you to assign reference data sets to business units and locations. You can set up multiple configurations to perform what-if scenarios, and then print each configuration to compare the resulting enterprise structure. If you do not use the Enterprise Structures Configurator, then you must set up your enterprise structure using the individual tasks that correspond to each enterprise component. In addition, you will not be able to set up multiple configurations and compare different scenarios. It is recommended that you use the Enterprise Structures Configurator.

What's an ultimate holding company?

The legal entity that represents the top level in your organization hierarchy, as defined by the legal name entered for the enterprise. This designation is used only to create an organization tree, with the ultimate holding company as the top level, divisions and country holding companies as the second level, and legal employers as the third level.

What happens if I override the set assignment?

For the selected business unit, you can override the default reference data set for one or more reference data groups. For example, assume you have three reference data groups: Vision 1 SET, Vision 2 SET, and Vision 3 SET, where Vision SET 1 is the default set for business unit United Kingdom Vision 1 BU. You can override the default so that grades are assigned to Vision 2 SET, departments are assigned to Vision 3 SET, and jobs are assigned to the default set, Vision 3 SET.

What's the default reference data set?

The reference data set that is assigned to a business unit for all reference data groups, such as grades, locations, departments, and jobs. You can override the default reference data set for any reference data group.

Define Reference Data Sharing

Reference Data Sharing: Explained

Reference data sharing facilitates sharing of configuration data such as jobs and payment terms, across organizational divisions or business units. You define reference data sets and determine how the data is shared or partitioned. Use reference data sets to reduce duplication and maintenance by sharing common data across business entities where appropriate. Depending on the requirement (specific or common), each business unit can maintain its data at a central location, using a set of values either specific to it or shared by other business units.

You can share reference data after it is filtered on the basis of sets. A common reference data set is available as the default set, which can be assigned to several business units sharing the same reference data. For commonly used data such as currencies, you can use the common reference data set and assign it to multiple business units in various countries that use the same currency. In cases where the default set cannot be assigned to an entity, you can create specific sets. The data set visible on the transactional page depends on the sharing method used to share reference data.

For example, XYZ Corporation uses the same grades throughout the entire organization. Instead of managers in different business units setting up the same grades, XYZ Corporation decides to create a set called Grades and assign the grades reference data group for all business units in the organization to the Grades set, so that the grades can be shared.

Note

For specific information on configuring reference data sharing for a particular object or product, refer to its product documentation.

FAQs for Define Reference Data Sharing

What reference data objects can be shared across business units?

The following list contains the reference data objects for the Oracle Fusion Applications that can be shared across business units and the method in which the reference data for each is shared.


Application Name

Reference Data Object

Method of Sharing

Trading Community Model

Customer Account Relationship

Assignment to one set only, with common values

Trading Community Model

Customer Account Site

Assignment to one set only, with common values

Trading Community Model

Sales Person

Assignment to one set only, with common values

Opportunity Management

Sales Method Group

Assignment to one set only, with common values

Work Management

Assessment Templates

Assignment to one set only, with common values

Enterprise Contracts

Contract Types

Assignment to one set only, with common values

Sales

Sales Method

Assignment to one set only, with common values

Common Components

Activity Templates

Assignment to one set only, with common values

Payables

Payment Terms

Assignment to multiple sets, no common values allowed

Receivables

Accounting Rules

Assignment to one set only, with common values

Receivables

Aging Buckets

Assignment to one set only, with common values

Receivables

Auto Cash Rules

Assignment to one set only, with common values

Receivables

Collectors

Assignment to one set only, with common values

Receivables

Lockbox

Assignment to one set only, with common values

Receivables

Memo Lines

Assignment to one set only, with common values

Receivables

Payment Term

Assignment to one set only, with common values

Receivables

Remit To Address

Assignment to one set only, with common values

Receivables

Revenue Contingencies

Assignment to one set only, with common values

Receivables

Transaction Source

Assignment to one set only, with common values

Receivables

Transaction Type

Assignment to one set only, with common values

Advanced Collections

Collections Setups

Assignment to one set only, with common values

Advanced Collections

Dunning Plans

Assignment to one set only, with common values

Tax

Tax Classification Codes

Assignment to one set only, with common values

Performance Management

Performance Templates

Assignment to one set only, with common values

Human Resources

Departments

Assignment to one set only, with common values

Human Resources

Jobs

Assignment to one set only, with common values

Human Resources

Locations

Assignment to one set only, with common values

Human Resources

Grades

Assignment to one set only, with common values

Project Billing

Project and Contract Billing

Assignment to multiple sets, common values not allowed

Project Foundation

Project Accounting Definition

Assignment to one set only, no common values allowed

Project Foundation

Project Rates

Assignment to one set only, with common values

Distributed Order Orchestration

Hold Codes

Assignment to one set only, with common values

Distributed Order Orchestration

Orchestration Process

Assignment to one set only, with common values

Define Legal Jurisdictions and Authorities for Human Capital Management

Jurisdictions: Explained

Jurisdiction is a physical territory such as a group of countries, country, state, county, or parish where a particular piece of legislation applies. French Labor Law, Singapore Transactions Tax Law, and US Income Tax Laws are examples of particular legislation that apply to legal entities operating in different countries' jurisdictions. Judicial authority may be exercised within a jurisdiction.

Types of jurisdictions are:

Identifying Jurisdiction

For each legal entity, select an identifying jurisdiction. An identifying jurisdiction is your first jurisdiction you must register with to be allowed to do business in a country. If there is more than one jurisdiction that a legal entity needs to register with to commence business, select one as the identifying jurisdiction. Typically the identifying jurisdiction is the one you use to uniquely identify your legal entity.

Income tax jurisdictions and transaction tax jurisdictions do not represent the same jurisdiction. Although in some countries, the two jurisdictions are defined at the same geopolitical level, such as a country, and share the same legal authority, they are two distinct jurisdictions.

Income Tax Jurisdiction

Create income tax jurisdictions to properly report and remit income taxes to the legal authority. Income tax jurisdictions by law impose taxes on your financial income generated by all your entities within their jurisdiction. Income tax is a key source of funding that the government uses to fund its activities and serve the public.

Transaction Tax Jurisdiction

Create transaction tax jurisdictions through Oracle Fusion Tax in a separate business flow, because of the specific needs and complexities of various taxes. Tax jurisdictions and their respective rates are provided by suppliers and require periodic maintenance. Use transaction tax jurisdiction for legal reporting of sales and value added taxes.

Jurisdictions and Legal Authorities: Explained

You are required to register your legal entities with legal authorities in the jurisdictions where you conduct business. Register your legal entities as required by local business requirements or other relevant laws. For example, register your legal entities for tax reporting to report sales taxes or value added taxes.

Legal Jurisdictions and Authorities

Define jurisdictions and related legal authorities to support multiple legal entity registrations, which are used by Oracle Fusion Tax and Oracle Fusion Payroll. When you first create a legal entity, the Oracle Fusion Legal Entity Configurator automatically creates one legal reporting unit for that legal entity with a registration.

Legal Authorities: Explained

A legal authority is a government or legal body that is charged with powers to make laws, levy and collect fees and taxes, and remit financial appropriations for a given jurisdiction.

Legal Authorities

For example, the Internal Revenue Service is the authority for enforcing income tax laws in United States. In some countries, such as India and Brazil, you are required to print legal authority information on your tax reports. Legal authorities are defined in the Oracle Fusion Legal Entity Configurator. Tax authorities are a subset of legal authorities and are defined using the same setup flow.

Legal authorities are not mandatory in Oracle Fusion Human Capital Management (HCM), but are recommended and are generally referenced on statutory reports.

Define Legal Entities for Human Capital Management

Payroll Statutory Units, Legal Employers, and Tax Reporting Units: How They Work Together

When you set up legal entities, you can identify them as legal employers and payroll statutory units, which makes them available for use in Oracle Fusion Human Capital Management (HCM). A tax reporting unit is created automatically when you add a legal entity and identify it as a payroll statutory unit. Depending on how your organization is structured, you may have only one legal entity that is also a payroll statutory unit and a legal employer, or you may have multiple legal entities, payroll statutory units, and legal employers.

Legal Employers and Payroll Statutory Unit

Payroll statutory units enable you to group legal employers so that you can perform statutory calculations at a higher level, such as for court orders or for United Kingdom (UK) statutory sick pay. In some cases, a legal employer is also a payroll statutory unit. However, your organization may have several legal employers under one payroll statutory unit. A legal employer can belong to only one payroll statutory unit.

Payroll Statutory Units and Tax Reporting Units

Payroll statutory units and tax reporting units have a parent-child relationship, with the payroll statutory unit being the parent.

Tax Reporting Units and Legal Employers

Tax reporting units are indirectly associated with a legal employer through the payroll statutory unit. One or more tax reporting units can be used by a single legal employer, and a tax reporting unit can be used by one or more legal employers. For example, assume that a single tax reporting unit is linked to a payroll statutory unit. Assume also that two legal employers are associated with this payroll statutory unit. In this example, both legal employers are associated with the single tax reporting unit.

FAQs for Define Legal Entities for Human Capital Management

What's a legal employer?

A legal employer is a legal entity that employs workers. You define a legal entity as a legal employer in the Oracle Fusion Legal Entity Configurator.

The legal employer is captured at the work relationship level, and all employment terms and assignments within that relationship are automatically with that legal employer. Legal employer information for worker assignments is also used for reporting purposes.

What's a payroll statutory unit?

Payroll statutory units are legal entities that are responsible for paying workers, including the payment of payroll tax and social insurance. A payroll statutory unit can pay and report on payroll tax and social insurance on behalf of one or many legal entities, depending on the structure of your enterprise. For example, if you are a multinational, multicompany enterprise, then you register a payroll statutory unit in each country where you employ and pay people. You can optionally register a consolidated payroll statutory unit to pay and report on workers across multiple legal employers within the same country. You associate a legislative data group with a payroll statutory unit to provide the correct payroll information for workers.

What's a tax reporting unit?

Use a tax reporting unit to group workers for the purpose of tax and social insurance reporting. A tax reporting unit is the Oracle Fusion Human Capital Management (HCM) version of the legal reporting unit in Oracle Fusion Applications. To create a tax reporting unit, you use the Oracle Fusion Legal Entity Configurator to define a legal entity as a payroll statutory unit. When you identify a legal entity as a payroll statutory unit, the application transfers the legal reporting units that are associated with that legal entity to Oracle Fusion HCM as a tax reporting unit (or should this be tax reporting units?). You can then access the tax reporting unit using the Manage TRU - HCM Information task.

If you identify a legal entity as a legal employer only, and not as a payroll statutory unit, you must enter a parent payroll statutory unit. The resulting legal reporting units are transferred to Oracle Fusion HCM as tax reporting units, but as children of the parent payroll statutory unit that you entered, and not the legal entity that you identified as a legal employer.

Define Business Units for Human Capital Management

Business Units: Explained

A business unit is a unit of an enterprise that performs one or many business functions that can be rolled up in a management hierarchy. A business unit can process transactions on behalf of many legal entities. Normally, it will have a manager, strategic objectives, a level of autonomy, and responsibility for its profit and loss. Roll business units up into divisions if you structure your chart of accounts with this type of hierarchy. In Oracle Fusion Applications, you assign your business units to one primary ledger. For example, if a business unit is processing payables invoices they will need to post to a particular ledger. This assignment is mandatory for your business units with business functions that produce financial transactions.

In Oracle Fusion Applications, use business unit as a securing mechanism for transactions. For example, if you run your export business separately from your domestic sales business, secure the export business data to prevent access by the domestic sales employees. To accomplish this security, set up the export business and domestic sales business as two separate business units.

The Oracle Fusion Applications business unit model:

Business units process transactions using reference data sets that reflect your business rules and policies and can differ from country to country. With Oracle Fusion Application functionality, you can choose to share reference data, such as payment terms and transaction types, across business units, or you can choose to have each business unit manage its own set depending on the level at which you wish to enforce common policies.

In countries where gapless and chronological sequencing of documents is required for subledger transactions, define your business units in alignment with your ledger definition, because the uniqueness of sequencing is only ensured within a ledger. In these cases, define a single ledger and assign one legal entity and business unit.

In summary, use business units in the following ways:

Brief Overview of Business Unit Security

Business units are used by a number of Oracle Fusion Applications to implement data security. You assign data roles to your users to give them access to data in business units and permit them to perform specific functions on this data. When a business function is enabled for a business unit, the application can trigger the creation of data roles for this business unit base on the business function's related job roles.

For example, if a payables invoicing business function is enabled, then it is clear that there are employees in this business unit that perform the function of payables invoicing, and need access to the payables invoicing functionality. Therefore, based on the correspondence between the business function and the job roles, appropriate data roles are generated automatically. Use Human Capital Management (HCM) security profiles to administer security for employees in business units.

Assigning Reference Data Sets to Reference Objects: Points to Consider

You can assign the reference data sets to reference objects on the Manage Reference Data Set Assignments page. For multiple assignments, you can classify different types of reference data sets into groups and assign them to reference entity objects. The assignment takes into consideration the determinant type, determinant, and reference group, if any.

Determinant Types

The partitioned reference data is shared based on a business context setting called the determinant type. It is the point of reference used in the data assignment process. The following table lists the determinant types used in the reference data assignment.


Type

Description

Asset Book

Information about the acquisition, depreciation, and retirement of an asset that belongs to a ledger or a business unit.

Business Unit

The departments or organizations within an enterprise.

Cost Organization

The organization used for cost accounting and reporting on various inventory and cost centers within an enterprise.

Project Unit

A logical organization within an enterprise that is responsible for enforcing consistent project management practices.

Reference Data Set

References to other shared reference data sets.

Determinant

The determinant or determinant value is the value that corresponds to the selected determinant type. The determinant is one of the criteria for selecting the appropriate reference data set. For example, when managing set assignments for the set determinant type, Reference Data Set is the determinant type, and you would enter the corresponding set code value as the corresponding determinant value.

Reference Groups

A transactional entity may have multiple reference entities (generally considered to be setup data) that are treated in the same manner because of commonness in implementing business policies and legal rules. Such reference entities in your application are grouped into logical units called reference groups, based on the functional area and the partitioning requirements that they have in common. For example, all tables and views that define Sales Order Type details might be part of the same reference group.

Note

The reference groups are predefined in the reference groups table and are available for selection and assignment.

Define Workforce Structures: Define Organization Structures

Designing an Enterprise Configuration: Example

This example illustrates how to set up an enterprise based on a global company operating mainly in the US and the UK with a single primary industry.

Scenario

InFusion Corporation is a multinational enterprise in the high technology industry with product lines that include all the components that are required to build and maintain air quality monitoring (AQM) systems for homes and businesses. Its primary locations are in the US and the UK, but it has smaller outlets in France, Saudi Arabia, and the United Arab Emirates (UAE).

Enterprise Details

In the US, InFusion employs 400 people and has a company revenue of $120 million. Outside the US, InFusion employs 200 people and has revenue of $60 million.

Analysis

InFusion requires three divisions. The US division will cover the US locations. The Europe division will cover the UK and France. Saudi Arabia and the UAE will be covered by the Middle East division.

InFusion requires legal entities with legal employers, payroll statutory units, tax reporting units, and legislative data groups for the US, UK, France, Saudi Arabia, and UAE, in order to employ and pay its workers in those countries.

InFusion requires a number of departments across the enterprise for each area of business, such as sales and marketing, and a number of cost centers to track and report on the costs of those departments.

InFusion requires business units for human capital management (HCM) purposes. Infusion has general managers responsible for business units within each country. Those business units may share reference data. Some reference data can be defined within a reference data set that multiple business units may subscribe to. Business units are also required for financial purposes. Financial transactions are always processed within a business unit.

Resulting Enterprise Configuration

Based on this analysis, InFusion requires an enterprise with multiple divisions, ledgers, legal employers, payroll statutory units, tax reporting units, legislative data groups, departments, cost centers, and business units.

This figure illustrates the enterprise configuration that results from the analysis of InFusion Corporation.

A figure of an enterprise configuration

Using Single or Multiple Classifications for an Organization: Points to Consider

Organization classifications define the purpose of the organization, whether it's a department, a division, or a legal entity. In some enterprises, organization classifications overlap, which means that the same organization can be assigned multiple classifications. For example, one organization within an enterprise might be both a project organization and a department. The classifications of organizations vary according to business objectives, legal structure, industry, company culture, size and type of growth. You can create organizations in Oracle Fusion with one or more classifications to reflect your enterprise structure.

Defining an Organization with One Classification

Define each organization in your enterprise as a separate organization with a single classification to reflect your enterprise structure and provide flexibility for growth and expansion. The advantage of setting up separate organizations is the ability to add further organizations to expand the enterprise easily. For example, if your enterprise acquires another company which has a different line of business in a country in which you employ people, then you can create a division to represent the new company, a legal entity (classified as a legal employer and payroll statutory unit) for the company's payroll tax and social insurance, and any additional departments for workers.

Defining an Organization with Multiple Classifications

Define an organization with multiple classifications if the organization has multiple purposes. For example, if you want to use an organization within the Oracle Fusion Customer Relationship Management applications as a department that employs sales people, you can classify it as a department and a sales organization. Or, if your enterprise operates and employs people in multiple countries, you can create a legal entity for each country using the Oracle Fusion Legal Entity Configurator and then use the Manage Departments task to classify them as a department as well.

Disability Organizations: Explained

Set up disability organizations to identify the external organizations with which workers with disabilities are registered. Disability organizations provide information and support to people with disabilities. The Royal National Institute of Blind People is an example of a disability organization. Disability organizations can also assess the degree to which a person is affected by the disability.

Disability Organizations and Person Records

When you create person records for workers with disabilities, you select the disability organization with which the worker is registered, identify the registration and expiration dates, and enter any other descriptive or legislative information that pertains to the disability.

Cost Centers and Departments: Explained

A cost center represents the smallest segment of an organization for which costs are collected and reported. A department is an organization with one or more operational objectives or responsibilities that exist independently of its manager and has one or more workers assigned to it.

The following two components need to be considered in designing your enterprise structure:

Cost Centers

A cost center also represents the destination or function of an expense as opposed to the nature of the expense which is represented by the natural account. For example, a sales cost center indicates that the expense goes to the sales department.

A cost center is generally attached to a single legal entity. To identify the cost centers within a chart of accounts structure use one of these two methods:

Departments

A department is an organization with one or more operational objectives or responsibilities that exist independently of its manager. For example, although the manager may change, the objectives do not change. Departments have one or more workers assigned to them.

A manager of a department is typically responsible for:

Note

The manager of a sales department may also be responsible for meeting the revenue targets.

The financial performance of departments is generally tracked through one or more cost centers. In Oracle Fusion Applications, departments are defined and classified as Department organizations. Oracle Fusion Human Capital Management (HCM) assigns workers to departments, and tracks the headcount at the departmental level.

The granularity of cost centers and their relationship to departments varies across implementations. Cost center and department configuration may be unrelated, identical, or consist of many cost centers tracking the costs of one department.

Department Classifications: Points to Consider

A department can be classified as a project organization, sales and marketing organization, or cost organization.

Oracle Fusion Human Capital Management (HCM) uses trees to model organization hierarchies. It provides seeded tree structures for department and other organizational hierarchies that can include organizations with any classification.

Project Organization

Classify departments as a project owning organization to enable associating them with projects or tasks. The project association is one of the key drivers for project access security.

In addition, you must classify departments as project expenditure organizations to enable associating them to project expenditure items. Both project owning organizations and project expenditure organizations can be used by Oracle Fusion Subledger Accounting to derive accounts for posting Oracle Fusion Projects accounting entries to Oracle Fusion General Ledger.

Sales and Marketing Organization

In Oracle Fusion Customer Relationship Management (CRM), you can define sales and marketing organizations. Sales organization hierarchies are used to report and forecast sales results. Sales people are defined as resources assigned to these organizations.

In some enterprises, the HCM departments and hierarchies correspond to sales organizations and hierarchies. It is important to examine the decision on how to model sales hierarchies in relationship to department hierarchies when implementing customer relationship management to eliminate any possible redundancy in the definition of the organizations.

The following figure illustrates a management hierarchy, in which the System Components Division tracks its expenses in two cost centers, Air Compressors and Air Transmission. At the department level, two organizations with a classifications of Department are defined, the Marketing Department and Sales Department. These two departments can be also identified as a Resource Organizations, which will allow assigning resources, such as sales people, and other CRM specific information to them. Each department is represented in the chart of accounts by more than one cost center, allowing for granular as well as hierarchical reporting.

The figure illustrates a management hierarchy, in which the System Components Division tracks
its expenses in two cost centers. The department is defined as an
organization with a classification of Marketing Department, and a
classification of Sales Department.

Cost Organization

Oracle Fusion Costing uses a cost organization to represent a single physical inventory facility or group of inventory storage centers, for example, inventory organizations. This cost organization can roll up to a manager with responsibility for the cost center in the financial reports.

A cost organization can represent a costing department. Consider this relationship when determining the setup of departments in HCM. There are no system dependencies requiring these two entities, cost organization and costing department, be set up in the same way.

Locations: Explained

A location identifies physical addresses of a workforce structure, such as a department or a job. You can also create locations to enter the addresses of external organizations that you want to maintain, such as employment agencies, tax authorities, and insurance or benefits carriers.

The locations that you create exist as separate structures that you can use for reporting purposes, and also in rules that determine employee eligibility for various types of compensation and benefits. You enter information about a location only once. Subsequently, when you set up other workforce structures you select the location from a list.

Location Sets

When you create a location, you must associate it with a set. Only those users who have access to the set's business unit can access the location set and other associated workforce structure sets, such as those that contain departments and jobs.

You can also associate the location to the common set so that users across your enterprise can access the location irrespective of their business unit. When users search for locations, they can see the locations that they have access to along with the locations in the common set.

The following figure shows how locations sets restrict access to users.

Controlling access to locations using
sets

Action Components: How They Work Together

Actions track changes to Human Capital Management (HCM) records, for example, changes to employment and assignment records. When you create or update these records, the action identifies the cause of the creation or change.

Action

You can view a history of effective-dated changes (assignment history, for example), and the action and reason details are particularly useful. You sometimes use actions to categorize the type of change. Each predefined termination action is associated with a termination type (either voluntary or involuntary) to help categorize the termination. For example, the termination actions Death and Reduction in Force are categorized as voluntary and involuntary respectively. In certain cases, actions determine the business flow. For example, you can select from a list of employment-related actions, such as Assignment Change, Transfer, or Termination. The action you select determines the path you take through the current business flow. If you want to use your own action names to track changes, you can create new actions and associate them with the appropriate action types.

Note

If you are creating your own termination-related action, it is highly recommended that you specify the termination type for the action, whether it is voluntary or involuntary. This information is useful for analysis and reporting purposes.

Action Reason

You can optionally associate reasons with actions, for example, a generic action of termination could have reasons such as voluntary retirement or involuntary layoff. The primary reason for doing this is for analysis and reporting purposes. You can view the action and reason details in the Employee Termination Report. Line managers can view predictions about who is likely to leave voluntarily, which are based on existing and historical terminations data. The process that generates the predictions uses the action and reason data to identify whether a termination is voluntary or involuntary. When managers allocate compensation to their workers, they can select from a list of action reasons that help identify the type of or reason for the compensation allocation.

Action Type

Action type identifies the type of business process associated with the action and determines what happens when you select an action. An action type is associated with one or more predefined actions. You can create your own actions and associate them with the predefined action types. For example, the Hire an Employee action type is associated with the Hire action. You could create an action Hire Part-Time and associate it with the Hire an Employee action type. Your action appears in the Action list of values on the Hire an Employee page. To hire a part-time employee, you could select the Hire Part-Time action instead of the predefined Hire action.

The Three-Tier Employment Model: Explained

The three-tier employment model comprises three types of entities, which are work relationships, employment terms, and assignments. Users can include contract details in employment terms.

When you configure the employment model for the enterprise or legal employer (when you create or update the enterprise or legal employer), the following three-tier options are available:

Single Employment Terms with Single Assignment

Each work relationship contains one set of employment terms, and each set of employment terms contains one assignment.

Both the employment terms and the assignment are created automatically.

A work relationship with one set of
employment terms and one assignment

Single Employment Terms with Multiple Assignments

Each work relationship contains one set of employment terms, and the employment terms can contain one or more assignments.

The employment terms and one assignment are created automatically when the work relationship is created; additional assignments are created manually. Additional assignments can belong to the employment terms or exist outside them.

A work relationship with a single set
of employment terms and multiple assignments

Multiple Employment Terms with Single Assignment

Each work relationship can contain one or more sets of employment terms, and each set of employment terms can contain a single assignment.

One set of employment terms and the associated assignment are created automatically when the work relationship is created; additional employment terms and assignments are created manually. Additional assignments can belong to employment terms or exist outside them.

A work relationship with multiple sets
of employment terms, each of which has a single assignment

Multiple Employment Terms with Multiple Assignments

Each work relationship can contain one or more sets of employment terms, and each set of employment terms can contain one or more assignments.

One set of employment terms and an associated assignment are created automatically when the work relationship is created; additional employment terms and assignments are created manually. Additional assignments can belong to employment terms or exist outside them.

A work relationship with multiple sets
of employment terms and multiple assignments in each

The Two-Tier Employment Model: Explained

The two-tier employment model comprises two types of entities, which are work relationships and assignments. Employment terms occur in the three-tier employment model only.

When you configure the employment model for the enterprise or legal employer (when you create or update the enterprise or legal employer), you can select from three two-tier options:

Single Assignment

If you select Single Assignment, each work relationship of any type has one assignment only.

The assignment is created automatically when the work relationship is created.

Work relationships with one assignment
each

Single Assignment with Contract

If you select Single Assignment with Contract, users can include contract information in the single assignment. This approach enables those legislations that require contract information in employment records to meet their obligations without having to use a three-tier employment model.

The assignment is created automatically when the work relationship is created. Including contract information in the assignment is optional.

Work relationships with one assignment
each, some of which include contract information

Multiple Assignments

If you select Multiple Assignments, each work relationship of any type can include one or more assignments.

One assignment is created automatically when the work relationship is created. Additional assignments are optional and are created manually.

Work relationships with one or more
assignments

Selecting the Employment Model: Critical Choices

By default, every enterprise uses the two-tier single-assignment employment model. You can select a different employment model for the enterprise or for individual legal employers. This topic discusses the choices you can make and identifies any restrictions.

Using the Two-Tier Employment Model

If you select any of the two-tier employment models at the enterprise level:

If you select:

Using the Three-Tier Employment Model

If you select any of the three-tier employment models at the enterprise level, you can select a different employment model for individual legal employers.

In legal employers where employment terms are used, employee and nonworker work relationships have at least one set of employment terms. Additional sets of employment terms, where supported, are optional.

Note that employment terms are not valid for contingent workers. If you select Single Employment Terms with Single Assignment, contingent workers have a single assignment in each work relationship; otherwise, contingent workers can have multiple assignments in each work relationship.

If you select a three-tier employment model that supports:

Changing the Employment Model for the Enterprise or Legal Employer

In general, you can change the employment model for the enterprise or legal employer both during initial implementation and later. However, there are some restrictions on switching to and from particular employment models.

The following table identifies whether you can switch from one two-tier employment model to a different two-tier employment model.


From

To Single Assignment

To Single Assignment with Contract

To Multiple Assignments

Single Assignment

N/A

See note

Yes

Single Assignment with Contract

See note

N/A

Yes

Multiple Assignments

See note

Yes

N/A

Note

Yes, provided that no work relationships exist in the enterprise or legal employer.

You can switch from a two-tier employment model to a three-tier employment model only if no work relationships exist in the enterprise or legal employer.

You can switch from a three-tier employment model to a two-tier employment model only if no work relationships exist in the enterprise or legal employer.

You can switch from one three-tier employment model to any other three-tier employment model at any time.

Employment Terms Override: Explained

If you use the three-tier employment model, assignments inherit most attribute values from the associated employment terms. For example, if you set the assignment category to full-time in the employment terms, then all assignments associated with those employment terms are full-time by default. For the enterprise or legal employer, you specify whether attribute values inherited from employment terms can be overridden at the assignment level.

Preventing Override at the Assignment Level

If you prevent override at the assignment level, then users cannot update assignment attribute values inherited from employment terms. This approach is recommended if you want to enforce particular assignment attribute values.

The restriction applies only to attribute values that users specify on the employment terms, and they can specify as many or as few attributes as required at that level. Any value that users omit from the employment terms can be updated without restriction at the assignment level.

Allowing Override at the Assignment Level

If you allow override at the assignment level, then users can update assignment attribute values inherited from employment terms. Using employment terms in this way can be efficient, particularly if workers in your enterprise have multiple assignments in a single set of employment terms: users enter attribute values once only in the employment terms, but can update individual attributes as necessary at the assignment level.

Deferring the Decision to the Employment Terms

If you have no compelling reason either to allow or to prevent override at the assignment level, you can defer the decision to each set of employment terms. That is, whenever a user creates a set of employment terms, that user can decide whether to allow or prevent override at the assignment level.

Work Day Information: Explained

Work day information defines the standard working hours for each worker assignment in the enterprise or legal employer.

Sources of Work Day Information

If a schedule has been assigned to the enterprise, legal employer, or department, work day information is taken automatically from that schedule. Otherwise, you can enter work day information for the enterprise, legal employer, and department.

Work day information can also be defined for positions. In any assignment, standard working hours are inherited from one of the following entities in this order of preference:

  1. Position

  2. Department

  3. Legal employer

  4. Enterprise

How Work Day Information Is Used

For assignment budgeting purposes, FTE is calculated automatically by dividing the assignment working hours by the standard working hours, which the assignment inherits from the position, department, legal employer, or enterprise. If standard working hours are not available for any of these entities, then FTE cannot be calculated. Although FTE can also be entered manually, automatic calculation of FTE is efficient for FTE reporting and promotes consistency among the various uses of FTE information.

Using Worker Numbers: Points to Consider

Every person record in the enterprise has a person number. In addition, you can allocate worker numbers to employee and contingent worker work relationships. Worker numbers are optional: they are provided primarily for Oracle E-Business Suite customers who have used employee and contingent worker numbers and want to continue using them.

Enabling Worker Numbers for the Enterprise

By default, worker numbers are not used. If you enable worker numbers for the enterprise, then each employee and contingent worker work relationship in the enterprise must have a worker number. If you do not enable worker numbers for the enterprise, they cannot be used. The decision that you make for the enterprise cannot be overridden at the legal employer level.

Selecting the Number-Generation Method

Worker numbers can be generated either manually or automatically.

If you select manual generation, then you are recommended to define a numbering scheme to suit local requirements. For example, determine whether uniqueness within the enterprise or at the legal employer level is important, and define the numbering scheme accordingly.

If you select automatic worker-number generation, numbers can be allocated from either an enterprise sequence or a legal employer sequence. If you use a legal-employer sequence, worker numbers are not guaranteed to be unique in the enterprise. Also, they cannot be transferred outside the legal employer: if a worker leaves the enterprise and later starts a new work relationship of the same type but with a different legal employer, a new worker number is allocated to the work relationship.

Setting the Number-Generation Method for a Legal Employer

All legal employers automatically inherit the enterprise number-generation method. You can override the number-generation method at the legal employer level, as follows:

FAQs for Define Organization Structures

What's a reporting establishment?

A reporting establishment is an organization that is used for statutory reporting other than tax and social insurance reporting. A reporting establishment has a parent-child relationship with a legal employer, with the legal employer being the parent organization. A legal employer can be the parent of multiple reporting establishments.

In some countries, such as France, a reporting establishment can also be a tax reporting unit.

What's the difference between a job set and a job family?

A job family is a group of jobs that have different but related functions, qualifications, and titles. They are beneficial for reporting. You can define competencies for job families by associating them with model profiles.

A job set is an organizational partition of jobs. For example, a job set can be global and include jobs for use in all business units, or it can be restricted to jobs for a specific country or line of business. When you select a job, for a position or an assignment, the available jobs are those in the set associated with the business unit in which you are working, and also those in the Common set.

What's the purpose of the legislative action attributes?

The legislative attributes apply to the transfer and termination actions. You can indicate whether an action is transfer-related. You can specify the termination type for termination-related actions. For example, the termination-related action Resignation can have the termination type as voluntary and the action Reduction in Force can have the termination type as involuntary. You may enter this information typically to meet specific legislative requirements or for reporting purposes.

Can I delete an action or action reason?

No. If you no longer want users to select an action or action reason you can enter an end date, beyond which the action or reason will be unavailable.

Can I create additional action types?

No. Action types are predefined and can contain one or more actions. You may associate your actions with the predefined action types but not create your own action types.

Can I delete an organization?

No. However, you can disable an organization if it is no longer required. For example, if the enterprise is downsizing, then you can set the status of the organization to inactive. Changing the status of the organization disables the organization and the organization is no longer available to select.

How can I identify my organization in a report?

Use the organization manager information to enter a reporting name to help you identify an organization in a report. You use organization hierarchies for statutory, legal and management reporting.

Why can't I see my location in the search results?

You can search for approved locations only. Also, if you created a location in Oracle Fusion Trading Community Model, then you can't access that location from Oracle Fusion Global Human Resources. For use in Oracle Fusion HCM, you must recreate the location from the Manage Locations page.

How can I associate a location with an inventory organization?

From the Manage Locations page in Oracle Fusion Global Human Resources.

To appear on the Create or Edit Location pages, your inventory organization must be effective on today's date and must exist in the location set that you selected.

What happens if I select an inventory organization when I'm creating or editing a location?

The location is available for selection in purchase documents of that inventory organization in Oracle Fusion Inventory Management. If you don't select an inventory organization, then the location is available in purchase documents across all inventory organizations.

What happens if I select a geographic hierarchy node when I'm creating or editing a location?

The calendar events that were created for the geographical node start to apply for the location and may impact the availability of worker assignments at that location. The geographical hierarchy nodes available for selection on the Locations page display from a predefined geographic hierarchy.

What happens if I inactivate a location?

Starting from the effective date that you entered, you can no longer associate the location with other workforce structures, assignments, or applications. If the location is already in use, it will continue to be available to the components that currently use it.

Define Workforce Structures: Define Grades

Grades: Explained

Create grades to record the level of compensation for workers. You can create grades for multiple pay components, such as salary, bonus, and overtime rates. You can define one or more grades that are applicable for jobs and positions. This list of valid grades, combined with the settings for two profile options, enables you to restrict the grades that can be selected when you set up assignments or employment terms for a worker.

Grades and Sets

You assign each grade to a set. If you assign a grade to the common set, then the grade is available for use in all business units. To limit a grade to a single business unit, you can assign it to a set that is specific to that business unit.

Grade Steps

Grade steps are distinct increments of progression within a grade. You can set up grades with or without grade steps.

The following figure illustrates the difference between grades with and without steps.

A figure comparing grades with steps
and grades without steps

Grade Rates

Grade rate values are the compensation amounts associated with each grade. You can set up rates at the same time that you create grades, or set them up independently from grades. For grades with steps, you set up the step rates when you include them in a grade ladder. Grade rates are optional.

Grade Ladders

You can combine grades into grade ladders to group your grades or grades with steps in the sequence in which your workers typically progress. For example, you might create three grade ladders for your enterprise: one for technical grades, another for management grades, and a third for administrative grades.

Lookup Types for Grades: Explained

This topic identifies the lookup type for managing grades that has an extensible customization level. Review these lookup values, and update them as appropriate to suit enterprise requirements.

Lookup Type for Grades

The GRADE_PAY_RATE_TYPE lookup type identifies the compensation components for which you want to set up grade rates. The predefined values are salary, bonus, and overtime.

Grade Rates: Explained

Grade rates contain the pay values that are related to each grade. Grade rate values can be either a fixed amount or a range of values, and you can set up rates for different types of pay, such as salary, overtime, and bonuses.

Grade rates for some jobs or positions might include an hourly salary rate and an overtime rate. Grade rates for other jobs or positions might contain a salary rate type with a range of amounts and a bonus rate type with a fixed amount. Grade rates typically serve only as a guideline to validate that the salary you propose during the compensation process for a worker on a certain grade is appropriate for that grade.

This figure illustrates a grade that has two rate types associated with it. One is a salary rate type that has a range of values, and the other is a bonus rate type with a fixed amount.

A figure that shows one grade with
both a salary rate type and a bonus rate type associated with it.

This figure illustrates a different grade that has two rate types associated with it. One is a salary rate type that has a fixed amount, and the other is an overtime rate type that also has a fixed amount.

A figure that shows one grade with
both a salary rate type that is a fixed amount and an overtime rate
type associated with it.

Rate Types

The types of rates that you can set up depend on the values for lookup type GRADE_PAY_RATE_TYPE. Examples of rate types are: salary, bonus, and overtime pay.

Grade Rates and Legislative Data Groups

You assign a legislative data group to each grade rate. Depending on how your enterprise is configured, you may have several legislative data groups. You can set up grades that are shared across different areas of your business, and then enter rates that are specific to each legislative data group.

Grade Rates and Grades

You can set up grade rates when you set up grades, or you can set them up independently from grades. For grades with steps, you enter rates when you attach the grades to a grade ladder.

Grade Ladders: Explained

Create grade ladders to group grades and grades with steps in the sequence in which your workers typically progress. Grade ladders describe the grades and steps to which a worker is eligible to progress and compensation value associated with that grade and step. You can set up separate grade ladders for different types of jobs or positions in your enterprise. For example, you may create three grade ladders for your enterprise: one for technical grades, another for management grades, and a third for administrative grades.

Ladders with Grades

You create ladders with grades by building a hierarchy of grades that were created without steps. When you set up this type of ladder, only grades without steps are available to add to the ladder. You cannot create a grade ladder with a combination of both grades and grades with steps.

You do not define any grade rates when you set up a ladder with grades; the rates for the grades within the ladder are inherited from the rates that were added when you set up the grades. To add or edit rates for grades, you must use the Manage Grade Rates task.

Ladders with Grade Steps

You create ladders with grade steps using grades that were created with steps When you set up this type of ladder, only grades with steps are available to add to the ladder.

You define step rates when you set up the ladder, and the rates are unique to each ladder. You cannot share step rates between grade ladders.

Grades, Grade Rates, Sets, and Legislative Data Groups: How They Work Together

You assign grades to sets, and you assign grade rates to legislative data groups. If you have grades that are common across multiple business units, you can assign the grades to the set that is associated with the business units, and then set up grade rates that are specific to each legislative data group.

The following figure illustrates how you can use sets to share grades across multiple business units and then change the grade rates for each legislative data group.

A figure that shows five grades assigned
to one set and then legislative data groups for the US, UK, and Australia.
Each legislative data group has the same set but different rates.

Grades and Sets

Sets enable you to share grades that are common across business units in your enterprise. You can assign grades to either a specific set or to the common set to each grade. If you assign the grade to the common set, then the grade is available for use in all business units.

Grade Rates and Legislative Data Groups

Grade rate values are associated with each component of compensation for your workers. While grades may be common across different areas of your enterprise, grade rates vary among the countries in which you employ people. For example, if your enterprise has engineer jobs in the United States, the United Kingdom, and Australia, you can set up grades for a set that is shared between the countries, but set up different grade rates for each country in the applicable currency.

Setting Up Grade Ladders for Pay Scale Requirements: Worked Example

This example illustrates how to use a grade ladder to create a pay scale that is typical of technicians in the metal industry in Germany. The ladder includes four grades, and each grade includes four steps.

The following table summarizes key decisions for the grades, rates, and grade ladder in this scenario.


Decision to Consider

In This Example

Are steps required for the grades?

Yes.

Which step in each grade should be the ceiling step?

The last step in each grade.

What type of rates are necessary?

Salary rates only.

Will the ladder be created using grades or grades with steps?

Grades with steps.

Summary of the Tasks

To set up the pay scale, complete these tasks:

Creating Grades

  1. In the Workforce Structures work area, click Manage Grades to open the Manage Grades page.
  2. On the Manage Grades page, click Create to open the Create Grade: Grade Details page.
  3. In the Grade Details region of the Create Grade: Grade Details page, complete the fields as shown in this table, using the defaults unless otherwise indicated.

    Field

    Value

    Grade Set

    Common

    Name

    Technicians 03

    Code

    Tech03


  4. Click Next to access the Create Grade: Grade Steps page.
  5. In the Grade Steps region of the Create Grade: Grade Steps page, click Add Row.
  6. Add four steps for the grade by completing the fields as shown in this table. You must click Add Row after adding each step.

    Field

    Value

    Step Name

    Year 1

    Step Name

    Year 2

    Step Name

    Year 3

    Step Name

    Year 4


  7. Verify that Year 4 is the ceiling step.
  8. Click Submit. You will add the grade rates when you create the grade ladder.
  9. In the Warning dialog, click Yes.
  10. In the Confirmation dialog, click OK.
  11. Repeat steps 2 through 9 to add three more grades with steps. Complete the information for each grade using the information in these tables. The ceiling step in each grade is Year 4.

    Field

    Grade 2

    Grade 3

    Grade 4

    Grade Set

    Common

    Common

    Common

    Name

    Technicians 04

    Technicians 05

    Technicians 06

    Code

    Tech04

    Tech05

    Tech06


    Field

    Value

    Step Name

    Year 1

    Step Name

    Year 2

    Step Name

    Year 3

    Step Name

    Year 4


Creating a Grade Ladder

  1. In the Workforce Structures work area, click Manage Grades Ladders to open the Manage Grade Ladders page.
  2. On the Manage Grade Ladders page, click Create to access the Create Grade Ladder: Grade Ladder Details page.
  3. In the Grade Ladder Details region of the Create Grade Ladder: Grade Ladder Details page, complete the fields as shown in this table, using default values unless otherwise indicated.

    Field

    Value

    Grade Set

    Common

    Name

    Metal Technicians

    Grade Type

    Grade with steps


  4. Click Next to access the Create Grade Ladder: Grades page.
  5. In the Search Grades region of the Create Grade Ladder: Grades page, enter TECH in the Code field and click Search.
  6. Select Tech03 and click Add to Grade Ladder.
  7. Select Tech04 and click Add to Grade Ladder.
  8. In the Add to Grade Ladder Hierarchy dialog, select At the top and click OK.
  9. Select Tech05 and click Add to Grade Ladder.
  10. In the Add to Grade Ladder Hierarchy dialog, select At the top and click OK.
  11. Select Tech06 and click Add to Grade Ladder.
  12. In the Add to Grade Ladder Hierarchy dialog, select At the top and click OK.
  13. Verify that the grades appear in numerical order, with Tech06 at the top of the ladder and Tech03 at the bottom of the ladder.
  14. Click Next to access the Create Grade Ladder: Rate Values page.
  15. On the Create Grade Ladder: Rate Values page, select the legislative data group for Germany.
  16. In the Grade Step Rates region, click Add Row.
  17. Complete the following fields as shown in this table.

    Field

    Value

    Name

    Technician Ladder Rates

    Rate Type

    Salary

    Frequency

    Monthly

    Annualization Factor

    12

    Currency

    EUR


  18. In the Step Rate Values region, enter rates for the four steps in each grade by completing the fields as shown in this table.

    Grade Name

    Step Name

    Value

    Technicians 03

    Step 1

    1,750.73

    Technicians 03

    Step 2

    1,878.90

    Technicians 03

    Step 3

    2,009.79

    Technicians 03

    Step 4

    2,143.92

    Technicians 04

    Step 1

    2,238.57

    Technicians 04

    Step 2

    2,408.39

    Technicians 04

    Step 3

    2,577.68

    Technicians 04

    Step 4

    2,744.81

    Technicians 05

    Step 1

    2,831.87

    Technicians 05

    Step 2

    3,047.14

    Technicians 05

    Step 3

    3,257.52

    Technicians 05

    Step 4

    3,469.00

    Technicians 06

    Step 1

    3,586.36

    Technicians 06

    Step 2

    3,851.38

    Technicians 06

    Step 3

    4,122.34

    Technicians 06

    Step 4

    2,143.92


  19. Click Next.
  20. On the Create Grade Ladder: Review page, review the grade ladder hierarchy and the rates, and click Submit.
  21. In the Warning dialog, click Yes.
  22. In the Confirmation dialog, click OK.

Setting Up Grade Ladders for Spine Point Requirements: Example

This example illustrates how you can use grades, rates, and a grade ladder to represent spine points.

Scenario

Some organizations, such as in the public sector in the United Kingdom (UK), use spine points to structure their grades. Each point corresponds to one or more steps within a grade, as grades often overlap each other.

Grade Structure

You can use grade ladders to meet the requirements of a grade structure with spine points. This example shows a grade structure with spine points that is similar to one for teachers, lecturers, and other university workers in the UK.

The following figure illustrates an example of a grade structure with spine points.

A table that shows spine points and
the grades and salaries associated with each point

Analysis

To set up grades for the spine point structure, you must:

Resulting Grades, Rates, and Grade Ladder

To create the grades needed for the grade structure with spine points, you must create three grades with steps. You can name the steps using the spine point numbers. The following table lists the grades and steps needed to meet the requirements of the grade structure with spine points.


Grade Name

Steps

Ceiling Step

Grade 1

  • Spine Point 1

  • Spine Point 2

  • Spine Point 3

  • Spine Point 4

  • Spine Point 5

  • Spine Point 6

Spine Point 4

Grade 2

  • Spine Point 6

  • Spine Point 7

  • Spine Point 8

  • Spine Point 9

  • Spine Point 10

  • Spine Point 11

  • Spine Point 12

Spine Point 11

Grade 3

  • Spine Point 12

  • Spine Point 13

  • Spine Point 14

  • Spine Point 15

  • Spine Point 16

  • Spine Point 17

Spine Point 17

To create the grade ladder for the grade structure with spine points, you must create a ladder using grades with steps. When you create the rates, use annual salary amounts. The following table lists the grades, steps, and rates to add to the ladder.


Grade

Steps

Rates

Grade 1

  • Spine Point 1

  • Spine Point 2

  • Spine Point 3

  • Spine Point 4

  • Spine Point 5

  • Spine Point 6

  • 25, 674

  • 26, 631

  • 27, 068

  • 27, 796

  • 30, 394

  • 31, 778

Grade 2

  • Spine Point 6

  • Spine Point 7

  • Spine Point 8

  • Spine Point 9

  • Spine Point 10

  • Spine Point 11

  • Spine Point 12

  • 31, 778

  • 32, 648

  • 33, 542

  • 34, 466

  • 35, 425

  • 38, 441

  • 39, 510

Grade 3

  • Spine Point 12

  • Spine Point 13

  • Spine Point 14

  • Spine Point 15

  • Spine Point 16

  • Spine Point 17

  • 39, 510

  • 40, 634

  • 41, 746

  • 42, 914

  • 44, 118

  • 45, 358

FAQs for Define Grades

Can I edit the legislative data group for a grade rate?

No. If you need to change the legislative data group for a grade rate, then you must change the grade rate to inactive, and create a new grade rate with the correct legislative data group.

How can I add rates to grade steps?

You add rates for a grade with steps when you add the grade to a grade ladder.

Define Workforce Structures: Define Jobs and Positions

Jobs: Example

Jobs are typically used without positions by service industries where flexibility and organizational change are key features.

Software Industry

For example, XYZ Corporation has a director over the departments for developers, quality assurance, and technical writers. Recently, three developers have left the company. The director decides to redirect the head count to other areas. Instead of hiring all three back into development, one person is hired to each department, quality assurance, and technical writing.

In software industries, the organization is fluid. Using jobs gives an enterprise the flexibility to determine where to use head count, because the job only exists through the person performing it. In this example, when the three developers leave XYZ Corporation, their jobs no longer exist, therefore the corporation has the flexibility to move the headcount to other areas.

This figure illustrates the software industry job setup.

Jobs setup example

Positions: Examples

Positions are typically used by industries that use detailed approval rules, which perform detailed budgeting and maintain head counts, or have high turnover rates.

Retail Industry

ABC Corporation has high turnover. It loses approximately 5% of their cashiers monthly. The job of cashier includes three positions: front line cashier, service desk cashier, and layaway cashier. Each job is cross trained to take over another cashier position. When one cashier leaves from any of the positions, another existing cashier from the front line, service desk or layaway can assist where needed. . But to ensure short lines and customer satisfaction, ABC must replace each cashier lost to turnover.

Since turnover is high in retail it is better for this industry to use positions. There is an automatic vacancy when an employee terminates employment. The position exists even when there are no holders. This is important if the person who leaves the company is a manager or supervisor with direct reports. All direct reports continue reporting to the position even if it is empty. You do not need to reassign these employees to another manager or supervisor; the replacement manager is assigned to the existing position.

Also, an advantage to using positions is that when you hire somebody new many of the attributes are defaulted in from the position. This speeds up the hiring process.

This figure illustrates the retail position setup.

Position example set up for retail
industry

Health Care Industry

The hospital has a structured head count and detailed budgeting. For example, a specific number of surgeons, nurses, and interns of various types are needed. These positions need to be filled in order for the hospital to run smoothly. Use jobs and positions if you need to apply detailed head count rules.

Health care is an industry that needs to regulate employment, roles, and compensation according to strict policies and procedures. Fixed roles tend to endure over time, surviving multiple incumbents. Industries that manage roles rather than individuals, where roles continue to exist after individuals leave, typically model the workforce using positions.

This figure illustrates the hospital position setup.

Position example set up for a health
care industry

Job and Position Lookups: Explained

This topic identifies common lookups that are job and position-related and for which you can create new lookup values. Review these lookups, and update them as appropriate to suit enterprise requirements.

Job Lookups

Job lookups are described in the following table.


Lookup Type

Description

JOB_FUNCTION_CODE

Description of the primary function of a job. Used for grouping and reporting jobs of like functions.

MANAGER_LEVEL

Description of the seniority of a manager.

EVAL_SYSTEM

Identifies the evaluation system used for the job or position.

EVAL_SYSTEM_MEAS

Measurement unit for the evaluation criteria.

Position Lookups

Position lookups are described in the following table.


Lookup Type

Description

SECURITY_CLEARANCE

Classifies if security clearance is needed.

EVAL_SYSTEM

Identifies the evaluation system used for the job or position.

EVAL_SYSTEM_MEAS

Measurement unit for the evaluation criteria.

BARGAINING_UNIT_CODE

Identifies a legally organized group of people which have the right to negotiate on all aspects of terms and conditions with employers or employer federations.

PROBATION_PERIOD

Specifies the unit of measurement for the probation period of a position. For example, 365 "Day", 52 "Week", 12 "Month", or 1 "Year".

Define Workforce Structures: Define Worker Directory

Search Relevance Profile Options: Explained

The strength of the relationship between the person performing a gallery search and each person whose assignment appears in the search results can determine the order of the results: the stronger the relationship, the closer to the top of the results an assignment appears. The search relevance profile options control how the strength of the relationship between the searcher and the search result is calculated.

Weighting Profile Options

Using the following profile options, you can change the weighting applied to the relevant factors.


Profile Option

Description

HR: Organization Hierarchy Weight

Specifies the weighting applied to the relationship strength value for the organization hierarchy proximity factor.

HR: Position Hierarchy Weight

Specifies the weighting applied to the relationship strength value for the position hierarchy proximity factor.

HR: Manager Hierarchy Weight

Specifies the weighting applied to the relationship strength value for the manager hierarchy proximity factor.

HR: Location Proximity Weight

Specifies the weighting applied to the relationship strength value for the location proximity factor.

HR: Selection History Weight

Specifies the weighting applied to the relationship strength value for the selection history factor.

HR: Social Network Weight

Specifies the weighting applied to the relationship strength value for the social network factor.

The default value of each weighting profile option is 0.5. To increase the relevance of a factor relative to other factors, you increase its weighting; to decrease its relevance, you reduce its weighting.

HR: Selection History Timeout

The number of times the searcher selects a person's assignment from the search results during a specified period, which is 7 days by default, is recorded automatically. You can specify this period for the enterprise on the HR: Selection History Timeout profile option.

HR: Maximum Hierarchy Proximity

When the searcher's primary assignment is in the same organization, position, or manager hierarchy as a person's assignment, the strength of the relationship depends on their proximity to each other in the hierarchy. The maximum number of hierarchy boundaries to include in the calculation is 4 by default. You can set this value for the enterprise on the HR: Maximum Hierarchy Proximity profile option.

HR: Relationship Priority Factor

The searcher can specify a rating for a search result, and each rating is associated with a multiplying factor. On this profile option, you can specify the highest possible multiplying factor that can be applied to a search result. By default, the multiplying factor is 2. If you increase its value, you increase the significance of the searcher's own ratings relative to other factors.