Skip Headers

Contents

5 Common Applications Configuration: Define Enterprise Structures for Customer Data Management

This chapter contains the following:

Enterprise Structures: Overview

Enterprise Structures Business Process Model: Explained

Global Enterprise Configuration: Points to Consider

Modeling Your Enterprise Management Structure in Oracle Fusion: Example

Define Initial Configuration with the Enterprise Structures Configurator

Define Reference Data Sharing

Define Enterprise: Manage Enterprise HCM Information

Define Enterprise: Manage Locations

Define Geographies

Define Legal Entities for Customer Data Management: Manage Legal Entity

Define Legal Entities for Customer Data Management: Manage Legal Entity HCM Information

Define Business Units for Customer Data Management: Manage Service Provider Relationships

Define Business Units for Customer Data Management: Specify Customer Contract Management Business Function Properties

Define Business Units for Customer Data Management: Specify Supplier Contract Management Business Function Properties

Define Business Units for Customer Data Management: Assign Business Unit Business Function

Define Business Units for Customer Data Management: Manage Business Units

Define Workforce Structures for CRM: Manage Locations

Define Workforce Structures for CRM: Manage Divisions

Define Workforce Structures for CRM: Manage Departments

Define Workforce Structures for CRM: FAQs for Manage Job Families

Define Workforce Structures for CRM: Manage Job

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:

Industry
Business unit requirements for autonomy
Business and accounting policies
Business functions performed by business units and optionally, centralized in shared service centers
Locations of facilities

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:

Account for themselves to the public through statutory and external reporting
Comply with legislation and regulations
Pay income and transaction taxes
Process value added tax (VAT) collection on behalf of the taxing authority

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.

Enterprise Structures Business Process Model: Explained

In Oracle Fusion Applications, the Enterprise Performance and Planning Business Process Model illustrates the major implementation tasks that you perform to create your enterprise structures. This process model includes the Set Up Enterprise Structures business process, which consist of implementation activities that span many product families. Information Technology is a second Business Process Model which contains the Set Up Information Technology Management business process. Define Reference Data Sharing is one of the activities in this business process and is important in the implementation of the enterprise structures. This activity creates the mechanism to share reference data sets across multiple ledgers, business units, and warehouses, reducing the administrative burden and decreasing the time needed to implement.

The following figure and chart describes the Business Process Model structures and activities.

This diagram lists the
BPM activities: Define Enterprise, Define Enterprise Structures, Define
Legal Jurisdictions and Authorities, Define Legal Entity, Define Business
Units, Define Financial Reporting Structures, Define Chart of Accounts,
Define Ledgers, Define Accounting Configurations, Define Facilitates,
and Define Reference Data Sharing.

BPM Activities	Description
Define Enterprise	Define the enterprise to capture the name of the deploying enterprise and the location of the headquarters. There is normally a single enterprise organization in a production environment. Multiple enterprises are defined when the system is used to administer multiple customer companies, or when you choose to set up additional enterprises for testing or development.
Define Enterprise Structures	Define enterprise structures to represent an organization with one or more legal entities under common control. Define internal and external organizations to represent each area of business within the enterprise.
Define Legal Jurisdictions and Authorities	Define information for governing bodies that operate within a jurisdiction.
Define Legal Entities	Define legal entities and legal reporting units for business activities handled by the Oracle Fusion Applications.
Define Business Units	Define business units of an enterprise to allow for flexible implementation, to provide a consistent entity for controlling and reporting on transactions, and to be an anchor for the sharing of sets of reference data across applications.
Define Financial Reporting Structures	Define financial reporting structures, including organization structures, charts of accounts, organizational hierarchies, calendars, currencies and rates, ledgers, and document sequences which are used in organizing the financial data of a company.
Define Chart of Accounts	Define chart of accounts including hierarchies and values to enable tracking of financial transactions and reporting at legal entity, cost center, account, and other segment levels.
Define Ledgers	Define the primary accounting ledger and any secondary ledgers that provide an alternative accounting representation of the financial data.
Define Accounting Configurations	Define the accounting configuration that serves as a framework for how financial records are maintained for an organization.
Define Facilities	Define inventory, item, and cost organizations. Inventory organizations represent facilities that manufacture or store items. The item master organization holds a single definition of items that can be shared across many inventory organizations. Cost organizations group inventory organizations within a legal entity to establish the cost accounting policies.
Define Reference Data Sharing	Define how reference data in the applications is partitioned and shared.

Note

There are product specific implementation activities that are not listed here and depend on the applications you are implementing. For example, you can implement Define Enterprise Structures for Human Capital Management, Project Management, and Sales Management.

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
Business Unit Management
Security Structure
Compliance Requirements

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.

Your company is required to report using US Generally Accepted Accounting Principles (GAAP) standards and UK Statements of Standard Accounting Practice and Financial Reporting Standards. How many ledgers do you need to achieve proper statutory reporting?
Your managers need reports that show profit and loss (revenue and expenses) for their lines of business. Do you use business units and balancing segments to represent your divisions and businesses? Do you secure data by two segments in your chart of accounts which represents each department and legal entity or one segment that represents both to produce useful, but confidential management reports?
Your corporate management requires reports showing total organizational performance with drill down capability to the supporting details. Do you need multiple balancing segment hierarchies to achieve proper rollup of balances for reporting requirements?
Your company has all administrative, account payables, procurement, and human resources functions performed at their corporate headquarters. Do you need one or more business unit in which to perform all these functions? How will your shared service center be configured?

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:

Creation of three separate ledgers representing your separate legal entities:
- InFusion America Inc.
- InFusion Financial Services Inc.
- InFusion UK Services Ltd.
Consolidation of results for system components, installations, and maintenance product lines across the enterprise
All UK general and administrative costs processed at the UK headquarters
US Systems' general and administrative costs processed at US Corporate headquarters
US Financial Services maintains its own payables and receivables departments

InFusion Corporation is the enterprise
and has two divisions, 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, Ltd. 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.

The enterprise is mandatory because it serves as an umbrella for the entire implementation. All organizations are created within an enterprise.
Legal entities are also mandatory. They can be optionally mapped to balancing segment values or represented by ledgers. Mapping balancing segment values to legal entities is mandatory if you plan to use the intercompany functionality.
At least one ledger is mandatory in an implementation in which you record your accounting transactions.
Business units are also mandatory because financial transactions are processed in business units.
A shared service center is optional, but if used, must be a business unit.
Divisions are optional and can be represented with a hierarchy of cost centers or by a second balancing segment value.
Departments are mandatory because they track your employees.
Optionally, add an item master organization and inventory organizations if you are tracking your inventory transactions in Oracle Fusion Applications.

Note

Some Oracle Fusion Human Capital Management and Customer Relationship Management 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.

Define Initial Configuration with the Enterprise Structures Configurator

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 for your offerings on the Configure Offerings page in the Setup and Maintenance work area. 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

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

Finally, 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:

Legislative data groups (the application creates one legislative data group for each country that is identified in the configuration.)
Name of the legislative data group that will be assigned to the payroll statutory unit that is generated for each legal entity.
Organization hierarchy.

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.

Note

If your PDF viewer preferences are set to open PDFs in a browser window, the Technical Summary report replaces the Oracle Fusion application. Use your browser's Back button to return to the application.

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.

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.

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, expenses and income, pay transaction taxes, or perform intercompany trading.

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

Facilitating local compliance
Taking advantage of lower corporation taxation in some jurisdictions
Preparing for acquisitions or disposals of parts of the enterprise
Isolating one area of the business from risks in another area. For example, your enterprise develops property and also leases properties. You could operate the property development business as a separate legal entity to limit risk to your leasing business.

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:

InFusion Lighting Japan LE
InFusion Lighting US LE
InFusion Security UK LE
InFusion Security India LE

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
Legal entity and its relationship to business units
Legal entity and its relationship to divisions
Legal entity and its relationship to ledgers
Legal entity and its relationship to balancing segments
Legal entity and its relationship to consolidation rules
Legal entity and its relationship to intercompany transactions
Legal entity and its relationship to worker assignments and legal employer
Legal entity and payroll reporting
Legal reporting units

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:

Identify the legal entities within the ledger.
Balance transactions that cross legal entity boundaries through intercompany transactions.
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.

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:

Allows for flexible implementation
Provides a consistent entity for controlling and reporting on transactions
Anchors the sharing of sets of reference data across applications

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:

Management reporting
Processing of transactions
Security of transactional data
Reference data definition and sharing

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 based 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 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:

Country
Country and Division
Country and business function
Division
Division and legal entity
Division and business function
Business function
Legal entity
Business function and legal entity

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

If you use Oracle Fusion Financials, the legal entity option is recommended because of the manner in which financial transactions are processed.
The business unit level that you select determines how the application automatically creates reference data sets.

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.

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:

Assignment to one set only, no common values allowed. The simplest form of sharing reference data that allows assigning a reference data object instance to one and only one set. For example, Asset Prorate Conventions are defined and assigned to only one reference data set. This set can be shared across multiple asset books, but all the values are contained only in this one set.
Assignment to one set only, with common values. The most commonly used method of sharing reference data that allows defining reference data object instance across all sets. For example, Receivables Transaction Types are assigned to a common set that is available to all the business units without the need to be explicitly assigned the transaction types to each business unit. In addition, you can assign a business unit specific set of transaction types. At transaction entry, the list of values for transaction types includes transaction types from the set assigned to the business unit, as well as transaction types assigned to the common set that is shared across all business units.
Assignment to multiple sets, no common values allowed. The method of sharing reference data that allows a reference data object instance to be assigned to multiple sets. For instance, Payables Payment Terms use this method. It means that each payment term can be assigned to one or more than one set. For example, you assign the payment term Net 30 to several sets, but the payment term Net 15 is assigned to only your corporate business unit specific set. At transaction entry, the list of values for payment terms consists of only one set of data; the set that is assigned to the transaction's business unit.

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:

