This guide also applies to on-premises implementations

4Define Enterprise Structures

This chapter contains the following:

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, that describe its operations and provide a basis for reporting.

  • Legal

  • Managerial

  • Functional

In Oracle Fusion, these structures are implemented using the chart of accounts and organization hierarchies. 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

  • Departments

Aligned these structures with your strategic objectives.

This figure is a grid with 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.

  • Owned by its shareholders, who may be individuals or other corporations.

Many other kinds of legal entities exist, 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 the entity 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 contributes to 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 its 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 have to be reflected directly in the legal structure of the enterprise. The management structure can include divisions, subdivisions, lines of business, strategic business units, profit, 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 as well as being reflected in the chart of accounts.

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 and selling, general, and administrative 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 includes:

  • Set Up Enterprise Structures business process, which consists of implementation activities that span many product families.

  • Information Technology, a second Business Process Model which contains the Set Up Information Technology Management business process.

  • Define Reference Data Sharing, which 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 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 get the name of the deploying enterprise and the location of the headquarters.

Define Enterprise Structures

Define enterprise structures to represent an organization with one or more legal entities under common control. Define 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 perform 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 has a manager, strategic objectives, a level of autonomy, and responsibility for its profit and loss.

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 your manufacturing and storage facilities as Inventory Organizations if Oracle Fusion tracks inventory balances there and Item Organizations if Oracle Fusion only tracks the items used in the facility but not the balances.

Define Reference Data Sharing

Define how reference data in the applications is partitioned and shared.

Note: Some product-specific implementation activities 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. 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 US dollars. Your product line includes all the components to build and maintain air quality monitoring (AQM) applications 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 initial costs of these applications.

Analysis

The following are elements you must 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 want 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 do you use 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 units in which to perform all these functions? How is your shared service center configured?

Global Enterprise Structure Model

The following figure and table summarize the model that your committee has designed and uses numeric 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 application 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 one primary ledger in
Great Britain Pounds (GBP). InFusion UK also has 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 center with three
associated warehouses. InFusion Corporation shares one common item
master. The table indicates if the enterprise structure
entities are required or optional during an implementation.

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

  • The enterprise is required because it serves as an umbrella for the entire implementation. All organizations are created within an enterprise.

  • Legal entities are also required. They can be optionally mapped to balancing segment values or represented by ledgers. Mapping balancing segment values to legal entities is required if you plan to use the intercompany functionality. The InFusion Corporation is a legal entity but is not discussed in this example.

  • At least one ledger is required in an implementation in which you record your accounting transactions.

  • Business units are also required 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 required 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 Oracle Sales Cloud implementations do not require recording accounting transactions and therefore, do not require a ledger.

Essbase Character and Word Limitations

The following is a comprehensive list of character and word limitations that apply to Essbase. All of the limitations apply to all of the Oracle Fusion General Ledger configurations summarized in the table.

Oracle Fusion General Ledger Configuration Maps to Essbase

Chart of Account Name

Cube Name

Chart of Account Segment Name

Dimension Name

Chart of Accounts Segment Value

Dimension Member Name

Chart of Accounts Segment Value Description

Alias for Member

Tree and Tree Version Name

Dimension Member Name

Primary Ledger Name

Dimension Member Name in Ledger Dimension

Secondary Ledger Name

Dimension Member Name in Ledger Dimension

Reporting Currency Name

Dimension Member Name in Ledger Dimension

Ledger Set Name

Dimension Member Name in Ledger Dimension

Accounting Calendar Period Names

Dimension Member Name in Accounting Period Name

Scenario Name Defined in Predefined Value Set Called Accounting Scenario

Dimension Member Name in Scenario Dimension

Even if case sensitivity is enabled in an aggregate storage outline for which duplicate member names is enabled, do not use matching dimension names with only case differences. For example, do not:

  • Name two dimensions Product and product.

  • Use quotation marks or brackets.

  • Use tabs in dimension, member, or alias names.

  • Use accent characters.

  • Use the characters for dimension or member names.

Restricted Characters

The following is a list of characters that are restricted and cannot be used in dimension, member, or alias names.

Character Meaning

@

at sign

\

backslash

,

comma

-

dash, hyphen, or minus sign

For the accounting calendar period names, you can use a hyphen or an underscore in the middle of an accounting calendar period name. For example: Jan-15 or Adj_Dec-15 can be used successfully.

=

equal sign

<

less than sign

()

parentheses

.

period

+

plus sign

'

single quotation mark

_

underscore

For the accounting calendar period names, you can use a hyphen or an underscore in the middle of an accounting calendar period name. For example: Jan-15 or Adj_Dec-15 can be used successfully.

|

vertical bar

Other Restrictions

  • Don't place spaces at the beginning or end of names. Essbase ignores such spaces.

  • Don't use these types of words as dimension or member names:

    • Calculation script commands, operators, and keywords.

    • Report writer commands.

    • Function names and function arguments.

    • Names of other dimensions and members (unless the member is shared).

    • Generation names, level names, and aliases in the database.

    • Any of these words in the table below:

      List 1 List 2 List 3

      ALL

      AND

      ASSIGN

      AVERAGE

      CALC

      CALCMBR

      COPYFORWARD

      CROSSDIM

      CURMBRNAME

      DIM

      DIMNAME

      DIV

      DYNAMIC

      EMPTYPARM

      EQ

      EQOP

      EXCEPT

      EXP

      EXPERROR

      FLOAT

      FUNCTION

      GE

      GEN

      GENRANGE

      GROUP

      GT

      ID

      IDERROR

      INTEGER

      LE

      LEVELRANGE

      LOOPBLOCK

      LOOPPARMS

      LT

      MBR

      MBRNAME

      MBRONLY

      MINUS

      MISSING, #MISSING

      MUL

      MULOP

      NE

      NON

      NONINPUT

      NOT

      OR

      PAREN

      PARENPARM

      PERCENT

      PLUS

      RELOP

      SET

      SKIPBOTH

      SKIPMISSING

      SKIPNONE

      SKIPZERO

      TO

      TOLOCALRATE

      TRAILMISSING

      TRAILSUM

      UMINUS

      UPPER

      VARORXMBR

      XMRONLY

      $$$UNIVERSE$$$

      #MI

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

ESC process for creating enterprise structure

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 don't select this feature, then you must set up your enterprise structure using individual tasks provided elsewhere in the offerings, and you can't create multiple configurations to compare different scenarios.

Establish Enterprise Structures

To define your enterprise structures, use the guided flow within the Establish Enterprise Structures task to enter basic information about your enterprise, such as the primary industry. 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 enough information 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, you are prompted to set up a descriptive flexfield structure for jobs, and for positions if applicable. Descriptive flexfields enable you to get more information when you create jobs and positions.

Review Configuration

You can view a result of the interview process prior to loading the configuration. The review results, show the divisions, legal entities, business units, reference data sets, and the management reporting structure that the application will create when you load the configuration.

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.

Rolling Back an Enterprise Structure Configuration: Explained

The Enterprise Structures Configurator (ESC) provides the ability to roll back an enterprise configuration in the following circumstances:

Roll Back a Configuration Manually

You can manually roll back an enterprise configuration after loading it, for example, because you decide you do not want to use it. Clicking the Roll Back Configuration button on the Manage Enterprise Configuration page rolls back any enterprise structures that were created as a part of loading the configuration.

Roll Back a Configuration Automatically

If an error occurs during the process of loading the configuration, then the application automatically rolls back any enterprise structures that were created before the error was encountered.

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 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 company revenue of 120 million US dollars.. Outside the US, InFusion employs 200 people and has revenue of 60 million US dollars.

Analysis

InFusion requires three divisions.

  • The US division covers the US locations.

  • The Europe division covers UK and France.

  • Saudi Arabia and the UAE are 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, 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 has general managers responsible for business units within each country. Those business units may share reference data. Some reference data can be defined within a reference data set that multiple business units may subscribe to. Business units are also required for financial purposes. Financial transactions are always processed within a business unit.

Resulting Enterprise Configuration

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

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

A figure of an enterprise configuration

Divisions: 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 reflect directly the legal structure of the enterprise. The management entities and structure can include:

  • Divisions and subdivisions

  • Lines of business

  • Other strategic business units

  • 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 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 achieving business goals including profits. 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 generally reports to a top corporate executive.

By definition a division can be represented in the chart of accounts. Companies can use 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 permit up to three balancing segments. The values of the management segment can be 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 following rights and responsibilities to:

  • Own property

  • Trade

  • Repay debt

  • 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

  • Minimizing the enterprise's tax liability

  • 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, 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

  • 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), which 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

Use the Enterprise Structures Configurator (ESC), to 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, 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 its enterprise structure. The corporation has 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. These registers are part of the Oracle Fusion Trading Community Architecture.

When your legal entities are trading with each other, represent them as legal entities and 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.

Several decisions you should consider when you create legal entities.

  • The importance of using legal entity on 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 Using Legal Entities on 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, a sales order creates an obligation on the legal entity that books the order to deliver the goods on the acknowledged date. The creation also creates an obligation on 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.

  • 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, Business Unit ACM UK has a default legal entity of InFusion UK Ltd. When a purchase order is placed in ACM UK, the legal entity InFusion UK Ltd is legally obligated to the supplier. Oracle Fusion Procurement, Oracle Fusion Project Portfolio Management, 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 wanted, 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 one segment represents your legal entity to ease your requirement to account for your operations to regulatory agencies, tax authorities, and investors. Accounting for your operations means you must produce a balanced trial balance sheet by legal entity. If you account for many legal entities in a single ledger, you must:

  1. Identify the legal entities within the ledger.

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

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

Represent your legal entities by at least one balancing segment value. You may represent it by two or three balancing segment values if more granular reporting is required. For example, if your legal entity operates in multiple jurisdictions in Europe, you might define balancing segment values and map them to legal reporting units. You can represent a legal entity with 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. This solution is used 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 want to isolate the assets and liabilities for that entity.

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

If your enterprise regularly spins off businesses or holds managers accountable for utilization of assets, identify the business with a balancing segment value. If you account for each legal entity in a separate ledger, no requirement exists to identify the legal entity with a balancing segment value.

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 the portion is not a separate legal entity. If you do not map legal entities sharing the same ledger to balancing segments, you cannot distinguish them using intercompany functionality or track 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 feature to create intercompany entries automatically 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.