Sales_Japan
Marketing_Japan
Sales_US
Sales_UK
Marketing_India
Sales_India

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:

Sales_Japan_Set
Mktg_Japan_Set
Sales_US_Set
Sales_UK_Set
Mktg_India_Set
Sales_India_Set
Grades_Set

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

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.

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:

The primary industry of your enterprise
How you manage your people

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

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

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.

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.

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'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.

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.

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.

Reference Data Sets: Explained

Reference data sets are logical groups of reference data that can be accessed by various transactional entities depending on the business context. Oracle Fusion Applications contains a common reference data set as well as an enterprise set that may be used as a default set. Depending on your business requirement you can create and maintain additional reference data sets, while continuing to use the common reference data set.

Consider the following scenario.

Partitioning

The partitioning of reference data and creation of data sets enable you to create reference entities across tables or lookup types, and share modular information and data processing options among business units. With the help of partitioning, you can choose to create separate sets and subsets for each business unit depending upon its business requirement, or create common sets or subsets to enable sharing reference data between several business units, without the need for duplicating the reference data. Partitioning provides you the flexibility to handle the reference data in a way appropriate to your business needs.

The following figure illustrates the reference data sharing method (assignment to one set only, with common values) where the user can access the data assigned to a specific set in a particular business unit, as well as access the data assigned to the common set.

Difference between a common set and
a specific set

Reference Data Sets and Sharing Methods: Explained

Reference Data Sets

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:

Assignment to one set only, no common values allowed. The simplest form of sharing reference data that allows assigning a reference data object instance to one and only one set. For example, Asset Prorate Conventions are defined and assigned to only one reference data set. This set can be shared across multiple asset books, but all the values are contained only in this one set.
Assignment to one set only, with common values. The most commonly used method of sharing reference data that allows defining reference data object instance across all sets. For example, Receivables Transaction Types are assigned to a common set that is available to all the business units without the need to be explicitly assigned the transaction types to each business unit. In addition, you can assign a business unit specific set of transaction types. At transaction entry, the list of values for transaction types includes transaction types from the set assigned to the business unit, as well as transaction types assigned to the common set that is shared across all business units.
Assignment to multiple sets, no common values allowed. The method of sharing reference data that allows a reference data object instance to be assigned to multiple sets. For instance, Payables Payment Terms use this method. It means that each payment term can be assigned to one or more than one set. For example, you assign the payment term Net 30 to several sets, but the payment term Net 15 is assigned to only your corporate business unit specific set. At transaction entry, the list of values for payment terms consists of only one set of data; the set that is assigned to the transaction's business unit.

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

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 Enterprise: Manage Enterprise HCM Information

Enterprise: Explained

An enterprise consists of legal entities under common control and management.

Enterprise Defined

When implementing Oracle Fusion Applications you operate within the context of an enterprise that has already been created in the application for you. This is either a predefined enterprise or an enterprise that has been created in the application by a system administrator.

An enterprise organization captures the name of the deploying enterprise and the location of the headquarters. There is normally a single enterprise organization in a production environment. Multiple enterprises are defined when the system is used to administer multiple customer companies, for example, multiple tenants, or when a customer chooses to set up additional enterprises for testing or development.

Oracle Fusion Applications offers capabilities for multiple tenants to share the same applications instance for some human resources processes. If you offer business process outsourcing services to a set of clients, each of those clients may be represented as an enterprise within an Oracle Fusion Application instance. To support this functionality, system owned reference data such as sequences, sets, and flexfields are also defined within an enterprise.

In Oracle Fusion Applications, an organization classified as an enterprise is defined before defining any other organizations in the HCM Common Organization Model. All other organizations are defined as belonging to an enterprise.

Managing Enterprise Information for Non-Oracle Fusion HCM Users: Explained

The Manage Enterprise HCM Information task includes default settings for your enterprise such as the employment model, worker number generation, and so on. If you are not implementing Oracle Fusion Human Capital Management (HCM), then the only action you may need to perform using this task is to change the enterprise name, if necessary. The other settings are HCM-specific and are not relevant outside of Oracle Fusion HCM.

Define Enterprise: Manage Locations

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

Creating Multiple Locations Simultaneously

If you have a list of locations 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 location information to the spreadsheet, and then upload directly to your enterprise configuration. You can upload the spreadsheet multiple times to accommodate revisions.

FAQs for Manage Locations

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.

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 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 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.

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.

Define Geographies

Geography Hierarchy: Explained

Geography hierarchy is a data model that lets you establish conceptual parent-child relationships between geographies. A geography, such as Tokyo or Peru, describes a boundary on the surface of the earth. The application can extrapolate information based on this network of hierarchical geographical relationships.

For example, in the geography hierarchy the state of California is defined as the parent of San Mateo county, which is the parent of Redwood City, which is the parent of the postal code 94065. If you enter just 94065, the application can determine that the postal code is in California, or that the corresponding city is Redwood City.

The application leverages geography hierarchy information to facilitate business processes that rely on geography information, for example, tax calculation, order sourcing rules, sales territory definition. The geography hierarchy information is centrally located in the Trading Community Model and shared among other application offerings.

The top level of the geography hierarchy is Country, so the hierarchy essentially contains countries and their child geographies. Other aspects of the geography hierarchy include:

Geography
Geography type
Geography usage
Master reference geography hierarchy
User defined zones

Geography

A geography is a boundary such as a country, state, province or city. It is a physical space with boundaries that is a defined instance of a geography type. For example, San Jose is a geography of the City geography type.

Geography Type

Geography types are a divisional grouping of geographies, which can be either geopolitical (for example, City, Province, and District) or user defined (for example, Continent, Country Regions, Tax Regions).

Geography Usage

Geography usage indicates how a geography type or geography is used in the application. A master reference geography always has the usage of Master Reference. User defined zones can have the usages of Tax, Shipping, or Territory, based on what is relevant for their purpose.

Master Reference Geography Hierarchy

The geography hierarchy data is considered to be the single source of truth for geographies. It is all the data, including geography types and geographies, that you define and maintain in the Trading Community Model tables.

The geography usage for the entire hierarchy is the master reference, and defined geography types and geographies are considered as master reference geography types and geographies. For example, Country is a universally recognized geography type, and United States is considered a master geography.

User Defined Zones

User defined zones are a collection of geographical data, created from master reference data for a specific purpose. For example, territory zones are collections of master reference geographies ordered in a hierarchy. Tax and shipping zones are collections of master reference geographies without a hierarchical grouping.

Importing Geographies: Explained

A geography, such as Tokyo or Peru, describes a boundary on the surface of the earth. You can create new geographies by importing data through interface tables. There are two options for populating the interface tables: using the tool of your preference to load the data or using file-based data import. If you plan to provide the data details in a source file, use the file-based import feature. If you will populate the interface table directly, run the geography loader process to import the data. Having a good understanding of the import entity, interface table, and destination table will help you prepare your import data.

Consider the following when importing geographies:

File-based import option
Geography loader process option
Import object entity, interface table, and destination tables

File-Based Import Option

The file-based import process reads the data included in your XML or text file, populates the interface tables, and imports the data into the application destination tables. The File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the geography import object, create source file mappings, and schedule the import activities.

Geography Loader Process Option

Populate the interface table with your import data, then navigate to the Run Geography Loader Setup and Maintenance task to schedule the import of data from the interface table to the destination table.

Import Object Entity, Interface Table, and Destination Tables

The geography import object consists of one entity and interface table that forms the geography. If you are using file-based import, you can map your source file data to import entity attributes that correspond to the interface table columns. The import activity process populates the interface table based on the mapping and your source file. If using the geography loader scheduled process, populate the interface table directly using your preferred tool. If you need the unique IDs of existing application data for your import data, use the Define Data Export Setup and Maintenance task list to export the information.

Note

Spreadsheets containing detailed information about each interface table, including the import attributes, corresponding interface table columns, defaults, and validations, are available from the Oracle Enterprise Repository by searching on a specific interface table name or initiating a search using the FusionApps: Interface Table asset type.

The following lists the object entity, tables, and resulting application object:

File-Based Import Entities	Interface Tables	Destination Tables	Application Object
ImpGeography	HZ_IMP_GEOGRAPHIES_T	HZ_GEOGRAPHIES HZ_GEOGRAPHY_IDENTIFIERS HZ_GEOGRAPHY_TYPES_B HZ_HIERARCHY_NODES	Geography

File-Based Import Entities

Interface Tables

Destination Tables

Application Object

ImpGeography

HZ_IMP_GEOGRAPHIES_T

HZ_GEOGRAPHIES

HZ_GEOGRAPHY_IDENTIFIERS

HZ_GEOGRAPHY_TYPES_B

HZ_HIERARCHY_NODES

Geography

Define Geographies: Manage Geographies

Defining Address Cleansing: Explained

Address cleansing provides a way to validate, correct, and standardize addresses that are entered in a user interface. Geography validation only validates the geography attributes of an address, for example, State, City, and Postal codes; address cleansing validates both the geography attributes and the address line attributes.

Address cleansing can only be used through the Oracle Fusion Trading Community Data Quality product, because the feature is delivered using Data Quality integration. You need to ensure that you have a license for the countries that will use Trading Community Data Quality data cleansing.

You can specify the real time address cleansing level for each country by choosing either None, meaning that there is no real time address cleansing, or by choosing Optional, meaning that you will have the choice to cleanse addresses. Once you have enabled address cleansing for a country a Verify Address icon appears at address entry points in the application. You can then click the icon to perform address cleansing and receive a corrected, standardized address. If Trading Community Data Quality does not find a matching address the application will alert you.