Tip: In the Oracle Fusion Supply Chain applications, you can model intercompany relationships using business units, from which legal entities are derived.
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 for 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 has 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 do the following:

  • Assign your business units to one primary ledger. For example, if a business unit is processing payables invoices, then it must post to a particular ledger. This assignment is required for your business units with business functions that produce financial transactions.

  • Use a business unit as a securing mechanism for transactions. For example, if you run your export business separately from your domestic sales business, then 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 provides the following advantages:

  • Enables flexible implementation

  • Provides consistent entity that controls and reports on transactions

  • Shares 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 share reference data, such as payment terms and transaction types, across business units, or you can have each business unit manage its own set depending on the level at which you want 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 legal entities to ensure the uniqueness of sequencing.

In summary, use business units for:

  • Management reporting

  • Transaction processing

  • Transactional data security

  • Reference data sharing and definition

Brief Overview of Business Unit Security

A number of Oracle Fusion Applications use business units to implement data security. You assign roles like Accounts Payable Manager to users to permit them to perform specific functions, and you assign business units for each role to users to give them access to data in those business units. For example, users which have been assigned a Payables role for a particular business unit, can perform the function of payables invoicing on the data in that business unit. Roles can be assigned to users manually using the Security Console, or automatically using provisioning rules. Business Units can be assigned to users using the Manage Data Access for Users task in Setup and Maintenance.

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 one of two levels:

  • Business function level, such as Sales, Consulting, Product Development, and so on.

  • 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. You select the check boxes at the intersections of the two components.

The business units listed by the application are suggestions only, and are meant to simplify the process to create business units. You aren't required to select all of the business units suggested. When you navigate to the next page in the ESC guided flow, the Manage Business Units page, you can't delete any of the business units 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 its enterprise structure. InFusion has 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. As a result, there is a reduction in the administrative burden and the time to implement new business units. For example, you can share sales methods, or transaction types across business units. You may also share certain 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 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 determine that certain aspects of your corporate policy can affect all business units. The remaining aspects are at the discretion of the business unit manager to implement. This allows your enterprise to balance autonomy and control for each business unit. For example, your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level. In such a case, you can let managers define their own sales methods, but define payment terms centrally. In this example:

  • Each business unit has its own reference data set for sales methods.

  • One central reference data set for payment terms is 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 set up 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

Variations exist 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. This method is 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. This method is 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. You need not explicitly assign 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 the following:

    • Transaction types from the set assigned to the business unit.

    • 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 assign Net 15 to a set specific only to your business unit. At transaction entry, the list of values for payment terms consists of only 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 enables you to group set-enabled reference data such as jobs or grades to share the data across different parts of the organization. Sets also enable you to filter reference data at the transaction level so that only data assigned to certain sets is available to be selected. 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 assigned to the Common Set is always available, in addition to the reference data assigned to the set that corresponds to the business unit on the transaction.

Other types of reference data can be specific to certain business units, so you can 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 to use 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 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. They 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 assigns the data to the default set for each business unit. When setting up jobs, they assign the Jobs set and 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 can select data from the set that corresponds to the business unit they enter on the transaction, and any data assigned to the Common Set. For example, for transactions for the Marketing_Japan business unit, grades, locations, and departments from the Mktg_Japan_Set is available to select, as well as from the Common Set.

When using jobs at the transaction level, users can select jobs from the Jobs set and from the Common Set when they enter a sales business unit on the transaction. For example, when a manager hires an employee for the Sales_India business unit, the list of jobs is filtered to show jobs from the Jobs and Common sets.

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

  • Common set

  • 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 includes grade in the:

  • Common set

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

Note the following:

  • The key to using jobs or positions depends on 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. For example, if you hire someone into a new role and want to transfer the position to another department.

During implementation, one of the earliest decisions 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

The following table outlines information about Primary industries and how they set up their workforce.

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

Industry You always replace employees by rehiring to same role You replace the headcount, but the manager can use the headcount in a different job You 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 headcounts, or have high turnover rates.

Retail Industry

ABC Corporation has high turnovers. It loses approximately 5% of its cashiers monthly. The job of the cashier includes three positions: front line cashier, service desk cashier, and layaway cashier. Each job is cross-trained to take over another cashier's 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 Corporation must replace each cashier lost to turnover. Since turnover is high in retail it's better for this industry to use positions.

Note the following:

  • An automatic vacancy is created when an employee terminates employment.

  • The position exists even when there are no holders. Having the position continue to exist 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 the position is empty.

  • You don't have to reassign these employees to another manager or supervisor. The replacement manager is assigned to the existing position.

Also, an added advantage to using Positions is when you hire somebody new, many of the attributes are inherited 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

Health care is an industry that must 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.

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

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.

Jobs setup example

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 to identify additional details about the job, such as the nature of the work that is performed or the relative skill level required. 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. A position belongs 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, consider whether 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. 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 can't set up multiple configurations and compare different scenarios. Using the Enterprise Structures Configurator is the recommended process for setting up your enterprise structures.

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 these levels:

  • Ultimate holding company as the top level

  • Divisions and country holding companies as the second level

  • 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

  • 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 common data is shared or partitioned across business entities to avoid duplication and reduce maintenance effort. 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.

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 can't 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 different business units setting up and using the same grades, XYZ Corporation decides to create a set called Grades, which contains the grades. All business units in the organization have the Grades set so that the grades can be shared and used.

Note: For specific information about configuring reference data sharing for a particular object or product, refer to the relevant product documentation.

Reference Data Sets: Explained

Reference data sets are logical groups of reference data that various transactional entities can use depending on the business context. You can get started using either the common reference data set or the enterprise set depending on your implementation requirement. You can also create and maintain custom reference data sets, while continuing to use the common reference data set.

Consider the following scenario. Your enterprise can decide that only some aspects of corporate policy should affect all business units. The remaining aspects are at the discretion of the business unit manager to implement. This enables your enterprise to balance autonomy and control for each business unit. For example, your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level. Then, you can let managers define their own sales methods, but define payment terms centrally. As a result, each business unit has its own reference data set for sales methods and one central reference data set for payment terms assigned to all business units.

Partitioning

Partitioning reference data and creating data sets provide you the flexibility to handle the reference data to fulfill your business requirements. You can share modular information and data processing options among business units with ease. You can create separate sets and subsets for each business unit. Alternatively, you can create common sets or subsets to enable sharing reference data between several business units, without duplicating the reference data.

The following figure illustrates the reference data sharing method (assignment to one set only, with common values). 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

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. As a result, there is a reduction in the administrative burden and the time to implement new business units. For example, you can share sales methods, or transaction types across business units. You may also share certain 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 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 determine that certain aspects of your corporate policy can affect all business units. The remaining aspects are at the discretion of the business unit manager to implement. This allows your enterprise to balance autonomy and control for each business unit. For example, your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level. In such a case, you can let managers define their own sales methods, but define payment terms centrally. In this example:

  • Each business unit has its own reference data set for sales methods.

  • One central reference data set for payment terms is 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 set up 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

Variations exist 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. This method is 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. This method is 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. You need not explicitly assign 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 the following:

    • Transaction types from the set assigned to the business unit.

    • 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 assign Net 15 to a set specific only to your business unit. At transaction entry, the list of values for payment terms consists of only 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 using 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 the 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 using a business context setting called the determinant type. A determinant type 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 (also called determinant value) is a value that corresponds to the selected determinant type. The determinant is one of the criteria for selecting the appropriate reference data set.

Reference Groups

A transactional entity may have multiple reference entities (generally considered to be setup data). However, all reference entities are treated alike because of similarity in implementing business policies and legal rules. Such reference entities in your application are grouped into logical units called reference groups. For example, all tables and views that define Sales Order Type details might be a part of the same reference group. Reference groups are predefined in the reference groups table.

Items and Supplier Site Reference Data Sharing: Explained

Some products, such as items and supplier sites, required special logic for reference data sharing and have implemented their own domain-specific ways for sharing data.

Items

If you share your items across warehouses or manufacturing facilities, you can access them through a common item master. Configure one or multiple item masters for your enterprise, based your enterprise structure. A single item master is recommended because it provides simpler and more efficient maintenance. However, in rare cases, it may be beneficial to keep multiple item masters. For example, if you acquire another enterprise and want to continue to operate your lines of business separately, maintaining a second item master might be the best decision.

Suppliers Sites

You can approve particular suppliers to supply specified commodities and authorize your business units to buy from those suppliers when the need arises. For example, you might be a household cleaning products manufacturer and need dyes, plastics, and perfumes to make your products. You purchase from a central supplier 70% of your perfume supplies with an additional supplier, in reserve, from whom you purchase the remaining 30%. At the same time, each of your business units purchases plastics and dyes from the same supplier, but from different local supplier sites to save transportation costs.

To implement business unit-specific supplier sites, Oracle Fusion Procurement supports a method for defining suppliers sites as owned and managed by the business unit responsible for negotiating the supplier terms. Your other business units that have a service provider relationship defined with your procurement business unit subscribe to the supplier sites using the supplier site assignments feature. In addition, Procurement allows sharing of the following procurement data objects across business units:

  • Supplier qualification data, such as approved supplier lists

  • Catalog content, such as agreements, smart forms, public shopping lists, and content zones

  • Procurement configuration data

FAQs for Define Reference Data Sharing

What reference data objects can be shared across business units?

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

Application Name Reference Data Object Method of Sharing

Trading Community Model

Customer Account Relationship

Assignment to one set only, no common values allowed

Trading Community Model

Customer Account Site

Assignment to one set only, no common values allowed

Trading Community Model

Salesperson

Assignment to one set only, no common values allowed

Opportunity Management

Sales Method Group

Assignment to one set only, with common values

Work Management

Assessment Templates

Assignment to one set only, with common values

Enterprise Contracts

Contract Types

Assignment to one set only, with common values

Sales

Sales Method

Assignment to one set only, with common values

Common Components

Activity Templates

Assignment to one set only, with common values

Payables

Payment Terms

Assignment to multiple sets, no common values allowed

Receivables

Accounting Rules

Assignment to one set only, with common values

Receivables

Aging Buckets

Assignment to one set only, with common values

Receivables

Auto Cash Rules

Assignment to one set only, with common values

Receivables

Collectors

Assignment to one set only, with common values

Receivables

Lockbox

Assignment to one set only, with common values

Receivables

Memo Lines

Assignment to one set only, with common values

Receivables

Payment Terms

Assignment to one set only, with common values

Receivables

Remit To Address

Assignment to one set only, with common values

Receivables

Revenue Contingencies

Assignment to one set only, with common values

Receivables

Transaction Source

Assignment to one set only, with common values

Receivables

Transaction Type

Assignment to one set only, with common values

Advanced Collections

Collections Setups

Assignment to one set only, with common values

Advanced Collections

Dunning Plans

Assignment to one set only, with common values

Tax

Tax Classification Codes

Assignment to multiple sets, no common values allowed

Human Resources

Departments

Assignment to one set only, with common values

Human Resources

Jobs

Assignment to one set only, with common values

Human Resources

Locations

Assignment to one set only, with common values

Human Resources

Grades

Assignment to one set only, with common values

Project Billing

Project and Contract Billing

Assignment to multiple sets, no common values allowed

Project Foundation

Project Accounting Definition

Assignment to one set only, no common values allowed

Project Foundation

Project Rates

Assignment to one set only, with common values

Order Management

Hold Codes

Assignment to one set only, with common values

Order Management

Orchestration Process

Assignment to one set only, with common values

What reference data objects can be shared across asset books?

The following list contains the reference data objects for Oracle Fusion Assets that can be shared across asset books and the method in which the reference data for each is shared.

Application Name Reference Data Object Method of Sharing

Assets

Bonus Rules

Assignment to one set only, no common values allowed

Assets

Depreciation Ceilings

Assignment to one set only, no common values allowed

Assets

Depreciation Methods

Assignment to one set only, with common values

Assets

Asset Descriptions

Assignment to one set only, no common values allowed

Assets

Property Types

Assignment to one set only, with common values

Assets

Prorate Conventions

Assignment to one set only, no common values allowed

Assets

Asset Queue Names

Assignment to one set only, with common values

Assets

Retirement Types

Assignment to one set only, with common values

Assets

Unplanned Types

Assignment to one set only, with common values

What reference data objects can be shared across cost organizations?

The following list contains the reference data objects for Oracle Fusion Cost Management that can be shared across cost organizations and the method in which the reference data for each is shared.

Application Name Reference Data Object Method of Sharing

Cost Management

Cost Structure

Assignment to one set only, no common values allowed

What reference data objects can be shared across project units?

The following table contains the reference data objects for Oracle Fusion Project Foundation that can be shared across project units and the method in which the reference data for each is shared.

Application Name Reference Data Object Method of Sharing

Project Foundation

Project Definition

Assignment to multiple sets, no common values allowed

Project Foundation

Project Transaction Types

Assignment to multiple sets, no common values allowed

Define Enterprise: Manage Enterprise HCM Information

Enterprise: Explained

An enterprise is a collection 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. 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 create and manage locations using the Manage Locations task in the Workforce Structures work area.

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

Note the following:

  • 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

Uploading Locations Using a Spreadsheet

If you have a list of locations already defined for your enterprise, you can upload them from a spreadsheet.

To use this option:

  • Download a spreadsheet template

  • Add your location information to the spreadsheet

  • 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 you created for the geographic node start to apply for the location and may impact the availability of worker assignments at that location. You manage locations using the Manage Locations task in the Workforce Structures work area.

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 Oracle Fusion Global Human Resources, go to the Manage Locations page. Use the Manage Locations task in the Workforce Structures work area.

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

This topic describes geography structures and the tasks you can perform using geography structures.

A geography structure is a hierarchical grouping of geography types for a country. For example, the geography structure for the United States is as follows:

Level Geography Type

1

State

2

County

3

City

4

Postal Code

You can use the geography structure to relate geography types for a country and define geography types for a country.

Relate Geography Types for a Country

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 geography type Country is implicitly at the top of the geography structure with the level 1. The subsequent geography types that you add after country are numbered in sequence.

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. To quickly create country structure, you can copy a structure from another country and modify the geography types for the country.

Define Geography Types for a Country

You can use any of the master reference geography types to create your geography structure. 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: You cannot delete geography types that have associated geography data. You can only delete the lowest level geography type of the country structure.

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

Geography Hierarchy: Explained

This topic describes geography hierarchy and various aspects of geography hierarchy.

Geography hierarchy is a data model that creates conceptual parent-child relationships between geographies. The top level of the geography hierarchy is country, which is the parent, and the hierarchy contains several child geographies. The following table shows sample parent-child relationships in a geography.

California Parent of San Mateo county

San Mateo County

Parent of Redwood City

Redwood City

Parent of 94065

94065

Child

When you enter just 94065, the application determines that the postal code is in California and the corresponding city is Redwood City.

The application uses geography hierarchy information to facilitate business processes that rely on geography information, such as, tax calculation, order sourcing rules, and sales territory definition. The geography hierarchy information is centrally located and shared among other application offerings.

The geography hierarchy includes:

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

  • Geography type: Geography types are divisional grouping of user defined geographies, for example, Continent, Country Regions, and Tax Regions.

  • Geography usage: Geography usage indicates how a geography type or geography is used in the application.

  • Master reference geography hierarchy: The geography hierarchy data is considered the single source of reference for all geography related data such as geography types and geographies.

    The geography usage for the entire hierarchy is the master reference, and defined geography types and geographies are the master reference geography types and geographies. For example, you can create geography types called State, City, and Postal Code. Then, you can rank the State as the highest level, City as the second level, and Postal Code as the lowest level within the country structure.

  • User defined zones: User defined zones are a collection of geographical data, created from master reference data for a specific purpose. For example, while the territory zones are collections of master reference geographies ordered with a hierarchy, the tax and shipping zones are without a hierarchical grouping.

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. If the setup for master geography data is incomplete, then the geography data is either not imported or created. As a result, the list of values for the address attribute does not list any geography data.

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.

The Geography Dimension value in territories is derived from sell-to addresses of sales accounts. To use geography dimensions in territories, you must validate the geography elements in the addresses, such as state, city, and postal code. You can validate the address by enabling geography validation for each country using the Manage Geographies task. Perform the following in the Manage Geographies task:

  • Enable at least one level in the geography hierarchy for geography validation.

  • Enable geography validation for all geography levels that you intend to use for territory definition for each country.

  • If needed, enable a list of values containing specific geography elements. This will help users search and select appropriate geography values during addresses entry and eliminate all possibilities of wrong address entry.

You can set geography validation control to Error in the Manage Geography Validation page. This ensures that users can only use valid geography elements in addresses.

Note: If you have already created addresses before setting up geography validation for a country, you must enabling geography validation and then execute the Run Maintain Geography Name Referencing task for that country. This validates all your geography elements.

Managing Geography Structures, Hierarchies, and Validation: Worked Example

This example shows how to configure the geography structure, hierarchy, and validation for a country geography, using the United Kingdom country geography as an illustration.

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:

  1. County

  2. Post Town

What is the geography hierarchy?

Create the following hierarchy:

  1. Country of United Kingdom

  2. County of Berkshire

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

Defining the Geography Structure

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

  1. On the Manage Geographies page, enter GB in the Code field. Click Search.

  2. On the Manage Geographies page, click Structure Defined.

  3. On the Manage Geography Structure page, click the Create button next to the Copy Country Structure From field.

  4. In the Geography Structure section, select the County list item in the Add Geography Type field.

  5. Click Add.

  6. Select the Post Town list item in the Add Geography Type field.

  7. Click Add.

Defining the Geography Hierarchy

To create the geography hierarchy for United Kingdom, 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.

  1. On the Manage Geographies page, enter GB in the Code field. Click Search.

  2. On the Manage Geographies page, click Hierarchy Defined.

  3. In the Geography Hierarchy section, click United Kingdom to highlight the table row, and click Create.

  4. In the Create County page, Primary and Alternate Names section, enter Berkshire in the Name field.

  5. Click Save and Close.

  6. In the Geography Hierarchy section, click Berkshire to highlight the table row, and click Create.

  7. In the Create Post Town page, Primary and Alternate Names section, enter Reading in the Name field.

  8. Click Save and Close.

Defining the Geography Validations

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

  1. On the Manage Geographies page, click Validation Defined.

  2. In the Address Style section, click No Styles Format to highlight the table row.

  3. For the County geography type, click the County list item in the Map to Attribute field.

  4. Select the Enable List of Values and Geography Validation options.

  5. For the Post Town geography type, click the City list item in the Map to Attribute field.

  6. Select the Geography Validation option.

  7. In the Geography Validation Control section, select Error in the Geography Validation Level for Country list.

  8. Click Save and Close.

Geocoding: Explained

This topic explains geocoding and how to enable this option in the application.