Geography Structure, Hierarchy, and Validation: How They Fit Together

There are three components that are dependent on each other when defining a country: geography structure, geography hierarchy, and geography validation. Every country has to have the geography structure defined first before the hierarchy can be defined, and the geography hierarchy has to be defined before the validation can be defined.

Geography Structure

Firstly, you need to create a geography structure for each country to define which geography types are part of the country structure, and how the geography types are hierarchically related within the country structure. For example, you can create geography types called State, City, and Postal Code. Then you can rank the State geography type as the highest level within the country, the City as the second level, and the Postal Code as the lowest level within the country structure. Geography structure can be defined using the Manage Geographies task, or can be imported using tasks in the Define Geographies activity.

Geography Hierarchy

Once the geography structure is defined, the geographies for each geography type can be added to the hierarchy. For example, below the United States you can create a geography called California using a State geography type.

As part of managing the geography hierarchy you can view, create, edit, and delete the geographies for each geography type in the country structure. You can also add a primary and alternate name and code for each geography. A geography hierarchy can be created using the Manage Geographies task, or can be imported using tasks in the Define Geographies activity.

Geography Validation

After defining the geography hierarchy, you need to specify the geography validations for the country. You can choose which address style formats you would like to use for the country, and for each selected address style format you can map geography types to address attributes. You can also select which geography types should be included in geography or tax validation, and which geography types will display in a list of values during address entry in other user interfaces. The geography validation level for the country, such as error or warning, can also be selected.

Geography Structures: Explained

A geography structure is a hierarchical grouping of geography types for a country. For example, the geography structure for the United States is the geography type of State at the top, then followed by the County, then the City, and finally the Postal Code.

You can use the geography structure to establish:

How geographies can be related
The types of geographies you can define for the country

How Geographies Can Be Related

You can determine how a country's geographies are hierarchically related by creating the hierarchy of the geography types in the geography structure. When you define a country's structure the country geography type is implicitly at the top of the geography structure, and the numbering of the subsequent levels start with 1 as the next geography level after country.

You must add a geography type as a level in the country structure before you can define a geography for that geography type in a country. For example, before defining the state of California, the State geography type must be added to the United States country structure. Only one geography type can be used for each level, you cannot define more than one geography type at the same level.

Note

After you first define a country structure you can only add geography types below the current lowest level, and delete geography types without defined geographies.

To simplify the creation of a country structure you can copy a structure from another country, and then amend the geography type hierarchy for the country.

The Types of Geographies You Can Define for the Country

The application provides you with a set of available master reference geography types. If required, you can create a geography type before adding it to the country structure. Each geography type is added below the current lowest level.

Note

If you want to delete a geography type that is not at the lowest level in the country structure, then you have to delete the geography type level and all the levels below it.

A geography type that you create within the country structure can be used for other country structures as well.

Geography Validation: Explained

Geography validation determines the geography mapping and validation for a country's address styles, as well as the overall geography validation control for a country.

The No Styles Format address style format is the default address style format for a country. By defining the mapping and validation for this format you will ensure that validations can be performed for any address in the country. After the No Styles Format is defined you can set up additional mapping for specific address styles.

For each address style format, you can define the following:

Map to attribute
Enable list of values
Tax validation
Geography validation
Geography validation control

Map to Attribute

For every address style format, you can map each geography type to an address attribute. For example, you can map the State geography type to the State address attribute for the United States, or map the State geography type to the County address attribute for the United Kingdom. The geography types that appear are based on how the country structure is defined. The list of address attributes that appear are based on address formats delivered with the application, or your customer defined address formats.

Note

You only need to map geography types that you want to use for geography or tax validation purposes.

Enable List of Values

Once a geography type is mapped to an attribute, then you can specify whether the geography type will appear in a list of values during address entry in user interfaces. It is very important to review carefully if you want to enable a list of values. You should only enable a list of values if you have sufficient geography data imported or created for that geography. Once you have enabled a list of values for an address attribute, you can only select the geography data available for the geography type. This means that if a specific geography value is not available in the geography hierarchy, you cannot create an address with a different geography value.

Tax Validation

You can also specify whether a geography type will be included in tax validation. For example, for the United States North America address style format you specify that County, State, and City are used for tax validation. This will mean that when a transaction involves an address with the North America address style, the address must have the correct county, state, and city combination based on the geography hierarchy data, to be considered valid for tax calculation.

Geography Validation

You can specify whether a geography type will be included in geography validation. This will mean that, for example, when the user enters a United States address using the North America address style format, the address must have the correct country, state, and postal code combination based on geography hierarchy data to be considered geographically valid.

If an address element is mapped to a geography type, but not selected for geography validation usage, then during address entry suggested values will be provided for the address element, but the address element will not be validated.

Note

For either the tax or geography validation, do not skip more than one consecutive level unless you are certain that the selected geography types can uniquely identify geographies. For example, the United States country structure is: State, County, City, and Postal Code, and you want to select just State and Postal Code for geography or tax validation. However, for the combination of California and 94065, the city can be either Redwood Shores or Redwood City. In this case, you should also select at least the City geography type for geography or tax validation.

Geography Validation Control

You can select the geography validation level for a country. Validation will check if the entered address maps to the geography hierarchy data available for the country, and the geography validation control determines whether you can save an address that did not pass validation during address entry. For example, if the validation level is Error, then an address cannot be saved if the values do not match the geography hierarchy data.

These are the geography validation levels you can choose:

Error - only completely valid addresses can be saved, with all mandatory address elements entered.
No Validation - all addresses can be saved including incomplete and invalid addresses.

Regardless of the result of validation, the validation process will try to map any address attribute to a geography of the country, and store any mapping it could establish based on the available data. This is called Geography Name Referencing and it is executed as part of validation. The result of this referencing is used in several business processes in the application to map an address to a specific geography or zone.

Managing Geography Structures, Hierarchies, and Validation: Worked Example

This example shows how to start the configuration of the geography structure, hierarchy, and validation for the country geography of the United Kingdom.

The following table summarizes the key decisions for this scenario.

Decisions to Consider	In This Example
Copy an existing country structure?	No, create a new country structure.
What is the structure of the geography types?	Create geography types with the following ranking structure: County Post Town
What is the geography hierarchy?	Create the following hierarchy: Country of United Kingdom County of Berkshire Post Town of Reading
Which address style format will you use when mapping geography validations?	The default address style format, called the No Styles Format.
Are you using Oracle Fusion Tax for tax purposes?	No, do not select Tax Validation for the geography types.

Add the County and Post Town geography types to the geography structure. Then add the geographies for the County and Post Town geography types to define the geography hierarchy. Finally, specify the geography validations for the geography types you have added to the geography structure.

Defining the geography structure

You add the County and Post Town geography types to the United Kingdom geography structure.

On the Manage Geographies page, enter GB in the Code field. Click Search.
On the Manage Geographies page, click Structure Defined.
On the Manage Geography Structure page, click the Create button next to the Copy Country Structure From field.
In the Geography Structure section, select the County list item in the Add Geography Type field.
Click Add.
Select the Post Town list item in the Add Geography Type field.
Click Add.

Defining the geography hierarchy

You want to begin to create the geography hierarchy for the United Kingdom, so you add the geographies for the County and Post Town geography types using the geography hierarchy User Interfaces. You can also use the Manage File Import Activities task to import geography hierarchies using a csv or xml file.

On the Manage Geographies page, enter GB in the Code field. Click Search.
On the Manage Geographies page, click Hierarchy Defined.
On the Manage Geography Hierarchy page, Geography Hierarchy section, click the United Kingdom to highlight the table row.
Click the Create button.
In the Create County page, Primary and Alternate Names section, enter Berkshire in the Name field.
Click Save and Close.
On the Manage Geography Hierarchy page, Geography Hierarchy section, click Berkshire to highlight the table row.
Click the Create button.
In the Create Post Town page, Primary and Alternate Names section, enter Reading in the Name field.
Click Save and Close.

Defining the geography validations

Now you want to specify the geography validations for the geography types you have added to the United Kingdom. You define the geography mapping and validation for the United Kingdom default address style format. You map the geography types to attributes, enable the geography types for Lists of Values and Geography validation, and set the geography validation level.

On the Manage Geographies page, click Validation Defined.
On the Manage Geography Validation page, Address Style section, click No Styles Format to highlight the table row.
For the County geography type, click the County list item in the Map to Attribute field.
Click the Enable List of Values option for the County geography type.
Click the Geography Validation option for the County geography type.
For the Post Town geography type, click the City list item in the Map to Attribute field.
Click the Geography Validation option for the Post Town geography type.
In the Geography Validation Control section, click the Error list item in the Geography Validation Level for Country field.
Click Save and Close.

FAQs for Manage Geographies

When do I define address cleansing?

When address data entered into the application needs to conform to a particular format, in order to achieve consistency in the representation of addresses. For example, making sure that the incoming data is stored following the correct postal address format.

Why can't I update a geography structure by copying an existing country structure?

You can only update a geography structure by adding existing geography types, or by creating new geography types and then adding them to the geography structure. You can only copy an existing country structure when you are defining a new country structure.

Why can't I delete a level of the country geography structure?

If a geography exists for a country geography structure level then you cannot delete the level. For example, if a state geography has been created for the United States country geography structure, then the State level cannot be deleted in the country geography structure.

Can I add any geography to the geography hierarchy?

Yes. However, the geography type for the geography that you want to add must be already added to the country geography structure.

Can I edit a specific geography in the geography hierarchy?

Yes. In the Manage Geography Hierarchy page you can edit details such as the geography's date range, primary and alternate names and codes, and parent geographies.

How can I add a geography that is the level below another geography in a geography hierarchy?

Select the geography that you want your geography to be created below, and then click the Create icon. This will allow you to create a geography for a geography type that is the level below the geography type you selected. The structure of the country's geography types are defined in the Manage Geography Structure page.

Define Geographies: Define File-Based Data Import

Files, Import Objects, Mapping, and Import Activity Components: How They Work Together

File-based import supports the import of data from an external text or xml file to interface tables and then from interface tables to target application tables.

Overview of File-Based Data Import

File-based import includes the following:

Source files with import data
Import objects with available import attributes
Mappings between source files and interface table columns
Import Activities to define import options, a processing schedule, and monitor progress

Source Files

External data can be obtained in various ways and formatted in a text or xml file. The source file data is mapped to interface table columns using a Mapping. The source file is identified on an Import Activity, along with other import processing details. The file processing component of the file-based data import consists of reading the source file, parsing the data, and inserting the data into the appropriate interface tables.

Objects

Import objects are defined where interface tables exist and external files can be used to import data into the interface tables. Import Object definitions for Oracle objects that support file-based import are predefined and can be accessed with the appropriate security privilege. Individual object attributes represent the interface table columns and are used to map source file data or constant values in Mappings and Import Activity definitions. Use the Import Object definition to manage the display of attributes that can be mapped, to indicate required mappings, and to set site level default values as required.

Mappings

Import mapping enables you to predefine a mapping between the columns provided in a source file and the attributes pertaining to the objects being imported. Once you create a mapping, it can be reused in the Import Activity definition.

Manage Import Activities

An Import Activity definition provides the instructions for the import processing. It includes the source file or file location and mapping, plus import processing options and schedule. You can monitor the progress of the Import Activity processing and view completion reports for both successful records and errors.

File-Based Import Processing: How it Works

The file-based data import process includes processing the source file data and inserting it into the interface tables, moving the interface table data into the destination application tables, and then processing the attachments for the imported objects. Processing factors are subject to the settings defined for the Import Activity, Mapping, and Import Object. You can monitor the processing steps and view process reports for each Import Activity.

This topic describes the following:

Inserting Data in the Interface Tables
Interface Table Data Validation and Error Counts
Interface Table to Destination Application Table Processing
Importing Attachments
Viewing Import Results

Inserting Data in the Interface Tables

Data exists in various sources and in various formats. The file import processing starts with reading the source data, parsing the data, and inserting into the appropriate interface tables. The source of the data comes from the following:

Source file values mapped to target object attributes in the Import Activity.
Constant values defined for target object attributes in the Import Activity.
Default values defined for target object attributes in the Import Object.

Interface Table Data Validation and Error Counts

The data is initially validated against the predefined Import Mapping and the Import Object settings as the interface tables are being populated by the initial file import process. The interface table data is validated again before importing into the destination application tables.

Validation includes:
- Missing required values
- Values that exceed the attribute length
- Invalid values
- Duplicates to existing records in the destination application tables based on the combination of attributes selected for duplicate validation in the predefined Import Mapping.
  
  Note
  
  For the Lead import object, the duplicate checking is only done for existing leads created within the look back days setting of the Import Activity.
- Duplicates to existing records in the destination application tables for Customer Data Management objects based on Matching Configurations.
Errors
Most validation issues are recorded as errors, with the exception of Customer Data Management duplicates found during the Matching Configuration process. In this case, matched records are only considered as errors if:
- Customer Management Duplicates option is set to Do Not Import for the Import Activity and
- The main object of the Import Activity is a consumer, customer, or legal entity object
Allowable Error Count Threshold
The validation of the interface table occurs before any records are imported into the destination application tables. Once the validation process has completed, the count of records with errors is compared to the Allowable Error Count Threshold value specified for the Import Activity. A count above the threshold will stop the import process for all records. If the count is below the threshold, records without errors will import. In either case, records with errors will be reported in the Error and Exception files.

Interface Table to Destination Application Table Processing

The import process orchestrates the import for each of the component objects that make up the overall main objects of the Import Activity.

Importing Attachments

Once the objects have imported successfully, the attachments are processed. The import process matches the source file attachment name to the file name included in the compressed file entered on the Import Activity. The attachment file is imported into Universal Content Manager and then associated as an attachment to the imported object.

Viewing Import Results

You can monitor all file-based Import Activities that are currently scheduled to run, have completed successfully, or failed with errors. For each Import Activity, you can view the details pertaining to each underlying process. Once an Import Activity process has completed, the following processing reports are added as attachments to the process:

Log file. Includes the records that were successfully imported plus the unique destination application table identifiers for the objects.
Exception file. Includes the records that were not imported plus a reference to an error for each record that failed validation.
Error file. Includes all the errors for each record that failed validation.

File-Based Import Objects: Explained

Import objects represent the application and attribute information for business objects that can be imported using external source files.

This topic describes the following:

Import object management options
Custom objects

Import Object Management Options

A single import object can have multiple associated components that are considered objects by themselves. An object and associated objects that can be imported within the same source file are grouped together within the application module class.

Note

Each object includes the Import Activity object (MktImpJobs1). The Import Activity object is a required component of the application module but is not mapped to a source file. All values for this object are derived from the Import Activity definition. Consequently, do not update the Map, Required, and Default Value settings for the Import Activity object.

The following table includes information about the import object:

Option	Description
Attributes	A view-only listing of object attributes that represent each column in the interface table for the object.
Length	A view-only listing of widths for the columns in the interface tables. If the source file values for the attribute have more characters than the attribute length, the source file row will not be imported.
Default Value	Optionally, specify an attribute value to use if a value is not available from the source file or Import Activity constant value.
Map	Enable the list of attributes that can be mapped to a source file or constant value in the Import Mapping and Import Activity Map Fields step.
Required	Specify the list of attributes that must be mapped to source file columns. Consequently, if you have selected an attribute as required, you must also enable the Map option for that attribute. When mapping the external source file, the required target attribute defined for the object are displayed with an asterisk.

Custom Objects

To use the file-based import feature for custom objects, you must first generate the artifacts required for import. You generate these required artifacts within Oracle Fusion CRM Application Composer, after making your object model extensions.

File-Based Import Mapping: Explained

This topic contains the following sections:

Import options
Source file options
Target options

Import Options

The following attributes pertain to the import mapping.

Attribute	Description
Object	The business object to be imported.
Name	The name that identifies the mapping in the Import Mapping and Import Activity UIs. If the mapping was initially created while mapping fields directly in the Import Activity user interface and automatically saved without providing a user-defined mapping name, the mapping name is derived from the Import Activity name and date.
Decimal Separator	The format of the fractional portion of numerical values in columns mapped to attributes with a decimal attribute type.
Date Format	The format of values in columns mapped to attributes with a date attribute type.
Timestamp Format	The format of values in columns mapped to attributes with a time stamp attribute type.
Lock	If selected, prevents any user, other than the creator of the mapping, from editing the mapping.

Source File Options

Map each column that the source file is expected to contain with a specific attribute.

The following table describes the details pertaining to columns provided in the source file:

Source Column	Description
Sequence	The sequence number in which the columns are expected to be provided in the source file. Two rows cannot have the same sequence number.
Column Name	The column name expected in the source file if a header row is included, or more generic values such as Column A, Column B, and so on, if the header row is not included for Text file types. The tagging structure is represented for XML file types.
Column Width	Use when the delimiter value is fixed width for Text file types only.
Ignore	Ignore the source file column to exclude the data from being imported.
Required	If selected, a value must exist in the source file or the row will not be imported.

Target Options

The following table describes the details pertaining to corresponding attributes in the target application table:

Target Attributes	Description
Object	The group of import objects that represent the components of the business object being imported.
Attribute	The attribute name that represents the corresponding interface table column for the object.
Duplicate Validation	If selected, the attribute, along with other selected attributes, determines what constitutes a duplicate object when comparing objects in the interface tables and existing objects in the target application tables. For example, to validate the uniqueness of an object in the target application tables by the combination of an object's name and date, select Duplicate Validation for both attributes in the mapping.

Import Activity Source File Options: Explained

The Import Activity consists of a step by step guided process to assist you with creating an import activity for a given object.

This topic describes the source file options defined in the Import Activity that are used by the import process to locate and parse the source file data.

Source File Data

Enter attribute details pertaining to the source file as follows:

Option	Description
File Type	Source file must be either Text or XML.
Data Type, Delimiter, and Header Row Included	A Text file type can further be defined based on how the data is delimited and if the source file is expected to include a row of headings for each column.
Import Mapping	Displays a list of predefined mappings for the object selected for this import activity. The selected mapping will be used as the basis for mapping your source file in the next Import Activity step.

Source File Location

The following outlines the options that are available to you when locating your source file for import.