Geocoding is the process of finding latitude and longitude coordinates from geographic data such as street addresses or zip codes. Once these coordinates are available, you can use the spatial services feature to identify points of interest, such as customer and contact addresses, in the vicinity. The application integrates the Geocoding feature with eLocation (http://elocation.oracle.com/maps_oracle_dot_com_main.html), which is a Geocoding service provided by Oracle.

By default, the Geocoding option is turned off in the application. You can enable the Geocoding option in the Setup and Maintenance, Manage Geographies page.

If the Geocoding feature is enabled, the feature can be scheduled to run at regular time intervals. This ensures that newly created or updated locations are picked up and geocoded whenever you create or update an address using the user interface, web services, bulk import, or file-based import.

Setting Up Geocoding: Procedure

This procedure lists the steps to set up geocoding in Oracle applications.

Geocoding is a process that determines the latitude and longitude coordinates for a location. By default, geocoding is turned off in the application. You can use geocoding to display customers in the vicinity of a mobile address.

Enabling Geocoding for a Country

To enable geocoding for a country, complete these steps:

  1. From the Setup and Maintenance work area, search for Manage Geographies and click Go to Task.

  2. Search the country for which you want to enable geocoding. You can either search by the country name or country code.

  3. Click Search. The search results for the matching country names are displayed.

  4. Select the country for which you want to enable the geocoding option.

  5. Select Geocoding Defined for the country.

Populating Location Latitude and Longitude Information

Once geocoding is enabled, you can schedule this feature to run at regular time intervals so that newly created or updated locations are picked up and geocoded. To schedule the geocoding feature to run at regular intervals, complete these steps:

  1. Navigate to the Scheduled Processes work area, and click Schedule New Process.

  2. Click the Name drop-down and search for Populate Location Latitude and Longitude Information, and then click OK.

  3. Enter the parameters such as Start Date and End Date, and click Submit.

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:

  • Nokia geography reference data

  • File-based import option

  • Geography loader process option

  • Import object entity, interface table, and destination tables

Nokia Geography Reference Data

Oracle Sales Cloud includes third-party (Nokia) master geography data for multiple countries that can be easily imported. You can import Oracle-licensed Nokia data from Navteq, for those countries where the data is available, such as the U.S. You can import Nokia Geography data using the Manage Geographies task. Search for the country, and select Import Nokia Data from the Actions menu. If the licensed Navteq data is not available for a particular country, then the Import Nokia Data action is disabled.

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.

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

Nokia Geography Reference Data: Explained

Oracle Sales Cloud includes third-party Nokia master geography data that is available for import for the following countries.

Country Name Country Code

1.

Andorra

AD

2.

Argentina

AR

3.

Austria

AT

4.

Belgium

BE

5.

Brazil

BR

6.

Bulgaria

BG

7.

Canada

CA

8.

Cayman Island

KY

9.

Chile

CL

10.

Croatia

HR

11.

Czech Republic

CZ

12.

Denmark

DK

13.

Dominican Republic

DO

14.

Estonia

EE

15.

Finland

FI

16.

France

FR

17.

Germany

DE

18.

Greece

GR

19.

Guadeloupe

GP

20.

Hungary

HU

21.

Iceland

IS

22.

India

IN

23.

Indonesia

ID

24.

Ireland

IE

25.

Isle of Man

IM

26.

Israel

IL

27.

Italy

IT

28.

Jamaica

JM

29.

Latvia

LV

30.

Liechtenstein

LI

31.

Lithuania

LT

32.

Luxembourg

LU

33.

Malaysia

MY

34.

Malta

MT

35.

Martinique

MQ

36.

Mexico

MX

37.

Netherlands

NL

38.

New Zealand

NZ

39.

Norway

NO

40.

Peru

PE

41.

Poland

PL

42.

Portugal

PT

43.

Puerto Rico

PR

44.

Reunion Island

RE

45.

Romania

RO

46.

Russian Federation (Russia)

RU

47.

San Marino

SM

48.

Slovakia

SK

49.

Slovenia

SI

50.

South Africa

ZA

51.

Spain

ES

52.

Swaziland

SZ

53.

Sweden

SE

54.

Switzerland

CH

55.

Taiwan

TW

56.

Turkey

TR

57.

United Kingdom

GB

58.

United States

US

59.

Uruguay

UY

60.

Holy See (Vatican City State)

VA

Replacing Existing Master Geography Data with Revised Nokia Geography Data: Procedure

You must import and set up reference geography data for the countries where you do business. Using the Nokia geography reference data, you no longer have to source geography data from a third party. You can import Oracle-licensed Nokia data from NAVTEQ, including the country structure and hierarchy information, either to create a new geography setup or replace your existing geography data.

This topic describes the steps to replace your existing master geography data with the revised Nokia geography data.

Creating an Export File of All Territories

You must export all territories before deleting the master geography data because removing the master geography data invalidates the territory definitions that are based on the Geography dimension. You can either export the definitions of all territories to a file or make manual corrections. If there are a large number of territories, export the territories definition to a file that can be used during the territories import process. However, if there are very few affected territories, then you can choose to either export the territories definition to a file or make corrections manually.

This procedure is applicable only if there are territories defined using the Geography dimension.

Perform the following steps to create an export file of all territories.

  1. From the Territories and Quotas work area, click View Active Territories in the Tasks pane.

  2. In the View Active Territories page, select the top territory.

  3. Click the Actions drop-down list, and select Export, and then Export Selected Territory Hierarchy.

  4. In the Warning dialog box, click OK.

  5. Click the Actions drop-down list and select Export, and then View Export Status.

  6. Review the status of the export job and verify if it has completed successfully.

  7. In the Exported Data File column, click the .zip file against your export job, and click Save. All the territories are exported to a compressed file on your system.

  8. Click OK.

  9. Click Done in the View Active Territories page.

Deleting the Territory Geography Data

A territory definition has references to the territory geography data and master geography data. Since territory geography data is based on the master geography data, you must delete the territory geography data prior to deleting the master geography data. When you delete the territory geography data, all territories that are defined using geography dimension become invalid.

This procedure is applicable only if territory geographies are defined.

Perform the following steps to delete the territory geography data.

  1. From the Setup and Maintenance work area, search for Manage Territory Geographies and click Go to Task.

  2. In the Manage Territory Geographies page, click View All Hierarchies.

  3. Select the top node for the country for which you want to replace the master geography data and click the Delete icon.

  4. In the Warning dialog box, click OK.

  5. In the Confirmation dialog box, click OK. The parent node of the territory geography data and its children are deleted.

  6. Repeat steps 3 to 5 to delete all top nodes in the territory geography data.

  7. Click Save and Close.

Although the territory geography data is deleted, the territory definitions may appear to remain valid. This is because the Territory Management application retains a copy of the dimension members referenced in the territory definitions. This copy is updated when you trigger the Load and Activate process from the Enable Dimensions and Metrics task.

Deleting the Master Geography Data

To delete the master geography data for a country, you must create a support request with proper justification. Note that when the master geography data is deleted, the geography and its children are deleted and all the related territory, tax, and shipping zone references become invalid. So you must take backup of these before deleting the master geography data.

Importing Nokia Geography Reference Data

Use this procedure to import Nokia geography reference data licensed by Oracle. If the country data you want to import is not available, then the Import Nokia Data action is disabled.

The geography data is provided by Nokia and is third-party content. As per Oracle policy, this software and documentation may provide access to or information about content and services from third parties. Oracle and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content and services. Oracle and its affiliates are not responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Perform the following steps to import Nokia geography reference data. Currently, the revised Nokia geography reference data is available only for US at this time.

  1. From the Setup and Maintenance work area, search for Manage Geographies, and click Go to Task.

  2. In the Manage Geographies page, enter either the country name or the two-letter ISO code (for example, US), and click Search.

  3. Select the country in the search results.

  4. Click the Actions drop-down list, and select Import Nokia Data.

  5. In the Warning dialog box, click OK.

  6. In the Confirmation dialog box, click OK.

The import of larger countries may require several hours to complete.

You can track the progress of the import process by selecting Scheduled Processes from the Navigator menu.

Note: To access the Scheduled Processes work area, you must be signed in as a user with the Employee abstract role. The initial user does not have this role assigned, but the other users you created do.

After the import is complete, you can search for the country again in the Manage Geographies page. Check marks now appear in the Structure Defined and Hierarchy Defined columns indicating the import completed successfully.

Geography import complete.

Next, click the Validation Defined icon to define the validations, enable List of Values, and choose address style format for a country as set up before. For more information, see the "Geography Validation: Explained" topic.

The Geocoding Defined and Address Cleansing Defined columns are used for additional features which you must license from Oracle and set up separately.

  • Geocoding makes it possible to display customers in the vicinity of a mobile address. You set up Geocoding Enabled for those countries where you are using Around Me functionality in Sales Cloud Mobile.

  • Cleansing makes it possible to validate addresses down to the street level.

Running the Geography Name Referencing Process

The Geography Name Referencing (GNR) process validates address elements in location tables, such as HZ_LOCATIONS, against the master geography data.

Perform the following steps to run the GNR process.

  1. Navigate to the Scheduled Processes work area, and click Schedule New Process.

  2. Click the Name drop-down list and search for Validate Geographies Against Master Geographies, and then click OK.

  3. Click OK in the Schedule New Process dialog box.

  4. In the Process Details dialog box, enter the following details:

    • Location Table Name: HZ_LOCATIONS

    • Run Type: ALL

    • Usage Code: GEOGRAPHY

  5. Enter the country code in the Country Code field.

  6. Click Submit.

  7. In the Confirmation dialog box, click OK.

  8. Click Close.

  9. In the Scheduled Processes page, click the Refresh icon.

  10. Verify if the status of the process has completed successfully.

Recreating and Loading the Territory Geography Data

You can recreate the territory geography data, after the master geography data is imported, using either of the following methods:

  • Import process: If you created the original territory geography data using the import process, then use the same import file to recreate the territory geography structure.

    For more information about importing the territory geography data using the import file, see "Importing Territory Geography Hierarchies Using File-Based Data Import: Quick Start" in the Oracle Sales Cloud Understanding File-Based Data Import and Export guide.

  • Manual creation process: You can manually recreate the territory geography data structures, as they existed before their deletion, using the Manage Territory Geographies task.

    For more information about creating zones and adding geographies to a zone, see "Managing Territory Geographies: Worked Example" topic.

After you have recreated the territory geography data, perform the following steps to load the data.

  1. From the Setup and Maintenance work area, search for Enable Dimensions and Metrics, and click Go to Task.

  2. In the Enable Dimensions and Metrics page, click the Actions drop-down list, and select Load and Activate. The process loads the territory geography data to make dimension members available for selection when defining territories.

  3. In the Confirmation dialog box, click OK.

  4. Click Done.

Restoring the Invalid Territory Definitions

After recreating the territory geography hierarchies and running the Load and Activate option from the Enable Dimensions and Metrics task, the geography dimensions are populated with the new geography members. The geography members in the territory appear as invalid because your territories still reference the old copies of the dimension members that were deleted. The new members are not referenced automatically by the territories. You must re-reference the territory definitions from the old geography dimension members to the new ones.

You can restore the invalid territory definitions by either importing the previously created export file or making manual corrections to the territories.

  • Restoring Valid Territory Definitions Using Territories Import

    1. Open the export file you saved in the "Creating an Export File of All Territories" step. The compressed file contains four CSV files.

    2. Open TERR_HEADER.CSV file.

    3. Enter REPLACE in the Action column for all territories that are based on geography dimension.

    4. Save the file in CSV format and compress it together with three other CSV files.

    5. From the Territories and Quotas work area, click View Active Territories in the Tasks pane.

    6. Click the Actions drop-down list, and select Import to Proposal, and then Import Territories.

    7. Select the newly created compressed file and click OK.

    8. Click the Actions drop-down list and select Import to Proposal, and then View Import Status.

    9. Review the status of the export job and verify if it has completed successfully.

    10. Click OK.

    11. From the Tasks pane, click Manage Territory Proposals.

    12. In the Manage Territory Proposals page, under Current Territory Proposals table, search for the proposal with your import file name.

    13. Click the import file name to open the territory proposal.

    14. Click Edit Coverage to verify that the territory definitions are valid.

    15. Verify that there are no values listed as invalid in the Selected Dimension Members section.

    16. Click Save and Close.

    17. Click Activate. The territory proposal of your import file is activated.

  • Restoring Valid Territory Definitions through Manual Corrections

    Although this method is always applicable, it is most appropriate when you have to restore territory definitions for a smaller number of territories.

    1. From the Territories and Quotas work area, click Manage Territory Proposals in the Tasks pane.

    2. In the Manage Territory Proposals page, click the Create icon.

    3. In the Create Territory Proposals dialog box, enter a name and click Save and View.

    4. In the Territory Proposals page, add all the territories with the Geography dimension value other than the value "Any" to the proposal.

    5. Select a territory and click Edit Coverage.

    6. In the Edit Coverage page, select Geography from the Dimensions drop-down list. The invalid dimension members are displayed in the Selected Dimension Members pane.

    7. Expand the values in the Available Dimension Members section or search for the member that has the same name as the one marked invalid in the Selected Dimension Members pane.

    8. Select one or more new geography dimension members from Available Dimension Members pane and click Add icon to the Selected Dimension Members pane.

    9. Click the Remove icon to remove the invalid members from the Selected Dimension Members pane.

    10. Click Save and Close.

    11. Repeat steps 4 to 10 for all territories that were based on Geography dimension.

    12. Click Activate. After the activation process is complete, your territory definitions are valid again and are referencing to the new geography data.

  • Running Batch Assignment Process for Opportunities

    1. From Navigator, click Scheduled Processes.

    2. In the Schedule Processes page, click Schedule New Process.

    3. In the Schedule New Process dialog box, search for the Revenue Territory Based Assignment process and select it.

    4. Click OK.

    5. In the Process Details dialog box, enter OpenOpportunitiesByCreationDate in the View Criteria Name field. This selects all revenue lines belonging to open opportunities that were created in the last 'X' days.

    6. Enter BindOptyCreationDateFrom= followed by the date.

      For example, if BindOptyCreationDateFrom=2014-01-01, then all open opportunities which were created between 1st January 2014 till the current date, are processed.

    7. Click Submit to schedule the process.

    8. In the Confirmation dialog box, make a note of the process identifier for monitoring the process, and click OK.

    9. Click Close.

    10. In the Schedule Processes page, click the Refresh icon.

    11. Review the status of the process job and verify if it has completed successfully.

      Note: Review a small subset of the open opportunities to confirm that the territory assignment is as expected.
  • Running Batch Assignment Process for Sales Accounts

    1. Ensure that the ZCA_SA_AUTO_ASSIGN_ON_CREATE and ZCA_SA_AUTO_ASSIGN_ON_UPDATE profile options are set to Yes in the Manage Customer Center Profile Options task.

    2. From Navigator, click Customers.

    3. In the Customers page, click Create Account.

    4. In the Create Account page, enter a name and address of the sales account, and select the Address is sell to check box.

    5. Click Save and Close.

    6. From Navigator, click Customers.

    7. In the Search pane, search for the name of the sales account you created and select it.

    8. Under Customer Information, select Sales Account Team. The details of the sales account and territories associated with the sales account are displayed.

      This indicates that the sales account was created successfully and the batch assignment was run automatically to assign the matching territories to the sales account.

    To run the batch assignment process manually from the Scheduled Processes page, perform the following steps.

    1. From Navigator, click Scheduled Processes.

    2. In the Schedule Processes page, click Schedule New Process.

    3. In the Schedule New Process dialog box, search for the Request Sales Account Assignments process and select it.

    4. Click OK.

    5. Enter SalesAccount_Work_Object in the Work Object Code field and SalesAccountTerritory_Candidate_Object in the Candidate Object Code field.

    6. Select Territory in the Assignment Mode list.

    7. Enter AllSalesAccountsVC in the View Criteria Name field. This selects all sales accounts.

    8. Click Submit to schedule the process.

    9. In the Confirmation dialog box, make a note of the process identifier for monitoring the process, and click OK.

    10. Click Close.

    11. In the Schedule Processes page, click the Refresh icon.

    12. Review the status of the process job and verify if it has completed successfully.

      Note: Review a small subset of the accounts to confirm that the territory assignment is as expected.

Creating Countries: Procedure

This procedure lists the steps to create countries in Oracle Sales Cloud.

In Oracle Sales Cloud, countries are pre-seeded. If you are unable to find a specific country in the Manage Geographies page, then you can add it to the application.

Note: Oracle Sales Cloud provides support for Nokia geography data for 60 countries. For more information on the list of countries, see the Nokia Geography Reference Data: Explained topic.

For countries where Nokia geography data is not available, you can purchase the geography data from a third-party data provider and load it into the application using File-Based Data Import. For more information, see the Importing Geographies chapter in the Oracle Sales Cloud Understanding File-Based Data Import and Export guide.

If countries are not available in the application, then use the procedure outlined in this topic to create them.

Perform the following steps to create a new country.

  1. From the Setup and Maintenance work area, search for Manage Territories and click Go to Task.

  2. Click the New icon.

  3. Enter the following details:

    • Territory Code: Enter a unique code for the territory.

    • Territory Name: Enter a unique name for the territory.

    • Description: Enter a description for the territory.

  4. Click Save and Close.

    Note: After you have added a new country in the application, if you want to import the geography data for that country, then you must perform Step 5 to 10.
  5. From the Setup and Maintenance work area, search for Manage Geographies and click Go to Task.

  6. In the Manage Geographies page, enter either the country name or the two-letter ISO code for the country you just added, and click Search.

  7. Select the country in the search results.

  8. Click the Actions drop-down, and select Create Country.

  9. In the Create Country dialog box, select the name of the country and click Save.

  10. Click Done.

Importing Geographies Using File-Based Import: Explained

This topic explains how to prepare and import geography data from an external data source using the File-Based Data Import feature. A geography is any region with a boundary around it, regardless of its size. It might be a state, a country, a city, a county, or a ward. You must create or import geographies before you can associate them with custom zones and addresses.

Note: The application ships with third-party (Nokia) master geography data for multiple countries that can be easily imported. You can import Oracle-licensed Nokia data from Navteq, for those countries where the data is available, such as the U.S. You can import Nokia Geography data using the Manage Geographies task. Search for the country, and select Import Nokia Data from the Actions menu. If the licensed Navteq data is not available for a particular country, then the Import Nokia Data action is disabled. For more information, see Replacing Existing Master Geography Data with Revised Nokia Geography Data: Procedure.

If Nokia geography data is not available for a country, then use the information in this chapter to import it using File-Based Data Import.

Consider the following questions when importing your data:

  • How does your legacy system or source system represent the geography data compared to how Oracle applications represent the same data?

  • Do you have to configure values in the application to map to your data values?

  • What import features are available for importing your business object?

  • How do you verify your imported data?

Comparing Business Object Structures

You must understand how your geography data corresponds with the data in the application so that you can map your legacy data to the data that the application requires. First, you must understand how the application represents the structure of the data for a geography.

You must import a separate country structure import object for each country. Each of these import objects must contain the geography types that are used in the country's structure, organized in a hierarchy using geography level numbers. For example, if you are importing the country structure of Australia, the country structure could be the following: 1: Country, 2: State, 3: County, 4: Town, 5: ZIP.

Import Objects for the Geography

To facilitate importing geographies, the application incorporates the structure of the geography into import objects. The import object for the geography is ImpGeography.

Comparing Business Object Data

Each import object is a collection of attributes that helps to map your data to the application data and to support one-to-many relationships between the structural components that make up the geography.

You must understand the attribute details of the import objects so that you can prepare your import data. You can use reference guide files that contain attribute descriptions, values that populate attributes by default when you do not provide values, and validation information for each import object attribute. The validation information includes the navigation path to the task where you can define values in the application. For example, if you have values in your data that correlate to a choice list in the application, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.

Import Object Related Import Object Topic

ImpGeography

Geography Import Objects: How They Work Together

Note:

You can use the keyword importing geographies to search for related topics in Help.

Extensible Attributes

The application doesn't support extensible attributes for geographies. You can import only data for geography object that already exist by default in the application.

Importing Geographies Using File-Based Data Import

For the geography business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for a file-based import. The file-based import process reads the data in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.

The Define File-Based Data Import Setup and Maintenance task list includes the tasks that are required to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When you're creating a new geography, you import the Geography object. You must be assigned the Master Data Management Administrator job role to access and submit the import activities for geographies.

When importing geography information, you must provide the parent reference information for all parent levels for the entity.

Verifying Your Imported Data

Oracle applications provide File-Based Import activity reports, which you can use to verify imported data. Users with the Master Data Management Administrator job role can also navigate to the Manage Geographies work area to view the imported geographies.

Geography Import Objects: How They Work Together

This topic describes the Geography import object. You use the Geography import object to import geography information.

This topic introduces the following:

  • Target objects for the Geography import object

  • Target import object attributes

  • Reference guide files for target import object attributes

Geography Target Import Objects

You can use the Geography import object to import geography hierarchy information to create or update the geography data of a country. To map the source data in your import file to the target attributes in the application, you must understand how the target objects are related and what attributes are included in each target object.

The target import objects in the Geography import object contain information about the geography hierarchy. When updating an existing geography, you must provide the parent reference information of the existing geography, which connects the geography to the country of which it is a part.

Use the ImpGeography target import object to create and update geography information.

Note: Before you import geography data for a country, you must define the country's geography structure.

Target Import Object Attributes

You must compare the attributes that you want to import with the target object attributes that are available and with their valid values. To evaluate your source data and Oracle Sales Cloud attributes for mapping and validation, you use a reference file. See the File Based Data Import for Oracle Sales Cloud guide available on the Oracle Sales Cloud Help Center (https://docs.oracle.com/cloud/latest/salescs_gs/docs.htm). In the File Based Data Imports chapter, see the topic for your import object of interest, which includes links to reference files for target import objects. A reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or prerequisite setup tasks that are required.

To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the Manage File Import Mappings task, or you can define the mapping when you define the import activity using the Manage File Import Activities task. Both tasks are available in the Setup and Maintenance work area.

Note: If any of the attributes you want to import do not have an equivalent target object attribute, then review the Application Composer extensibility features for geography.

Reference Files for Target Import Object Attributes

To access the reference guide files for the geography's target import objects, see the File Based Data Import for Oracle Sales Cloud guide available on the Oracle Sales Cloud Help Center (https://docs.oracle.com/cloud/latest/salescs_gs/docs.htm). In the File Based Data Imports chapter, see the topic for your import object of interest, which includes links to reference files for target import objects. For detailed information on importing geographies using file-based import, refer to Document No. 1481758.1, Importing Master Reference Geography Data, on the Oracle Support site.

The following table lists the reference files that are available by target import object.

Target Import Object Description Attribute Reference Guide File Names

ImpGeography

Contains information that captures a country's geography hierarchy details, such as geography type, geography code, etc.

HZ_IMP_GEOGRAPHIES_T _Reference

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 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 real time address validation and tax purposes.

The following table summarizes the key decisions that you must make in 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 the application?

All, except for the RecordTypeCode field

When do you want to process the import?

Immediately

Summary of the Tasks

You perform the following steps to create an import activity and activate the import:

  1. Determining what information is in the source file.

  2. Creating and scheduling the import activity.

  3. Monitoring the import results.

Prerequisites for Importing Additional Geography Data After Your Initial Import

  1. Ensure that the combination of the Source ID and Parent Source ID values is unique for each row of data within a single import. However, your source data files don't 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, then the changed IDs will not affect the import.

  2. Ensure that all 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 must include US, CA, and San Jose.

  3. 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, then your geography import creates two state records (CA and California) in the application data, with the US as the country parent.

Determining What Information is in the Source File

  1. The source geography data files must include a unique Source ID value for each row of data and Parent Source ID value for the parent of that row of data. The Source or Parent Source IDs should not be longer than 18 characters.

  2. You can structure your geography source data 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

Creating and Scheduling the Import Activity

You can create an import activity, enter the import details, and schedule the import. An import activity includes selecting the source file or file location, mapping the source file to the database, and scheduling the import.

  1. In the Setup and Maintenance work area, search for the Manage File Import Activities task. Click Go to Task.

  2. In the Manage Import Activities page, click Create.

  3. In the Create Import Activity: Map Fields page, map each field from your source file to the target object and attribute, as shown in the following 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.

  4. Click Next.

  5. In the Create Import Activity: Map Fields page, map each field from your source file to the Oracle Sales Cloud database object and attribute, as shown in the following table.

    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 don't want to import a column in the text file, then you can select Ignore.

    Note: If you can't map the fields from your source file to the relevant target object, then see the import object spreadsheets.

  6. Click Next.

  7. In the Create Import Activity: Create Schedule page, select Immediate in the Schedule field so that the import will start as soon as you activate it.

    Instead of immediately importing the data, you can choose a date and time to start the import. You can also specify whether the import will be repeated and the frequency of the repeated import.

  8. Click Next.

Monitoring the Import Results

You can monitor the processing of the import activity and view the completion reports for both successful records and errors.

  1. In the Create Import Activity: Review and Activate page, verify your import details in the Import Details, File Details, Import Options, and Schedule sections. Update the import details if required by navigating to the previous screens using the Back link.

  2. Confirm your import details, and click Activate to submit the import.

    After the import activity has finished, the Status field value changes to Completed.

Importing Country Structures Using File-Based Import: Explained

This topic explains how to prepare and import country structure data from an external data source using the File-Based Data Import feature. A country structure is a hierarchical grouping of geography types for a country. For example, the geography structure for the United States has the geography type of State at the top, followed by the County, then the City, and finally the Postal Code.

You can use the country structure to set up the following:

  • The relationships between geographies within a country

  • The types of geographies that you can define for a country

Consider the following questions when importing your data:

  • How does your legacy system or source system represent the geography data compared to how the application represents the same data?

  • Do you have to configure values in the application to map to your data values?

  • Do you have to customize the application to capture additional attributes that are critical to the way you do business?

  • What import features are available for importing your business object?

  • How do you verify your imported data?

Comparing Business Object Structures

You must understand how your country structure data corresponds with the data in the application so that you can map your legacy data to the data that the application requires. First, you must understand how the application represents the structure of the data for a country structure.

You must import a separate country structure import object for each country. Each of these import objects must contain the geography types that are used in the country's structure, organized in a hierarchy using geography level numbers. For example, if you're importing the country structure of Australia, the country structure could be the following: 1: Country, 2: State, 3: County, 4: Town, 5: ZIP.

Import Objects for the Country Structure

To facilitate importing country structures, the application incorporates the structure of the country structure into import objects. The import object for country structures is GeoStructureLevel.

Comparing Business Object Data

Each import object is a collection of attributes that helps to map your data to the application data and to support one-to-many relationships between the structural components that make up the country structure.

You must understand the attribute details of the import objects so that you can prepare your import data. . You can use reference guide files that contain attribute descriptions, values that populate attributes by default when you don't provide values, and validation information for each attribute. The validation information includes the navigation path to the task where you can define values in the application. For example, if you have values in your data that correlate to a choice list in the application, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.

Import Object Related Import Object Topic

Country Structure

Country Structure Import Objects: How They Work Together

Extensible Attributes

If you need to extend the application object to import your legacy or source data, you must use Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.

Importing Country Structures Using File-Based Data Import

For the country structure business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for a file-based import. The file-based import process reads the data in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.

The Define File-Based Data Import Setup and Maintenance task list includes the tasks that are required to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When you're creating a new country structure, you import the Country Structure object. You must be assigned the Master Data Management Administrator job role to access and submit the import activities for country structures.

Verifying Your Imported Data

You can view the list of import activities from the Manage Import Activities page. You can verify your imported data by clicking the Status column for your import activity.

Country Structure Import Objects: How They Work Together

This topic describes the Country Structure import object. You use the Country Structure import object when you submit a file-based import activity to import your country structure information. This topic introduces the following:

  • Target objects for the Country Structure import object

  • Target import object attributes

  • Reference guide files for target import object attributes

Country Structure Target Import Objects

The Country Structure import object contains one target import object. The target import object organizes the individual attributes of the different aspects of the geography structure. When updating an existing country structure, you must provide the parent reference information of the existing country structure. This reference information connects the imported geography structure to the existing one. Use the ImpGeoStructureLevel target import object to create and update country structure information.

Target Import Object Attributes

You must compare the attributes that you want to import with the target object attributes that are available and with their valid values. To evaluate your source data and Oracle Sales Cloud attributes for mapping and validation, you use a reference file. See the File Based Data Import for Oracle Sales Cloud guide available on the Oracle Sales Cloud Help Center (https://docs.oracle.com/cloud/latest/salescs_gs/docs.htm). In the File Based Data Imports chapter, see the topic for your import object of interest, which includes links to reference files for target import objects. A reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or prerequisite setup tasks that are required.

To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the Manage File Import Mappings task, or you can define the mapping when you define the import activity using the Manage File Import Activities task. Both tasks are available in the Setup and Maintenance work area.

Note: If any of the attributes you want to import does not have an equivalent target object attribute, then review the Application Composer extensibility features for country structures.

Reference Files for Target Import Object Attributes

To access reference files for this object's target import objects, see the File Based Data Import for Oracle Sales Cloud guide available on the Oracle Sales Cloud Help Center (https://docs.oracle.com/cloud/latest/salescs_gs/docs.htm). In the File Based Data Imports chapter, see the topic for your import object of interest, which includes links to reference files for target import objects.

For detailed information on importing geographies using file-based import, refer to Document No. 1481758.1, Importing Master Reference Geography Data, on the Oracle Support site.

The following table lists the reference files that are available by target import object.

Target Import Object Description Reference Guide File Names

ImpGeoStructureLevel

Information that specifies a country's geography structure.

HZ_IMP_GEO_STRUCTURE _LEVELS_Reference

Importing and Exporting Territory Geography Zones: Explained

Territory geography zones are geographical boundaries that you can set up to replicate your organization's regions, such as a Pacific Northwest sales region. You can set up territory geography zones in one application instance, and then after the territory geography zones are defined you can export the territory zones and import them into another application instance.

To define your territory geography zones and then import your territory zones into another application instance, you must complete the following steps:

  1. Import the master reference geography data into the application.

  2. Define your territory geography zones using the Manage Territory Geographies task.

  3. Export the territory geography zones.

  4. Import the territory geography zones into another application instance.

Import the master reference geography data

Firstly, you need to import the master reference geography data. Master reference geography data consists of geography elements such as country, state, and city, and is required for any geographical information you store in the application, such as address information used in customer and sales records. For more information, refer to the Geography Hierarchy: Explained topic listed in the related topics section. Master reference geography data can be imported into the application using the Manage File Import Activities task in Setup and Maintenance - refer to the Importing Master Reference Geography Data: Worked Example topic listed in the related topics section for more information.

Define your territory geography zones

Once the master reference geography data has been imported, you can then create your territory geography zones in the application using the Manage Territory Geographies task in Setup and Maintenance. For more information, refer to the Managing Territory Geographies: Worked Example topic listed in the related topics section.

Export the territory geography zones

Once you have completed importing the master reference geography data and defining your territory geography zone tasks, you can create a configuration package to export the territory zone data. For more information, refer to the Exporting Setup Data demo listed in the related topics section.

Import the territory geography zones

Once you have downloaded your configuration package for your territory geography zone setup, you can import the territory zones into another application instance. For more information, refer to the Importing Setup Data listed in the related topics section.

Note: Ensure that you import your master reference geography data into the new application instance before you import the configuration package.

Defining Address Cleansing: Explained

Address cleansing validates, corrects, and standardizes address information that you enter in the application. Address cleansing, unlike geography validation, validates both the geography attributes and the address line attributes.

To use the address cleansing functionality, you need to have license for the customer data quality application, because the feature is delivered using data quality integration.

You can specify the real-time address cleansing level for each country by choosing either of these options:

  • None: Specifies no real time address cleansing.

  • Optional: Provides option to cleanse addresses.

Once you have enabled address cleansing for a country, a Verify Address icon appears at address entry points in the application. Click the icon to perform address cleansing and receive a corrected, standardized address. If the application does not find a matching address, then an alert message is displayed.

FAQs for Define 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 Legal Jurisdictions and Authorities

Jurisdictions and Legal Authorities: Explained

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

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

Jurisdictions: Explained

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

Types of jurisdictions are:

  • Identifying Jurisdiction

  • Income Tax Jurisdiction

  • Transaction Tax Jurisdiction

Identifying Jurisdiction

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

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

Income Tax Jurisdiction

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

Transaction Tax Jurisdiction

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

Legal Authorities: Explained

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

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

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

Creating Legal Jurisdictions, Addresses and Authorities: Examples

Define legal jurisdictions and related legal authorities to support multiple legal entity registrations, which are used by Oracle Fusion Tax and Oracle Fusion Payroll.

Legal Jurisdictions

Create a legal jurisdiction by following these steps:

  1. Navigator > Setup and Maintenance > Manage Legal Jurisdictions > Go to Task.

  2. Select Create.

  3. Enter a unique Name, United States Income Tax.

  4. Select a Territory, United States.

  5. Select a Legislative Category, Income tax.

  6. Select Identifying, Yes. Identifying indicates the first jurisdiction a legal entity must register with to do business in a country.

  7. Enter a Start Date if desired. You can also add an End Date to indicate a date that the jurisdiction may no longer be used.

  8. Select a Legal Entity Registration Code, EIN or TIN.

  9. Select a Legal Reporting Unit Registration Code, Legal Reporting Unit Registration Number.

  10. Optionally enter one or more Legal Functions.

  11. Save and Close.

Legal Addresses for Legal Entities and Reporting Units

Create a legal address for legal entities and reporting units by following these steps:

  1. Navigator > Setup and Maintenance > Manage Legal Address > Go to Task.

  2. Select Create.

  3. Select Country.

  4. Enter Address Line 1, Oracle Parkway.

  5. Optionally enter Address Line 2, and Address Line 3.

  6. Enter or Select Zip Code, 94065.

  7. Select Geography 94065 and Parent Geography Redwood Shores, San Mateo, CA.

  8. Optionally enter a Time Zone, US Pacific Time.

  9. OK.

  10. Save and Close.

Legal Authorities

Create a legal authority by following these steps:

  1. Navigator > Setup and Maintenance >Manage Legal Authorities > Go to Task.

  2. Enter the Name, California Franchise Tax Board.

  3. Enter the Tax Authority Type, Reporting.

    Note: Create an address for the legal authority.
  4. Select Create.

  5. The Site Number is automatically assigned.

  6. Optionally enter a Mail Stop.

  7. Select Country, United States

  8. Enter Address Line 1, 121 Spear Street, Suite 400.

  9. Optionally enter Address Line 2, and Address Line 3.

  10. Enter or Select Zip Code, 94105.

  11. Select Geography 94105 and Parent Geography San Francisco, San Francisco, CA.

  12. OK.

  13. Optionally enter a Time Zone, US Pacific Time.

  14. Optionally click the One-Time Address check box.

  15. The From Date defaults to today's date. Update if necessary.

  16. Optionally enter a To Date to indicate the last day the address can be used.

    Note: You can optionally enter Address Purpose details.
  17. Select Add Row.

  18. Select Purpose.

  19. The Purpose from Date will default to today's date.

  20. Optionally enter a Purpose to Date.

  21. OK.

  22. Save and Close.

Creating Legal Entities, Registrations, and Reporting Units: Examples

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.

Legal Entity

Create a legal entity by following these steps:

  1. Navigator > Setup and Maintenance > Manage Legal Entity > Go to Task.

  2. Accept the default Country, United States.

  3. Enter Name, InFusion USA West.

  4. Enter Legal Entity Identifier, US0033.

  5. Optionally enter Start Date. When the start date is blank the legal entity is effective from the creation date.

  6. Optionally enter an End Date.

  7. Optionally, if your legal entity should be registered to report payroll tax and social insurance, select the Payroll statutory unit check box.

  8. Optionally, if your legal entity has employees, select the Legal employer check box.

  9. Optionally, if this legal entity is not a payroll statutory unit, select an existing payroll statutory unit to report payroll tax and social instance on behalf of this legal entity.

  10. Enter the Registration Information

  11. Accept the default Identifying Jurisdiction, United States Income Tax.

  12. Search for and select a Legal Address, 500 Oracle Parkway, Redwood Shores, CA 94065.

    The legal address must have been entered previously using the Manage Legal Address task.

  13. OK.

  14. Optionally enter a Place of Registration.

  15. Enter the EIN or TIN.

  16. Enter the Legal Reporting Unit Registration Number.

  17. Save and Close.

  18. Navigator > Setup and Maintenance > Define Legal Entries > Manage Legal Entity > Select... to set scope.

  19. Select the Manage Legal Entity.

  20. In the *Legal Entity list, select Select and Add.

  21. Click Apply and Go to Task.

  22. Select your legal entity.

  23. Save and Close on the very bottom of the window.

    This sets the scope for your task list to the selected legal entity.

  24. Save and Close.

Legal Entity Registrations

A legal entity registration with the same name as that of the legal entity is created by default. To verify this, locate the Manage Legal Entity Registrations task and then select Go to Task. To create another registration for the legal entity follow these steps:

  1. Navigator > Setup and Maintenance > Manage Legal Entity Registrations: Verify that the Legal Entity scope value is set correctly.

  2. Go to Task.

  3. Select Create.

  4. Enter Jurisdiction.

  5. Enter Registered Address.

  6. Enter Registered Name.

  7. Optionally enter Alternate Name, Registration Number, Place of Registration, Issuing Legal Authority, and Issuing Legal Authority Address, Start Date, and End Date.

  8. Save and Close.

Legal Reporting Unit

When a legal entity is created, a legal reporting unit with the same name as that of the entity is also automatically created. To create more legal reporting units or modify the settings follow these steps:

  1. Navigator > Setup and Maintenance > Define Legal Reporting Unit. > Manage Legal Reporting Unit. Verify that the Legal Entity scope value is set correctly.

  2. Go to Task

  3. Select Create.

  4. Enter Territory, United States.

  5. Enter Name.

  6. Optionally enter a Start Date.

  7. Enter Registration Information.

  8. Search for and select Jurisdiction.

  9. Enter Main Legal Reporting Unit information.

  10. Select the value Yes or No for the Main Legal Reporting Unit. Set value to yes only if you are creating a new main (primary) legal reporting unit.

  11. Enter the Main Effective Start Date, 1/1/11.

  12. Save and Close.

Define Legal Entities: Manage Legal Entity

Legal Entities: Explained

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

Legal entities have the following rights and responsibilities to:

  • Own property

  • Trade

  • Repay debt

  • 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

  • Minimizing the enterprise's tax liability

  • 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, 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

  • 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), which 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.

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. These registers are part of the Oracle Fusion Trading Community Architecture.

When your legal entities are trading with each other, represent them as legal entities and 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.

Several decisions you should consider when you create legal entities.

  • The importance of using legal entity on 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 Using Legal Entities on 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, a sales order creates an obligation on the legal entity that books the order to deliver the goods on the acknowledged date. The creation also creates an obligation on 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.

  • 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, Business Unit ACM UK has a default legal entity of InFusion UK Ltd. When a purchase order is placed in ACM UK, the legal entity InFusion UK Ltd is legally obligated to the supplier. Oracle Fusion Procurement, Oracle Fusion Project Portfolio Management, 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 wanted, 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 one segment represents your legal entity to ease your requirement to account for your operations to regulatory agencies, tax authorities, and investors. Accounting for your operations means you must produce a balanced trial balance sheet by legal entity. If you account for many legal entities in a single ledger, you must:

  1. Identify the legal entities within the ledger.

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

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

Represent your legal entities by at least one balancing segment value. You may represent it by two or three balancing segment values if more granular reporting is required. For example, if your legal entity operates in multiple jurisdictions in Europe, you might define balancing segment values and map them to legal reporting units. You can represent a legal entity with 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. This solution is used 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 want to isolate the assets and liabilities for that entity.

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

If your enterprise regularly spins off businesses or holds managers accountable for utilization of assets, identify the business with a balancing segment value. If you account for each legal entity in a separate ledger, no requirement exists to identify the legal entity with a balancing segment value.

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 the portion is not a separate legal entity. If you do not map legal entities sharing the same ledger to balancing segments, you cannot distinguish them using intercompany functionality or track 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 feature to create intercompany entries automatically 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.

Tip: In the Oracle Fusion Supply Chain applications, you can model intercompany relationships using business units, from which legal entities are derived.
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 for 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.

Define Legal Entities: Manage Legal Entity HCM Information

HCM Organization Models: Examples

These examples illustrate different models for human capital management (HCM) organizations that include a legislative data group (LDG).

The example includes LDGs, which aren't organization classification, to show how to partition payroll data by associating them with a payroll statutory unit.

Simple Configuration

This example illustrates a simple configuration that does not include any tax reporting units.

Note the following:

  • 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 these countries report at the legal entity level.

This figure illustrates a simple configuration where the enterprise has only one legal entity, which 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

This example illustrates a more complex configuration. In this enterprise, you define one legal entity, InFusion US as a payroll statutory unit with two separate legal entities, which are also legal employers. This model shows multiple legal employers that are associated with a single payroll statutory unit. 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 you can categorize the balances separately by one of the following:

  • Payroll statutory unit

  • Legal employer

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

A figure that contains one enterprise with one payroll
statutory unit, multiple legal employers and multiple tax reporting
units

One Payroll Statutory Unit and Two Tax Reporting Units

This model makes no distinction between a legal employer and a payroll statutory unit. You define tax reporting units as subsidiaries to the legal entity.

In this enterprise, legal entity is the highest level of aggregation for payroll calculations and reporting. Statutory reporting boundaries are 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. The legal entity 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

In this model, the enterprise has one legal entity. 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 wouldn't typically:

  • Report on tax reporting unit balances within a legal employer

  • Categorize balances 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. 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

In this model, the enterprise has two legal entities. The 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 wouldn't typically:

  • Report on tax reporting unit balances within a legal employer

  • Categorize balances 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). 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.

Use the Manage Legal Reporting Unit HCM Information task to designate an existing legal reporting unit as a tax reporting unit. If you create a new legal reporting unit that belongs to a legal employer (that is not also a payroll statutory unit), you select a parent payroll statutory unit and then, when you run the Manage Legal Reporting Unit HCM Information task, you designate it as a tax reporting unit and select the legal employer.

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 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, multiple company 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 Legal Entities: Manage Legal Entity Tax Profile

Party Tax Profiles: Explained

A tax profile is the body of information that relates to a party's transaction tax activities. A tax profile can include main and default information, tax registration, tax exemptions, party fiscal classifications, tax reporting codes, configuration options, and service subscriptions.

Set up tax profiles for the following parties involved in your transactions:

  • First parties

  • Third parties

  • Tax authorities

First Parties

Set up tax profiles for your first-party legal entities, legal reporting units, and business units.

First-party legal entities identify your organization to the relevant legal authorities, for example, a national or international headquarters. Legal entities let you model your external relationships to legal authorities more accurately. The relationships between first-party legal entities and the relevant tax authorities normally control the setup of the transaction taxes required by your business. Under most circumstances, the tax setup is used and maintained based on the configuration of the legal entity. Enter the default information, party fiscal classifications, tax reporting codes, and configuration options for your legal entities. You can also specify if you're using the tax services of an external service provider for tax calculation.

First-party legal reporting units identify each office, service center, warehouse, and any other location within the organization with a tax requirement. A legal reporting unit tax profile is automatically created for the headquarter legal entity. Set up additional legal reporting unit tax profiles for those needed for tax purposes. For legal reporting units, enter the default information, tax registrations, party fiscal classifications, and tax reporting codes. Also, define tax reporting details for your VAT and global tax reporting needs for tax registrations of tax regimes that allow this setup.

Business units organize your company data according to your internal accounting, financial monitoring, and reporting requirements. To help you manage the tax needs of your business units, you can use the business unit tax profile in either of two ways:

  • Indicate that business unit tax setup is used and maintained based on the configuration of the associated legal entity at transaction time. The tax setup of the associated legal entity setup is either specific to the legal entity or shared across legal entities using the Global Configuration Owner setup.

  • Indicate that tax setup is used and maintained by a specific business unit. Create configuration options for the business unit to indicate that the subscribed tax content is used for the transactions created for the business unit.

For business units that maintain their own setup, enter the default information, tax reporting codes, configuration options, and service providers as required.

Third Parties

Set up third-party tax profiles for parties with the usage of customer, supplier, and their sites. Enter the default information, tax registrations, party fiscal classifications, and reporting codes required for your third parties or third-party sites. You can set up tax exemptions for your customers and customer sites.

Banks are also considered third parties. When a bank is created, the tax registration number specified on the bank record is added to the party tax profile record in Oracle Fusion Tax. You can't modify the party tax profile for a bank as it's view only. You can only modify the bank record.

Note: You don't need to set up party tax profiles for third parties. Taxes are still calculated on transactions for third parties that don't have tax profiles.

Tax Authorities

Set up a tax authority party tax profile using the Legal Authorities setup task. The tax authority party tax profile identifies a tax authority party as a collecting authority or a reporting authority or both. A collecting tax authority manages the administration of tax remittances. A reporting tax authority receives and processes all company transaction tax reports.

The collecting and reporting tax authorities appear in the corresponding list of values on all applicable Oracle Fusion Tax pages. All tax authorities are available in the list of values as an issuing tax authority.

Specifying First-Party Tax Profile Options: Points to Consider

Set up first-party tax profiles for all legal entities, legal reporting units, and business units in your organization that have a transaction tax requirements. How you set up your first parties can impact the tax calculation on your transactions.

The first-party tax profile consists of:

  • Defaults and controls: Applicable to legal entities and legal reporting units. Business units that use their own tax setup don't have defaults and controls.

  • Tax registrations: Applicable to legal reporting units.

  • Party fiscal classifications: Applicable to legal entities and legal reporting units.

  • Tax reporting codes: Applicable to legal entities, legal reporting units, and business units who don't use the tax setup of the legal entity.

  • Configuration options: Applicable to legal entities and business units who don't use the tax setup of the legal entity.

  • Service subscriptions: Applicable to legal entities and business units who don't use the tax setup of the legal entity.

Defaults and Controls

The following table describes the defaults and controls available at the first-party tax profile level:

Option Description

Set as self-assessment (reverse charge)

Automatically self-assess taxes on purchases.

Rounding Level

Perform rounding operations on the:

  • Header: Applies rounding to calculated tax amounts once for each tax rate per invoice.

  • Line: Applies rounding to the calculated tax amount on each invoice line.

Rounding Rule

The rule that defines how the rounding should be performed on a value involved in a taxable transaction. For example, up to the next highest value, down to the next lowest value, or nearest.

Note: If you defined a rounding precedence hierarchy in the configuration owner tax option settings for the combination of configuration owner and event class, Oracle Fusion Tax considers the rounding details in the applicable tax profile.

Set Invoice Values as Tax Inclusive

This first party intends to send or receive invoices with invoice line amount inclusive of the tax amount.

Note: This option overrides the tax inclusive handling setting at the tax level, but not at the tax rate level.

Tax Registrations

Set up a separate tax registration to represent each distinct registration requirement for a first-party legal reporting unit. Oracle Fusion Tax uses tax registrations in tax determination and tax reporting. If your first party has more than one tax registration under the same tax regime, then the application considers the tax registration in the order: tax jurisdiction; tax; tax regime.

You must enable the Use tax reporting configuration option on the first-party tax regime to allow entry of global tax reporting configuration details during tax registration setup for legal reporting units for these tax regimes.

Party Fiscal Classifications

If applicable, associate first-party fiscal classification codes with this party. The party fiscal classification codes you enter become part of tax determination for invoices associated with this party. Specify start and end dates to control when these fiscal classifications are applicable for this party and transaction.

For legal entities, you can view the associated legal classifications that were assigned to the tax regime defined for this first party. The legal classifications are used in the tax determination process, similar to the party fiscal classifications.

Tax Reporting Codes

Set up tax reporting types to capture additional tax information on transactions for your tax reports for your first parties. Depending on the tax reporting type code, you either enter or select a tax reporting code for this party. Specify start and end dates to control when these tax reporting codes are applicable.

Configuration Options

The legal entities and business units in your organization are each subject to specific sets of tax regulations as designated by the tax authorities where you do business. Use configuration options to associate legal entities and business units with their applicable tax regimes. You can set up tax configuration options when you create a tax regime or when you create a party tax profile. Both setup flows display and maintain the same party and tax regime definitions.

Service Subscriptions

Oracle Fusion Tax lets you use the tax services of external service providers for tax calculation of US Sales and Use Tax on Receivables transactions. The setup for provider services is called a service subscription. A service subscription applies to the transactions of one configuration option setup for a combination of tax regime and legal entity or business unit. Set up service subscriptions when you create a tax regime or when you create a party tax profile for a first-party legal entity or business unit.

FAQs for Manage Legal Entity Tax Profile

When does a party tax profile get created for a legal entity?

The legal entity party tax profile is automatically created when a legal entity record is created.

When a legal entity is created through a back-end process, a legal entity party tax profile is created, when you:

  • Save a tax regime to which the legal tax entity subscribes.

  • Save the configuration owner tax option that are defined for the legal entity.

You can also create a party tax profile for a legal entity manually. Use the Create Legal Entity Tax Profile page or edit the tax profile that was automatically generated with the relevant tax information.

Define Legal Entities: Define Legal Reporting Units

Planning Legal Reporting Units: Points to Consider

Each of your legal entities has at least one legal reporting unit. Legal reporting units can also be referred to as establishments. You can define either domestic or foreign establishments. Define legal reporting units by physical location, such as sales offices, or by logical unit, such as groups of employees subject to different reporting requirements. For example, define logical legal reporting units for both salaried and hourly paid employees.

Another example of logical reporting units is in Oracle Fusion Human Capital Management (HCM) where you use legal reporting units to model tax reporting units. A tax reporting unit is used to group workers for the purpose of tax reporting.

Planning Legal Reporting Units

Plan and define your legal reporting units at both the local and national levels if you operate within the administrative boundaries of a jurisdiction that is more granular than country. For example, your legal entity establishes operations in a country that requires reporting of employment and sales taxes locally as well as nationally. Therefore, you need more than one legally registered location to meet this legal entity's reporting requirements in each local area. Additionally, legal entities in Europe operate across national boundaries, and require you to set up legal reporting units for the purposes of local registration in each country. There can be multiple registrations associated with a legal reporting unit. However, only one identifying registration can be defined by the legal authority used for the legal entity or legal reporting unit and associated with the legal reporting unit.

Define Business Units: Manage Business Units

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 has 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 do the following:

  • Assign your business units to one primary ledger. For example, if a business unit is processing payables invoices, then it must post to a particular ledger. This assignment is required for your business units with business functions that produce financial transactions.

  • Use a business unit as a securing mechanism for transactions. For example, if you run your export business separately from your domestic sales business, then 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 provides the following advantages:

  • Enables flexible implementation

  • Provides consistent entity that controls and reports on transactions

  • Shares 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 share reference data, such as payment terms and transaction types, across business units, or you can have each business unit manage its own set depending on the level at which you want 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 legal entities to ensure the uniqueness of sequencing.

In summary, use business units for:

  • Management reporting

  • Transaction processing

  • Transactional data security

  • Reference data sharing and definition

Brief Overview of Business Unit Security

A number of Oracle Fusion Applications use business units to implement data security. You assign roles like Accounts Payable Manager to users to permit them to perform specific functions, and you assign business units for each role to users to give them access to data in those business units. For example, users which have been assigned a Payables role for a particular business unit, can perform the function of payables invoicing on the data in that business unit. Roles can be assigned to users manually using the Security Console, or automatically using provisioning rules. Business Units can be assigned to users using the Manage Data Access for Users task in Setup and Maintenance.

Define Business Units: Assign Business Unit Business Function

Business Functions: Explained

A business unit can perform many business functions in Oracle Fusion Applications.

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. In such cases, any segment that allows the identification of associated revenue and costs can be used as a profit center identification. The segment can be qualified as a cost center segment.

However, there are 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.

FAQs for Assign Business Unit Business Function

Why did the newly added ledger and legal entity not show up in the list when assigning business functions?

When assigning the business functions, the list of values for the Primary Ledger and default Legal Entity are empty or do not show newly added values.

  • Cause: The Review and Submit Accounting Configuration was not performed after ledger or legal entity were added.

  • Solution: Submit the Review and Submit Accounting Configuration for the ledger from the Define Accounting Configuration task list in the Setup and Maintenance work area.

Define Business Units: Manage Service Provider Relationships

Shared Service Centers: Explained

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

Service Provider Model

The service provider model centralizes the following business functions:

  • Procurement

    • Services business units that enable the Requisitioning business function.

    • Processes requisitions and negotiates supplier terms for client business units.

  • Payables Payment

    • Services business units that enable the Payables Invoicing business function.

    • Processes payments for client business units.

  • Customer Payments

    • Services business units that enable the Billing and Revenue Management business function.

    • Processes payments for the transactions of client business units assigned the Billing and Revenue Management business function.

This functionality is used to frame service level agreements and drive security. The service provider relationships provides you with a clear record of how your business operations 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 for 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 businesses. 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 takes 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: 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 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

    Note: You must select a default currency in the customer or supplier business function properties page, if not populated automatically from the ledger assigned to the business unit in the assign business function setup task.
  • Manage project billing options

  • Set up clause numbering

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

Managing Clause Numbering

You can choose to number clauses manually or automatically.

If you choose the automatic numbering method, you must select a determinant level for the numbering. You must then select the appropriate clause sequence category from document sequences that you set up for this numbering level.

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.

  • Set the clause numbering level for automatic clause numbering of contracts.

  • For a contract with no assigned ledger or legal entity, set the document sequence to Global or Business Unit level.

  • Enable the Contract Expert enabling 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:

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

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

  3. 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 setting the clause numbering level. Then select the appropriate clause sequence category for the specified numbering level. You must have previously set up document sequences for the document sequence categories of global, ledger, and business unit. 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: Specify Supplier Contract Management Business Function Properties

Supplier Contracts Business Unit Setup: Explained

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

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

Note: The customer must select a default currency in the customer or supplier business function properties page, if not automatically populated from the ledger assigned to the business unit in the assign business function setup task.

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

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.

  • Set the clause numbering level for automatic clause numbering of contracts.

  • For a contract with no assigned ledger or legal entity, set the document sequence to Global or Business Unit level.

  • Enable the Contract Expert enabling 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:

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

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

  3. 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 setting the clause numbering level. Then select the appropriate clause sequence category for the specified numbering level. You must have previously set up document sequences for the document sequence categories of global, ledger, and business unit. 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.