Option	Description
File Selection	Select from the following file selections: Specific file Enables you to upload a specific source file from a local file system, such as your desktop, a URL address, or from a network path. A file name is required for this option. Most recent file Enables you to schedule repeating import activities without having to select a new file every time. This selection is only available when you select Network from the Upload From options. You need to copy the new file to the specified network path for repeating import activities. You do not need to enter a file name for this option and can only upload your source file from a network path. The asterisk wildcard is supported for multiple characters. The question mark wildcard is supported for a single character.
Upload From	You can upload the source file from three locations: Desktop URL Network If you select Desktop, a File Name field with an associated Update button is displayed. Click Update and browse to search for and select the file you want to upload. If you select URL, enter the address location as in the following example format: `http://www.example.com/` If you select Network, enter the file name path as in the following example format: `\ComputerName\SharedFolder\Resource\` Note If you selected the Specific File as your file selection option, then you will have to include the file name for both URL and Network file path locations.

Option

Description

File Selection

Select from the following file selections:

Specific file
Enables you to upload a specific source file from a local file system, such as your desktop, a URL address, or from a network path. A file name is required for this option.
Most recent file
Enables you to schedule repeating import activities without having to select a new file every time. This selection is only available when you select Network from the Upload From options.

You need to copy the new file to the specified network path for repeating import activities. You do not need to enter a file name for this option and can only upload your source file from a network path. The asterisk wildcard is supported for multiple characters. The question mark wildcard is supported for a single character.

Upload From

You can upload the source file from three locations:

Desktop
URL
Network

If you select Desktop, a File Name field with an associated Update button is displayed. Click Update and browse to search for and select the file you want to upload.

If you select URL, enter the address location as in the following example format: http://www.example.com/

If you select Network, enter the file name path as in the following example format: \ComputerName\SharedFolder\Resource\

Note

If you selected the Specific File as your file selection option, then you will have to include the file name for both URL and Network file path locations.

Import Activity Attachment Options: Explained

This topic includes the following:

Provide attachment information in the source file columns for the corresponding object record row
Select all the attachment files referenced in the source file in the Import Activity definition

Source Files

Attachments are processed after the associated objects have imported successfully. Attachment related source file columns are not mapped to target attributes but used to directly associate the attachments to the corresponding import objects by the import process. Consequently, the source file column names must have specific values for the import process to identify the attachment information. If an object has multiple attachments, the set of columns must be repeated for each attachment. For example, if the imported objects have a maximum possibility of two attachment files, at a minimum, you must have two columns labeled ATTACHMENT_FILE_NAME.

The following table describes the source file column names:

Column Name	Description
ATTACHMENT_FILE_NAME	The only required column for each attachment file. This column is for the attachment file name and must match exactly to the file name that will be added to the Import Activity.
ATTACHMENT_FILE_TITLE	An optional column to provide a file title.
ATTACHMENT_FILE_DESC	An optional column to provide a file description.
ATTACHMENT_CATEGORY_NAME	An optional column for the Category Name. If one is not provided, the Oracle defined category for the object is used.

Import Activity Attachment File Selection

The Import Activity requires a single compressed file that includes all the attachment files referenced in the source file. The selection method can occur in two ways:

Select a compressed file in zip or jar format that contains all the individual attachment documents. A compressed file that contains a hierarchy of folders that organizes the individual documents is acceptable.
Alternatively, if the Universal Content Management Applet Enabled profile is set to Yes, you can select individual attachment documents and the applet will compress the selection into a single compressed file. Select Multiple Files and then click Browse to display the file selector. Browse through the file system and select multiples files from across various folders.

Note

You must select all attachments in one operation. For example, you cannot select few files now and then return later to select more attachments files. If more than one row in the source file references the same file, you only need to select it once.

Import Activity Import Options: Explained

The File Import Activity consists of a step by step guided process to assist you with creating an import activity for a given object.

This topic describes the import options defined in the Import Activity that are used by the import process to interpret source file data and import interface table data into the target application tables.

Source File Data Transformation

The following options are used to identify the formatting of source file data so the data can be correctly interpreted and transformed by the import process:

Option	Description
Decimal Separator	The format of the fractional portion of numerical values in columns mapped to attributes with a decimal attribute type.
Date Format	The format for values in columns mapped to attributes with a date attribute type.
Time Stamp Format	The format for values in columns mapped to attributes with a time stamp attribute type.
File Encoding	The overall encoding of the characters within the file.

Interface to Target Import Options

The following options are used when importing the interface table information to the target application tables:

Option	Description
Import Mode	Determines if the Import Activity process should create new records or update existing records. If updating existing records, the record IDs must be provided in the source file. If an existing record is not found, a new record is created. Update mode is not supported for all import objects. Consequently, the Import Mode is set to Create and is not updatable for those objects. If creating new records, the import process evaluates the data in the interface tables with existing objects in the target application tables for possible duplicates. Customer Data Management objects are evaluated using the rules defined in the set of Matching Configurations. All other objects are evaluated using the combination of attributes selected for duplicate validation in the predefined Import Mapping.
Allowable Error Count	An error count above the threshold will stop the import process for all records. If the error count is below the threshold, records without errors are imported. In either case, records with errors will be reported in the Error and Exception files. Validation errors include: Missing required values Values that exceed the attribute length Invalid identifiers and lookup codes Duplicates to existing records in the destination tables based on the combination of attributes selected for duplicate validation in the predefined Import Mapping Duplicates found using matching configurations for Customer Data Management objects do not contribute to the error count.
Notification E-Mail	The e-mail of the intended recipient of import processing notifications.
Customer Data Management Duplicates	Consumer, customer, and legal entity objects imported by themselves or as components of another object are subject to duplicate verification. The duplicates are determined using the following matching configurations: Batch Location Basic Duplicate Identification Batch Person Basic Duplicate Identification Batch Organization Basic Duplicate Identification You can select from one of the following: Do Not Import Duplicate Records If the main object of the Import Activity is a consumer, customer, or a legal entity object, rows that are matched to existing records will not be imported. These duplicates records are reported in the Exception and Error reports. If the Customer Data Management objects are components of another object and one or more matches are found, the existing duplicate records are evaluated to determine the most recent record. The most recent record will be associated with the main object being imported. For example, when importing a marketing response object, the consumer object is also a component of the response. If the consumer is matched to an existing record, the consumer in the interface tables is not imported. However, the response object will import and the most recent existing consumer record will be associated to the response. Import Duplicate Records The Customer Data Management objects will be imported even if matched records exist. Import Duplicate Records and Create Resolution Request The Customer Data Management objects will be imported even if matched records exist. In addition, a duplicate resolution request is created and displayed in the Customer Data Management, Duplicate Resolution work area.
Duplicate Look Back Days	This option applies only to the Lead import object. Only existing leads created within the period determined by the look back days value are evaluated for duplicates based on the attributes selected for duplicate validation in the predefined import mapping. If a duplicate is found, the lead will not be imported and the duplicate record will be reported on the Exception report. Duplicate leads are included in the calculation of the allowable error count threshold.

Import Activity Field Mapping: Explained

After entering your import options, the second step of the import activity process is to map fields in the source file to the corresponding target attributes.

This topic explains:

Map Fields
Saving the Import Mapping
Constant Values

Map Fields

The Map Fields section can be subdivided into source file columns and target attribute columns.

The source column header value is derived from one of the following:

Predefined mapping, if one is selected
The source file, if the Header Row Included option is selected in the first step of the Import Activity definition (for Text file type only)
Generic values of Column A, Column B, and so on, if the Header Row Included option is not selected (for Text file type only)
XML tagging structure (for XML file type only)

The following table outlines the source columns:

Source Column	Description
Column Header	Represents the column header for Text file types and the tagging structure for XML file types.
Example Value	Values are derived from the first source file saved with the predefined mapping. If you did not select a predefined mapping, the example values are taken from the first data row in the source file selected in the first step of the Import Activity definition.
Ignore	Select this option if you do not want to import the source file data in that column.

The following table outlines the target columns:

Target Column	Description
Object	The group of import objects that represent the components of the business object being imported.
Attribute	The attribute name that represents the corresponding interface table column for the object.

Saving the Import Mapping

The mapping between source file information and target attributes is saved as a reusable mapping when the Import Activity is saved, using the import activity name and date to derive a mapping name. If you selected a predefined mapping, modifications made in the Import Activity to an unlocked mapping will update and save to the predefined mapping. If the predefined mapping is locked, a modified mapping will be saved as a new mapping. To specify a mapping name for new mappings, select the Save As option from the Map Fields Actions menu.

Constant Values

Constant values provide a way to specify a value for a target attribute that all imported objects will inherit. For example, if a source file does not contain a column for business unit and all of the objects in the file belong to the same business unit, enter a constant value for the object and business unit attribute.

File-Based Import Monitoring: Explained

You can monitor all file import activities that are currently scheduled to run, have completed successfully, or failed with errors. For each import activity, you can view the details pertaining to each underlying process and make necessary updates for any failed records to import again.

You can view the list of import activities from the Manage Import Activities page. Select the import activity that you want to monitor by clicking on the hyperlink in the corresponding Status column. The View Import Status results page is displayed which contains the following sections:

Files Processed
Import Processes

Files Processed

The Files Processed section displays a row for each source file that is processed.

The import processing details are summarized and displayed for each source file and include the following:

File Processing Summary Information	Description
Records Read From File	The number of records read from the source file.
Format Errors	The number of errors found when processing data to insert into the interface tables from the source file, Import Activity constants, and Import Object value default values. View the error details in the Exception and Error files attached to the process.
Load Errors	The number of errors found when importing data from the interface tables to the destination application tables. View the error details in the Exception and Error files attached to the process.
Successfully Loaded	The number of import objects imported to the application destination tables. If the import object is made up of multiple components, each component is counted as successfully loaded. Consequently the Successfully Loaded count may be larger than the Records Read From File count. View the successful record details in the Log file attached to the process.
Attachments	Once an Import Activity process has completed, processing reports are included in the Attachments column. The Log file includes the records that were successfully imported plus the unique destination application table identifiers for the objects. The Exception file includes the records that were not imported plus a reference to one of the errors for each record that failed. The Error file includes all the errors for each record that failed validation.

Import Processes

From the Import Processes section, you can view details pertaining to each process involved in importing the objects in the source file. A listing of brief messages provides information on processing steps within each underlying process.

Importing Geographies Using File-based Data Import: Worked Example

This example demonstrates how to import data using the File-Based Data Import tool. In this particular example you have a source file containing geography data that you want to import into the application, so that the geography data can be used for uses related to locations, such as real time address validation and tax purposes.

The following table summarizes the key decisions for this scenario:

Decisions to Consider	In This Example
What type of object are you importing?	Geography
What file type are you using for your source data?	Text file
Where are you uploading your source data file from?	Your desktop
What data type is your source data file?	Comma separated
Which fields are you importing into Oracle Fusion applications?	All, except for the RecordTypeCode field
When do you want to process the import?	Immediately

Summary of the Tasks

These are the steps that are required to create an import activity and submit the import:

Determine what information is in the source file.
Create and schedule the import activity.
Monitor the import results.

Prerequisites when importing additional geography data after your initial import

You need to ensure that the combination of Source ID and Parent Source ID values are unique for each row of data within a single import. However, your source data files do not need to have the same Source ID and Parent Source ID values as your previously imported geography data. If the geography structure levels and the parents for each geography value are the same, the changed IDs will not affect the import.
Ensure that all of the parents of a child geography are included in your data file so that the child geography can be added. For example, if you originally imported US, CA, and San Francisco, and now you want to import the city of San Jose in CA, then your data file needs to include US, CA, and San Jose.
Check that your source data file has the correct values for the geography data that you have already loaded. For example, if your initial import included the value US for country and CA as state, and in a subsequent import you have California as a state, your geography import will result in two state records (CA and California) in the application data, with the US as the country parent.

Determine what information is in the source file

Your source geography data files should include a unique Source ID value for each row of data, and a Parent Source ID value which identifies the parent of that row of geography data. Source IDs, or Parent Source IDs, should not exceed 18 characters. An example of geography source data could be as follows:

Geography Level	Name	Source ID	Parent Source ID
1 (Country)	US	1
2 (State)	CA	11	1
3 (County)	Alameda	111	11
4 (City)	Pleasanton	1111	111
4 (City)	Dublin	1112	111

Create and schedule the import activity

You create an import activity, enter the import details, and schedule the import. An import activity definition provides the instructions for the import processing - this includes selecting the source file, or file location; mapping fields from the source file to the Oracle Fusion object and attribute; and scheduling the import.

Navigate to Setup and Maintenance and search for the Manage File Import Activities task. Click Go to Task.
In the Manage Import Activities page, click the Create icon.

In the Create Import Activity: Set Up page, create an import activity for the Geography object type by completing the fields, as shown in this table:

Field	Value
Name	Master Reference Geographies
Object	Geography
File Type	Text File
File Selection	Specific file
Upload From	Desktop
File Name	Choose relevant file from desktop
Data Type	Comma separated

Note

Ensure that the file type that you select in the Create Import Activity: Set Up page matches the file type of the source data file.

Click Next.

On the Create Import Activity: Map Fields page, map each field from your source file to the Oracle Fusion object and attribute, as shown in this example:

Column Header	Example Value	Ignore	Object	Attribute
Primary Geography Name	Primary Geography Name	United States	Imp Geography	Primary Geography Name
Country Code	US	No	Imp Geography	Country Code
Record Type Code	0	Yes	Imp Geography	Record Type Code
Source ID	10265	No	Imp Geography	Source ID
Parent Source ID	1053	No	Imp Geography	Parent Source ID

If you do not want to import a column in the text file you can select Ignore.

Note

If you have any difficulties mapping the fields from your source file to the relevant Oracle Fusion applications object, you can use the import object spreadsheets for reference.

Click Next.
On the Create Import Activity: Create Schedule page, select Immediate in the Schedule field so that the import will start immediately.
Instead of immediately importing the data, you can choose a date and time to start the import. You can also specify if the import will be repeated, and the frequency of the repeated import.
Click Next.

Monitor the import results

You monitor the progress of the Import Activity processing, and view completion reports for both successful records and errors.

On the Create Import Activity: Review and Activate page, you verify your import details in the Import Details, File Details, Import Options, and Schedule sections.
Your import details are correct so you click Activate to submit the import.
Once the import activity has completed, the Status field value will change to Completed.

Define Geographies: FAQs for File-Based Data Import

What determines the list of objects displayed?

A single import object can have multiple associated components that are considered objects by themselves. Whether or not an associated object can be grouped as a component of another object for the purpose of file import is determined by the complexity of the object structure and how it is stored in the data model. Oracle Fusion provides import objects predefined to meet the file processing import requirements. Consequently, in some cases, more than one source file may be required to capture all associated components of an object.

What happens if I inactivate an Import Activity?

The Import Activity will not stop the currently running process. However, it will stop the next process that has not started plus any future repeating file import activities. You can always activate the process at a later stage.

What happens if I add a marketing list in the Import Activity definition?

File-based data import enables you to record consumers and organization contacts in a marketing list when importing consumer, lead, and response import objects. Select an existing list or create a new one. A marketing list is assigned the list type value of Imported if created while defining an import activity. After the objects are imported successfully, the consumers and contacts are added as members of the marketing list.

Define Legal Entities for Customer Data Management: Manage Legal Entity

Legal Entities: Explained

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

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

Facilitating local compliance
Taking advantage of lower corporation taxation in some jurisdictions
Preparing for acquisitions or disposals of parts of the enterprise
Isolating one area of the business from risks in another area. For example, your enterprise develops property and also leases properties. You could operate the property development business as a separate legal entity to limit risk to your leasing business.

The Role of Your Legal Entities

Legal Entity in Oracle Fusion: Points to Consider

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

The importance of legal entity in transactions
Legal entity and its relationship to business units
Legal entity and its relationship to divisions
Legal entity and its relationship to ledgers
Legal entity and its relationship to balancing segments
Legal entity and its relationship to consolidation rules
Legal entity and its relationship to intercompany transactions
Legal entity and its relationship to worker assignments and legal employer
Legal entity and payroll reporting
Legal reporting units

The Importance of Legal Entity in Transactions

Legal Entity and Its Relationship to Business Units

Legal Entity and Its Relationship to Divisions

Legal Entity and Its Relationship to Ledgers

Legal Entity and Its Relationship to Balancing Segments

Identify the legal entities within the ledger.
Balance transactions that cross legal entity boundaries through intercompany transactions.
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.

Note

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

Legal Entity and Its Relationship to Consolidation Rules

Legal Entity and its Relationship to Intercompany Transactions

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

Define Legal Entities for Customer Data Management: Manage Legal Entity HCM Information

HCM Organization Models: Examples

These examples illustrate different models for human capital management (HCM) organizations. Each example includes a legislative data group (LDG). LDGs are not an organization classification, but they are included in the example to show how you associate them with a payroll statutory unit to partition payroll data.

Simple Configuration

This example illustrates a simple configuration that does not include any tax reporting units. The legal employer and payroll statutory units are the same, sharing the same boundaries. Reporting can only be done at a single level. Countries such as Saudi Arabia and the United Arab Emirates (UAE) might use this type of model, as reporting in these countries is done at the legal entity level.

This figure illustrates a simple configuration where the enterprise has only one legal entity that is both a payroll statutory unit and a legal employer.

An enterprise with one legal entity
that is also a payroll statutory unit and a legal employer. The legal
entity is associated with one legislative data group.

Multiple Legal Employers and Tax Reporting Units Under One Payroll Statutory Unit

This example illustrates a more complex configuration. In this enterprise, one legal entity, InFusion US, is defined as a payroll statutory unit and has two separate legal entities, which are also legal employers. This model shows multiple legal employers that are associated with a single payroll statutory unit, and how tax reporting units are always associated with a specific legal employer (or employers) through the payroll statutory unit. The implication is that payroll statutory reporting boundaries vary from human resources (HR) management, and the balances can be categorized separately by either payroll statutory unit, legal employer, or tax reporting unit. This configuration is based on tax filing requirements, as some tax-related payments and reports are associated with a higher level than employers. An example of a country that might use this model is the US.

This figure illustrates an enterprise that has one payroll statutory unit and multiple legal employers and tax reporting units.

An enterprise with one payroll statutory
unit, two legal entities that are also legal employers, and two tax
reporting units

One Payroll Statutory Unit and Two Tax Reporting Units That Are Subsidiaries of the Legal Entity

This model makes no distinction between a legal employer and a payroll statutory unit. Tax reporting units are defined as subsidiaries to the legal entity. In this enterprise, legal entity is the highest level of aggregation for payroll calculations and reporting, and statutory reporting boundaries are assumed to be the same for both payroll and HR management. An example of a country that might use this model is France.

This figure illustrates an example of an organization with one legal entity that is both a legal employer and a payroll statutory unit and that has two tax reporting units.

An organization that has one legal
entity that is both a payroll statutory unit and legal employer and
has two tax reporting units.

One Payroll Statutory Unit with Several Tax Reporting Units That Are Independent from the Legal Employer

In this model, the enterprise has one legal entity, and legal employers and tax reporting units are independent from each other within a payroll statutory unit, because there is no relationship from a legal perspective. Therefore, you can run reporting on both entities independently. Using this model, you would not typically need to report on tax reporting unit balances within a legal employer, and balances can be categorized by either or both organizations, as required. An example of a country that might use this model is India.

This figure illustrates an enterprise with one legal entity that is a payroll statutory unit and a legal employer, and the tax reporting units are independent from the legal employer.

A figure that shows an enterprise with
one legal entity that is both a legal employer and a payroll statutory
unit and that has multiple tax reporting units that are independent
from the legal employer

Multiple Payroll Statutory Units with Several Tax Reporting Units that are Independent from the Legal Employer

In this model, the enterprise has two legal entities, and legal employers and tax reporting units are independent from each other within a payroll statutory unit, because there is no relationship from a legal perspective. Therefore, you can run reporting on both entities independently. Using this model, you would not typically need to report on tax reporting unit balances within a legal employer, and balances can be categorized by either or both organizations, as required. An example of a country that might use this model is the United Kingdom (UK).

This figure illustrates an enterprise with two legal entities, and legal employers and tax reporting units are independent from each other.

A graphic that illustrates an enterprise
with two legal entities

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 Manage Legal Entity HCM Information

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.

Define Business Units for Customer Data Management: Manage Service Provider Relationships

Shared Service Centers: Explained

Oracle Fusion Applications allows defining relationships between business units to outline which business unit provides services to the other business units.

Service Provider Model

In Oracle Fusion Applications V1.0, the service provider model centralizes only the procurement business function. Your business units that have the requisitioning business function enabled can define relationships with business units that have the procurement business function enabled. These service provider business units will process requisitions and negotiate supplier terms for their client business units.

This functionality is used to frame service level agreements and drive security. The definition of service provider relationships provides you with a clear record of how the operations of your business are centralized. For other centralized processing, business unit security is used (known in Oracle EBS as Multi-Org Access Control). This means that users who work in a shared service center have the ability to get access and process transactions on behalf of many business units.

Shared Service Center: Points to Consider

Oracle Fusion applications supports shared service centers in two ways. First, with business unit security, which allows your shared service centers personnel to process transactions for other business units called clients. This was the foundation of Multi Org Access Control in the Oracle E-Business Suite.

Second, the service provider model expands on this capability to allow a business unit and its personnel in a shared service center to work on transactions of the client business units. It is possible to view the clients of a service provider business unit, and to view service providers of a client business unit.

Your shared service centers provide services to your client business units that can be part of other legal entities. In such cases, your cross charges and recoveries are in the form of receivables invoices, and not merely allocations within your general ledger, thereby providing internal controls and preventing inappropriate processing.

For example, in traditional local operations, an invoice of one business unit cannot be paid by a payment from another business unit. In contrast, in your shared service center environment, processes allowing one business unit to perform services for others, such as paying an invoice, are allowed and completed with the appropriate intercompany accounting. Shared service centers provide your users with access to the data of different business units and can comply with different local requirements.

Security

The setup of business units provides you with a powerful security construct by creating relationships between the functions your users can perform and the data they can process. This security model is appropriate in a business environment where local business units are solely responsible for managing all aspects of the finance and administration functions.

In Oracle Fusion applications, the business functions your business unit performs are evident in the user interface for setting up business units. To accommodate shared services, use business unit security to expand the relationship between functions and data. A user can have access to many business units. This is the core of your shared service architecture.

For example, you take orders in many business units each representing different registered legal entities. Your orders are segregated by business unit. However, all of these orders are managed from a shared service order desk in an outsourcing environment by your users who have access to multiple business units.

Benefits

In summary, large, medium, and small enterprises benefit from implementing share service centers. Examples of functional areas where shared service centers are generally implemented include procurement, disbursement, collections, order management, and human resources. The advantages of deploying these shared service centers are the following:

Reduce and consolidate the number of control points and variations in processes, mitigating the risk of error.
Increase corporate compliance to local and international requirements, providing more efficient reporting.
Implement standard business practices, ensuring consistency across the entire enterprise and conformity to corporate objectives.
Establish global processes and accessibility to data, improving managerial reporting and analysis.
Provide quick and efficient incorporation of new business units, decreasing startup costs.
Establish the right balance of centralized and decentralized functions, improving decision making.
Automate self-service processes, reducing administrative costs.
Permit business units to concentrate on their core competencies, improving overall corporate profits.

Service Provider Model: Explained

In Oracle Fusion applications, the service provider model defines relationships between business units for a specific business function, identifying one business in the relationship as a service provider of the business function, and the other business unit as its client.

Procurement Example

The Oracle Fusion Procurement product family has taken advantage of the service provide model by defining outsourcing of the procurement business function. Define your business units with requisitioning and payables invoicing business functions as clients of your business unit with the procurement business function. Your business unit responsible for the procurement business function will take care of supplier negotiations, supplier site maintenance, and purchase order processing on behalf of your client business units. Subscribe your client business units to the supplier sites maintained by the service providers, using a new procurement feature for supplier site assignment.

In the InFusion example below, business unit four (BU4) serves as a service provider to the other three business units (BU1, BU2, and BU3.) BU4 provides the corporate administration, procurement, and human resources (HR) business functions, thus providing cost savings and other benefits to the entire InFusion enterprise.

A figure that shows an example of a
procurement service provider model.

Define Business Units for Customer Data Management: Specify Customer Contract Management Business Function Properties

Customer Contracts Business Unit Setup: Explained

Using the Specify Customer Contract Management Business Function Properties task, available by navigating to Setup and Maintenance work area and searching on the task name, you can specify a wide variety of business function settings for customer contracts in a specific business unit. The selections you make for these business functions impact how Oracle Fusion Enterprise Contracts behaves during contract authoring.

Using the Specify Customer Contract Management Business Function Properties task, manage these business function properties:

Enable related accounts
Set currency conversion details
Manage project billing options
Set up the Contract Terms Library

The setup options available for the Contract Terms Library are applicable to both customer and supplier contracts, and are described in the business unit setup topic for the Contract Terms Library. That topic is available as a related link to this topic.

Enabling Related Customer Accounts

Contract authors can specify bill-to, ship-to, and other accounts for the parties in a contract. Enable the related customer accounts option if you want accounts previously specified as related to the contract party to be available for selection.

Managing Currency Conversion Options

If your organization plans to transact project-related business in multiple currencies, then select the multicurrency option. This allows a contract author to override a contract's currency, which defaults from the ledger currency of the business unit. It also enables the contract author to specify currency conversion attributes to use when converting from the bill transaction currency to the contract currency and from the invoice currency to the ledger currency.

In the Bill Transaction Currency to Contract Currency region, enter currency conversion details that will normally be used, by all contracts owned by this business unit, to convert transaction amounts in the bill transaction currency to the contract currency. Newly created contracts contain the default currency conversion values, but you can override the values on any contract, if needed.

In the Invoice Currency to Ledger Currency region:

Enter invoice transaction conversion details if the invoice and ledger currencies can be different.
Enter revenue transaction conversion details if the revenue and ledger currencies can be different for as-incurred and rate-based revenue.

Managing Project Billing Options

The options available for selection in the Project Billing region control the behavior of project invoicing and revenue recognition for contracts with project-based work.

Project billing can behave differently for external contracts (customer billing) or intercompany and interproject contracts (internal billing).

Set these options, which apply to all contracts:

Select the Transfer Revenue to General Ledger option if you want to create revenue accounting events and entries, and transfer revenue journals to the general ledger. If this option is not selected, then revenue can still be generated, but will not be transferred to the general ledger.
Indicate if a reason is required for credit memos that are applied to invoices.

There are two sets of the following options, one for customer billing and a second for internal billing:

Select an invoice numbering method, either Manual or Automatic. The invoice numbering method is the method that Oracle Fusion Receivables uses to number its invoices, upon release of draft invoices from Project Billing.
- If the invoice numbering method is Manual, then select an invoice number type, which sets the type of Receivables invoice numbers that are allowed. Valid values are Alphanumeric and Numeric.
- If the invoice numbering method is Automatic, then enter the next invoice number to use when generating Receivables invoice numbers.
Select the Receivables batch source to use when transferring invoices to Receivables.

Set this option only for customer billing:

Indicate if you want contract authors to manually enter the Receivables transaction type on the customer contracts they create.

Contract Terms Library Business Unit Setup: Explained

You can specify a wide variety of Contract Terms Library settings for either customer or supplier contracts within each business unit, by using either the Specify Customer Contract Management Business Function Properties or the Specify Supplier Contract Management Business Function Properties tasks. These tasks are available by navigating to the Setup and Maintenance work area and searching on the task name.

For the Contract Terms Library in each business unit, you can:

Enable clause and template adoption.
Set the clause numbering method.
Enable the Contract Expert feature.
Specify the layout for printed clauses and contract deviation reports.

Enabling Clause Adoption

If you plan to use clause adoption in your implementation, then set up the following:

Specify a global business unit
You must designate one of the business units in your organization as the global business unit by selecting the Global Business Unit option. This makes it possible for the other local business units to adopt and use approved content from that global business unit. If the Global Business Unit option is not available for the business unit you are setting up, this means that you already designated another business unit as global.
Enable automatic adoption
If you are implementing the adoption feature, then you can have all the global clauses in the global business unit automatically approved and available for use in the local business by selecting the Autoadopt Global Clauses option. If you do not select this option, the employee designated as the Contract Terms Library Administrator must approve all global clauses before they can be adopted and used in the local business unit. This option is available only for local business units.
Specify the administrator who approves clauses available for adoption
You must designate an employee as the Contract Terms Library administrator if you are using adoption. If you do not enable automatic adoption, then the administrator must adopt individual clauses or localize them for use in the local business unit. The administrator can also copy over any contract terms templates created in the global business unit. The clauses and contract terms templates available for adoption are listed in the administrator's Terms Library work area.

Setting Clause Numbering Options

You can set up automatic clause numbering for the clauses in the business unit by selecting Automatic in the Clause Numbering field and entering a Document Sequence Category you previously set up in the Clause Sequence Category field. If clause numbering is manual, contract terms library administrators must enter unique clause numbers each time they create a clause.

You can choose to display the clause number in front of the clause title in contracts by selecting the Display Clause Number in Clause Title option.

Enabling Contract Expert

You must select the Enable Contract Expert option to be able to use the Contract Expert feature in a business unit. This setting takes precedence over enabling Contract Expert for individual contract terms templates.

Specifying the Printed Clause and Deviations Report Layouts

For each business unit, you can specify the Oracle BI Publisher RTF file that serves as the layout for:

The printed contract terms
Enter the RTF file you want used for formatting the printed clauses in the Clause Layout Template field.
The contract deviations report

The RTF file you select as the Deviations Layout Template determines the appearance of the contract deviations report PDF. This PDF is attached to the approval notification sent to contract approvers.

Define Business Units for Customer Data Management: Specify Supplier Contract Management Business Function Properties

Supplier Contracts Business Unit Setup: Explained

Using the Specify Supplier Contract Management Business Function Properties task, available by selecting Setup and Maintenance from the Tools menu and searching on the task name, you can specify a variety of business function settings for supplier contracts in a specific business unit.

The selections you make for these business functions impact how the Contract Terms Library behaves during supplier contract authoring.

Managing Contract Terms Library Setup Options

The setup options available for the Contract Terms Library are applicable to both customer and supplier contracts, and are described in the business unit setup topic for the Contract Terms Library. That topic is available as a related link to this topic.

Contract Terms Library Business Unit Setup: Explained

For the Contract Terms Library in each business unit, you can:

Enable clause and template adoption.
Set the clause numbering method.
Enable the Contract Expert feature.
Specify the layout for printed clauses and contract deviation reports.

Enabling Clause Adoption

If you plan to use clause adoption in your implementation, then set up the following:

Specify a global business unit
You must designate one of the business units in your organization as the global business unit by selecting the Global Business Unit option. This makes it possible for the other local business units to adopt and use approved content from that global business unit. If the Global Business Unit option is not available for the business unit you are setting up, this means that you already designated another business unit as global.
Enable automatic adoption
If you are implementing the adoption feature, then you can have all the global clauses in the global business unit automatically approved and available for use in the local business by selecting the Autoadopt Global Clauses option. If you do not select this option, the employee designated as the Contract Terms Library Administrator must approve all global clauses before they can be adopted and used in the local business unit. This option is available only for local business units.
Specify the administrator who approves clauses available for adoption
You must designate an employee as the Contract Terms Library administrator if you are using adoption. If you do not enable automatic adoption, then the administrator must adopt individual clauses or localize them for use in the local business unit. The administrator can also copy over any contract terms templates created in the global business unit. The clauses and contract terms templates available for adoption are listed in the administrator's Terms Library work area.

Setting Clause Numbering Options

You can choose to display the clause number in front of the clause title in contracts by selecting the Display Clause Number in Clause Title option.

Enabling Contract Expert

Specifying the Printed Clause and Deviations Report Layouts

For each business unit, you can specify the Oracle BI Publisher RTF file that serves as the layout for:

The printed contract terms
Enter the RTF file you want used for formatting the printed clauses in the Clause Layout Template field.
The contract deviations report

The RTF file you select as the Deviations Layout Template determines the appearance of the contract deviations report PDF. This PDF is attached to the approval notification sent to contract approvers.

Define Business Units for Customer Data Management: Assign Business Unit Business Function

Business Functions: Explained

A business unit can perform many business functions in Oracle Fusion Applications. Prior to Oracle Fusion Applications, operating units in Oracle E-Business Suite were assumed to perform all business functions, while in Oracle PeopleSoft , each business unit had one specific business function. Oracle Fusion Applications blends these two models and allows defining business units with one or many business functions.

Business Functions

A business function represents a business process, or an activity that can be performed by people working within a business unit and describes how a business unit is used. The following business functions exist in Oracle Fusion applications:

Billing and revenue management
Collections management
Customer contract management
Customer payments
Expense management
Incentive compensation
Marketing
Materials management
Inventory management
Order fulfillment orchestration
Payables invoicing
Payables payments
Procurement
Procurement contract management
Project accounting
Receiving
Requisitioning
Sales

Although there is no relationship implemented in Oracle Fusion Applications, a business function logically indicates a presence of a department in the business unit with people performing tasks associated with these business functions. A business unit can have many departments performing various business functions. Optionally, you can define a hierarchy of divisions, business units, and departments as a tree over HCM organization units to represent your enterprise structure.

Note

This hierarchy definition is not required in the setup of your applications, but is a recommended best practice.

Your enterprise procedures can require a manager of a business unit to have responsibility for their profit and loss statement. However, there will be cases where a business unit is performing only general and administrative functions, in which case your manager's financial goals are limited to cost containment or recovering of service costs. For example, if a shared service center at the corporate office provides services for more commercially-oriented business units, it does not show a profit and therefore, only tracks its costs.

In other cases, where your managers have a responsibility for the assets of the business unit, a balance sheet can be produced. The recommended best practice to produce a balance sheet, is to setup the business unit as a balancing segment in the chart of accounts. The business unit balancing segment can roll up to divisions or other entities to represent your enterprise structure.

When a business function produces financial transactions, a business unit must be assigned to a primary ledger, and a default legal entity. Each business unit can post transactions to a single primary ledger, but it can process transactions for many legal entities.

The following business functions generate financial transactions and will require a primary ledger and a default legal entity:

Billing and revenue management
Collections management
Customer payments
Expense management
Materials management
Payables invoicing
Project accounting
Receiving
Requisitioning

Business Unit Hierarchy: Example

For example, your InFusion America Company provides:

Air quality monitoring systems through your division InFusion Air Systems
Customer financing through your division InFusion Financial Services

The InFusion Air Systems division further segments your business into the System Components and Installation Services subdivisions. Your subdivisions are divided by business units:

System Components by products: Air Compressors and Air Transmission
Installation Services by services: Electrical and Mechanical

A figure that shows an example of a
business unit hierarchy.

Oracle Fusion applications facilitates independent balance sheet rollups for legal and management reporting by offering up to three balancing segments. Hierarchies created using the management segment can provide the divisional results. For example, it is possible to define management segment values to correspond to business units, and arrange them in a hierarchy where the higher nodes correspond to divisions and subdivisions, as in the Infusion US Division example above.

Define Business Units for Customer Data Management: Manage Business Units

Business Units: Explained

The Oracle Fusion Applications business unit model:

Allows for flexible implementation
Provides a consistent entity for controlling and reporting on transactions
Anchors the sharing of sets of reference data across applications

In summary, use business units in the following ways:

Management reporting
Processing of transactions
Security of transactional data
Reference data definition and sharing

Brief Overview of Business Unit Security

Define Workforce Structures for CRM: Manage Locations

Locations: Explained

Location Sets

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

Creating Multiple Locations Simultaneously

Define Workforce Structures for CRM: FAQs for Manage Locations

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

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?

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

What happens if I inactivate a location?

Define Workforce Structures for CRM: Manage Divisions

Division: Explained

Divisions

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.

Adding a New Division After Acquiring a Company: Example

This example shows how to restructure your enterprise after acquiring a new division.

Scenario

You are part of a senior management team at InFusion Corporation. InFusion is a global company with organizations in the United States (US), the United Kingdom (UK), France, China, Saudi Arabia, and the United Arab Emirates (UAE). Its main area of business is in the high tech industry, and it has just acquired a new company. You must analyze their current enterprise structure and determine what new organizations you need to create to accommodate the new company.

Details of the Acquired Company

The acquired company is a financial services business based in Germany. Because the financial services business differs significantly from the high tech business, you want to keep the financial services company as a separate business with all the costs and reporting rolling up to the financial services division.

Analysis

The following table summarizes the key decisions that you must consider when determining what new organizations to set up and how to structure the enterprise.

Decision to Consider	In This Example
Create location?	The financial services company is based in Frankfurt as are the departments, so you need to create only one location.
Create separate division?	Yes. Although the new division will exist within the current enterprise structure, you want to keep the financial services company as a separate line of business. Creating a separate division means you can manage the costs and reporting separately from the InFusion Corporation. It also means you do not have to modify any existing organizations in the enterprise setup.
Create business unit?	Yes. The financial services business requires you to create several jobs that do not exist in your high tech business. You can segregate the jobs that are specific to financial services in a new business unit.
How many departments?	The financial services company currently has three departments for sales, accounting, and marketing. As you have no plans to downsize or change the company, you can create three departments to reflect this structure.
How many cost centers?	Although you can have more than one cost center tracking the costs of a department, you decide to create one cost center for each department to track costs.
How many legal entities?	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. In this case, you need only one legal entity. You must define the legal entity as a legal employer and payroll statutory unit. As the new division operates in Germany only, you can configure the legal entity to suit Germany legal and statutory requirements. Note When you identify the legal entity as a payroll statutory unit, the application transfers the legal reporting unit that is associated with that legal entity to Oracle Fusion HCM as a tax reporting unit.
Create legislative data group?	Yes. Because you currently do not employ or pay people in Germany, you must create one legislative data group to run payroll for the workers in Germany.

Resulting InFusion Enterprise Structure

Based on the analysis, you must create the following:

One new division
One new location
Three new departments
Three new cost centers
One new legal entity
One new legislative data group

The following figure illustrates the structure of InFusion Corporation after adding the new division and the other organizations.

A graphic that illustrates InFusion
corporation after adding a new division

Define Workforce Structures for CRM: Manage Departments

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
Departments

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:

Assign a cost center value in the value set for each cost center. For example, assign cost center values of PL04 and G3J1 to your manufacturing teams in the US and India. These unique cost center values allow easy aggregation of cost centers in hierarchies (trees) even if the cost centers are in different ledgers. However, this approach will require defining more cost center values.
Assign a balancing segment value with a standardized cost center value to create a combination of segment values to represent the cost center. For example, assign the balancing segment values of 001 and 013 with cost center PL04 to represent your manufacturing teams in the US and India. This creates 001-PL04 and 013-PL04 as the cost center reporting values.
The cost center value of PL04 has a consistent meaning. This method requires fewer cost center values to be defined. However, it prevents construction of cost center hierarchies using trees where only cost center values are used to report results for a single legal entity. You must specify a balancing segment value in combination with the cost center values to report on a single legal entity.

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:

Controlling costs within their budget
Tracking assets used by their department
Managing employees, their assignments, and compensation

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.

Define Workforce Structures for CRM: FAQs for Manage Job Families

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.

Define Workforce Structures for CRM: Manage Job

Jobs: Example

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

Software Industry

This figure illustrates the software industry job setup.