Oracle® Fusion
Applications Common Implementation Guide 11g Release 6 (11.1.6) Part Number E20360-06 |
![]() Home |
![]() Contents |
![]() Book List |
![]() Contact Us |
![]() Previous |
![]() Next |
This chapter contains the following:
Enterprise Structures: Overview
Enterprise Structures Business Process Model: Explained
Global Enterprise Configuration: Points to Consider
Modeling Your Enterprise Management Structure in Oracle Fusion: Example
Define Initial Configuration with the Enterprise Structures Configurator
Define Enterprise: Manage Enterprise HCM Information
Define Enterprise: Manage Locations
Define Legal Jurisdictions and Authorities
Define Legal Entities: Manage Legal Entity
Define Legal Entities: Manage Legal Entity HCM Information
Define Legal Entities: Manage Legal Entity Tax Profile
Define Legal Entities: Define Legal Reporting Units
Define Chart of Accounts for Enterprise Structures: Manage Chart of Accounts
Define Chart of Accounts for Enterprise Structures: Manage Chart of Accounts Value Sets
Define Chart of Accounts for Enterprise Structures: Manage Account Hierarchies
Define Chart of Accounts for Enterprise Structures: Manage Accounting Calendars
Define Accounting Configurations of Enterprise Structures: Manage Primary or Secondary Ledgers
Define Accounting Configurations of Enterprise Structures: Specify Ledger Options
Define Accounting Configurations of Enterprise Structures: Manage Reporting Currencies
Define Business Units: Manage Service Provider Relationships
Define Business Units: Specify Customer Contract Management Business Function Properties
Define Business Units: Specify Supplier Contract Management Business Function Properties
Define Business Units: Assign Business Unit Business Function
Define Business Units: Manage Business Units
Define Workforce Structures: Manage Enterprise HCM Information
Define Workforce Structures: Manage Locations
Define Workforce Structures: Manage Divisions
Define Workforce Structures: Manage Departments
Define Workforce Structures: FAQs for Manage Job Families
Define Workforce Structures: Manage Job
Define Workforce Structures: Manage Person Search Relevance Profile Option Values
Define Facilities: Manage Facility Shifts, Workday Patterns, and Schedules
Define Facilities: Manage Inventory Organizations
Define Facilities: Manage Item Organizations
Oracle Fusion Applications have been designed to ensure your enterprise can be modeled to meet legal and management objectives. The decisions about your implementation of Oracle Fusion Applications are affected by your:
Industry
Business unit requirements for autonomy
Business and accounting policies
Business functions performed by business units and optionally, centralized in shared service centers
Locations of facilities
Every enterprise has three fundamental structures, legal, managerial, and functional, that are used to describe its operations and provide a basis for reporting. In Oracle Fusion, these structures are implemented using the chart of accounts and organizations. Although many alternative hierarchies can be implemented and used for reporting, you are likely to have one primary structure that organizes your business into divisions, business units, and departments aligned by your strategic objectives.
The figure above shows a typical group of legal entities, operating various business and functional organizations. Your ability to buy and sell, own, and employ comes from your charter in the legal system. A corporation is a distinct legal entity from its owners and managers. The corporation is owned by its shareholders, who may be individuals or other corporations. There are many other kinds of legal entities, such as sole proprietorships, partnerships, and government agencies.
A legally recognized entity can own and trade assets and employ people in the jurisdiction in which it is registered. When granted these privileges, legal entities are also assigned responsibilities to:
Account for themselves to the public through statutory and external reporting
Comply with legislation and regulations
Pay income and transaction taxes
Process value added tax (VAT) collection on behalf of the taxing authority
Many large enterprises isolate risk and optimize taxes by incorporating subsidiaries. They create legal entities to facilitate legal compliance, segregate operations, optimize taxes, complete contractual relationships, and isolate risk. Enterprises use legal entities to establish their enterprise's identity under the laws of each country in which their enterprise operates.
In the figure above, a separate card represents a series of registered companies. Each company, including the public holding company, InFusion America, must be registered in the countries where they do business. Each company consists of various divisions created for purposes of management reporting. These are shown as vertical columns on each card. For example, a group might have a separate company for each business in the United States (US), but have their United Kingdom (UK) legal entity represent all businesses in that country. The divisions are linked across the cards so that a business can appear on some or all of the cards. For example, the air quality monitoring systems business might be operated by the US, UK, and France companies. The list of business divisions is on the Business Axis. Each company's card is also horizontally striped by functional groups, such as the sales team and the finance team. This functional list is called the Functional Axis. The overall image suggests that information might, at a minimum, be tracked by company, business, division, and function in a group environment. In Oracle Fusion Applications, the legal structure is implemented using legal entities.
Successfully managing multiple businesses requires that you segregate them by their strategic objectives, and measure their results. Although related to your legal structure, the business organizational hierarchies do not need to be reflected directly in the legal structure of the enterprise. The management structure can include divisions, subdivisions, lines of business, strategic business units, and cost centers. In the figure above, the management structure is shown on the Business Axis. In Oracle Fusion Applications, the management structure is implemented using divisions and business units.
Straddling the legal and business organizations is a functional organization structured around people and their competencies. For example, sales, manufacturing, and service teams are functional organizations. This functional structure is represented by the Functional Axis in the figure above. You reflect the efforts and expenses of your functional organizations directly on the income statement. Organizations must manage and report revenues, cost of sales, and functional expenses such as research and development (R&D) and selling, general, and administrative (SG&A) expenses. In Oracle Fusion Applications, the functional structure is implemented using departments and organizations, including sales, marketing, project, cost, and inventory organizations.
In Oracle Fusion Applications, the Enterprise Performance and Planning Business Process Model illustrates the major implementation tasks that you perform to create your enterprise structures. This process model includes the Set Up Enterprise Structures business process, which consist of implementation activities that span many product families. Information Technology is a second Business Process Model which contains the Set Up Information Technology Management business process. Define Reference Data Sharing is one of the activities in this business process and is important in the implementation of the enterprise structures. This activity creates the mechanism to share reference data sets across multiple ledgers, business units, and warehouses, reducing the administrative burden and decreasing the time needed to implement.
The following figure and chart describes the Business Process Model structures and activities.
BPM Activities |
Description |
---|---|
Define Enterprise |
Define the enterprise to capture the name of the deploying enterprise and the location of the headquarters. There is normally a single enterprise organization in a production environment. Multiple enterprises are defined when the system is used to administer multiple customer companies, or when you choose to set up additional enterprises for testing or development. |
Define Enterprise Structures |
Define enterprise structures to represent an organization with one or more legal entities under common control. Define internal and external organizations to represent each area of business within the enterprise. |
Define Legal Jurisdictions and Authorities |
Define information for governing bodies that operate within a jurisdiction. |
Define Legal Entities |
Define legal entities and legal reporting units for business activities handled by the Oracle Fusion Applications. |
Define Business Units |
Define business units of an enterprise to allow for flexible implementation, to provide a consistent entity for controlling and reporting on transactions, and to be an anchor for the sharing of sets of reference data across applications. |
Define Financial Reporting Structures |
Define financial reporting structures, including organization structures, charts of accounts, organizational hierarchies, calendars, currencies and rates, ledgers, and document sequences which are used in organizing the financial data of a company. |
Define Chart of Accounts |
Define chart of accounts including hierarchies and values to enable tracking of financial transactions and reporting at legal entity, cost center, account, and other segment levels. |
Define Ledgers |
Define the primary accounting ledger and any secondary ledgers that provide an alternative accounting representation of the financial data. |
Define Accounting Configurations |
Define the accounting configuration that serves as a framework for how financial records are maintained for an organization. |
Define Facilities |
Define inventory, item, and cost organizations. Inventory organizations represent facilities that manufacture or store items. The item master organization holds a single definition of items that can be shared across many inventory organizations. Cost organizations group inventory organizations within a legal entity to establish the cost accounting policies. |
Define Reference Data Sharing |
Define how reference data in the applications is partitioned and shared. |
Note
There are product specific implementation activities that are not listed here and depend on the applications you are implementing. For example, you can implement Define Enterprise Structures for Human Capital Management, Project Management, and Sales Management.
Start your global enterprise structure configuration by discussing what your organization's reporting needs are and how to represent those needs in the Oracle Fusion Applications. Consider deployment on a single instance, or at least, on as few instances as possible, to simplify reporting and consolidations for your global enterprises. The following are some questions and points to consider as you design your global enterprise structure in Oracle Fusion.
Enterprise Configuration
Business Unit Management
Security Structure
Compliance Requirements
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?
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?
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?
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?
This example uses a fictitious global company to demonstrate the analysis that can occur during the enterprise structure configuration planning process.
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 has 400 plus employees and revenue of $120 million. Your product line includes all the components to build and maintain air quality monitoring (AQM) systems for homes and businesses. You have two distribution centers and three warehouses that share a common item master in the US and UK. Your financial services organization provides funding to your customers for the start up costs of these systems.
The following are elements you need to consider in creating your model for your global enterprise structure.
Your company is required to report using US Generally Accepted Accounting Principles (GAAP) standards and UK Statements of Standard Accounting Practice and Financial Reporting Standards. How many ledgers do you need to achieve proper statutory reporting?
Your managers need reports that show profit and loss (revenue and expenses) for their lines of business. Do you use business units and balancing segments to represent your divisions and businesses? Do you secure data by two segments in your chart of accounts which represents each department and legal entity or one segment that represents both to produce useful, but confidential management reports?
Your corporate management requires reports showing total organizational performance with drill down capability to the supporting details. Do you need multiple balancing segment hierarchies to achieve proper rollup of balances for reporting requirements?
Your company has all administrative, account payables, procurement, and human resources functions performed at their corporate headquarters. Do you need one or more business unit in which to perform all these functions? How will your shared service center be configured?
The following figure and table summarize the model that your committee has designed and uses numerical values to provide a sample representation of your structure. The model includes the following recommendations:
Creation of three separate ledgers representing your separate legal entities:
InFusion America Inc.
InFusion Financial Services Inc.
InFusion UK Services Ltd.
Consolidation of results for system components, installations, and maintenance product lines across the enterprise
All UK general and administrative costs processed at the UK headquarters
US Systems' general and administrative costs processed at US Corporate headquarters
US Financial Services maintains its own payables and receivables departments
In this chart, the green globe stands for mandatory and gold globe stands for optional setup. The following statements expand on the data in the chart.
The enterprise is mandatory because it serves as an umbrella for the entire implementation. All organizations are created within an enterprise.
Legal entities are also mandatory. They can be optionally mapped to balancing segment values or represented by ledgers. Mapping balancing segment values to legal entities is mandatory if you plan to use the intercompany functionality.
At least one ledger is mandatory in an implementation in which you record your accounting transactions.
Business units are also mandatory because financial transactions are processed in business units.
A shared service center is optional, but if used, must be a business unit.
Divisions are optional and can be represented with a hierarchy of cost centers or by a second balancing segment value.
Departments are mandatory because they track your employees.
Optionally, add an item master organization and inventory organizations if you are tracking your inventory transactions in Oracle Fusion Applications.
Note
Some Oracle Fusion Human Capital Management and Customer Relationship Management implementations do not require recording of accounting transactions and therefore, do not require implementation of a ledger.
Note
The InFusion Corporation is a legal entity but is not discussed in this example.
The Enterprise Structures Configurator is an interview-based tool that guides you through the process of setting up a basic enterprise structure. By answering questions about your enterprise, the tool creates a structure of divisions, legal entities, business units, and reference data sets that reflects your enterprise structure. After you create your enterprise structure, you also follow a guided process to determine whether or not to use positions, and whether to set up additional attributes for jobs and positions. After you define your enterprise structure and your job and position structures, you can review them, make any necessary changes, and then load the final configuration.
This figure illustrates the process to configure your enterprise using the Enterprise Structures Configurator.
To be able to use the Enterprise Structures Configurator, you must select the Enterprise Structures Guided Flow feature for your offerings on the Configure Offerings page in the Setup and Maintenance work area. If you do not select this feature, then you must set up your enterprise structure using individual tasks provided elsewhere in the offerings, and you cannot create multiple configurations to compare different scenarios.
To define your enterprise structures, you use the guided flow within the Establish Enterprise Structures task to enter basic information about your enterprise, such as the primary industry and the location of your headquarters. You then create divisions, legal entities, business units, and reference data sets. The Establish Enterprise Structures task enables you to create multiple enterprise configurations so that you can compare different scenarios. Until you load a configuration, you can continue to create and edit multiple configurations until you arrive at one that best suits your enterprise.
You also use a guided process to determine whether you want to use jobs only, or jobs and positions. The primary industry that you select in the Establish Enterprise Structures task provides the application with the information needed to make an initial recommendation. You can either accept the recommendation, or you can answer additional questions about how you manage people in your enterprise, and then make a selection. After you select whether to use jobs or positions, the guided process prompts you to set up a descriptive flexfield structure for jobs, and for positions if you have chosen to use them. Descriptive flexfields enable you to capture additional information when you create jobs and positions.
Finally, you can review a summary of the results of the two interview processes. For each configuration, the online summary lists the divisions, legal entities, business units, reference data sets, and job and position structures that the application will create when you load the configuration.
For a more detailed analysis of a configuration, you can access the Technical Summary Report. This report lists the same information as the online summary, but also lists the following information that will be created by the application when you load the configuration, based on your configuration:
Legislative data groups (the application creates one legislative data group for each country that is identified in the configuration.)
Name of the legislative data group that will be assigned to the payroll statutory unit that is generated for each legal entity.
Organization hierarchy.
The Technical Summary report also lists the default settings that will be loaded for these fields, which you access from the Manage Enterprise HCM Information task: Worker Number Generation, Employment Model and Allow Employment Terms Override. You can print the Technical Summary Report for each of your configurations and compare each scenario.
Note
If your PDF viewer preferences are set to open PDFs in a browser window, the Technical Summary report replaces the Oracle Fusion application. Use your browser's Back button to return to the application.
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.
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.
InFusion Corporation is a multinational enterprise in the high technology industry with product lines that include all the components that are required to build and maintain air quality monitoring (AQM) systems for homes and businesses. Its primary locations are in the US and the UK, but it has smaller outlets in France, Saudi Arabia, and the United Arab Emirates (UAE).
In the US, InFusion employs 400 people and has a company revenue of $120 million. Outside the US, InFusion employs 200 people and has revenue of $60 million.
InFusion requires three divisions. The US division will cover the US locations. The Europe division will cover the UK and France. Saudi Arabia and the UAE will be covered by the Middle East division.
InFusion requires legal entities with legal employers, payroll statutory units, tax reporting units, and legislative data groups for the US, UK, France, Saudi Arabia, and UAE, in order to employ and pay its workers in those countries.
InFusion requires a number of departments across the enterprise for each area of business, such as sales and marketing, and a number of cost centers to track and report on the costs of those departments.
InFusion requires business units for human capital management (HCM) purposes. Infusion has general managers responsible for business units within each country. Those business units may share reference data. Some reference data can be defined within a reference data set that multiple business units may subscribe to. Business units are also required for financial purposes. Financial transactions are always processed within a business unit.
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.
Managing multiple businesses requires that you segregate them by their strategic objectives and measure their results. Responsibility to reach objectives can be delegated along the management structure. Although related to your legal structure, the business organizational hierarchies do not need to reflect directly the legal structure of the enterprise. The management entities and structure can include divisions and subdivisions, lines of business, and other strategic business units, and include their own revenue and cost centers. These organizations can be included in many alternative hierarchies and used for reporting, as long as they have representation in the chart of accounts.
A division refers to a business oriented subdivision within an enterprise, in which each division organizes itself differently to deliver products and services or address different markets. A division can operate in one or more countries, and can be comprised of many companies or parts of different companies that are represented by business units.
A division is a profit center or grouping of profit and cost centers, where the division manager is responsible for attaining business goals including profit goals. A division can be responsible for a share of the company's existing product lines or for a separate business. Managers of divisions may also have return on investment goals requiring tracking of the assets and liabilities of the division. The division manager reports to a top corporate executive.
By definition a division can be represented in the chart of accounts. Companies may choose to represent product lines, brands, or geographies as their divisions: their choice represents the primary organizing principle of the enterprise. This may coincide with the management segment used in segment reporting.
Oracle Fusion Applications supports a qualified management segment and recommends that you use this segment to represent your hierarchy of business units and divisions. If managers of divisions have return on investment goals, make the management segment a balancing segment. Oracle Fusion applications allows up to three balancing segments. The values of the management segment can be comprised of business units that roll up in a hierarchy to report by division.
Historically, divisions were implemented as a node in a hierarchy of segment values. For example, Oracle E-Business Suite has only one balancing segment, and often the division and legal entity are combined into a single segment where each value stands for both division and legal entity.
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.
A legal entity is a recognized party with rights and responsibilities given by legislation.
Legal entities have the right to own property, the right to trade, the responsibility to repay debt, and the responsibility to account for themselves to regulators, taxation authorities, and owners according to rules specified in the relevant legislation. Their rights and responsibilities may be enforced through the judicial system. Define a legal entity for each registered company or other entity recognized in law for which you want to record assets, liabilities, expenses and income, pay transaction taxes, or perform intercompany trading.
A legal entity has responsibility for elements of your enterprise for the following reasons:
Facilitating local compliance
Taking advantage of lower corporation taxation in some jurisdictions
Preparing for acquisitions or disposals of parts of the enterprise
Isolating one area of the business from risks in another area. For example, your enterprise develops property and also leases properties. You could operate the property development business as a separate legal entity to limit risk to your leasing business.
In configuring your enterprise structure in Oracle Fusion Applications, you need to understand that the contracting party on any transaction is always the legal entity. Individual legal entities own the assets of the enterprise, record sales and pay taxes on those sales, make purchases and incur expenses, and perform other transactions.
Legal entities must comply with the regulations of jurisdictions, in which they register. Europe now allows for companies to register in one member country and do business in all member countries, and the US allows for companies to register in one state and do business in all states. To support local reporting requirements, legal reporting units are created and registered.
You are required to publish specific and periodic disclosures of your legal entities' operations based on different jurisdictions' requirements. Certain annual or more frequent accounting reports are referred to as statutory or external reporting. These reports must be filed with specified national and regulatory authorities. For example, in the United States (US), your publicly owned entities (corporations) are required to file quarterly and annual reports, as well as other periodic reports, with the Securities and Exchange Commission (SEC), who enforces statutory reporting requirements for public corporations.
Individual entities privately held or held by public companies do not have to file separately. In other countries, your individual entities do have to file in their own name, as well as at the public group level. Disclosure requirements are diverse. For example, your local entities may have to file locally to comply with local regulations in a local currency, as well as being included in your enterprise's reporting requirements in different currency.
A legal entity can represent all or part of your enterprise's management framework. For example, if you operate in a large country such as the United Kingdom or Germany, you might incorporate each division in the country as a separate legal entity. In a smaller country, for example Austria, you might use a single legal entity to host all of your business operations across divisions.
Using the Enterprise Structures Configurator (ESC), you can create legal entities for your enterprise automatically, based on the countries in which divisions of your business operate, or you can upload a list of legal entities from a spreadsheet.
If you are not certain of the number of legal entities that you need, you can create them automatically. To use this option, you first identify all of the countries in which your enterprise operates. The application opens the Map Divisions by Country page, which contains a matrix of the countries that you identified, your enterprise, and the divisions that you created. You select the check boxes where your enterprise and divisions intersect with the countries to identify the legal entities that you want the application to create. The enterprise is included for situations where your enterprise operates in a country and acts on behalf of several divisions within the enterprise and is a legal employer in a country. If you select the enterprise for a country, the application creates a country holding company.
The application automatically creates the legal entities that you select, and identifies them as payroll statutory units and legal employers. For each country that you indicated that your enterprise operates in, and for each country that you created a location for, the application also automatically creates a legislative data group.
Any legal entities that you create automatically cannot be deleted from the Create Legal Entities page within the Enterprise Structures Configurator. You must return to the Map Divisions by Country page and deselect the legal entities that you no longer want.
InFusion Corporation is using the ESC to set up their enterprise structure. They have identified two divisions, one for Lighting, and one for Security. The Lighting division operates in Japan and the US, and the Security division operates in the UK and India.
This figure illustrates InFusion Corporation's enterprise structure.
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
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.
Oracle Fusion Applications support the modeling of your legal entities. If you make purchases from or sell to other legal entities, define these other legal entities in your customer and supplier registers, which are part of the Oracle Fusion Trading Community Architecture. When your legal entities are trading with each other, you represent both of them as legal entities and also as customers and suppliers in your customer and supplier registers. Use legal entity relationships to determine which transactions are intercompany and require intercompany accounting. Your legal entities can be identified as legal employers and therefore, are available for use in Human Capital Management (HCM) applications.
There are several decisions that need to be considered in creating your legal entities.
The importance of legal entity in transactions
Legal entity and its relationship to business units
Legal entity and its relationship to divisions
Legal entity and its relationship to ledgers
Legal entity and its relationship to balancing segments
Legal entity and its relationship to consolidation rules
Legal entity and its relationship to intercompany transactions
Legal entity and its relationship to worker assignments and legal employer
Legal entity and payroll reporting
Legal reporting units
All of the assets of the enterprise are owned by individual legal entities. Oracle Fusion Financials allow your users to enter legal entities on transactions that represent a movement in value or obligation.
For example, the creation of a sales order creates an obligation for the legal entity that books the order to deliver the goods on the acknowledged date, and an obligation of the purchaser to receive and pay for those goods. Under contract law in most countries, damages can be sought for both actual losses, putting the injured party in the same state as if they had not entered into the contract, and what is called loss of bargain, or the profit that would have made on a transaction.
In another example, if you revalued your inventory in a warehouse to account for raw material price increases, the revaluation and revaluation reserves must be reflected in your legal entity's accounts. In Oracle Fusion Applications, your inventory within an inventory organization is managed by a single business unit and belongs to one legal entity.
A business unit can process transactions on behalf of many legal entities. Frequently, a business unit is part of a single legal entity. In most cases the legal entity is explicit on your transactions. For example, a payables invoice has an explicit legal entity field. Your accounts payables department can process supplier invoices on behalf of one or many business units.
In some cases, your legal entity is inferred from your business unit that is processing the transaction. For example, your business unit A agrees on terms for the transfer of inventory to your business unit B. This transaction is binding on your default legal entities assigned to each business unit. Oracle Fusion Procurement, Oracle Fusion Projects, and Oracle Fusion Supply Chain applications rely on deriving the legal entity information from the business unit.
The division is an area of management responsibility that can correspond to a collection of legal entities. If desired, you can aggregate the results for your divisions by legal entity or by combining parts of other legal entities. Define date-effective hierarchies for your cost center or legal entity segment in your chart of accounts to facilitate the aggregation and reporting by division. Divisions and legal entities are independent concepts.
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.
Oracle Fusion General Ledger supports up to three balancing segments. Best practices recommend that one of these segments represents your legal entity to ease your requirement to account for your operations to regulatory agencies, tax authorities, and investors. Accounting for your operations means you must produce a balanced trial balance sheet by legal entity. If you account for many legal entities in a single ledger, you must:
Identify the legal entities within the ledger.
Balance transactions that cross legal entity boundaries through intercompany transactions.
Decide which balancing segments correspond to each legal entity and assign them in Oracle Fusion General Ledger Accounting Configuration Manager. Once you assign one balancing segment value in a ledger, then all your balancing segment values must be assigned. This recommended best practice facilitates reporting on assets, liabilities, and income by legal entity.
Represent your legal entities by at least one balancing segment value. You may represent it by two or three balancing segment values if more granular reporting is required. For example, if your legal entity operates in multiple jurisdictions in Europe, you might define balancing segment values and map them to legal reporting units. You can represent a legal entity by more than one balancing segment value, do not use a single balancing segment value to represent more than one legal entity.
In Oracle Fusion General Ledger, there are three balancing segments. You can use separate balancing segments to represent your divisions or strategic business units to enable management reporting at the balance sheet level for each division or business unit. For example, use this solution to empower your business unit and divisional managers to track and assume responsibility for their asset utilization or return on investment. Using multiple balancing segments is also useful when you know at the time of implementation that you are disposing of a part of a legal entity and need to isolate the assets and liabilities for that entity.
Note
Implementing multiple balancing segments requires every journal entry that is not balanced by division or business unit, to generate balancing lines. Also, you cannot change to multiple balancing segments easily after you have begun to use the ledger because your historical data is not balanced by the new multiple balancing segments. Restating historical data must be done at that point.
To use this feature for disposal of a part of a legal entity, implement multiple balancing segments at the beginning of the legal entity's corporate life or on conversion to Oracle Fusion.
If you decided to account for each legal entity in a separate ledger, there is no requirement to identify the legal entity with a balancing segment value within the ledger.
Note
While transactions that cross balancing segments don't necessarily cross legal entity boundaries, all transactions that cross legal entity boundaries must cross balancing segments. If you make an acquisition or are preparing to dispose of a portion of your enterprise, you may want to account for that part of the enterprise in its own balancing segment even if it is not a separate legal entity. If you do not map legal entities sharing the same ledger to balancing segments, you will not be able to distinguish them using the intercompany functionality or track their individual equity.
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.
Use Oracle Fusion Intercompany functionality for automatic creation of intercompany entries across your balancing segments. Intercompany processing updates legal ownership within the enterprise's groups of legal entities. Invoices or journals are created as needed. To limit the number of trading pairs for your enterprise, set up intercompany organizations and assign then to your authorized legal entities. Define processing options and intercompany accounts to use when creating intercompany transactions and to assist in consolidation elimination entries. These accounts are derived and automatically entered on your intercompany transactions based on legal entities assigned to your intercompany organizations.
Intracompany trading, in which legal ownership isn't changed but other organizational responsibilities are, is also supported. For example, you can track assets and liabilities that move between your departments within your legal entities by creating departmental level intercompany organizations.
Note
In the Oracle Fusion Supply Chain applications, model intercompany relationships using business units, from which legal entities are inferred.
Legal 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.
Your legal entities are required to pay payroll tax and social insurance such as social security on your payroll. In Oracle Fusion Applications, you can register payroll statutory units to pay and report on payroll tax and social insurance on behalf of many of your legal entities. As the legal employer, you might be required to pay payroll tax, not only at the national level, but also at the local level. You meet this obligation by establishing your legal entity as a place of work within the jurisdiction of a local authority. Set up legal reporting units to represent the part of your enterprise with a specific legal reporting obligation. You can also mark these legal reporting units as tax reporting units, if the legal entity must pay taxes as a result of establishing a place of business within the jurisdiction.
A business unit is a unit of an enterprise that performs one or many business functions that can be rolled up in a management hierarchy. A business unit can process transactions on behalf of many legal entities. Normally, it will have a manager, strategic objectives, a level of autonomy, and responsibility for its profit and loss. Roll business units up into divisions if you structure your chart of accounts with this type of hierarchy. In Oracle Fusion Applications, you assign your business units to one primary ledger. For example, if a business unit is processing payables invoices they will need to post to a particular ledger. This assignment is mandatory for your business units with business functions that produce financial transactions.
In Oracle Fusion Applications, use business unit as a securing mechanism for transactions. For example, if you run your export business separately from your domestic sales business, secure the export business data to prevent access by the domestic sales employees. To accomplish this security, set up the export business and domestic sales business as two separate business units.
The Oracle Fusion Applications business unit model:
Allows for flexible implementation
Provides a consistent entity for controlling and reporting on transactions
Anchors the sharing of sets of reference data across applications
Business units process transactions using reference data sets that reflect your business rules and policies and can differ from country to country. With Oracle Fusion Application functionality, you can choose to share reference data, such as payment terms and transaction types, across business units, or you can choose to have each business unit manage its own set depending on the level at which you wish to enforce common policies.
In countries where gapless and chronological sequencing of documents is required for subledger transactions, define your business units in alignment with your ledger definition, because the uniqueness of sequencing is only ensured within a ledger. In these cases, define a single ledger and assign one legal entity and business unit.
In summary, use business units in the following ways:
Management reporting
Processing of transactions
Security of transactional data
Reference data definition and sharing
Business units are used by a number of Oracle Fusion Applications to implement data security. You assign data roles to your users to give them access to data in business units and permit them to perform specific functions on this data. When a business function is enabled for a business unit, the application can trigger the creation of data roles for this business unit based on the business function's related job roles.
For example, if a payables invoicing business function is enabled, then it is clear that there are employees in this business unit that perform the function of payables invoicing, and need access to the payables invoicing functionality. Therefore, based on the correspondence between the business function and the job roles, appropriate data roles are generated automatically. Use Human Capital Management (HCM) security profiles to administer security for employees in business units.
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.
To create business units automatically, you must specify the level at which to create business units. Business units within your enterprise may be represented at the business function level, such as Sales, Consulting, Product Development, and so on, or they may be represented at a more detailed level, where a business unit exists for each combination of countries in which you operate and the functions in those countries.
You can automatically create business units at the following levels:
Country
Country and Division
Country and business function
Division
Division and legal entity
Division and business function
Business function
Legal entity
Business function and legal entity
Select the option that best meets your business requirements, but consider the following:
If you use Oracle Fusion Financials, the legal entity option is recommended because of the manner in which financial transactions are processed.
The business unit level that you select determines how the application automatically creates reference data sets.
After you select a business unit level, the application generates a list of business units, and you select the ones you want the application to create. If you select a level that has two components, such as country and division, then the system displays a table listing both components, and you select the check boxes at the intersections of the components.
The business units listed by the application are suggestions only, and are meant to simplify the process to create business units. You are not required to select all of the business units suggested. When you navigate to the next page in the ESC guided flow, which is the Manage Business Units page, you cannot delete any of the business units that were created automatically. You must return to the Create Business Units page and deselect any business units that you no longer want.
InFusion Corporation is using the Enterprise Structures Configurator to set up their enterprise structure. They have identified two divisions, one for Lighting, and one for Security. They operate in four countries: US, UK, Japan, and India, and they have created a legal entity for each of the countries. The sales and marketing functions are based in both India and Japan, while the US and the UK have only the sales function.
This figure illustrates InFusion Corporation's enterprise structure.
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 |
|
Country and Division |
|
Country and business function |
|
Division |
|
Division and Legal Entity |
|
Division and Business Function |
|
Business Function |
|
Legal Entity |
|
Legal Entity and Business Function |
|
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.
Oracle Fusion Applications reference data sharing feature is also known as SetID. The reference data sharing functionality supports operations in multiple ledgers, business units, and warehouses, thereby reducing the administrative burden and decreasing the time needed to implement new business units. For example, you can share sales methods, transaction types, or payment terms across business units or selected other data across asset books, cost organizations, or project units.
The reference data sharing features use reference data sets to which reference data is assigned. The reference data sets group assigned reference data. The sets can be understood as buckets of reference data assigned to multiple business units or other application components.
You begin this part of your implementation by creating and assigning reference data to sets. Make changes carefully as changes to a particular set will affect all business units or application components using that set. You can assign a separate set to each business unit for the type of object that is being shared. For example, assign separate sets for payment terms, transaction types, and sales methods to your business units.
Your enterprise can decide that some aspects of corporate policy should affect all business units and leave other aspects to the discretion of the business unit manager. This allows your enterprise to balance autonomy and control for each business unit. For example, if your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level, you can let managers define their own sales methods, but define payment terms centrally. In this case, each business unit would have its own reference data set for sales methods, and there would be one central reference data set for payment terms assigned to all business units.
The reference data sharing is especially valuable for lowering the cost of setting up new business units. For example, your enterprise operates in the hospitality industry. You are adding a new business unit to track your new spa services. The hospitality divisional reference data set can be assigned to the new business unit to quickly setup data for this entity component. You can establish other business unit reference data in a business unit specific reference data set as needed
There are variations in the methods used to share data in reference data sets across different types of objects. The following list identifies the methods:
Assignment to one set only, no common values allowed. The simplest form of sharing reference data that allows assigning a reference data object instance to one and only one set. For example, Asset Prorate Conventions are defined and assigned to only one reference data set. This set can be shared across multiple asset books, but all the values are contained only in this one set.
Assignment to one set only, with common values. The most commonly used method of sharing reference data that allows defining reference data object instance across all sets. For example, Receivables Transaction Types are assigned to a common set that is available to all the business units without the need to be explicitly assigned the transaction types to each business unit. In addition, you can assign a business unit specific set of transaction types. At transaction entry, the list of values for transaction types includes transaction types from the set assigned to the business unit, as well as transaction types assigned to the common set that is shared across all business units.
Assignment to multiple sets, no common values allowed. The method of sharing reference data that allows a reference data object instance to be assigned to multiple sets. For instance, Payables Payment Terms use this method. It means that each payment term can be assigned to one or more than one set. For example, you assign the payment term Net 30 to several sets, but the payment term Net 15 is assigned to only your corporate business unit specific set. At transaction entry, the list of values for payment terms consists of only one set of data; the set that is assigned to the transaction's business unit.
Note: Oracle Fusion Applications contains a reference data set called Enterprise. Define any reference data that affects your entire enterprise in this set.
Reference data sharing is a feature within Oracle Fusion that enables you to group set-enabled reference data such as jobs or grades so that the data can be shared across different parts of the organization. Sets also enable you to filter reference data at the transaction level so that only data that has been assigned to certain sets is available to select. To filter reference data, Oracle Fusion Human Capital Management (HCM), applications use the business unit on the transaction. To set up reference data sharing in Oracle Fusion HCM, you create business units and sets, and then assign the sets to the business units.
Some reference data in your organization may be considered global, and should therefore be made available for use within the entire enterprise. You can assign this type of data to the Common Set, which is a predefined set. Regardless of the business unit on a transaction, reference data that has been assigned to the Common Set will always be available, in addition to the reference data that has been assigned to the set that corresponds to the business unit on the transaction.
Other types of reference data may be specific to certain business units, so you want to restrict the use of the data to those business units. In this case, you can create sets specifically for this type of data, and assign the sets to the business units.
When you assign reference data sets to business units, you assign a default reference data set that will be used for all reference data types for that business unit. You can override the set assignment for one or more data types.
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.
When deciding how to create business units, InFusion decides to create them using the country and business function level. Therefore, they created the following business units:
Sales_Japan
Marketing_Japan
Sales_US
Sales_UK
Marketing_India
Sales_India
Because locations, departments, and grades are specific to each business unit, InFusion does not want to share these types of reference data across business units. They will create a reference data set for each business unit so that data of those types can be set up separately. Because the jobs in the Sales business function are the same across many locations, InFusion decides to create one additional set called Jobs and they will override the set assignment for the Jobs reference data group and assign it to the Jobs set. Based on these requirements, they create the following sets:
Sales_Japan_Set
Mktg_Japan_Set
Sales_US_Set
Sales_UK_Set
Mktg_India_Set
Sales_India_Set
Grades_Set
InFusion assigns business units to sets as follows:
Business Unit |
Default Set Assignment |
Set Assignment Overrides |
---|---|---|
Sales_Japan |
Sales_Japan_Set for grades, departments, and locations |
Jobs set for jobs |
Marketing_Japan |
Mktg_Japan_Set for grades, departments, and locations |
None |
Sales_US |
Sales_US_Set for grades, departments, and locations |
Jobs set for jobs |
Sales_UK |
Sales_UK_Set for grades, departments, and locations |
Jobs set for jobs |
Marketing_India |
Mktg_India_Set for grades, departments, and locations |
None |
Sales_India |
Sales_India_Set for grades, departments, and locations |
Jobs set for jobs |
When setting up grades, departments, and locations for the business units, InFusion will assign the data to the default set for each business unit. When setting up jobs, they will assign the Jobs set and will assign the Common Set to any jobs that may be used throughout the entire organization.
When using grades, departments, and locations at the transaction level, users will be able to select data from the set that corresponds to the business unit that they enter on the transaction, and any data that was assigned to the Common Set. For example, for transactions for the Marketing_Japan business unit, grades, locations, and departments from the Mktg_Japan_Set will be available to select, as well as from the Common Set.
When using jobs at the transaction level, users will be able to select jobs from the Jobs set and from the Common Set when they enter one of the Sales business units on the transaction. For example, when a manager hires an employee for the Sales_India business unit, the list of jobs will be filtered to show jobs from the Jobs set and from the Common Set.
The following figure illustrates what sets of jobs can be accessed when a manager creates an assignment for a worker.
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.
The common set is a predefined set that enables you to share reference data across business units. When you select set-enabled data at the transaction level, the list of values includes data in both the common set and the set associated with the data type for the business unit on the transaction. For example, when you create an assignment, the list of values for grades will include both grades in the common set and in the set that is assigned to grades for the business unit in which you creating the assignment.
Jobs and positions represent roles that enable you to distinguish between tasks and the individuals who perform those tasks. The key to whether to use jobs or positions is how each is used. Positions offer a well-defined space independent of the person performing the job. Jobs are a space defined by the person. A job can be defined globally in the Common Set, whereas a position is defined within one business unit.
You can update the job and department of a position at any time. This is useful if you hire someone into a new role and want to transfer the position to another department.
During implementation, one of the earliest decisions you will make is whether to use jobs or a combination of jobs and positions. The determinants for this decision are:
The primary industry of your enterprise
How you manage your people
Primary industries and how they usually set up their workforce are listed in the table below.
Primary Industry |
Workforce Setup |
---|---|
Mining |
Positions |
Utilities |
Positions |
Manufacturing |
Positions |
Retail Trade |
Positions |
Transportation and Warehousing |
Positions |
Educational Services |
Positions |
Public Transportation |
Positions |
Agriculture, Forestry, Fishing, and Hunting |
Jobs |
Construction |
Jobs |
Wholesale Trade |
Jobs |
Information |
Jobs |
Finance and Insurance |
Jobs |
Professional, Scientific, and Technical Services |
Jobs |
Management of Companies and Enterprises |
Jobs |
Administrative and Support and Waste Management and Remediation Services |
Jobs |
Arts, Entertainment, and Recreation |
Jobs |
Accommodation and Food Services |
Jobs |
Other Services (Except Public Administration) |
Jobs |
The following table displays suggestions of whether to use jobs or a combination of jobs and positions based on your industry and how you manage your employees when there is turnover.
Industry |
We always replace employees by rehiring to same role |
We replace the head count, but the manager can use the head count in a different job |
We rehire to the same position, but the manager can request a reallocation of budget to a different post |
---|---|---|---|
Project (An industry that supports project-based forms of organization in which teams of specialists from both inside and outside the company report to project managers.) |
Positions |
Jobs |
Jobs |
Controlled (An industry that is highly structured in which all aspects of work and remuneration are well organized and regulated.) |
Positions |
Positions |
Positions |
Manufacturing |
Positions |
Jobs |
Positions |
Retail |
Positions |
Jobs |
Positions |
Education |
Positions |
Jobs |
Positions |
Other |
Positions |
Jobs |
Jobs |
Positions are typically used by industries that use detailed approval rules, which perform detailed budgeting and maintain head counts, or have high turnover rates.
ABC Corporation has high turnover. It loses approximately 5% of their cashiers monthly. The job of cashier includes three positions: front line cashier, service desk cashier, and layaway cashier. Each job is cross trained to take over another cashier position. When one cashier leaves from any of the positions, another existing cashier from the front line, service desk or layaway can assist where needed. . But to ensure short lines and customer satisfaction, ABC must replace each cashier lost to turnover.
Since turnover is high in retail it is better for this industry to use positions. There is an automatic vacancy when an employee terminates employment. The position exists even when there are no holders. This is important if the person who leaves the company is a manager or supervisor with direct reports. All direct reports continue reporting to the position even if it is empty. You do not need to reassign these employees to another manager or supervisor; the replacement manager is assigned to the existing position.
Also, an advantage to using positions is that when you hire somebody new many of the attributes are defaulted in from the position. This speeds up the hiring process.
This figure illustrates the retail position setup.
The hospital has a structured head count and detailed budgeting. For example, a specific number of surgeons, nurses, and interns of various types are needed. These positions need to be filled in order for the hospital to run smoothly. Use jobs and positions if you need to apply detailed head count rules.
Health care is an industry that needs to regulate employment, roles, and compensation according to strict policies and procedures. Fixed roles tend to endure over time, surviving multiple incumbents. Industries that manage roles rather than individuals, where roles continue to exist after individuals leave, typically model the workforce using positions.
This figure illustrates the hospital position setup.
Jobs are typically used without positions by service industries where flexibility and organizational change are key features.
For example, XYZ Corporation has a director over the departments for developers, quality assurance, and technical writers. Recently, three developers have left the company. The director decides to redirect the head count to other areas. Instead of hiring all three back into development, one person is hired to each department, quality assurance, and technical writing.
In software industries, the organization is fluid. Using jobs gives an enterprise the flexibility to determine where to use head count, because the job only exists through the person performing it. In this example, when the three developers leave XYZ Corporation, their jobs no longer exist, therefore the corporation has the flexibility to move the headcount to other areas.
This figure illustrates the software industry job setup.
Job and position structures 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.
When you define a job, you enter a value for the name of the job. To make job names more specific, set up attributes that enable you to identify additional details about the job, such as the nature of the work that is performed or the relative skill level required for the job. If these attributes apply to all jobs within your enterprise, set up enterprise-level job attributes. Standard capabilities mean that you can use the different segments of the name to identify common jobs or job holders for analysis or compensation, or for grouping records in reports, for example, to find all jobs of a specific job type. You should not use attributes with values that change regularly, for example, salary ranges or expense approval levels that change every year.
This figure illustrates how job type and job level provide further details for the HR Application Specialist job.
Position attributes at the enterprise level are similar to those for jobs. Each position that you define identifies a specific role in the enterprise, which you can manage independently of the person in the position, and it will belong to one specific department or organization. The name of each position must be unique. To simplify the process of managing unique names for positions, set up enterprise-level attributes to identify separate components of the position name. For example, you can set up an attribute for position title and one for position number. When defining the attributes that make up the structure of a position name you should also consider if any of your attributes are part of the definition of a common job type. Using job types for a position can help you manage common information that applies to many different positions. For example you can define a job type of Manager.Level 1 and use this for comparison of positions across departments or lines or business, or for setting common job requirements. You can then define multiple manager type positions in your HR department, each of which has responsibility for a different management function or group.
This figure illustrates how title and position number provide further details for the manager position.
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.
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.
The Enterprise Structures Configurator is an interview-based tool that guides you through setting up divisions, legal entities, business units, and reference data sets. The tool also enables you to assign reference data sets to business units and locations. You can set up multiple configurations to perform what-if scenarios, and then print each configuration to compare the resulting enterprise structure. If you do not use the Enterprise Structures Configurator, then you must set up your enterprise structure using the individual tasks that correspond to each enterprise component. In addition, you will not be able to set up multiple configurations and compare different scenarios. It is recommended that you use the Enterprise Structures Configurator.
The legal entity that represents the top level in your organization hierarchy, as defined by the legal name entered for the enterprise. This designation is used only to create an organization tree, with the ultimate holding company as the top level, divisions and country holding companies as the second level, and legal employers as the third level.
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.
For the selected business unit, you can override the default reference data set for one or more reference data groups. For example, assume you have three reference data groups: Vision 1 SET, Vision 2 SET, and Vision 3 SET, where Vision SET 1 is the default set for business unit United Kingdom Vision 1 BU. You can override the default so that grades are assigned to Vision 2 SET, departments are assigned to Vision 3 SET, and jobs are assigned to the default set, Vision 3 SET.
Reference data sharing facilitates sharing of configuration data such as jobs and payment terms, across organizational divisions or business units. You define reference data sets and determine how the data is shared or partitioned. Use reference data sets to reduce duplication and maintenance by sharing common data across business entities where appropriate. Depending on the requirement (specific or common), each business unit can maintain its data at a central location, using a set of values either specific to it or shared by other business units.
You can share reference data after it is filtered on the basis of sets. A common reference data set is available as the default set, which can be assigned to several business units sharing the same reference data. For commonly used data such as currencies, you can use the common reference data set and assign it to multiple business units in various countries that use the same currency. In cases where the default set cannot be assigned to an entity, you can create specific sets. The data set visible on the transactional page depends on the sharing method used to share reference data.
For example, XYZ Corporation uses the same grades throughout the entire organization. Instead of managers in different business units setting up the same grades, XYZ Corporation decides to create a set called Grades and assign the grades reference data group for all business units in the organization to the Grades set, so that the grades can be shared.
Note
For specific information on configuring reference data sharing for a particular object or product, refer to its product documentation.
Reference data sets are logical groups of reference data that can be accessed by various transactional entities depending on the business context. Oracle Fusion Applications contains a common reference data set as well as an enterprise set that may be used as a default set. Depending on your business requirement you can create and maintain additional reference data sets, while continuing to use the common reference data set.
Consider the following scenario.
Your enterprise can decide that some aspects of corporate policy should affect all business units and leave other aspects to the discretion of the business unit manager. This allows your enterprise to balance autonomy and control for each business unit. For example, if your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level, you can let managers define their own sales methods, but define payment terms centrally. In this case, each business unit would have its own reference data set for sales methods, and there would be one central reference data set for payment terms assigned to all business units.
The partitioning of reference data and creation of data sets enable you to create reference entities across tables or lookup types, and share modular information and data processing options among business units. With the help of partitioning, you can choose to create separate sets and subsets for each business unit depending upon its business requirement, or create common sets or subsets to enable sharing reference data between several business units, without the need for duplicating the reference data. Partitioning provides you the flexibility to handle the reference data in a way appropriate to your business needs.
The following figure illustrates the reference data sharing method (assignment to one set only, with common values) where the user can access the data assigned to a specific set in a particular business unit, as well as access the data assigned to the common set.
Oracle Fusion Applications reference data sharing feature is also known as SetID. The reference data sharing functionality supports operations in multiple ledgers, business units, and warehouses, thereby reducing the administrative burden and decreasing the time needed to implement new business units. For example, you can share sales methods, transaction types, or payment terms across business units or selected other data across asset books, cost organizations, or project units.
The reference data sharing features use reference data sets to which reference data is assigned. The reference data sets group assigned reference data. The sets can be understood as buckets of reference data assigned to multiple business units or other application components.
You begin this part of your implementation by creating and assigning reference data to sets. Make changes carefully as changes to a particular set will affect all business units or application components using that set. You can assign a separate set to each business unit for the type of object that is being shared. For example, assign separate sets for payment terms, transaction types, and sales methods to your business units.
Your enterprise can decide that some aspects of corporate policy should affect all business units and leave other aspects to the discretion of the business unit manager. This allows your enterprise to balance autonomy and control for each business unit. For example, if your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level, you can let managers define their own sales methods, but define payment terms centrally. In this case, each business unit would have its own reference data set for sales methods, and there would be one central reference data set for payment terms assigned to all business units.
The reference data sharing is especially valuable for lowering the cost of setting up new business units. For example, your enterprise operates in the hospitality industry. You are adding a new business unit to track your new spa services. The hospitality divisional reference data set can be assigned to the new business unit to quickly setup data for this entity component. You can establish other business unit reference data in a business unit specific reference data set as needed
There are variations in the methods used to share data in reference data sets across different types of objects. The following list identifies the methods:
Assignment to one set only, no common values allowed. The simplest form of sharing reference data that allows assigning a reference data object instance to one and only one set. For example, Asset Prorate Conventions are defined and assigned to only one reference data set. This set can be shared across multiple asset books, but all the values are contained only in this one set.
Assignment to one set only, with common values. The most commonly used method of sharing reference data that allows defining reference data object instance across all sets. For example, Receivables Transaction Types are assigned to a common set that is available to all the business units without the need to be explicitly assigned the transaction types to each business unit. In addition, you can assign a business unit specific set of transaction types. At transaction entry, the list of values for transaction types includes transaction types from the set assigned to the business unit, as well as transaction types assigned to the common set that is shared across all business units.
Assignment to multiple sets, no common values allowed. The method of sharing reference data that allows a reference data object instance to be assigned to multiple sets. For instance, Payables Payment Terms use this method. It means that each payment term can be assigned to one or more than one set. For example, you assign the payment term Net 30 to several sets, but the payment term Net 15 is assigned to only your corporate business unit specific set. At transaction entry, the list of values for payment terms consists of only one set of data; the set that is assigned to the transaction's business unit.
Note: Oracle Fusion Applications contains a reference data set called Enterprise. Define any reference data that affects your entire enterprise in this set.
You can assign the reference data sets to reference objects on the Manage Reference Data Set Assignments page. For multiple assignments, you can classify different types of reference data sets into groups and assign them to reference entity objects. The assignment takes into consideration the determinant type, determinant, and reference group, if any.
The partitioned reference data is shared based on a business context setting called the determinant type. It is the point of reference used in the data assignment process. The following table lists the determinant types used in the reference data assignment.
Type |
Description |
---|---|
Asset Book |
Information about the acquisition, depreciation, and retirement of an asset that belongs to a ledger or a business unit. |
Business Unit |
The departments or organizations within an enterprise. |
Cost Organization |
The organization used for cost accounting and reporting on various inventory and cost centers within an enterprise. |
Project Unit |
A logical organization within an enterprise that is responsible for enforcing consistent project management practices. |
Reference Data Set |
References to other shared reference data sets. |
The determinant or determinant value is the value that corresponds to the selected determinant type. The determinant is one of the criteria for selecting the appropriate reference data set. For example, when managing set assignments for the set determinant type, Reference Data Set is the determinant type, and you would enter the corresponding set code value as the corresponding determinant value.
A transactional entity may have multiple reference entities (generally considered to be setup data) that are treated in the same manner because of commonness in implementing business policies and legal rules. Such reference entities in your application are grouped into logical units called reference groups, based on the functional area and the partitioning requirements that they have in common. For example, all tables and views that define Sales Order Type details might be part of the same reference group.
Note
The reference groups are predefined in the reference groups table and are available for selection and assignment.
Some products required special logic for reference data sharing and have implemented their own domain specific ways for sharing data.
Items and supplier sites are two such product specific reference data objects that use product specific mechanisms to share data.
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 need to continue to operate your lines of business separately, maintaining a second item master might be the best decision.
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
The following list contains the reference data objects for the Oracle Fusion Applications that can be shared across business units and the method in which the reference data for each is shared.
Application Name |
Reference Data Object |
Method of Sharing |
---|---|---|
Trading Community Model |
Customer Account Relationship |
Assignment to one set only, with common values |
Trading Community Model |
Customer Account Site |
Assignment to one set only, with common values |
Trading Community Model |
Sales Person |
Assignment to one set only, with common values |
Opportunity Management |
Sales Method Group |
Assignment to one set only, with common values |
Work Management |
Assessment Templates |
Assignment to one set only, with common values |
Enterprise Contracts |
Contract Types |
Assignment to one set only, with common values |
Sales |
Sales Method |
Assignment to one set only, with common values |
Common Components |
Activity Templates |
Assignment to one set only, with common values |
Payables |
Payment Terms |
Assignment to multiple sets, no common values allowed |
Receivables |
Accounting Rules |
Assignment to one set only, with common values |
Receivables |
Aging Buckets |
Assignment to one set only, with common values |
Receivables |
Auto Cash Rules |
Assignment to one set only, with common values |
Receivables |
Collectors |
Assignment to one set only, with common values |
Receivables |
Lockbox |
Assignment to one set only, with common values |
Receivables |
Memo Lines |
Assignment to one set only, with common values |
Receivables |
Payment 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 one set only, with common values |
Performance Management |
Performance Templates |
Assignment to one set only, with common values |
Human Resources |
Departments |
Assignment to one set only, with common values |
Human Resources |
Jobs |
Assignment to one set only, with common values |
Human Resources |
Locations |
Assignment to one set only, with common values |
Human Resources |
Grades |
Assignment to one set only, with common values |
Project Billing |
Project and Contract Billing |
Assignment to multiple sets, common values not allowed |
Project Foundation |
Project Accounting Definition |
Assignment to one set only, no common values allowed |
Project Foundation |
Project Rates |
Assignment to one set only, with common values |
Distributed Order Orchestration |
Hold Codes |
Assignment to one set only, with common values |
Distributed Order Orchestration |
Orchestration Process |
Assignment to one set only, with common values |
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 |
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 |
The following list 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 |
An enterprise consists of legal entities under common control and management.
When implementing Oracle Fusion Applications you operate within the context of an enterprise that has already been created in the application for you. This is either a predefined enterprise or an enterprise that has been created in the application by a system administrator.
An enterprise organization captures the name of the deploying enterprise and the location of the headquarters. There is normally a single enterprise organization in a production environment. Multiple enterprises are defined when the system is used to administer multiple customer companies, for example, multiple tenants, or when a customer chooses to set up additional enterprises for testing or development.
Oracle Fusion Applications offers capabilities for multiple tenants to share the same applications instance for some human resources processes. If you offer business process outsourcing services to a set of clients, each of those clients may be represented as an enterprise within an Oracle Fusion Application instance. To support this functionality, system owned reference data such as sequences, sets, and flexfields are also defined within an enterprise.
In Oracle Fusion Applications, an organization classified as an enterprise is defined before defining any other organizations in the HCM Common Organization Model. All other organizations are defined as belonging to an enterprise.
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.
A location identifies physical addresses of a workforce structure, such as a department or a job. You can also create locations to enter the addresses of external organizations that you want to maintain, such as employment agencies, tax authorities, and insurance or benefits carriers.
The locations that you create exist as separate structures that you can use for reporting purposes, and also in rules that determine employee eligibility for various types of compensation and benefits. You enter information about a location only once. Subsequently, when you set up other workforce structures you select the location from a list.
When you create a location, you must associate it with a set. Only those users who have access to the set's business unit can access the location set and other associated workforce structure sets, such as those that contain departments and jobs.
You can also associate the location to the common set so that users across your enterprise can access the location irrespective of their business unit. When users search for locations, they can see the locations that they have access to along with the locations in the common set.
The following figure shows how locations sets restrict access to users.
If you have a list of locations already defined for your enterprise, you can upload them from a spreadsheet. To use this option, you first download a spreadsheet template, then add your location information to the spreadsheet, and then upload directly to your enterprise configuration. You can upload the spreadsheet multiple times to accommodate revisions.
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.
The calendar events that were created for the geographical node start to apply for the location and may impact the availability of worker assignments at that location. The geographical hierarchy nodes available for selection on the Locations page display from a predefined geographic hierarchy.
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.
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.
From the Manage Locations page in Oracle Fusion Global Human Resources.
To appear on the Create or Edit Location pages, your inventory organization must be effective on today's date and must exist in the location set that you selected.
Address cleansing provides a way to validate, correct, and standardize addresses that are entered in a user interface. Geography validation only validates the geography attributes of an address, for example, State, City, and Postal codes; address cleansing validates both the geography attributes and the address line attributes.
Address cleansing can only be used through the Oracle Fusion Trading Community Data Quality product, because the feature is delivered using Data Quality integration. You need to ensure that you have a license for the countries that will use Trading Community Data Quality data cleansing.
You can specify the real time address cleansing level for each country by choosing either None, meaning that there is no real time address cleansing, or by choosing Optional, meaning that you will have the choice to cleanse addresses. Once you have enabled address cleansing for a country a Verify Address icon appears at address entry points in the application. You can then click the icon to perform address cleansing and receive a corrected, standardized address. If Trading Community Data Quality does not find a matching address the application will alert you.
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.
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.
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.
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.
A geography structure is a hierarchical grouping of geography types for a country. For example, the geography structure for the United States is the geography type of State at the top, then followed by the County, then the City, and finally the Postal Code.
You can use the geography structure to establish:
How geographies can be related
The types of geographies you can define for the country
You can determine how a country's geographies are hierarchically related by creating the hierarchy of the geography types in the geography structure. When you define a country's structure the country geography type is implicitly at the top of the geography structure, and the numbering of the subsequent levels start with 1 as the next geography level after country.
You must add a geography type as a level in the country structure before you can define a geography for that geography type in a country. For example, before defining the state of California, the State geography type must be added to the United States country structure. Only one geography type can be used for each level, you cannot define more than one geography type at the same level.
Note
After you first define a country structure you can only add geography types below the current lowest level, and delete geography types without defined geographies.
To simplify the creation of a country structure you can copy a structure from another country, and then amend the geography type hierarchy for the country.
The application provides you with a set of available master reference geography types. If required, you can create a geography type before adding it to the country structure. Each geography type is added below the current lowest level.
Note
If you want to delete a geography type that is not at the lowest level in the country structure, then you have to delete the geography type level and all the levels below it.
A geography type that you create within the country structure can be used for other country structures as well.
Geography hierarchy is a data model that lets you establish conceptual parent-child relationships between geographies. A geography, such as Tokyo or Peru, describes a boundary on the surface of the earth. The application can extrapolate information based on this network of hierarchical geographical relationships.
For example, in the geography hierarchy the state of California is defined as the parent of San Mateo county, which is the parent of Redwood City, which is the parent of the postal code 94065. If you enter just 94065, the application can determine that the postal code is in California, or that the corresponding city is Redwood City.
The application leverages geography hierarchy information to facilitate business processes that rely on geography information, for example, tax calculation, order sourcing rules, sales territory definition. The geography hierarchy information is centrally located in the Trading Community Model and shared among other application offerings.
The top level of the geography hierarchy is Country, so the hierarchy essentially contains countries and their child geographies. Other aspects of the geography hierarchy include:
Geography
Geography type
Geography usage
Master reference geography hierarchy
User defined zones
A geography is a boundary such as a country, state, province or city. It is a physical space with boundaries that is a defined instance of a geography type. For example, San Jose is a geography of the City geography type.
Geography types are a divisional grouping of geographies, which can be either geopolitical (for example, City, Province, and District) or user defined (for example, Continent, Country Regions, Tax Regions).
Geography usage indicates how a geography type or geography is used in the application. A master reference geography always has the usage of Master Reference. User defined zones can have the usages of Tax, Shipping, or Territory, based on what is relevant for their purpose.
The geography hierarchy data is considered to be the single source of truth for geographies. It is all the data, including geography types and geographies, that you define and maintain in the Trading Community Model tables.
The geography usage for the entire hierarchy is the master reference, and defined geography types and geographies are considered as master reference geography types and geographies. For example, Country is a universally recognized geography type, and United States is considered a master geography.
User defined zones are a collection of geographical data, created from master reference data for a specific purpose. For example, territory zones are collections of master reference geographies ordered in a hierarchy. Tax and shipping zones are collections of master reference geographies without a hierarchical grouping.
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
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.
Once a geography type is mapped to an attribute, then you can specify whether the geography type will appear in a list of values during address entry in user interfaces. It is very important to review carefully if you want to enable a list of values. You should only enable a list of values if you have sufficient geography data imported or created for that geography. Once you have enabled a list of values for an address attribute, you can only select the geography data available for the geography type. This means that if a specific geography value is not available in the geography hierarchy, you cannot create an address with a different geography value.
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.
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.
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.
Note
The Geography Dimension value in territories is derived from sell-to addresses of sales accounts. To use geography dimensions in territories, ensure that the geography elements in addresses, such as state, city, and postal code, are validated. You can do so by enabling geography validation for each country using the Manage Geographies task. While doing so, ensure that at least one level in the geography hierarchy is enabled for geography validation. It is recommended that you enable geography validation for all geography levels that you intend to use for territory definition for each country. You can 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 also set geography validation control to Error in the Manage Geography Validation page. This ensures that users can only use valid geography elements in addresses. If you have already created addresses before setting up geography validation for a country, you must execute the Run Maintain Geography Name Referencing task for that country after enabling geography validation to ensure that all your geography elements are validated.
A geography, such as Tokyo or Peru, describes a boundary on the surface of the earth. You can create new geographies by importing data through interface tables. There are two options for populating the interface tables: using the tool of your preference to load the data or using file-based data import. If you plan to provide the data details in a source file, use the file-based import feature. If you will populate the interface table directly, run the geography loader process to import the data. Having a good understanding of the import entity, interface table, and destination table will help you prepare your import data.
Consider the following when importing geographies:
File-based import option
Geography loader process option
Import object entity, interface table, and destination tables
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.
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.
The geography import object consists of one entity and interface table that forms the geography. If you are using file-based import, you can map your source file data to import entity attributes that correspond to the interface table columns. The import activity process populates the interface table based on the mapping and your source file. If using the geography loader scheduled process, populate the interface table directly using your preferred tool. If you need the unique IDs of existing application data for your import data, use the Define Data Export Setup and Maintenance task list to export the information.
Note
Spreadsheets containing detailed information about each interface table, including the import attributes, corresponding interface table columns, defaults, and validations, are available from the Oracle Enterprise Repository by searching on a specific interface table name or initiating a search using the FusionApps: Interface Table asset type.
The following lists the object entity, tables, and resulting application object:
File-Based Import Entities |
Interface Tables |
Destination Tables |
Application Object |
---|---|---|---|
ImpGeography |
HZ_IMP_GEOGRAPHIES_T |
HZ_GEOGRAPHIES HZ_GEOGRAPHY_IDENTIFIERS HZ_GEOGRAPHY_TYPES_B HZ_HIERARCHY_NODES |
Geography |
This example demonstrates how to import data using the File-Based Data Import tool. In this particular example you have a source file containing geography data that you want to import into the application, so that the geography data can be used for uses related to locations, such as real time address validation and tax purposes.
The following table summarizes the key decisions for this scenario:
Decisions to Consider |
In This Example |
---|---|
What type of object are you importing? |
Geography |
What file type are you using for your source data? |
Text file |
Where are you uploading your source data file from? |
Your desktop |
What data type is your source data file? |
Comma separated |
Which fields are you importing into Oracle Fusion applications? |
All, except for the RecordTypeCode field |
When do you want to process the import? |
Immediately |
These are the steps that are required to create an import activity and submit the import:
Determine what information is in the source file.
Create and schedule the import activity.
Monitor the import results.
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 |
You create an import activity, enter the import details, and schedule the import. An import activity definition provides the instructions for the import processing - this includes selecting the source file, or file location; mapping fields from the source file to the Oracle Fusion object and attribute; and scheduling the import.
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.
Column Header |
Example Value |
Ignore |
Object |
Attribute |
---|---|---|---|---|
Primary Geography Name |
Primary Geography Name |
United States |
Imp Geography |
Primary Geography Name |
Country Code |
US |
No |
Imp Geography |
Country Code |
Record Type Code |
0 |
Yes |
Imp Geography |
Record Type Code |
Source ID |
10265 |
No |
Imp Geography |
Source ID |
Parent Source ID |
1053 |
No |
Imp Geography |
Parent Source ID |
If you do not want to import a column in the text file you can select Ignore.
Note
If you have any difficulties mapping the fields from your source file to the relevant Oracle Fusion applications object, you can use the import object spreadsheets for reference.
Instead of immediately importing the data, you can choose a date and time to start the import. You can also specify if the import will be repeated, and the frequency of the repeated import.
You monitor the progress of the Import Activity processing, and view completion reports for both successful records and errors.
Once the import activity has completed, the Status field value will change to Completed.
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 Oracle Fusion applications instance, and then after the territory geography zones are defined you can export the territory zones and import them into another Oracle Fusion applications instance.
To define your territory geography zones and then import your territory zones into another Oracle Fusion applications instance, you need to complete the following steps:
Import the master reference geography data into the Oracle Fusion application.
Define your territory geography zones using the Manage Territory Geographies task.
Export the territory geography zones.
Import the territory geography zones into another Oracle Fusion applications instance.
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.
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.
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.
Once you have downloaded your configuration package for your territory geography zone setup, you can import the territory zones into another Oracle Fusion 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 Oracle Fusion instance before you import the configuration package.
This example shows how to start the configuration of the geography structure, hierarchy, and validation for the country geography of the United Kingdom.
The following table summarizes the key decisions for this scenario.
Decisions to Consider |
In This Example |
---|---|
Copy an existing country structure? |
No, create a new country structure. |
What is the structure of the geography types? |
Create geography types with the following ranking structure:
|
What is the geography hierarchy? |
Create the following hierarchy:
|
Which address style format will you use when mapping geography validations? |
The default address style format, called the No Styles Format. |
Are you using Oracle Fusion Tax for tax purposes? |
No, do not select Tax Validation for the geography types. |
Add the County and Post Town geography types to the geography structure. Then add the geographies for the County and Post Town geography types to define the geography hierarchy. Finally, specify the geography validations for the geography types you have added to the geography structure.
You add the County and Post Town geography types to the United Kingdom geography structure.
You want to begin to create the geography hierarchy for the United Kingdom, so you add the geographies for the County and Post Town geography types using the geography hierarchy User Interfaces. You can also use the Manage File Import Activities task to import geography hierarchies using a csv or xml file.
Now you want to specify the geography validations for the geography types you have added to the United Kingdom. You define the geography mapping and validation for the United Kingdom default address style format. You map the geography types to attributes, enable the geography types for Lists of Values and Geography validation, and set the geography validation level.
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.
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.
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.
Yes. However, the geography type for the geography that you want to add must be already added to the country geography structure.
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.
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.
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 first create a legal entity, the Oracle Fusion Legal Entity Configurator automatically creates one legal reporting unit for that legal entity with a registration.
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
For each legal entity, select an identifying jurisdiction. An identifying jurisdiction is your first jurisdiction you must register with to be allowed to do business in a country. If there is more than one jurisdiction that a legal entity needs to register with to commence business, select one as the identifying jurisdiction. Typically the identifying jurisdiction is the one you use to uniquely identify your legal entity.
Income tax jurisdictions and transaction tax jurisdictions do not represent the same jurisdiction. Although in some countries, the two jurisdictions are defined at the same geopolitical level, such as a country, and share the same legal authority, they are two distinct jurisdictions.
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.
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.
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.
Define legal jurisdictions and related legal authorities to support multiple legal entity registrations, which are used by Oracle Fusion Tax and Oracle Fusion Payroll.
Create a legal jurisdiction by following these steps:
Navigate to the Manage Legal Jurisdictions page from the Setup and Maintenance work area by querying on the Manage Legal Jurisdictions task and selecting Go to Task.
Select Create.
Enter a unique Name, United States Income Tax.
Select a Territory, United States.
Select a Legislative Category, Income tax.
Select Identifying, Yes. Identifying indicates the first jurisdiction a legal entity must register with to do business in a country.
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.
Select a Legal Entity Registration Code, EIN or TIN.
Select a Legal Reporting Unit Registration Code, Legal Reporting Unit Registration Number.
Optionally enter one or more Legal Functions.
Select Save and Close.
Create a legal address for legal entities and reporting units by following these steps:
Navigate to the Manage Legal Address page from the Setup and Maintenance work area by querying on the Manage Legal Address task and selecting Go to Task.
Select Create.
Select Country.
Enter Address Line 1, Oracle Parkway.
Optionally enter Address Line 2, and Address Line 3.
Enter or Select Zip Code, 94065.
Select Geography 94065 and Parent Geography Redwood Shores, San Mateo, CA.
Optionally enter a Time Zone, US Pacific Time.
Select OK.
Select Save and Close.
Create a legal authority by following these steps:
Navigate to the Manage Legal Authorities page from the Setup and Maintenance work area by querying on the Manage Legal Authorities task and selecting Go to Task.
Enter the Name, California Franchise Tax Board.
Enter the Tax Authority Type, Reporting.
Note
Create an address for the legal authority.
Select Create.
The Site Number is automatically assigned.
Optionally enter a Mail Stop.
Select Country, United States
Enter Address Line 1, 121 Spear Street, Suite 400.
Optionally enter Address Line 2, and Address Line 3.
Enter or Select Zip Code, 94105.
Select Geography 94105 and Parent Geography San Francisco, San Francisco, CA.
Select OK.
Optionally enter a Time Zone, US Pacific Time.
Optionally click the One-Time Address check box.
The From Date defaults to today's date. Update if necessary.
Optionally enter a To Date to indicate the last day the address can be used.
Note
You can optionally enter Address Purpose details.
Select Add Row.
Select Purpose.
The Purpose from Date will default to today's date.
Optionally enter a Purpose to Date.
Select OK.
Select Save and Close.
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.
From within an implementation project, create a legal entity by following these steps:
Note
Working within an implementation project is required because you select a scope value within an implementation project. The scope value is the legal entity that you will create or select to work within for your implementation project.
Navigate to an implementation project that contains the Define Legal Entities task list from the Setup and Maintenance work area.
Select Go to Task for the Define Legal Entities task list within the implementation project.
Note
The following message appears:
You must first select a scope value to perform the task.
Select and add an existing scope value to the implementation project.
Create a new scope value and then add it to the implementation project.
Select Create New.
From the Manage Legal Entities page select Create.
Accept the default Country, United States.
Enter Name, InFusion USA West.
Enter Legal Entity Identifier, US0033.
Optionally enter Start Date. When the start date is blank the legal entity is effective from the creation date.
Optionally enter an End Date.
Optionally, if your legal entity should be registered to report payroll tax and social insurance, select the Payroll statutory unit check box.
Optionally, if your legal entity has employees, select the Legal employer check box.
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.
Note
Enter the Registration Information.
Accept the default Identifying Jurisdiction, United States Income Tax.
Search for and select a Legal Address, 500 Oracle Parkway, Redwood Shores, CA 94065.
Note
The legal address must have been entered previously using the Manage Legal Address task.
Select OK.
Optionally enter a Place of Registration.
Enter the EIN or TIN.
Enter the Legal Reporting Unit Registration Number.
Select Save and Close to navigate back to the Manage Legal Entities page.
Select Done to return to your implementation project. An issue with the done button has been fixed in 11g Release 1 (11.1.4).
In the Legal Entity choice list in the implementation project (just below the implementation project name and code), click Select and Add Legal Entity to choose the legal entity that you just created, and set the scope for the remainder of your setup.
Search for and select your legal entity from the Manage Legal Entities page.
Select Save and Close.
This sets the scope for your task list to the selected legal entity, as indicated in the Legal Entity choice list above the Tasks and Task Lists table.
A legal entity registration with the same name as that of the legal entity will be 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:
Navigate to your implementation project from the Setup and Maintenance work area. Verify that the parent Legal Entity scope value is set correctly.
Expand the Define Legal Entities task list within the implementation project.
Select Manage Legal Entity Registrations Go to Task.
Select Create.
Enter Jurisdiction.
Enter Registered Address.
Enter Registered Name.
Optionally enter Alternate Name, Registration Number, Place of Registration, Issuing Legal Authority, and Issuing Legal Authority Address, Start Date, and End Date.
Save and Close.
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:
Navigate to your implementation project from the Setup and Maintenance work area. Verify that the parent Legal Entity scope value is set correctly.
Select Go to Task for the Define Legal Entities task list within the implementation project.
Select Create.
Enter Territory, United States.
Enter Name.
Optionally enter a Start Date.
Note
Enter Registration Information.
Search for and select Jurisdiction.
Note
Enter Main Legal Reporting Unit information.
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.
Enter the Main Effective Start Date, 1/1/11.
Save and Close.
A legal entity is a recognized party with rights and responsibilities given by legislation.
Legal entities have the right to own property, the right to trade, the responsibility to repay debt, and the responsibility to account for themselves to regulators, taxation authorities, and owners according to rules specified in the relevant legislation. Their rights and responsibilities may be enforced through the judicial system. Define a legal entity for each registered company or other entity recognized in law for which you want to record assets, liabilities, expenses and income, pay transaction taxes, or perform intercompany trading.
A legal entity has responsibility for elements of your enterprise for the following reasons:
Facilitating local compliance
Taking advantage of lower corporation taxation in some jurisdictions
Preparing for acquisitions or disposals of parts of the enterprise
Isolating one area of the business from risks in another area. For example, your enterprise develops property and also leases properties. You could operate the property development business as a separate legal entity to limit risk to your leasing business.
In configuring your enterprise structure in Oracle Fusion Applications, you need to understand that the contracting party on any transaction is always the legal entity. Individual legal entities own the assets of the enterprise, record sales and pay taxes on those sales, make purchases and incur expenses, and perform other transactions.
Legal entities must comply with the regulations of jurisdictions, in which they register. Europe now allows for companies to register in one member country and do business in all member countries, and the US allows for companies to register in one state and do business in all states. To support local reporting requirements, legal reporting units are created and registered.
You are required to publish specific and periodic disclosures of your legal entities' operations based on different jurisdictions' requirements. Certain annual or more frequent accounting reports are referred to as statutory or external reporting. These reports must be filed with specified national and regulatory authorities. For example, in the United States (US), your publicly owned entities (corporations) are required to file quarterly and annual reports, as well as other periodic reports, with the Securities and Exchange Commission (SEC), who enforces statutory reporting requirements for public corporations.
Individual entities privately held or held by public companies do not have to file separately. In other countries, your individual entities do have to file in their own name, as well as at the public group level. Disclosure requirements are diverse. For example, your local entities may have to file locally to comply with local regulations in a local currency, as well as being included in your enterprise's reporting requirements in different currency.
A legal entity can represent all or part of your enterprise's management framework. For example, if you operate in a large country such as the United Kingdom or Germany, you might incorporate each division in the country as a separate legal entity. In a smaller country, for example Austria, you might use a single legal entity to host all of your business operations across divisions.
Oracle Fusion Applications support the modeling of your legal entities. If you make purchases from or sell to other legal entities, define these other legal entities in your customer and supplier registers, which are part of the Oracle Fusion Trading Community Architecture. When your legal entities are trading with each other, you represent both of them as legal entities and also as customers and suppliers in your customer and supplier registers. Use legal entity relationships to determine which transactions are intercompany and require intercompany accounting. Your legal entities can be identified as legal employers and therefore, are available for use in Human Capital Management (HCM) applications.
There are several decisions that need to be considered in creating your legal entities.
The importance of legal entity in transactions
Legal entity and its relationship to business units
Legal entity and its relationship to divisions
Legal entity and its relationship to ledgers
Legal entity and its relationship to balancing segments
Legal entity and its relationship to consolidation rules
Legal entity and its relationship to intercompany transactions
Legal entity and its relationship to worker assignments and legal employer
Legal entity and payroll reporting
Legal reporting units
All of the assets of the enterprise are owned by individual legal entities. Oracle Fusion Financials allow your users to enter legal entities on transactions that represent a movement in value or obligation.
For example, the creation of a sales order creates an obligation for the legal entity that books the order to deliver the goods on the acknowledged date, and an obligation of the purchaser to receive and pay for those goods. Under contract law in most countries, damages can be sought for both actual losses, putting the injured party in the same state as if they had not entered into the contract, and what is called loss of bargain, or the profit that would have made on a transaction.
In another example, if you revalued your inventory in a warehouse to account for raw material price increases, the revaluation and revaluation reserves must be reflected in your legal entity's accounts. In Oracle Fusion Applications, your inventory within an inventory organization is managed by a single business unit and belongs to one legal entity.
A business unit can process transactions on behalf of many legal entities. Frequently, a business unit is part of a single legal entity. In most cases the legal entity is explicit on your transactions. For example, a payables invoice has an explicit legal entity field. Your accounts payables department can process supplier invoices on behalf of one or many business units.
In some cases, your legal entity is inferred from your business unit that is processing the transaction. For example, your business unit A agrees on terms for the transfer of inventory to your business unit B. This transaction is binding on your default legal entities assigned to each business unit. Oracle Fusion Procurement, Oracle Fusion Projects, and Oracle Fusion Supply Chain applications rely on deriving the legal entity information from the business unit.
The division is an area of management responsibility that can correspond to a collection of legal entities. If desired, you can aggregate the results for your divisions by legal entity or by combining parts of other legal entities. Define date-effective hierarchies for your cost center or legal entity segment in your chart of accounts to facilitate the aggregation and reporting by division. Divisions and legal entities are independent concepts.
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.
Oracle Fusion General Ledger supports up to three balancing segments. Best practices recommend that one of these segments represents your legal entity to ease your requirement to account for your operations to regulatory agencies, tax authorities, and investors. Accounting for your operations means you must produce a balanced trial balance sheet by legal entity. If you account for many legal entities in a single ledger, you must:
Identify the legal entities within the ledger.
Balance transactions that cross legal entity boundaries through intercompany transactions.
Decide which balancing segments correspond to each legal entity and assign them in Oracle Fusion General Ledger Accounting Configuration Manager. Once you assign one balancing segment value in a ledger, then all your balancing segment values must be assigned. This recommended best practice facilitates reporting on assets, liabilities, and income by legal entity.
Represent your legal entities by at least one balancing segment value. You may represent it by two or three balancing segment values if more granular reporting is required. For example, if your legal entity operates in multiple jurisdictions in Europe, you might define balancing segment values and map them to legal reporting units. You can represent a legal entity by more than one balancing segment value, do not use a single balancing segment value to represent more than one legal entity.
In Oracle Fusion General Ledger, there are three balancing segments. You can use separate balancing segments to represent your divisions or strategic business units to enable management reporting at the balance sheet level for each division or business unit. For example, use this solution to empower your business unit and divisional managers to track and assume responsibility for their asset utilization or return on investment. Using multiple balancing segments is also useful when you know at the time of implementation that you are disposing of a part of a legal entity and need to isolate the assets and liabilities for that entity.
Note
Implementing multiple balancing segments requires every journal entry that is not balanced by division or business unit, to generate balancing lines. Also, you cannot change to multiple balancing segments easily after you have begun to use the ledger because your historical data is not balanced by the new multiple balancing segments. Restating historical data must be done at that point.
To use this feature for disposal of a part of a legal entity, implement multiple balancing segments at the beginning of the legal entity's corporate life or on conversion to Oracle Fusion.
If you decided to account for each legal entity in a separate ledger, there is no requirement to identify the legal entity with a balancing segment value within the ledger.
Note
While transactions that cross balancing segments don't necessarily cross legal entity boundaries, all transactions that cross legal entity boundaries must cross balancing segments. If you make an acquisition or are preparing to dispose of a portion of your enterprise, you may want to account for that part of the enterprise in its own balancing segment even if it is not a separate legal entity. If you do not map legal entities sharing the same ledger to balancing segments, you will not be able to distinguish them using the intercompany functionality or track their individual equity.
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.
Use Oracle Fusion Intercompany functionality for automatic creation of intercompany entries across your balancing segments. Intercompany processing updates legal ownership within the enterprise's groups of legal entities. Invoices or journals are created as needed. To limit the number of trading pairs for your enterprise, set up intercompany organizations and assign then to your authorized legal entities. Define processing options and intercompany accounts to use when creating intercompany transactions and to assist in consolidation elimination entries. These accounts are derived and automatically entered on your intercompany transactions based on legal entities assigned to your intercompany organizations.
Intracompany trading, in which legal ownership isn't changed but other organizational responsibilities are, is also supported. For example, you can track assets and liabilities that move between your departments within your legal entities by creating departmental level intercompany organizations.
Note
In the Oracle Fusion Supply Chain applications, model intercompany relationships using business units, from which legal entities are inferred.
Legal 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.
Your legal entities are required to pay payroll tax and social insurance such as social security on your payroll. In Oracle Fusion Applications, you can register payroll statutory units to pay and report on payroll tax and social insurance on behalf of many of your legal entities. As the legal employer, you might be required to pay payroll tax, not only at the national level, but also at the local level. You meet this obligation by establishing your legal entity as a place of work within the jurisdiction of a local authority. Set up legal reporting units to represent the part of your enterprise with a specific legal reporting obligation. You can also mark these legal reporting units as tax reporting units, if the legal entity must pay taxes as a result of establishing a place of business within the jurisdiction.
These examples illustrate different models for human capital management (HCM) organizations. Each example includes a legislative data group (LDG). LDGs are not an organization classification, but they are included in the example to show how you associate them with a payroll statutory unit to partition payroll data.
This example illustrates a simple configuration that does not include any tax reporting units. The legal employer and payroll statutory units are the same, sharing the same boundaries. Reporting can only be done at a single level. Countries such as Saudi Arabia and the United Arab Emirates (UAE) might use this type of model, as reporting in these countries is done at the legal entity level.
This figure illustrates a simple configuration where the enterprise has only one legal entity that is both a payroll statutory unit and a legal employer.
This example illustrates a more complex configuration. In this enterprise, one legal entity, InFusion US, is defined as a payroll statutory unit and has two separate legal entities, which are also legal employers. This model shows multiple legal employers that are associated with a single payroll statutory unit, and how tax reporting units are always associated with a specific legal employer (or employers) through the payroll statutory unit. The implication is that payroll statutory reporting boundaries vary from human resources (HR) management, and the balances can be categorized separately by either payroll statutory unit, legal employer, or tax reporting unit. This configuration is based on tax filing requirements, as some tax-related payments and reports are associated with a higher level than employers. An example of a country that might use this model is the US.
This figure illustrates an enterprise that has one payroll statutory unit and multiple legal employers and tax reporting units.
This model makes no distinction between a legal employer and a payroll statutory unit. Tax reporting units are defined as subsidiaries to the legal entity. In this enterprise, legal entity is the highest level of aggregation for payroll calculations and reporting, and statutory reporting boundaries are assumed to be the same for both payroll and HR management. An example of a country that might use this model is France.
This figure illustrates an example of an organization with one legal entity that is both a legal employer and a payroll statutory unit and that has two tax reporting units.
In this model, the enterprise has one legal entity, and legal employers and tax reporting units are independent from each other within a payroll statutory unit, because there is no relationship from a legal perspective. Therefore, you can run reporting on both entities independently. Using this model, you would not typically need to report on tax reporting unit balances within a legal employer, and balances can be categorized by either or both organizations, as required. An example of a country that might use this model is India.
This figure illustrates an enterprise with one legal entity that is a payroll statutory unit and a legal employer, and the tax reporting units are independent from the legal employer.
In this model, the enterprise has two legal entities, and legal employers and tax reporting units are independent from each other within a payroll statutory unit, because there is no relationship from a legal perspective. Therefore, you can run reporting on both entities independently. Using this model, you would not typically need to report on tax reporting unit balances within a legal employer, and balances can be categorized by either or both organizations, as required. An example of a country that might use this model is the United Kingdom (UK).
This figure illustrates an enterprise with two legal entities, and legal employers and tax reporting units are independent from each other.
When you set up legal entities, you can identify them as legal employers and payroll statutory units, which makes them available for use in Oracle Fusion Human Capital Management (HCM). A tax reporting unit is created automatically when you add a legal entity and identify it as a payroll statutory unit. Depending on how your organization is structured, you may have only one legal entity that is also a payroll statutory unit and a legal employer, or you may have multiple legal entities, payroll statutory units, and legal employers.
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 have a parent-child relationship, with the payroll statutory unit being the parent.
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.
A legal employer is a legal entity that employs workers. You define a legal entity as a legal employer in the Oracle Fusion Legal Entity Configurator.
The legal employer is captured at the work relationship level, and all employment terms and assignments within that relationship are automatically with that legal employer. Legal employer information for worker assignments is also used for reporting purposes.
Payroll statutory units are legal entities that are responsible for paying workers, including the payment of payroll tax and social insurance. A payroll statutory unit can pay and report on payroll tax and social insurance on behalf of one or many legal entities, depending on the structure of your enterprise. For example, if you are a multinational, multicompany enterprise, then you register a payroll statutory unit in each country where you employ and pay people. You can optionally register a consolidated payroll statutory unit to pay and report on workers across multiple legal employers within the same country. You associate a legislative data group with a payroll statutory unit to provide the correct payroll information for workers.
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: All legal entities, legal reporting units, and business units in your organization that have a transaction tax requirement.
Third parties: Your customers and suppliers and their locations and banks.
Tax authorities: Parties that administer tax rules and regulations.
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 more accurately model your external relationships to legal authorities. 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 are 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 that has 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.
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 not modify the party tax profile for a bank as it is view only. You can only modify the bank record itself.
Note
Setting up party tax profiles for third parties is not required. Taxes are still calculated on transactions for third parties that do not have tax profiles
Set up a tax authority party tax profile using the Legal Authorities set up 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.
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 do not 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 do not use the tax setup of the legal entity.
Configuration options: Applicable to legal entities and business units who do not use the tax setup of the legal entity.
Service subscriptions: Applicable to legal entities and business units who do not use the tax setup of the legal entity.
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:
|
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. |
You must 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.
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, similarly to the party fiscal classifications.
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.
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.
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.
The legal entity party tax profile is automatically created when a legal entity record is created. If a legal entity party tax profile record is not created, for example, when a legal entity is created through a back-end process, a legal entity party tax profile is created upon saving the tax regime when a legal entity is subscribed to or upon saving the configuration owner tax options when they are defined for the legal entity. Otherwise, create a party tax profile using the Create Legal Entity Tax Profile page. You can edit the tax profile that was automatically generated with the relevant tax information, but it is not required.
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 a sales office, 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 the Human Capital Management (HCM) system where you use your legal reporting units to model your tax reporting units. A tax reporting unit is used to group workers for the purpose of tax reporting.
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 operation 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, there can be only one identifying registration, defined by the legal authority used for the legal entity or legal reporting unit, associated with the legal reporting unit.
The chart of accounts is the underlying structure for organizing financial information and reporting. An entity records transactions with a set of codes representing balances by type, expenses by function, and other divisional or organizational codes that are important to its business.
A well-designed chart of accounts provides the following benefits:
Effectively manages an organization's financial business
Supports the audit and control of financial transactions
Provides flexibility for management reporting and analysis
Anticipates growth and maintenance needs as organizational changes occur
Facilitates an efficient data processing flow
Allows for delegation of responsibility for cost control, profit attainment, and asset utilization
Measures performance against corporate objectives by your managers
The chart of accounts facilitates aggregating data from different operations, from within an operation, and from different business flows, thus enabling the organization to report using consistent definitions to their stakeholders in compliance with legislative and corporate reporting standards and aiding in management decisions.
Best practices include starting the design from external and management reporting requirements and making decisions about data storage in the general ledger, including thick versus thin general ledger concepts.
Thick versus thin general ledger is standard terminology used to describe the amount of data populated and analysis performed in your general ledger. Thick and thin are the poles; most implementations are somewhere in between. Here are some variations to consider:
A general ledger used in conjunction with an enterprise profitability management (EPM) product, which has data standardized from each operation, is designed as a thin general ledger. Use this variation if your solution is project based, and Oracle Fusion Projects is implemented. More detailed reporting can be obtained from the Projects system. In the thin general ledger, business units, divisions, and individual departments are not represented in the chart of accounts.
A general ledger, with segments representing all aspects and capturing every detail of your business, with frequent posting, many values in each segment, and many segments, is called a thick general ledger. A thick general ledger is designed to serve as a repository of management data for a certain level of management. For example, a subsidiary's general ledger is designed to provide the upper management enough data to supervise operations, such as daily sales, without invoice details or inventory without part number details.
A primary ledger and a secondary ledger, where one is a thick general ledger and the other a thin general ledger, provides dual representation for reporting requirements that require more than one ledger.
With a thin general ledger, you use the general ledger for internal control, statutory reporting, and tracking of asset ownership. You minimize the data stored in your general ledger. A thin general ledger has many of the following characteristics:
Minimal chart of accounts
Short list of cost centers
Short list of natural accounts
Short list of cost accounts
Summary level asset and liability accounts
Low number of optional segments
Infrequent posting schedule
A thin general ledger has natural accounts at a statutory reporting level, for example, payroll expense, rent, property taxes, and utilities. It has cost centers at the functional expense level, such as Research and Development (R&D) or Selling, General, and Administrative (SG&A) expense lines, rather than at department or analytic levels. It omits business unit, division, and product detail.
One example of an industry that frequently uses a thin general ledger is retail. In a retail organization, the general ledger tracks overall sales numbers by region. A retail point of sales product tracks sales and inventory by store, product, supplier, markup, and other retail sales measures.
With a thick general ledger, you use the general ledger as a detailed, analytic tool, performing analytic functions directly in the general ledger. Data is broken down by many reporting labels, and populated frequently from the subledgers.
You maximize the data stored in the general ledger. A thick general ledger has many of the following characteristics:
Maximum use of the chart of accounts
Long list of natural accounts
Long list of cost centers
Long list of costing accounts
Detailed asset and liability accounts
Frequent posting schedule
In a thick general ledger, you obtain detail for cost of goods sold and inventory balances and track property plant and equipment at a granular level. Cost centers represent functional expenses, but also roll up to departmental or other expense analysis levels. Using product and location codes in optional segments can provide reporting by line of business. Posting daily, at the individual transaction level, can maximize the data stored in the general ledger.
One example of an industry that frequently uses a thick general ledger is electronic manufacturers. Detail on the revenue line is tagged by sales channel. Product is structured differently to provide detail on the cost of goods sold line, including your bill of materials costs. The general ledger is used to compare and contrast both revenue and cost of goods sold for margin analysis.
Consider implementing a thick ledger if there are business requirements to do any of the following:
Track entered currency balances at the level of an operational dimension or segment of your chart of accounts, such as by department or cost center
Generate financial allocations at the level of an operational dimension or segment
Report using multiple layered and versioned hierarchies of the operational dimension or segment from your general ledger
Consider implementing a thin ledger in addition to a thick ledger, if there are additional requirements for:
Minimal disclosure to the authorities in addition to the requirements listed above. For example, in some European countries, fiscal authorities examine ledgers at the detailed account level.
Fiscal only adjustments, allocations, and revaluations, which don't impact the thick general ledger.
The important consideration in determining if a thick ledger is the primary or secondary ledger is your reporting needs. Other considerations include how the values for an operational dimension or segment are derived and the amount of resources used in reconciling your different ledgers. If values for the operational dimension are always entered by the user like other segments of the accounting flexfield, then a thick primary ledger is the better choice.
However, if values for the operational dimension or segment are automatically derived from other attributes on the transactions in your subledger accounting rules, rather than entered in the user interface, then use a thick secondary ledger. This decision affects the amount of:
Storage and maintenance needed for both the general ledger and subledger accounting entries
System resources required to perform additional posting
In summary, you have:
Minimum demand on storage, maintenance, and system resources with the use of a thin ledger
Greater demand on storage, maintenance, and system resources with the use of a thick ledger
Greatest demand on storage, maintenance and system resources with the use of both thick and thin ledgers
Note
Generally speaking, there is a tradeoff between the volume of journals and balances created and maintained versus system resource demands. Actual performance depends on a wide range of factors including hardware and network considerations, transaction volume, and data retention policies.
The factors you need to consider in your decision to use a thick or thin general ledger for your organization, are your:
Downstream EPM system and its capabilities
Business intelligence system and its capabilities
Subledger systems and their capabilities and characteristics, including heterogeneity
General ledger reporting systems and their capabilities
Maintenance required for the thick or thin distributions and record keeping
Maintenance required to update value sets for the chart of accounts segments
Preferences of the product that serves as a source of truth
Level at which to report profitability including gross margin analysis
Industry and business complexity
There are several important elements to the basic chart of accounts in Oracle Fusion Applications: a structure that defines the account values, segments, and their labels, and rules (security and validation). Account combinations link the values in the segments together and provide the accounting mechanism to capture financial transactions.
The chart of accounts defines the number and attributes of various segments, including the order of segments, the width of segments, prompts, and segment labels, such as balancing, natural account, and cost center.
The chart of accounts further defines the combination of value sets associated with each segment of the chart of accounts, as well as the type, default value, additional conditions designating the source of the values using database tables, and the required and displayed properties for the segments.
A chart of accounts segment is a component of the account combination. Each segment has a value set attached to it to provide formatting and validation of the set of values used with that segment. The combination of segments creates the account combination used for recording and reporting financial transactions. Examples of segments that may be found in a chart of accounts are company, cost center, department, division, region, account, product, program, and location.
The value sets define the attributes and values associated with a segment of the chart of accounts. You can think of a value set as a container for your values. You can set up your flexfield so that it automatically validates the segment values that you enter against a table of valid values. If you enter an invalid segment value, a list of valid values appears automatically so that you can select a valid value. You can assign a single value set to more than one segment, and you can share value sets across different flexfields.
Segment labels identify certain segments in your chart of accounts and assign special functionality to those segments. Segment labels were referred to as flexfield qualifiers in Oracle E-Business Suite. Here are the segment labels that are available to use with the chart of accounts.
Balancing: Ensures that all journals balance for each balancing segment value or combination of multiple balancing segment values to use in trial balance reporting. There are three balancing segment labels: primary, second, and third balancing. The primary balancing segment label is required.
Cost Center: Facilitates grouping of natural accounts by functional cost types, accommodating tracking of specific business expenses across natural accounts. As cost centers combine expenses and headcount data into costs, they are useful for detailed analysis and reporting. Cost centers are optional, but required if you are accounting for depreciation, additions, and other transactions in Oracle Fusion Assets, and for storing expense approval limits in Oracle Fusion Expense Management.
Natural Account: Determines the account type (asset, liability, expense, revenue, or equity) and other information specific to the segment value. The natural account segment label is required.
Management: Optionally, denotes the segment that has management responsibility, such as the department, cost center, or line of business. Also can be attached to the same segment as one of the balancing segments to make legal entity reporting more granular.
Intercompany: Optionally, assigns the segment to be used in intercompany balancing functionality.
Note
All segments have a segment qualifier that enables posting for each value. The predefined setting is Yes to post.
An account combination is a completed code of segment values that uniquely identifies an account in the chart of accounts, for example 01-2900-500-123, might represent InFusion America (company)-Monitor Sales (division)-Revenue (account)-Air Filters (product).
The chart of accounts uses two different types of rules to control functionality.
Security rules: Prohibit certain users from accessing specific segment values. For example, you can create a security rule that grants a user access only to his or her department.
Cross-validation rules: Control the account combinations that can be created during data entry. For example, you may decide that sales cost centers 600 to 699 should enter amounts only to product sales accounts 4000 to 4999.
In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created.
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 financial reporting structure including your charts of accounts for both your US and UK operations.
InFusion Corporation has 400 plus employees and revenue of $120 million. Your product line includes all the components to build and maintain air quality monitoring (AQM) systems for homes and businesses.
In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created.
The chart of accounts structure provides the general outline of the chart of accounts and determines the number of segments, the type, the length, and the label (qualifier) of each segment. This forms the foundation of the chart of accounts definition object.
For each chart of accounts structure, it is possible to associate one or more chart of accounts structure instances. Chart of accounts structure instances under the same structure share a common configuration with the same segments, in the same order, and the same characteristics. Using one chart of accounts structure with multiple instances simplifies your accounting and reporting.
At the chart of accounts structure instance level, each segment is associated with a value set that conforms to the characteristic of that segment. For example, you assign a value set with the same segment type and length to each segment. You are using hierarchies with your chart of accounts segments. Each structure instance segment is assigned a tree code to indicate the source of the hierarchy information for the associated value set. The same value set can be used multiple times within the same or across different chart of accounts instances within the same structure or in different structures. This functionality reduces your segment value creation and maintenance across your charts of accounts.
The collective assignment of value sets to each of the segments forms one chart of accounts instance. At the chart of accounts structure instance level, you can select to enable dynamic insertion. Dynamic insertion allows the creation of account code combinations automatically the first time your users enter that new account combination. The alternative is to create them manually. By deciding to enable dynamic insertion, you save data entry time and prevent delays caused by the manual creation of new code combinations. Well defined cross validation rules help prevent the creation of inappropriate account code combinations.
Perform deployment after a new chart of accounts structure and structure instances are defined or any of their modifiable attributes are updated. Deployment validates and regenerates the necessary objects to enable your charts of accounts and chart of accounts structure instances. By unifying and standardizing you organization's chart of accounts, you are positioned to take full advantage of future functionality in Oracle Fusion General Ledger.
In summary, you are recommending to your company to unify the organization's chart of accounts in a single chart of accounts structure based on chart of accounts commonalities across ledgers. You have also decided to use the chart of accounts structure instance construct to serve different accounting and reporting requirements by using value sets specific to each of your entities.
In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created. A chart of accounts structure defines the key attributes for your chart of accounts, such as the number of segments, the segment sequences, the segment names, segment prompts, segment labels, for example natural account and primary balancing, and default value sets.
The chart of accounts instance is exposed in the user interfaces and processes. By default, a chart of accounts instance inherits all the attributes of the chart of accounts structure, meaning that all instances of the same structure share a common shape and have the same segments in the same order. However, at the chart of accounts instance level, you can override the default value set assignments for your segments and assign a unique account hierarchy that determines the parent and child relationships between the value set values. At the chart of accounts instance level, determine if allow dynamic insertion is enabled to generate new account combinations dynamically instead of creating them manually.
You are creating a chart of accounts structure as you setup your chart of accounts for your enterprise, InFusion America, Inc. Follow these steps:
Navigate to the Manage Chart of Accounts page from the Functional Setup Manger by querying on Manage Chart of Accounts and clicking on the Go To Task.
Select General Ledger from the Module list of values and click Search.
Click Manage Structures to open the Manage Key Flexfield Structures page.
Select the General Ledger row and click the Create to open the Create Key Flexfield Structure page.
Enter a unique Structure Code, INFUSION_AM_COA_STRUCTURE, and Name, InFusion America COA Structure. Provide an optional Description, InFusion America Inc. Chart of Accounts Structure.
Select the - Delimiter to visually separate your segment values.
Click Save.
To create a new segment, click the Create to open the Create Key Flexfield Segment page.
Enter the following parameters:
Parameter |
Value |
---|---|
Segment Code |
INFUSION_AM_CO |
Name |
InFusion America Company |
Description |
InFusion America Inc. Company |
Sequence Number |
1 |
Prompt |
Company |
Short Prompt |
CO |
Display Width |
2 |
Column Name |
Segment1 |
Default Value Set Code |
INFUSION_AM_COMPANY |
Select a segment label, Primary Balancing Segment, to indicate its purpose within your chart of accounts.
Note
Two segment labels are required: primary balancing segment and natural account segment. These labels are not used with each other or with other labels in a specific segment.
Click Save and Close.
Click Done.
Define additional segments following the same process.
You are creating a chart of accounts instance as you setup your chart of accounts for your enterprise, InFusion America, Inc. Follow these steps:
Navigate to the Manage Chart of Accounts page from the Functional Setup Manger by querying on Manage Chart of Accounts and clicking on the Go To Task.
Select General Ledger from the Module list of values and click Search.
Select the General Ledger row and click Manage Structure Instances to open the Manage Key Flexfield Structure Instance page.
Click the Create icon to open the Create Key Flexfield Structure Instance page.
Enter a unique Structure Instance Code, INFUSION_AM_COA_INSTANCE, and Name, InFusion America COA Instance. Provide an optional Description, InFusion America Inc. Chart of Accounts Structure Instance.
Select Dynamic combination creation allowed to indicate that you want to dynamically generate account combinations.
Associate your instance with your Structure Name, InFusion America Structure.
Note
By default, an instance inherits the key attributes of the associated structure. Some attributes, such as the value set assigned to each the segment, can be modified.
Click Save.
Optionally, select the segment row and click Edit to modify instance segments.
Check Required, Displayed, and Business intelligence enabled check boxes.
Note
The Business Intelligence check box is only valid when enabled on segments with segment labels. Check the Required and Displayed options for all segments including those intended for future use. The recommended best practice is to define one segment for future use and set a default value. This ensures room for expansion in your chart of accounts and that the extra segment is populated in the account combinations.
Click OK.
Click Save and Close.
Define additional instances following the same process.
Note
Alternatively, proceed directly with creating your value set values by selecting the corresponding Value Set Code in the Segment Instances table.
Click Done.
Click Deploy Flexfield.
Click OK.
Balancing segments ensure that all journals balance for each balancing segment value or combination of multiple balancing segment values. You can secure access to your primary balancing segment values only with data access sets. The general ledger application automatically calculates and creates balancing lines as required in journal entries. For example, recognizing an entity's receivable and the other entity's payable. There are three balancing segment labels: primary, second, and third balancing. The primary balancing segment label is required.
By enabling multiple balancing segments for your chart of accounts, it is possible to produce financial statements for each unique combination of segment values across not only one, but two or even three qualified balancing segments. This ability provides you greater insights into your operations as it affords you visibility along the critical fiscal dimensions you use to plan, monitor, and measure your financial performance.
The following explains processes that use balancing segments.
Intercompany balancing: Adds lines to unbalanced journals using intercompany rules.
Opening first period of the new accounting year: Calculates retained earnings amounts at the level of granularity that totals revenue and expense account balances for multiple balancing segment value combinations. This applies to standard and average balances.
Importing journals: Adds lines using the suspense account on unbalanced journals.
Posting journals: Adds additional lines to unbalanced journals for the following enabled account types:
Suspense
Rounding
Net income
Retained earnings
Cumulative translation adjustments from replication of revaluation journals to reporting currencies and for multiple reporting currency account type specific conversion
Posting prior period journals: Calculates any income statement impact and posts to the appropriate retained earnings account.
Translating balances: Supports multiple balancing segments for the following accounts:
Retained earnings: Calculated translated retained earnings are post to the retained earnings accounts by balancing segment. Retained earnings represents the summing of the translated revenue and expense accounts across multiple balancing segment values.
Cumulative translation adjustment: Amounts posted by balancing segment to these accounts represents currency fluctuation differences between ranges of accounts which use different rate types. For example, period end rates are used for asset and liability accounts and historical rates for equity accounts.
Revaluing Balances: Supports multiple balancing segments when calculating gain or loss accounts.
Creating Opening Balances: Initializes reporting currency balances by converting from the total primary currency. Any difference in the reporting currency amounts is offset by populating retained earnings accounts.
Closing year end: Supports multiple balancing segments when calculating the income statement offset and closing account in the closing journals.
Oracle Fusion General Ledger supports tracking financial results at a finer level of granularity than a single balancing segment. In addition to the required primary balancing segment for the chart of accounts, which is typically associated with the company dimension of a business organization, two additional segments of the chart of accounts can be optionally qualified as the second and third balancing segments respectively. Possible chart of accounts segments that can be tagged as these additional balancing segments include cost center or department, additional aspects of a business commonly used in measuring financial results.
There are several points to consider in using multiple balancing segments:
Journal entry processing
Implementation timing
Change options
Migration adjustments
Multiple balancing segments ensure that account balances come from journal entries where the debits equal the credits, and thus, the financial reports are properly generated for each unique instance of account value combinations across the balancing segments. Consider this option carefully as it provides more granular reporting but requires more processing resources.
When considering implementing the optional second and third balancing segments, keep in mind that these chart of accounts segment labels are set from the beginning of time and are actively used by your ledgers. This is important to ensure that balances are immediately maintained in accordance with the necessary balancing actions to produce consistent financial reporting for the desired business dimensions. Multiple balancing segment ledgers that are not maintained from the beginning of time require extensive manual balance adjustments to catch up and realign the balances in accordance with the multiple balancing segments.
Note
Do not set a segment already qualified as a natural account or intercompany segment as any of the three balancing segments. Validations are not performed when segment labels are assigned, so verify that all are assigned correctly before using your chart of accounts.
Once a segment has been enabled and designated as a balancing segment, you must not change the segment. Do not disable the segment or remove the segment labels. These settings must be consistently maintained throughout the life of the chart of accounts to control the accuracy and integrity of the financial data.
For charts of accounts migrated from Oracle E-Business Suite to Oracle Fusion General Ledger that use a segment with the secondary balance tracking segment qualifier, steps must be taken to ensure the proper transition to the second and third balancing segments. The required adjustments are extensive.
For ledgers associated with a migrated chart of accounts, its balances must be adjusted manually to be consistent with the second and third balancing segments as though these segment labels have been in place since the beginning of entries for these ledgers. This requires recomputing and updating of the following processes to reflect the correct balancing for each unique combination of segment values across the additional second and third balancing segments.
Intercompany balancing
Suspense posting
Rounding imbalance adjustments on posting
Entered currency balancing
Revaluation gains or losses
Retained earnings calculations at the opening of each new fiscal year
Cumulative translation adjustments during translation
Note
All previously translated balances must also be purged, and new translations run to properly account for translated retained earnings and cumulative translation adjustments with the correct level of balancing.
This simple example illustrates balancing along two balancing segments for a simple chart of accounts with three segments.
Your company has a chart of accounts with two balancing segments and three segments, qualified as follows:
Company: Primary balancing segment
Cost Center: Second balancing segment
Account: Natural account segment
The following multiple company and cost center journal has been entered to transfer advertising and phone expense from Company 1, Cost Center A to Company 2, Cost Center B.
Account |
Debit |
Credit |
---|---|---|
Company 1-Cost Center A-Advertising Expense Account |
600 |
|
Company 2-Cost Center B-Advertising Expense Account |
|
600 |
Company 1-Cost Center A-Phone Expense Account |
800 |
|
Company 2-Cost Center B-Phone Expense Account |
|
800 |
During the posting process, the last four lines are created to balance the entry across the primary and second balancing segments, company and cost center.
Account |
Debit |
Credit |
---|---|---|
Company 1-Cost Center A-Advertising Expense Account |
600 |
|
Company 2-Cost Center B-Advertising Expense Account |
|
600 |
Company 1-Cost Center A-Phone Expense Account |
800 |
|
Company 2-Cost Center B-Phone Expense Account |
|
800 |
Company 1-Cost Center A-Balancing Account |
|
600 |
Company 2-Cost Center B-Balancing Account |
600 |
|
Company 1-Cost Center A-Balancing Account |
|
800 |
Company 2-Cost Center B-Balancing Account |
800 |
|
To plan for future growth in the business organization that requires additional segments in the chart of accounts, extra segments can be added to the chart of accounts structure during your original implementation. Since all segments of the chart are required and have to be enabled, these unused segments can be assigned value sets that have a single value in the chart of accounts structure instance. This value is set as a default for that segment so that the extra segments are automatically populated when an account code combination is used.
A value set is the collection of account values that are associated with a segment of a chart of accounts structure instance. When creating values sets, consider the following critical choices:
Module Designation
Validation Type
Format Assignments
Security Rules
Values Definition
The module designation is used to tag value sets in Oracle Fusion Applications and sets the value sets apart during upgrades and other processes. Chart of accounts value sets upgraded from Oracle E-Business Suite Release 12 generically bear the module value of Oracle Fusion Middleware. When creating new value sets for a chart of accounts, the module can be specified as Oracle Fusion General Ledger to distinctly identify its intended use in an accounting flexfield, basically a chart of accounts.
Assign one of the following validation types to chart of accounts value sets:
Independent: The values are independently selected when filling out the segment in the account combination.
Table Validated: The values are stored in an external table to facilitate maintenance and sharing of the reference data.
Value sets for chart of accounts must use the Value Data Type of Character. The Value Subtype is set to Text. These two setting support values that are both numbers and characters, which are typical in natural account segment values. Set the maximum length of the value set to correspond to the length of the chart of accounts segment to which it is assigned. Best practices recommend restricting values to Upper Case Only or Numeric values that are zero filled by default.
If flexfield data security rules are to be applied to the chart of accounts segment associated with the value set, the Enable Security check box must be checked for the assigned value set. In addition, assign a data security resource name to enable creation of a data security object automatically for the value set. The data security object is used in the definition of flexfield data security rules.
Once these basic characteristic are defined for the value set, values can be added to the set in the Manage Values page.
Set the values to conform to the value set length and type.
Enter the value, its description, and its attributes including the Enable check box, Start Date, and End Date.
Assign the following attributes: Parent or Summary check box, Posting is allowed, and Budgeting is allowed.
Note
If the value set is used with a natural account segment, the value also requires you set the Natural Account Type, with one of the following values: Asset, Liability, Equity, Revenue or Expense. Other attributes used are Third Party Control Account, Reconciliation indicator, and Financial Category used with Oracle Transaction Business Intelligence reporting.
Oracle Fusion General Ledger best practice is to define the values for the value set after the value set is assigned to a chart of accounts structure instance. Otherwise you are not able to define the mandatory value attributes, such as summary flag, posting allowed, and account type for natural account segment. The attributes must be added after the value set is assigned to a chart of accounts structure instance.
Create your value sets before creating your chart of accounts. A value set can be shared by different charts of accounts or across different segments of the same chart of accounts.
You are creating a company value set to be used in your chart of accounts for your enterprise, InFusion America, Inc. Follow these steps:
Navigate to the Manage Chart of Accounts Value Sets task from within your implementation project and click the Go to Task.
Click the Create icon on the toolbar of the Search Results table. The Create Value Set page opens.
Enter a unique Value Set Code, InFusion America Company, and an optional Description, Company values for InFusion America Inc.
Select General Ledger from the list in the Module field.
Select Independent as Validation Type.
Select Character as the Validation Data Type.
Click Save and Close.
To map the Oracle Fusion General Ledger Accounting Flexfield in Oracle Transaction Business Intelligence (BI) Repository file (RPD) for Oracle Fusion Financials, populate values in the Manage Key Flexfields user interface. These values enable the Chart of Accounts segments for Oracle Fusion Transactional BI and provide the mapping with BI Object names that are used as dimension for each of the Chart of Accounts segments.
Check each of the Chart of Accounts segments' BI enabled check box on all segments that you intend to map in the RPD by performing the following steps:
From your implementation project or the Setup and Maintenance page, query for Manage Key Flexfields and select the Go to Task.
Enter GL# in the Key Flexfield Code field.
Click Search button.
Click on Manage Structure Instances button.
Click the Search button.
Click on the desired chart of accounts and Edit icon.
Click on the desired segment and the Edit icon.
Edit each of the segments by checking the BI enabled check box.
Click on Save button. This should be done for all segments in every Chart of Accounts Structure Instance that you intend to be mapped in RPD.
Click the Save and Close button and the Done button.
Populate the BI Object Name for each of the Segment Labels. This name is the logical table name in the RPD which would be used as the dimension for the corresponding segment. Perform the following steps:
From your implementation project or the Setup and Maintenance page, query for Manage Key Flexfields and select the Go to Task.
Enter GL# in the Key Flexfield Code field.
Query for GL# as Key Flexfield Code in Manage Key Flexfields page.
Click Search button.
Chose Actions menu and click on Manage Segment Labels
Populate the BI Object Name for all the segment labels that are need to be mapped in the RPD.
Segment Label Code |
BI Object Name |
---|---|
FA_COST_CTR |
Dim - Cost Center |
GL_BALANCING |
Dim - Balancing Segment |
GL_ACCOUNT |
Dim - Natural Account Segment |
Click the Save button.
Note
For all the non qualified segment labels, the BI Object Name should be populated with one of the following:
Dim - GL Segment1
Dim - GL Segment2
Dim - GL Segment3
Dim - GL Segment4
Dim - GL Segment5
Dim - GL Segment6
Dim - GL Segment7
Dim - GL Segment8
Dim - GL Segment9
Dim - GL Segment10
Deploy the flexfield using the Deploy Flexfield button from Manage Key Flexfields page.
Use the tree management feature in Oracle Fusion applications to organize data into hierarchies. A hierarchy contains organized data and enables the creation of groups and rollups of information that exist within an organization. Trees are hierarchical structures that enable several data management functions such as better access control, application of business rules at various levels of hierarchies, improved query performance, and so on.
For example, XYZ Corporation has two departments: Marketing and Finance. The Finance department has two functional divisions: Receivables and Payables. Defining a tree for the XYZ Corporation establishes a hierarchy between the organization and its departments, and between the departments and their respective functional divisions. Such a hierarchical modeling of organizational data could be used for executing several data management functions within that organization.
You can create one or more versions of trees, and they can be labeled for better accessibility and information retrieval. You can create trees for multiple data sources, which allow the trees to be shared across Oracle Fusion applications.
A tree structure is a representation of the data hierarchy, and guides the creation of a tree. A tree is an instance of the hierarchy as defined in the tree structure. Tree structures enable you to enforce business rules to which the data must adhere.
The root node is the topmost node of a tree. Child nodes report to the root node. Child nodes at the same level, which report to a common parent node, are called siblings. Leaves are details branching off from a node but not extending further down the tree hierarchy.
A tree is created having only one version. However, users can create more than one tree version depending on the need, and they can make changes to those versions. Depending on varying requirements, users can create one or more tree versions and publish all of them or some of them by making the versions active at the same time. Similar to any other version control system, versions of trees are maintained to keep track of all the changes that a tree undergoes in its life cycle.
Tree labels are short names associated with trees and tree structures and point directly to the data source. Tree labels are automatically assigned to the tree nodes. You can store labels in any table and register the label data source with the tree structure.
A tree structure defines the hierarchy for creating trees and prescribes rules based on which trees are created, versioned, and accessed. You can associate multiple data sources with a tree structure. A tree is an instance of this hierarchy. Every tree structure can contain one or more trees.
You can create tree structures specific to an application but you can share tree structures across applications. If you apply version control to the tree structure, it is carried over to the trees that are based on the tree structure. Each tree version contains at least one root node. Occasionally, a tree version may have more than one root node.
An administrator controls the access to tree structures through a set of rules that are periodically audited for validity.
Defining a tree structure involves specifying several important pieces of information on the Create Tree Structure: Specify Definition page.
The Tree Node table displays data in nodes that exist in the data hierarchy. You must select the correct and most appropriate tree node table to be able to define the tree structure, based on the tree hierarchy you want to establish. This selection also affects the level of security that is set on a tree node and its child entities.
The following options are used to determine the mode of sharing a tree structure across the applications.
Open: Indicates that the tree is associated with all reference data sets.
Set ID: Indicates that the tree will be associated with a specific reference data set.
Indicates the source where the tree structure is being defined. For predefined tree structures select Oracle and for custom structures, select Customers.
You can customize the predefined tree structures as well as the ones that you created. However, customizing the predefined tree structures involves certain level of access restrictions, and will be limited to specific tree nodes and downwards in hierarchy.
One or more trees and tree versions can be based on a tree structure. A tree structure can have one or more trees and tree versions based on it. Usually, only one active version is permitted at any given point of time. However, depending on the requirement, you can allow two or more tree versions to be in the active state for the same date range. This flexibility allows you to choose the tree version that you want to implement.
You can create, edit, and delete tree structures depending upon the requirement. You can also audit and change the status a tree structure.
You can create trees on the basis of a tree structure. When you edit an active tree structure, the status of the tree structure and all associated trees and their versions change to draft. To reuse a tree structure, you can create a copy of it without copying the associated trees and tree versions. If you delete a tree structure, all the associated trees and tree versions are automatically deleted.
Note
For specific information on working with the predefined tree structures that exist in an Oracle Fusion application, refer to the specific product documentation.
If you change the status of a tree structure, the status of the trees and tree versions associated with that tree structure also changes.
The following table lists the different statuses of a tree structure.
Status |
Meaning |
---|---|
Draft |
Yet to be published or is in a modified state. |
Active |
In use and based on which one or more trees or tree versions are created. |
Inactive |
Not in use. |
Use the tree structure audit results to verify the tree structure's correctness and data integrity. The audit results include the following details:
The name of the validator, which is a specific validation check
The result of the validation, including a detailed message
Corrective actions to take if there are any validation errors
Setting the status of a tree structure to active automatically triggers an audit of that tree structure. You can also manually trigger an audit on the manage Tree Structures page, using Actions - Audit. The Tree Structure Audit Result table shows a list of validations that ran against the selected tree structure.
The following table lists the validators used in the audit process and describes what each validator checks for. It also lists possible causes for validation errors and suggests corrective actions.
Validator |
Description (what is checked) |
Possible Cause for Validation Failure |
Suggested Corrective Action |
---|---|---|---|
Restrict By Set ID |
On the Manage Tree Structures: Specify Data Sources page, if the Set ID check box is selected to enable the Restrict Tree Node List of Values Based on option for a tree structure, each of its data source view objects must have a reference data set attribute. This validation does not take place when the check box is not selected. |
Even when the check box is selected, one or more of its data source view objects does not contain a reference data set attribute. |
If reference data set restriction is required for this tree structure, include a reference data set attribute on all data sources. Otherwise, deselect the check box. |
Row Flattened Table Name |
On the Manage Tree Structures: Specify Performance
Options page, a valid row flattened table must be specified for the
tree structure. It can either be the standard row flattened table |
|
Correct the row flattened table definition. |
Available Label Data Sources |
On the Manage Tree Structures: Specify Data Sources page, if a labeling scheme is specified for the tree structure by selecting a list item from the Labeling Scheme list box, the label data source view object specified for each data source must be accessible, and the primary keys must be valid. This restriction does not apply when you select None from the Labeling Scheme list box. |
|
|
Available Data Sources |
Each data source view object specified for the tree structure must be accessible, and all its primary key attributes must be valid. |
|
|
Column Flattened Table Name |
On the Manage Tree Structures: Specify Performance
Options page, a valid column flattened table must be specified for
the tree structure. It can either be the standard row flattened table |
|
Correct the column flattened table definition. |
Restrict by Date |
On the Manage Tree Structures: Specify Data Sources page, if the Date Range check box is selected to enable the Restrict Tree Node List of Values Based on option for a tree structure, each of its data source view objects must have effective start date and effective end date attributes. This validation does not take place when the check box is not selected. |
Even when the check box is selected, one or more of its data source view objects does not contain effective start date and effective end date attributes. |
If the date restriction is required for this tree structure, include the effective start date and effective end date attributes on all data sources. Otherwise, deselect the check box. |
Tree Node Table Name |
On the Manage Tree Structures: Specify Definition
page, a valid tree node table must be specified for the tree structure.
It can either be the standard row flattened table |
|
Correct the tree node table definition. |
Allow Node Level Security |
If the |
The option is set to No for the tree structure but one or more associated data sources have that option set to Yes. |
Correct the option setting in the tree structure and their data sources. |
The data sources provide the items for establishing hierarchy in a tree structure. In the tree management infrastructure, these data sources are Oracle Application Development Framework (ADF) business components view objects, which are defined by application development.
Selecting a labeling scheme determines how the tree nodes are labeled. You may select a labeling scheme to assign at the data source level, at the parent node level, or keep it open for customer assignment. You may also choose not to have any labeling scheme. However, if you decide to use any of the labeling schemes, you may need to select the following additional options, to restrict the list of values that appear under the selected tree node.
Allow Ragged Nodes: To include nodes that have no child nodes, and are shorter than the remaining nodes in the entire hierarchy.
Allow Skip Level Nodes: To include nodes that are at the same level but have parent nodes at different levels.
You can decide the depth of the tree structure by selecting an appropriate value from the list. Keeping the depth limit open renders an infinite list of values.
Using the following options, you can restrict the list of values that appear for selection under a specific tree node.
Date Range: Specifies whether a selection of nodes should be restricted to the same date range as the tree version.
Allow Multiple Root Nodes: Allows you to add multiple root nodes when creating a tree version.
Reference Data Set: Specifies whether a selection of nodes should be restricted to the same set as the tree.
Tree data sources have optional data source parameters with defined view criteria and associated bind variables. You can specify view criteria as a data source parameter when creating a tree structure, and edit the parameters when creating a tree. Multiple data sources can be associated with a tree structure and can have well-defined relationships among them.
Note
Parameter values customized at the tree level override the default values specified at the tree-structure level.
The data source parameters are applied to any tree version belonging to that data source, when performing node operations on the tree nodes. Data source parameters also provide an additional level of filtering for different tree structures. The tree structure definition supports three data source parameter types.
Bound Value: Captures any fixed value, which is used as part of the view criteria condition.
Variable: Captures and binds a dynamic value that is being used by the data source view object. This value is used by the WHERE condition of the data flow.
View Criteria: Captures the view criteria name, which is applied to the data source view object.
You can also specify which of the data source parameters are mandatory while creating or editing the tree structure.
View objects from the ADF business components are used as data sources. To associate the view object with the tree structure, you can pick the code from ADF business component view objects and provide the fully qualified name of the view object, for example, oracle.apps.fnd.applcore.trees.model.view.FndLabelVO.
Tree structures are heavily loaded with data. As a tree management guideline, use the following settings to improve performance of data rendering and retrieval.
Row Flattening
Column Flattening
Column Flattened Entity Objects
ADF Business Component View Objects
Row flattening optimizes parent-child information for run-time performance by storing additional rows in a table for instantly finding all descendants of a parent without initiating a CONNECT BY query. Row flattening eliminates recursive queries, which allows operations to perform across an entire subtree more efficiently.
To store row flattened data for the specific tree
structure, users can either use the central FND_TREE_NODE_RF
table or they can register their own row flattened table. For example,
in a table, if Corporation is the parent of Sales Division (Corporation-Sales
Division), and Sales Division is the parent of Region (Sales Division-Region),
a row-flattened table contains an additional row with Corporation
directly being the parent of Region (Corporation-Region).
Column flattening optimizes parent-child information for run-time performance by storing an additional column in a table for all parents of a child.
To store column flattened data for the specific tree
structure, users can either use the central FND_TREE_NODE_CF
table or they can register their own column flattened table. For
example, in a table, if Corporation is the parent of Sales Division
(Corporation-Sales Division), and Sales Division is the parent of
Region (Sales Division-Region), a flattened table in addition to these
columns, contains three new columns: Region, Sales Division, and Corporation.
Although positioned next to each other, the column Region functions
at the lower level and Corporation at the higher level, retaining
the data hierarchy.
In the absence of a column-flattened table, if you need to generate the business component view objects for your tree structure for the flattened table, use the tree management infrastructure to correctly provide the fully qualified name of the entity object for the column flattened table.
View objects from the ADF business components can also be used as data sources, eliminating the need to create new types of data sources. This field is to store the fully qualified name for the business component view object generated by the tree management for business intelligence reporting and usage The business component view object is a combination of the tree data source and column flattened entity. Using this option prevents data redundancy and promotes greater reuse of existing data, thereby improving the performance of the tree structure.
Tree labels are tags that are stored on tree nodes. You can store labels in any table and register the label data source with the tree structure. When a labeling scheme is used for trees, the selected labels are stored in the tree label entity and each tree node contains a reference to a tree label in the labeling scheme.
The following table lists the three ways in which tree labels are assigned to the tree nodes.
Labeling Scheme |
Description |
---|---|
Level |
Labels that are automatically assigned based on the data source to which the tree node belongs. A level label points to a specific data source. For example, in a tree that reflects the organizational hierarchy of an enterprise, all division nodes appear on one level and all department nodes on another. |
Group |
Labels that you can arbitrarily assign to tree nodes. |
Depth |
Labels that are automatically assigned based on the depth of the tree node within the tree. No manual assignment is performed. Note In an unbalanced hierarchy, a level may not be equal to depth. |
You can create and edit trees and tree versions depending upon the requirement. A tree can have one or more tree versions. Typically, when changes are made to an existing tree, a new version is created and published.
Trees are created based on the structure defined in the tree structure. You can create trees, modify existing trees, and delete trees. If you want to copy an existing tree, you can duplicate it. However, only the tree is duplicated and not its versions.
Creating a tree involves specifying the tree definition and specifying the labels that are used on its nodes. If the selected tree structure has data sources and parameters defined for it, they appear on the page allowing you to edit the parameter values at the tree node level.
Note
Parameter values customized at the tree level will override the default values specified at the tree-structure level.
Tree versions are created at the time of creating trees. A tree must contain a version.
Editing an existing tree provides you the choice to update the existing version. You can also edit the existing version that lies nested under the tree in the search results.
When you edit a tree version bearing Active status, the status changes to Draft until the modifications are saved or cancelled.
Use the tree version audit results to verify the tree version's correctness and data integrity. The audit results include the following details:
The name of the validator, which is a specific validation check
The result of the validation, including a detailed message
Corrective actions to take if there are any validation errors
An audit automatically runs whenever a tree version is set to active. You can also manually trigger an audit on the Manage Trees and Tree Versions page, using Actions - Audit. The Tree Version Audit Result table shows a list of validations that ran against the selected tree version.
The following table lists the validators used in the audit process and describes what each validator checks for. It also lists possible causes for validation errors and suggests corrective actions.
Validator |
Description (what is checked) |
Possible Cause for Validation Failure |
Suggested Corrective Action |
---|---|---|---|
Effective Date |
The effective start and end dates of the tree version must be valid. |
The effective end date is set to a value that is not greater than the effective start date. |
Modify the effective start and end dates such that the effective start date is earlier than the effective end date. |
Root Node |
On the Manage Tree Structures: Specify Data Sources page, if the Allow Multiple Root Nodes check box for the Restrict Tree Node List of Values Based on option is not selected, and if the tree structure is not empty, the tree version must contain exactly one root node. This validation does not take place if the check box is selected. |
Even if the check box is deselected, the tree version has multiple root nodes. |
Modify the tree version such that there is exactly one root node. |
Data Source Max Depth |
For each data source in the tree structure, on the Data Source dialog box, if the data source is depth-limited, the data in the tree version must adhere to the specified depth limit. This validation does not apply to data sources for which the Maximum Depth field is set to Unlimited. |
The tree version has data at a depth greater than the specified depth limit on one or more data sources. |
Modify the tree version such that all nodes are at a depth that complies with the data source depth limit. |
Duplicate Node |
On the Data Source dialog box, if the Allow Duplicates check box is not selected, the tree version should not contain more than one node with the same primary key from the data source. If the check box is selected, duplicate nodes are permitted. |
Even when the check box is deselected, the tree version contains duplicate nodes. |
Remove any duplicate nodes from the tree version. |
Available Node |
All nodes in the tree version should be valid and available in the underlying data source. |
|
Remove any orphaned nodes from the tree version. Update tree reference nodes so that they reference existing tree versions. |
Node Relationship |
All nodes must adhere to the relationships mandated by the data sources registered in the tree structure. |
The tree structure has data sources arranged in a parent-child relationship, but the nodes in the tree do not adhere to the same parent-child relationship. For example, if the tree structure has a Project data source with a Task data source as its child, Task nodes should always be under Project nodes in the tree version. This validation fails if there are instances where a Project node is added as the child of a Task node. |
Modify the tree version such that the nodes adhere to the same parent-child relationships as the data sources. |
SetID Restricted Node |
On the Manage Tree Structures: Specify Data sources page, if the Set ID check box is selected to enable the Restrict Tree Node List of Values Based on option for each tree node, the underlying node in the data source must belong to the same reference data set as the tree itself. This restriction does not apply when the check box is not selected. |
Even when the check box is selected, the tree version has nodes whose data source values belong to a different reference data set than the tree. |
Modify the tree version such that all nodes in the tree have data sources with reference data set matching that of the tree. |
Label Enabled Node |
On the Manage Tree Structures: Specify Data Sources page, if a labeling scheme is specified for the tree structure by selecting a list item from the Labeling Scheme list box, all nodes should have labels. This restriction does not apply when you select None from the Labeling Scheme list box. |
The tree structure has a labeling scheme but the tree version has nodes without labels. |
Assign a label to any node that does not have a label. |
Date Restricted Node |
On the Manage Tree Structures: Specify Data Sources page, if the Date Range check box is selected to enable the Restrict Tree Node List of Values Based on option for a tree structure, each node in the underlying data source must have an effective date range same as the effective date range of the tree version. This restriction does not apply if the check box is not selected. |
Even when the check box is selected, there are data source nodes that have a date range beyond the tree version's effective date range. For example, if the tree version is effective from Jan-01-2012 to Dec-31-2012, all nodes in the tree version must be effective from Jan-01-2012 to Dec-31-2012 at a minimum. It is acceptable for the nodes to be effective for a date range that extends partly beyond the tree version's effective date range (for example, the node data source value is effective from Dec-01-2011 to Mar-31-2013). It is not acceptable if the nodes are effective for none or only a part of the tree version's effective date range (for example, the node data source value are effective only from Jan-01-2012 to June-30-2012). |
Ensure that all nodes in the tree version have effective date range for the effective date range for the tree version. |
Multiple Active Tree Version |
On the Manage Tree Structures: Specify Definition page, if the Allow Multiple Active Tree Versions check box is not selected for the tree structure, there should not be more than one active tree version under a tree at any time. This restriction does not apply if the check box is selected. |
Even when the check box is not selected, there is more than one active tree version in the tree for the same date range. |
Set no more than one tree version to Active within the same date range and set the others to inactive or draft status. |
Range Based Node |
On the Data Source dialog box, if the Allow Range Children check box is not selected, range-based nodes are not permitted from that data source. This restriction does not apply if the check box is selected. |
Even when the check box is not selected, there are range-based nodes from a data source. |
Ensure that any range nodes in your tree version are from a data source that allows range children. |
Terminal Node |
On the Data Source dialog box, if the Allow Use as Leaves check box is not selected, values from that data source cannot be added as leaves (terminal nodes) to the tree version. This restriction does not apply if the check box is selected. |
Even when the check box is not selected, values from a data source are added as leaf nodes (terminal nodes). |
Modify the tree version such that all terminal nodes are from data sources for which this check box is selected. |
Usage Limit |
On the Data Source dialog box, if the Use All Values option is selected to set the Usage Limit for the data source, every value in the data source must appear as a node in the tree. This restriction does not apply if None option is selected. |
Even if the Use All Values option is selected, there are values in the data source that are not in the tree version. |
For each data source value that is not yet available, add nodes to the tree version. |
Data sources form the foundation for tree management in Oracle Fusion Applications. Tree structures, trees, and tree versions establish direct and real-time connectivity with the data sources. Changes to the data sources immediately reflect on the Manage Trees and Tree Versions page and wherever the trees are being used.
Tree structures contain the metadata of the actual data that is used in Oracle Fusion Applications. Tree structures contain the core business logic that is manifested in trees and tree versions.
Trees and tree versions are built upon the tree structures. They employ the business rules defined in the tree structures and allow an application to select and enable a subset of trees to fulfill a specific purpose in that application.
Source data is mapped to tree nodes at different levels in the database. Therefore, changes you make to the tree nodes affect the source data. Access control set on trees prevents unwanted data modifications in the database. Access control can be applied to the tree nodes or anywhere in the tree hierarchy.
Tree nodes are points of data convergence that serve as the building blocks of a tree structure. Technically, the node may be stored either in a product-specific table or in an entity that has been established by tree management as the default storage mechanism. However, since all data in Oracle Fusion Applications usually have a storage home, only user-created data needs to be stored in an entity.
Nodes are attached to tree versions. Whenever you create or edit a tree version, you need to specify its tree node.
You can create, modify, or delete tree nodes on the Tree Version: Specify Nodes page. To add a tree node, ensure that the tree structure with which the tree version is associated is mapped to a valid data source. You can also duplicate a tree node if the multiple root node feature is enabled.
In most trees, all nodes at the same level represent the same kind of information. For example, in a tree that reflects the organizational hierarchy, all division nodes appear on one level and all department nodes on another. Similarly, in a tree that organizes a user's product catalog, the nodes representing individual products might appear on one level and the nodes representing product lines on the next higher level.
When levels are not used, the nodes in the tree have no real hierarchy or reporting structure but do form a logical summarization structure. Strictly enforced levels mean that the named levels describe each node's position in the tree. This is natural for most hierarchies. Loosely enforced levels mean that the nodes at the same visual level of indentation do not all represent the same kind of information, or nodes representing the same kind of information appear at multiple levels. With loosely enforced levels, users assign a level to each node individually. The level is not tied to a particular visual position.
A tree node has the following node types.
Single: Indicates that the node is a value by itself.
Range: Indicates that the node represents a range of values and possibly could have many children. For example, a tree node representing account numbers 10000 to 99999.
Referenced Tree: Indicates that the tree node is actually another version for the tree based on the same tree structure, which is not physically stored in the same tree. For example, a geographic hierarchy for the United States can be referenced in a World geographic hierarchy.
Use Import Segment Values and Hierarchies process to load segment values and hierarchies if you maintain your chart of accounts reference data outside Oracle Fusion applications. You can load your segment values and hierarchies by populating two tables: GL_SEGMENT_VALUES_INTERFACE table and GL_SEGMENT_HIER_INTERFACE table, and running the Import Segment Values and Hierarchies process.
Note
You can load data to interface tables using predefined templates and the Load Interface File for Import scheduled process, which are both part of the External Data Integration Services for Oracle Cloud feature. For other implementations, optionally use this feature only if you have SFTP configured for it.
You can use GL_SEGMENT_VALUES_INTERFACE to load segment values and GL_SEGMENT_HIER_INTERFACE to load segment value hierarchies to Oracle Fusion applications. You can find details of the columns of the interface table in Oracle Enterprise Repository (OER) for Oracle Fusion Applications.
You must enter values in all columns of the interface table that require values, which includes all of the not null columns, in order for the Import Segment Values and Hierarchies process to be successful. Enter values in the following required columns of the interface table:
Column Name |
Value |
---|---|
STATUS_CODE |
Enter the value NEW to indicate that you are bringing new segment value data. |
VALUE_SET_CODE |
Enter the value set code for the segment values. |
VALUE |
Enter the segment value. |
SUMMARY_FLAG |
Select N if the segment value is a child value or Y if the segment value is a parent value. |
ENABLED_FLAG: |
Select Y to enable the segment value. Enter N to disable the segment value. |
ACCOUNT_TYPE: |
Enter the natural account type if the segment value is for natural account segment. Valid values are: A for Assets, L for Liabilities, E for Expenses, O for Owner's Equities, and R for Revenues. |
ALLOW_POSTING_FLAG |
Select Y if posting is allowed for this segment value. Select N if posting is not allowed. |
OBJECT_VERSION_NUMBER |
Enter default value of 1. |
You can enter values for the following optional columns:
Column Name |
Value |
---|---|
START_DATE_ACTIVE |
Enter the start date of the segment value |
END_DATE_ACTIVE |
Enter the end date of the segment value. |
THIRD_PARTY_CTRL_ACCOUNT |
Enter the third party control account value. Valid values are: CUSTOMER, SUPPLIER, R for Restrict Manual Journals, Y, and N. |
FINANCIAL_CATEGORY |
Enter a financial category value for Oracle Transactional Business Intelligence reporting. Valid values are values defined in the FINANCIAL_CATEGORY lookup type. |
DESCRIPTION |
There are different description columns for different languages. To see segment value description in a different language installation, you need to populate the segment description for that language too. |
The following columns should be left as null as Import Segment Values and Hierarchies process uses them for internal processing or does not use them in the current release.
CREATION_DATE
CREATED_BY
LAST_UPDATE_DATE
LAST_UPDATE_LOGIN
LAST_UPDATED_BY
SEGMENT_VALUE_INTERFACE_ID
REQUEST_ID
LOAD_REQUEST_ID
You must enter values in all columns of the interface table that require values, which includes all of the not null columns, in order for the Import Segment Values and Hierarchies process to be successful. Enter values in the following required columns of the interface table:
Column Name |
Value |
---|---|
STATUS_CODE |
Enter the value NEW to indicate that you are bringing new hierarchy data. |
VALUE_SET_CODE |
Enter the value set code for the segment values. |
TREE_CODE |
Enter the hierarchy name (tree code). |
TREE_VERSION NAME |
Enter the hierarchy version name (tree version name). |
TREE_VERSION_START_DATE_ACTIVE |
Enter the date that the tree version is activated. |
TREE_VERSION_END_DATE_ACTIVE |
Enter the date that the tree version is inactivated. |
VALUE |
Enter the segment value. |
PARENT_VALUE |
Select N if the segment value is a child value or Y if the segment value is a parent value. |
DEPTH |
Enter the depth of the hierarchy which shows the many ancestors the segment value has in the hierarchy. |
OBJECT_VERSION_NUMBER |
Enter default value of 1. |
The following columns should be left as null as Import Segment Values and Hierarchies process uses them for internal processing or does not use them in the current release.
CREATION_DATE
CREATED_BY
LAST_UPDATE_DATE
LAST_UPDATE_LOGIN
LAST_UPDATED_BY
SEGMENT_VALUE_INTERFACE_ID
REQUEST_ID
LOAD_REQUEST_ID
Load the segment values and hierarchies to the interface table by using the following steps.
Load segment values and hierarchies to comma separated values (csv) files. You can use the sample csv file or xls file that's provided in Oracle Enterprise Repository (OER) for Oracle Fusion Applications as a reference.
Upload the comma separated values (csv) file to the secure FTP server.
Run the Load Interface File for Import process.
After the data is loaded to the interface table, you can run the Import Segment Values and Hierarchies process to load the segment values and hierarchies.
Define an accounting calendar to create your accounting year and the periods it contains. Specify common calendar options that the application uses to automatically generate a calendar with its periods. Specifying all the options makes defining a correct calendar easier and more intuitive with fewer errors. The choices you make when specifying the following options are critical, because it is difficult to change your accounting calendar after a period status is set to open or future enterable.
Start Date
Period Frequency
Adjusting Period Frequency
Period Name Format
Note
In Oracle Fusion, the common calendar types, monthly, weekly, 4-4-5, 4-5-4, 5-4-4, 4-week, quarterly, and yearly, are automatically generated. This functionality makes it easier to create and maintain accounting calendars. By using the period frequency option, you no longer have to go through the tedious task of defining each period manually.
If you plan to run translation, specify a calendar start date that is a full year before the start date of the year of the first translation period for your ledger. Translation cannot be run in the first period of a calendar. Consider how many years of history you are going to load from your previous system and back up the start date for those years plus one more. You cannot add previous years once the first calendar period has been opened.
Use period frequency to set the interval for each subsequent period to occur, for example, monthly, quarterly, or yearly. If you select the period frequency of Other, by default, the application generates the period names, year, and quarter number. You specify the start and end dates. You must manually enter the period information. For example, select the period frequency of Other and enter 52 as the number of periods when you want to define a weekly calendar. For manually entered calendars, when you click the Add Year button, the application creates a blank year. Then, you must manually enter the periods for the new year. The online validation helps prevent erroneous entries.
Note
In Oracle Fusion applications a calendar can only have one period frequency and period type. Therefore, if you have an existing calendar with more than one period type associated with it, during the upgrade from Oracle E-Business Suite, separate calendars are created based on each calendar name and period type combination.
Use the adjusting period frequency to control when the application creates adjusting periods. For example, some of the frequencies you select add one adjusting period at year end, two at year end, or one at the end of each quarter. The default is None which adds no adjusting periods. If you select the frequency of Other, the Number of Adjusting Periods field is displayed. Enter the number of desired adjusting periods and then, manually define them.
The User-Defined Prefix field in the Period Name Format region is an optional feature that allows you to enter your own prefix. For example, define a weekly calendar and then enter a prefix of Week, - as the separator, and the period name format of Period numberYY fiscal year. The application creates the names of Week1-11, Week2-11, through Week52-11. The options for the Format field are predefined values. The list of values is filtered based on the selected separator and only displays the options that match the selected separator.
The year displayed in the period names is based on the selected period name format and the dates the period covers or if the period crosses years, on the year of the start date of the period. For example, April 10, 2010 to May 9, 2010 has the period name of Apr-10 and December 10, 2010 to January 9, 2011 has the name of Dec-10. If period frequency is Other, then the period format region is hidden. The application generates a temporary period name for calendars with period frequency of Other, using a fixed format of Period numberYY. You can override this format with your own customized period names.
Note
For an accounting calendar that is associated with a ledger, changing period names or adding a year updates the accounting period dimension in the balances cubes.
Calendar validation is automatic and prevents serious problems when you begin using the calendar. Once you set a calendar period status to open or future enterable, you cannot edit the period.
The calendar validation runs automatically when you save the calendar.
The following table lists the validation checks performed when the accounting calendar is saved.
Validation Performed |
Example of Data |
---|---|
Unique period number |
2 assigned for two periods |
Unique period name |
Jan-11 entered twice |
Period number beyond the maximum number of periods per year |
13 for a 12 period calendar with no adjusting periods |
Entered period name contains spaces |
Jan 11 |
Single or double quotes in the period name |
Jan '11 |
Nonadjusting periods with overlapping dates |
01-Jan-2011 to 31-Jan-2011 and 30-Jan-2011 to 28-Feb-2011 |
Period date gaps |
01-Jan-2011 to 28-Jan-2011 and 31-Jan-2011 to 28-Feb-2011 |
Missing period numbers |
Periods 1 through 6 defined for a twelve month calendar |
Period number gaps |
1, 3, 5 |
Period numbers not in sequential order by date |
Period 1 covers 01-Jan-2011 to 31-Jan-2011 and period 2 covers 01-Mar-2011 to 31-Mar-2011, and period 3 covers 01-Feb-2011 to 28-Feb-2011. |
Quarter number gaps |
1, 3, 4 |
Quarters not in sequential order by period |
1, 3, 2, 4 |
Period start or end dates more than one year before or after the fiscal year |
July 1, 2010 in a 2012 calendar |
Oracle Fusion General Ledger identifies erroneous entries online as you enter a new calendar or change data on an existing calendar. The application also automatically validates the data when you save the calendar.
The period naming format determines the year that is appended to the prefix for each period in the calendar. For the example, your accounting year has a set of twelve accounting period with a start date of September 1, 2011 and the end date is August 31, 2012, with each period's date range following the natural calendar month date range.
Calendar period naming format: Select the calendar period format to append the period's start date's year to the prefix. For the period covering September 1, 2011 to December 31, 2011, then 2011 or just 11, depending on the period format selected, is appended to each period's name. For the remaining periods covering January 1, 2012 to August 31, 2012, then 2012 or 12, is appended to each period's name.
Fiscal period naming format: Select the fiscal period format to always append the period's year assignment to the prefix. If the accounting periods in the set of twelve are all assigned the year of 2012, then 2012 or just 12, depending on the period format selected, is appended to the period name of all 12 periods.
Update an existing calendar before the new periods are needed as future periods, based on the future period setting in your accounting configuration. If a complete year has been defined and validated, use the Add Year button to add the next year quickly. Accept or change the new rows as required. For example, with the Other frequency type calendar, dates may differ from what the application generates.
The migration script assigns a period frequency that most closely matches your Oracle E-Business Suite Release 12 calendar. When you use the Oracle Fusion applications Add Year functionality for the first time, you have an opportunity to review and change the period frequency. The Calendar Options page opens only for calendars upgraded from Release 12 to allow one time modification.
Make your changes to the period frequency, adjusting period frequency, and period name format, including the prefix and separator, as needed. Changes can not conflict with the existing upgraded calendar definition. Update the calendar name and description in the calendar header, as needed, for all calendars. Period details for a new year will be generated automatically based on the latest calendar options. You can also manually update the calendar. The modified calendar options affect future years only.
The Setup and Maintenance work area in the Oracle Fusion Applications is used to manage the configuration of legal entities, ledgers, and reporting currencies that comprise your accounting configuration. To create a new legal entity or ledger, your implementation consultant or system administrator must create an implementation project. This implementation project can be populated by either adding a financials related offering or one or more task lists.
Note
Setup tasks that are not related to the ledger or legal entity specific setup tasks can be invoked from either an implementation project or launched directly from the Setup and Maintenance work area.
There are two offerings predefined for financial implementations.
The Oracle Fusion Accounting Hub offering is used to add the Oracle Fusion General Ledger and Oracle Fusion Subledger Accounting application features to an existing enterprise resource planning (ERP) system to enhance the current reporting and analysis.
The Oracle Fusion Financials offering, which includes the Oracle Fusion General Ledger and Oracle Fusion Subledger Accounting application features, as well as at least one of the subledger financial applications.
When adding an offering to an implementation project, implementation consultants can customize the tasks displayed by adding additional tasks to the implementation project.
Oracle Fusion Applications reflect the traditional segregation between the general ledger and associated subledgers. Detailed transactional information is captured in the subledgers and periodically imported and posted in summary or detail to the ledger.
A ledger determines the currency, chart of accounts, accounting calendar, ledger processing options, and accounting method for its associated subledgers. Each accounting setup requires a primary ledger and optionally, one or more secondary ledgers and reporting currencies. Reporting currencies are associated with either a primary of secondary ledger.
The number of ledgers and subledgers is unlimited and determined by your business structure and reporting requirements.
If your subsidiaries all share the same ledger with the parent company or they share the same chart of accounts and calendar, and all reside on the same applications instance, you can consolidate financial results in Oracle Fusion General Ledger in a single ledger. Use Oracle Fusion Financial Reporting functionality to produce individual entity reports by balancing segments. General Ledger has three balancing segments that can be combined to provide detailed reporting for each legal entity and then rolled up to provide consolidated financial statements.
Accounting operations using multiple ledgers can include single or multiple applications instances. You need multiple ledgers if one of the following is true:
You have companies that require different account structures to record information about transactions and balances. For example, one company may require a six-segment account, while another needs only a three-segment account structure.
You have companies that use different accounting calendars. For example, although companies may share fiscal year calendars, your retail operations require a weekly calendar, and a monthly calendar is required for your corporate headquarters.
You have companies that require different functional currencies. Consider the business activities and reporting requirements of each company. If you must present financial statements in another country and currency, consider the accounting principles to which you must adhere.
Oracle Fusion Subledgers capture detailed transactional information, such as supplier invoices, customer payments, and asset acquisitions. Oracle Fusion Subledger Accounting is an open and flexible application that defines the accounting rules, generates detailed journal entries for these subledger transactions, and posts these entries to the general ledger with flexible summarization options to provide a clear audit trail.
Companies account for themselves in primary ledgers, and, if necessary, secondary ledgers and reporting currencies. Your transactions from your subledgers are posted to your primary ledgers and possibly, secondary ledgers or reporting currencies. Local and corporate compliance can be achieved through an optional secondary ledger, providing an alternate accounting method, or in some cases, a different chart of accounts. Your subsidiary's primary and secondary ledgers can both be maintained in your local currency, and you can convert your local currency to your parent's ledger currency to report your consolidated financial results using reporting currencies or translation.
A primary ledger is the main record-keeping ledger. Like any other ledger, a primary ledger records transactional balances by using a chart of accounts with a consistent calendar and currency, and accounting rules implemented in an accounting method. The primary ledger is closely associated with the subledger transactions and provides context and accounting for them.
To determine the number of primary ledgers, your enterprise structure analysis must begin with your financial, legal, and management reporting requirements. For example, if your company has separate subsidiaries in several countries worldwide, enable reporting for each country's legal authorities by creating multiple primary ledgers that represent each country with the local currency, chart of accounts, calendar, and accounting method. Use reporting currencies linked to your country specific primary ledgers to report to your parent company from your foreign subsidiaries. Other considerations, such as corporate year end, ownership percentages, and local government regulations and taxation, also affect the number of primary ledgers required.
A secondary ledger is an optional ledger linked to a primary ledger for the purpose of tracking alternative accounting. A secondary ledger can differ from its primary ledger by using a different accounting method, chart of accounts, accounting calendar, currency, or processing options. All or some of the journal entries processed in the primary ledger are transferred to the secondary ledger, based on your configuration options. The transfers are completed based on the conversion level selected. There are four conversion levels:
Balance: Only Oracle Fusion General Ledger balances are transferred to the secondary ledger.
Journal: General Ledger journal posting process transfers the journal entries to the secondary ledger.
Subledger: Oracle Fusion Subledger Accounting creates subledger journals to subledger level secondary ledgers as well as reporting currencies.
Adjustments Only: Incomplete accounting representation that only holds adjustments. The adjustments can be manual or detailed adjustments from Subledger Accounting. This type of ledger must share the same chart of accounts, accounting calendar, and period type combination, and currency as the associated primary ledger.
Note
A full accounting representation of your primary ledger is maintained in any subledger level secondary ledger.
Secondary ledgers provide functional benefits, but produce large volumes of additional journal entry and balance data, resulting in additional performance and memory costs. When adding a secondary ledger, consider your needs for secondary ledgers or reporting currencies, and select the least costly data conversion level that meets your requirements. For secondary ledgers, the least costly level is the adjustment data conversion level because it produces the smallest amount of additional data. The balance data conversion level is also relatively inexpensive, depending upon how often the balances are transferred from the primary to the secondary ledger. The journal and subledger data conversion levels are much more expensive, requiring duplication of most general ledger and subledger journal entries, as well as general ledger balances.
For example, you maintain a secondary ledger for your International Financial Reporting Standards (IFRS) accounting requirements, while your primary ledger uses US Generally Accepted Accounting Principles (GAAP). You decided to select the subledger level for your IFRS secondary ledger. However, since most of the accounting is identical between US GAAP and IFRS, a better solution is to use the adjustment only level for your secondary ledger. The subledger level secondary ledger requires duplication of most subledger journal entries, general ledger journal entries, and general ledger balances. With the adjustment only level, your secondary ledger contains only the adjustment journal entries and balances necessary to convert your US GAAP accounting to the IFRS accounting, which uses a fraction of the resources that are required by full subledger level secondary ledger.
Following are scenarios that may require different combinations of primary and secondary ledgers:
The primary and secondary ledgers use different charts of accounts to meet varying accounting standards or methods. A chart of accounts mapping is required to instruct the application how to propagate balances from the source (primary) chart of accounts to the target (secondary) chart of accounts.
The primary and secondary ledgers use different accounting calendars to comply with separate industry and corporate standards.
Note
Use the same currency for primary and secondary ledgers to avoid difficult reconciliations, if you have the resources to support the extra posting time and data storage. Use reporting currencies or translations to generate the different currency views needed to comply with internal reporting needs and consolidations.
Reporting currencies maintain and report accounting transactions in additional currencies. Each primary and secondary ledger is defined with a ledger currency that is used to record your business transactions and accounting data for that ledger. It is advisable to maintain the ledger in the currency in which the majority of its transactions are denominated. For example, create, record, and close a transaction in the same currency to save processing and reconciliation time. Compliance, such as paying local transaction taxes, is also easier using a local currency. Many countries require that your accounting records be kept in their national currency.
If you need to maintain and report accounting records in different currencies, you do this by defining one or more reporting currencies for the ledger. There are three conversion levels for reporting currencies:
Balance: Only General Ledger balances are converted into the reporting currency using translation.
Journal: General Ledger journal entries are converted to the reporting currency during posting.
Subledger: Subledger Accounting creates subledger reporting currency journals along with primary ledger journals.
Note
A full accounting representation of your primary ledger is maintained in any subledger level reporting currency. Secondary ledgers cannot use subledger level reporting currencies.
Of the three data conversion levels available, the balance data conversion level is typically the least expensive, requiring duplication of only the balance level information. The journal and subledger data conversion levels are more expensive, requiring duplication of most general ledger and subledger journal entries, as well as general ledger balances.
Do not use journal or subledger level reporting currencies if your organization has only an infrequent need to translate your financial statements to your parent company's currency for consolidation purposes. Standard translation functionality meets this need. Consider using journal or subledger level reporting currencies when any of the following conditions exist.
You operate in a country whose unstable currency makes it unsuitable for managing your business. As a consequence, you need to manage your business in a more stable currency while retaining the ability to report in the unstable local currency.
You operate in a country that is part of the European Economic and Monetary Union (EMU), and you choose to account and report in both the European Union currency and your National Currency Unit (NCU).
Note
The second option is rare since most companies have moved beyond the initial conversion to the EMU currency. However, future decisions could add other countries to the EMU, and then, this option would again be used during the conversion stage.
Oracle Fusion Applications is an integrated suite of business applications that connects and automates the entire flow of the business process across both front and back office operations and addresses the needs of a global enterprise. The process of designing the enterprise structure, including the accounting configuration, is the starting point for an implementation. This process often includes determining financial, legal, and management reporting requirements, setting up primary and secondary ledgers, making currency choices, and examining consolidation considerations.
This figure shows the enterprise structure components and their relationships to each other. Primary ledgers are connected to reporting currencies and secondary ledgers to provide complete reporting options. Legal entities are assigned to ledgers, both primary and secondary, and balancing segments are assigned to legal entities. Business units must be connected to both a primary ledger and a default legal entity. Business units can record transactions across legal entities.
A primary ledger is the main record-keeping ledger. Create a primary ledger by combining a chart of accounts, accounting calendar, ledger currency, and accounting method. To determine the number of primary ledgers, your enterprise structure analysis must begin with determining financial, legal, and management reporting requirements. For example, if your company has separate subsidiaries in several countries worldwide, create multiple primary ledgers representing each country with the local currency, chart of accounts, calendar, and accounting method to enable reporting to each country's legal authorities.
If your company just has sales in different countries, with all results being managed by the corporate headquarters, create one primary ledger with multiple balancing segment values to represent each legal entity. Use secondary ledgers or reporting currencies to meet your local reporting requirements, as needed. Limiting the number of primary ledgers simplifies reporting because consolidation is not required. Other consideration such as corporate year end, ownership considerations, and local government regulations, also affect the number of primary ledgers required.
A secondary ledger is an optional ledger linked to a primary ledger. A secondary ledger can differ from its related primary ledger in chart of accounts, accounting calendar, currency, accounting method, or ledger processing options. Reporting requirements, for example, that require a different accounting representation to comply with international or country-specific regulations, create the need for a secondary ledger.
Below are scenarios and required action for different components in primary and secondary ledgers:
If the primary and secondary ledgers use different charts of accounts, the chart of accounts mapping is required to instruct the system how to propagate journals from the source chart of accounts to the target chart of accounts.
If the primary and secondary ledgers use different accounting calendars, the accounting date and the general ledger date mapping table will be used to determine the corresponding non-adjusting period in the secondary ledger. The date mapping table also provides the correlation between dates and non-adjusting periods for each accounting calendar.
If the primary ledger and secondary ledger use different ledger currencies, currency conversion rules are required to instruct the system on how to convert the transactions, journals, or balances from the source representation to the secondary ledger.
Note: Journal conversion rules, based on the journal source and category, are required to provide instructions on how to propagate journals and types of journals from the source ledger to the secondary ledger.
Reporting currencies are the currency you use for financial, legal, and management reporting. If your reporting currency is not the same as your ledger currency, you can use the foreign currency translation process or reporting currencies functionality to convert your ledger account balances in your reporting currency. Currency conversion rules are required to instruct the system on how to convert the transactions, journals, or balances from the source representation to the reporting currency.
Legal entities are discrete business units characterized by the legal environment in which they operate. The legal environment dictates how the legal entity should perform its financial, legal, and management reporting. Legal entities generally have the right to own property and the obligation to comply with labor laws for their country. They also have the responsibility to account for themselves and present financial statements and reports to company regulators, taxation authorities, and other stakeholders according to rules specified in the relevant legislation and applicable accounting standards. During setup, legal entities are assigned to the accounting configuration, which includes all ledgers, primary and secondary.
You assign primary balancing segment values to all legal entities before assigning values to the ledger. Then, assign specific primary balancing segment values to the primary and secondary ledgers to represent nonlegal entity related transactions such as adjustments. You can assign any primary balancing segment value that has not already been assigned to a legal entity. You are allowed to assign the same primary balancing segment values to more than one ledger. The assignment of primary balancing segment values to legal entities and ledgers is performed within the context of a single accounting setup. The Balancing Segment Value Assignments report is available to show all primary balancing segment values assigned to legal entities and ledgers across accounting setups to ensure the completeness and accuracy of their assignments. This report allows you to quickly identify these errors and view any unassigned values.
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. When a business function produces financial transactions, a business unit must be assigned 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. Normally, it will have a manager, strategic objectives, a level of autonomy, and responsibility for its profit and loss. You define business units as separate task generally done after the accounting setups steps.
The business unit model:
Allows for flexible implementation
Provides a consistent entity for controlling and reporting on transactions
Enables sharing of sets of reference data across applications
For example, if your company requires business unit managers to be responsible for managing all aspects of their part of the business, then consider using two balancing segments, company and business unit to enable the production of business unit level balance sheets and income statements.
Transactions are exclusive to business units. In other words, you can use business unit as a securing mechanism for transactions. For example, if you have an export business that you run differently from your domestic business, use business units to secure members of the export business from seeing the transactions of the domestic business.
Create a primary ledger as your main record-keeping ledger. Like any other ledger, a primary ledger records transactional balances by using a chart of accounts with a calendar, currency, and accounting rules implemented in an accounting method. The primary ledger is closely associated with the subledger transactions and provides context and accounting for them.
Your company, InFusion Corporation is implementing Oracle Fusion Applications. You have been assigned the task of creating a primary ledger for your InFusion America entity.
Navigate to the Define Accounting Configurations task list and open Manage Primary Ledgers from within your implementation project. Click the Go to Task.
Click the Create icon.
Enter the following values:
Field |
Value |
---|---|
Name |
InFusion America |
Description |
InFusion America primary ledger for recording transactions. |
Chart of Accounts |
InFusion America Chart of Accounts |
Accounting Calendar |
Standard Monthly |
Currency |
USD |
Accounting Method |
Standard Accrual |
Click Save and Edit Task List to navigate back to the accounting configuration task list.
Note
You cannot change the chart of accounts, accounting calendar, or currency for your ledger after you save your ledger.
This example demonstrates specifying the ledger options for your primary ledger. 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.
After completing your InFusion America Primary Ledger, select Specify Ledger Options under the Define Accounting Configuration task list on the Functional Setup Manager page.
Note
Both primary and secondary ledgers are created in the same way and use the same user interface to enable their specific ledger options.
Important: Select a period after the first defined period in the ledger calendar to enable running translation. You cannot run translation in the first defined period of a ledger calendar. In this example, your calendar began with Jan-2010.
Any value between 0 and 999 periods can be specified to permit entering journals but not posting them in future periods. Minimize the number of open and future periods to prevent entry in the wrong period.
This account is required for the General Ledger to perform the movement of revenue and expense account balances to this account at the end of the accounting year.
Note: The Cumulative Translation Adjustment (CTA) account is required for ledgers running translation.
The values entered here are used as the default for balance level reporting currency processing. InFusion America Primary Ledger is using the subledger level reporting currency processing.
Option |
Setting |
---|---|
Enable Suspense |
General Ledger |
Default Expense Account |
101-00-98199999-0000-000-0000-0000 |
Rounding Account |
101-10-98189999-0000-000-0000-0000 |
Entered Currency Balancing Account |
101-10-98179999-0000-000-0000-0000 |
Balancing Threshold Percent |
10 |
Option |
Description |
---|---|
Enable journal approval |
Click to enable journal approval functionality. Approval rules must be created in the Oracle Fusion Approvals Management (AMX). |
Notify when prior period journal |
Notify the user when a prior period date is selected on a journal entry. |
Allow mixed and statistical journals |
Enter both monetary and statistical amounts on the same line in a journal entry. |
Validate reference date |
Requires a reference date in an open or future enterable period. |
Note: To complete the intercompany accounting functionality, you must define intercompany rules.
To avoid data corruption, your cumulative adjustment account (CTA) can only be changed if you first perform the following set of steps:
Purge all translated balances
Change the CTA account
Rerun translation
To avoid data corruption, your retained earnings account can only be changed if you first perform the following set of steps:
Enter and post journals to bring the ending balances for your income statement accounts to zero at the end of each accounting year
Purge actual translated balances
Update the retained earnings account
Reverse the journal entries use to bring the ending account balances to zero and rerun translation
Optionally, assign legal entities and balancing segments to your accounting configuration.
Assign one or more legal entities to your configuration by following these steps:
Navigate to the Assign Legal Entities task. Click the Go to Task.
Click the Select and Add icon.
Click Search. Select your legal entities.
Click Apply. Click Done.
Click Save and Close.
Assign balancing segment values to your legal entities by following these steps:
Navigate to the Assign Balancing Segment Values to Legal Entities task. Click the Go to Task.
Click the Create icon.
Select the balancing segment value. Optionally, add a Start Date.
Click Save and Close to close the create page.
Click Save and Close.
Assign balancing segment values directly to your ledger by following these steps:
Navigate to the Assign Balancing Segment Value to Ledger task. Click the Go to Task.
Select the balancing segment value.
Optionally enter a start date.
Click Save and Close.
Note
The balancing segment values that are assigned to the ledger represent nonlegal entity transactions, such as adjustments. If you use legal entities, you must assign balancing segment values to all legal entities before assigning values to the ledger. The only available balancing segment values that can be assigned to ledgers are those not assigned to legal entities.
Reporting currency balances, set at the journal or subledger level, are updated when journal entries that originate in Oracle Fusion General Ledger are posted and converted to your reporting currencies. This process includes General Ledger manual journals, periodic journals, and allocations, and at the subledger level, journals from Oracle Fusion Subledger Accounting and imported from sources other than your Oracle Fusion subledgers. When you post a journal in a ledger that has one or more reporting currencies defined, the posting process creates new journals converted to each of your reporting currencies and includes them in the same batch as the original journal with a status of Posted.
Reporting currencies share a majority of the ledger options with their source ledger. For example, the reporting currency uses the same suspense account and retained earnings accounts as its source ledger. However, there are certain options that need to be set specifically for the reporting currencies. For example, reporting currencies are maintained at one of these three currency conversion levels:
Balance Level: Only balances are maintained in the reporting currency using the General Ledger Translation process.
Journal Level: Journal entries and balances are converted to the reporting currency by the General Ledger Posting process.
Subledger Level: Subledger Accounting creates reporting currency journals for subledger transactions. General Ledger converts journals that originated in General Ledger or that are imported from sources other than the Oracle Fusion subledgers. The full accounting representation of your primary ledger is maintained in the subledger level reporting currency.
Note
Secondary Ledgers cannot use subledger level reporting currencies.
There are multiple dependencies between a reporting currency and its source ledger. Therefore, it is important that you complete your period opening tasks, daily journal or subledger level reporting currencies accounting tasks, and period closing tasks in the correct order. Some guidelines are presented in the table below.
Type |
Task |
---|---|
Period Opening Tasks |
Open the accounting period in both your ledger and reporting currencies before you create or import journals for the period. Converted journals are only generated in your reporting currency if the period is open or future enterable. |
Daily Tasks |
Enter the daily conversion rates to convert your journals to each of your reporting currencies. |
Period Closing Tasks |
|
If you use reporting currencies at the journal or subledger level, when you create accounting, post journal entries, or translate balances, journals are posted in your reporting currency. General Ledger and Subledger Accounting automatically generate journals in your reporting currencies where the entered currency amounts are converted to the reporting currency amounts. Other factors used in the calculation of reporting currency balances are listed:
Manual Journals: Enter a manual journal batch in your reporting currency at the journal or subledger level by using the Create Journals page. Select the journal or subledger level reporting currency from the ledger's list of values and continue in the same manner as entering any other manual journal.
Conversion Rounding: Use the reporting currency functionality to round converted and accounted amounts using the same rounding rules used throughout your Oracle Fusion Applications. The reporting currency functionality considers several factors that are a part of the currencies predefined in your applications, including:
Currency Precision: Number of digits to the right of the decimal point used in currency transactions.
Minimum Accountable Unit: Smallest denomination used in the currency. This might not correspond to the precision.
Converted Journals: Generate and post automatically, using the General Ledger Posting process, journals in your reporting currencies when you post the original journals in the source ledger for the following types of journals:
Manual journals
Periodic and allocation journals
Unposted journals from non-Oracle subledger applications
Unposted journals from any Oracle Fusion subledger that does not support reporting currency transfer and import
Optionally, revaluation journals
Unconverted Journals: Rely on the subledger accounting functionality to converted and transfer Oracle Fusion subledger journals for both the original journal and the reporting currency journal to the General Ledger for import and posting. The reporting currency conversion for these journals is not performed by the General Ledger.
Approving Journals: Use the journal approval feature to process reporting currency journals through your organization's approval hierarchy. You can enable journal approval functionality separately in your source ledger and reporting currencies.
Document Numbers: Accept the default document numbers assigned by the General Ledger application to your journal when you enter a journal in your ledger. The converted journal in the reporting currency is assigned the same document number. However, if you enter a journal in the reporting currency, the document number assigned to the journal is determined by the reporting currency.
Sequential Numbering: Enable sequential numbering if you want to maintain the same numbering in your reporting currency and source ledger for journals, other than those journals for Oracle Fusion subledgers. Do not create separate sequences for your reporting currencies. If you do, the sequence defined for the reporting currencies is used and can cause document numbers not to be synchronized between the ledger and reporting currencies.
Note
If the Sequential Numbering profile option is set to Always Used or Partially Used and you define an automatic document numbering sequence, General Ledger enters a document number automatically when you save your journal. If you use manual numbering, you can enter a unique document number.
Revaluation: Run periodically revaluation in your ledger and reporting currencies as necessary to satisfy the accounting regulations of the country in which your organization operates.
Account Inquiries: Perform inquires in the reporting currency. Drill down to the journal detail that comprises the reporting currency balance. If the journal detail is a converted journal that was converted automatically when the original journal was posted in the source ledger, you can drill down further to see the source ledger currency journal amounts.
Note
Be careful when changing amounts in a reporting currency, since the changes are not reflected in your source ledger. Making journal entry changes to a reporting currency makes it more difficult to reconcile your reporting currency to your source ledger. In general, enter or change your journals in your source ledger, and then allow posting to update the reporting currency.
Note
If you use reporting currencies at the journal or subledger level, statistical journals are generated for your reporting currencies, but the journals are not affected by the currency conversion process.
Oracle Fusion Applications allows defining relationships between business units to outline which business unit provides services to the other business units.
In Oracle Fusion Applications V1.0, the service provider model centralizes only the procurement business function. Your business units that have the requisitioning business function enabled can define relationships with business units that have the procurement business function enabled. These service provider business units will process requisitions and negotiate supplier terms for their client business units.
This functionality is used to frame service level agreements and drive security. The definition of service provider relationships provides you with a clear record of how the operations of your business are centralized. For other centralized processing, business unit security is used (known in Oracle EBS as Multi-Org Access Control). This means that users who work in a shared service center have the ability to get access and process transactions on behalf of many business units.
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.
The setup of business units provides you with a powerful security construct by creating relationships between the functions your users can perform and the data they can process. This security model is appropriate in a business environment where local business units are solely responsible for managing all aspects of the finance and administration functions.
In Oracle Fusion applications, the business functions your business unit performs are evident in the user interface for setting up business units. To accommodate shared services, use business unit security to expand the relationship between functions and data. A user can have access to many business units. This is the core of your shared service architecture.
For example, you take orders in many business units each representing different registered legal entities. Your orders are segregated by business unit. However, all of these orders are managed from a shared service order desk in an outsourcing environment by your users who have access to multiple business units.
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.
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.
The Oracle Fusion Procurement product family has taken advantage of the service provide model by defining outsourcing of the procurement business function. Define your business units with requisitioning and payables invoicing business functions as clients of your business unit with the procurement business function. Your business unit responsible for the procurement business function will take care of supplier negotiations, supplier site maintenance, and purchase order processing on behalf of your client business units. Subscribe your client business units to the supplier sites maintained by the service providers, using a new procurement feature for supplier site assignment.
In the InFusion example below, business unit four (BU4) serves as a service provider to the other three business units (BU1, BU2, and BU3.) BU4 provides the corporate administration, procurement, and human resources (HR) business functions, thus providing cost savings and other benefits to the entire InFusion enterprise.
Using the Specify Customer Contract Management Business Function Properties task, available by navigating to Setup and Maintenance work area and searching on the task name, you can specify a wide variety of business function settings for customer contracts in a specific business unit. The selections you make for these business functions impact how Oracle Fusion Enterprise Contracts behaves during contract authoring.
Using the Specify Customer Contract Management Business Function Properties task, manage these business function properties:
Enable related accounts
Set currency conversion details
Manage project billing options
Set up the Contract Terms Library
The setup options available for the Contract Terms Library are applicable to both customer and supplier contracts, and are described in the business unit setup topic for the Contract Terms Library. That topic is available as a related link to this topic.
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.
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.
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.
You can specify a wide variety of Contract Terms Library settings for either customer or supplier contracts within each business unit, by using either the Specify Customer Contract Management Business Function Properties or the Specify Supplier Contract Management Business Function Properties tasks. These tasks are available by navigating to the Setup and Maintenance work area and searching on the task name.
For the Contract Terms Library in each business unit, you can:
Enable clause and template adoption.
Set the clause numbering method.
Enable the Contract Expert feature.
Specify the layout for printed clauses and contract deviation reports.
If you plan to use clause adoption in your implementation, then set up the following:
Specify a global business unit
You must designate one of the business units in your organization as the global business unit by selecting the Global Business Unit option. This makes it possible for the other local business units to adopt and use approved content from that global business unit. If the Global Business Unit option is not available for the business unit you are setting up, this means that you already designated another business unit as global.
Enable automatic adoption
If you are implementing the adoption feature, then you can have all the global clauses in the global business unit automatically approved and available for use in the local business by selecting the Autoadopt Global Clauses option. If you do not select this option, the employee designated as the Contract Terms Library Administrator must approve all global clauses before they can be adopted and used in the local business unit. This option is available only for local business units.
Specify the administrator who approves clauses available for adoption
You must designate an employee as the Contract Terms Library administrator if you are using adoption. If you do not enable automatic adoption, then the administrator must adopt individual clauses or localize them for use in the local business unit. The administrator can also copy over any contract terms templates created in the global business unit. The clauses and contract terms templates available for adoption are listed in the administrator's Terms Library work area.
You can set up automatic clause numbering for the clauses in the business unit by selecting Automatic in the Clause Numbering field and entering a Document Sequence Category you previously set up in the Clause Sequence Category field. If clause numbering is manual, contract terms library administrators must enter unique clause numbers each time they create a clause.
You can choose to display the clause number in front of the clause title in contracts by selecting the Display Clause Number in Clause Title option.
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.
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.
Using the Specify Supplier Contract Management Business Function Properties task, available by selecting Setup and Maintenance from the Tools menu and searching on the task name, you can specify a variety of business function settings for supplier contracts in a specific business unit.
The selections you make for these business functions impact how the Contract Terms Library behaves during supplier contract authoring.
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.
You can specify a wide variety of Contract Terms Library settings for either customer or supplier contracts within each business unit, by using either the Specify Customer Contract Management Business Function Properties or the Specify Supplier Contract Management Business Function Properties tasks. These tasks are available by navigating to the Setup and Maintenance work area and searching on the task name.
For the Contract Terms Library in each business unit, you can:
Enable clause and template adoption.
Set the clause numbering method.
Enable the Contract Expert feature.
Specify the layout for printed clauses and contract deviation reports.
If you plan to use clause adoption in your implementation, then set up the following:
Specify a global business unit
You must designate one of the business units in your organization as the global business unit by selecting the Global Business Unit option. This makes it possible for the other local business units to adopt and use approved content from that global business unit. If the Global Business Unit option is not available for the business unit you are setting up, this means that you already designated another business unit as global.
Enable automatic adoption
If you are implementing the adoption feature, then you can have all the global clauses in the global business unit automatically approved and available for use in the local business by selecting the Autoadopt Global Clauses option. If you do not select this option, the employee designated as the Contract Terms Library Administrator must approve all global clauses before they can be adopted and used in the local business unit. This option is available only for local business units.
Specify the administrator who approves clauses available for adoption
You must designate an employee as the Contract Terms Library administrator if you are using adoption. If you do not enable automatic adoption, then the administrator must adopt individual clauses or localize them for use in the local business unit. The administrator can also copy over any contract terms templates created in the global business unit. The clauses and contract terms templates available for adoption are listed in the administrator's Terms Library work area.
You can set up automatic clause numbering for the clauses in the business unit by selecting Automatic in the Clause Numbering field and entering a Document Sequence Category you previously set up in the Clause Sequence Category field. If clause numbering is manual, contract terms library administrators must enter unique clause numbers each time they create a clause.
You can choose to display the clause number in front of the clause title in contracts by selecting the Display Clause Number in Clause Title option.
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.
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.
A business unit can perform many business functions in Oracle Fusion Applications. Prior to Oracle Fusion Applications, operating units in Oracle E-Business Suite were assumed to perform all business functions, while in Oracle PeopleSoft , each business unit had one specific business function. Oracle Fusion Applications blends these two models and allows defining business units with one or many business functions.
A business function represents a business process, or an activity that can be performed by people working within a business unit and describes how a business unit is used. The following business functions exist in Oracle Fusion applications:
Billing and revenue management
Collections management
Customer contract management
Customer payments
Expense management
Incentive compensation
Marketing
Materials management
Inventory management
Order fulfillment orchestration
Payables invoicing
Payables payments
Procurement
Procurement contract management
Project accounting
Receiving
Requisitioning
Sales
Although there is no relationship implemented in Oracle Fusion Applications, a business function logically indicates a presence of a department in the business unit with people performing tasks associated with these business functions. A business unit can have many departments performing various business functions. Optionally, you can define a hierarchy of divisions, business units, and departments as a tree over HCM organization units to represent your enterprise structure.
Note
This hierarchy definition is not required in the setup of your applications, but is a recommended best practice.
Your enterprise procedures can require a manager of a business unit to have responsibility for their profit and loss statement. However, there will be cases where a business unit is performing only general and administrative functions, in which case your manager's financial goals are limited to cost containment or recovering of service costs. For example, if a shared service center at the corporate office provides services for more commercially-oriented business units, it does not show a profit and therefore, only tracks its costs.
In other cases, where your managers have a responsibility for the assets of the business unit, a balance sheet can be produced. The recommended best practice to produce a balance sheet, is to setup the business unit as a balancing segment in the chart of accounts. The business unit balancing segment can roll up to divisions or other entities to represent your enterprise structure.
When a business function produces financial transactions, a business unit must be assigned to a primary ledger, and a default legal entity. Each business unit can post transactions to a single primary ledger, but it can process transactions for many legal entities.
The following business functions generate financial transactions and will require a primary ledger and a default legal entity:
Billing and revenue management
Collections management
Customer payments
Expense management
Materials management
Payables invoicing
Project accounting
Receiving
Requisitioning
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
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.
A business unit is a unit of an enterprise that performs one or many business functions that can be rolled up in a management hierarchy. A business unit can process transactions on behalf of many legal entities. Normally, it will have a manager, strategic objectives, a level of autonomy, and responsibility for its profit and loss. Roll business units up into divisions if you structure your chart of accounts with this type of hierarchy. In Oracle Fusion Applications, you assign your business units to one primary ledger. For example, if a business unit is processing payables invoices they will need to post to a particular ledger. This assignment is mandatory for your business units with business functions that produce financial transactions.
In Oracle Fusion Applications, use business unit as a securing mechanism for transactions. For example, if you run your export business separately from your domestic sales business, secure the export business data to prevent access by the domestic sales employees. To accomplish this security, set up the export business and domestic sales business as two separate business units.
The Oracle Fusion Applications business unit model:
Allows for flexible implementation
Provides a consistent entity for controlling and reporting on transactions
Anchors the sharing of sets of reference data across applications
Business units process transactions using reference data sets that reflect your business rules and policies and can differ from country to country. With Oracle Fusion Application functionality, you can choose to share reference data, such as payment terms and transaction types, across business units, or you can choose to have each business unit manage its own set depending on the level at which you wish to enforce common policies.
In countries where gapless and chronological sequencing of documents is required for subledger transactions, define your business units in alignment with your ledger definition, because the uniqueness of sequencing is only ensured within a ledger. In these cases, define a single ledger and assign one legal entity and business unit.
In summary, use business units in the following ways:
Management reporting
Processing of transactions
Security of transactional data
Reference data definition and sharing
Business units are used by a number of Oracle Fusion Applications to implement data security. You assign data roles to your users to give them access to data in business units and permit them to perform specific functions on this data. When a business function is enabled for a business unit, the application can trigger the creation of data roles for this business unit based on the business function's related job roles.
For example, if a payables invoicing business function is enabled, then it is clear that there are employees in this business unit that perform the function of payables invoicing, and need access to the payables invoicing functionality. Therefore, based on the correspondence between the business function and the job roles, appropriate data roles are generated automatically. Use Human Capital Management (HCM) security profiles to administer security for employees in business units.
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.
A location identifies physical addresses of a workforce structure, such as a department or a job. You can also create locations to enter the addresses of external organizations that you want to maintain, such as employment agencies, tax authorities, and insurance or benefits carriers.
The locations that you create exist as separate structures that you can use for reporting purposes, and also in rules that determine employee eligibility for various types of compensation and benefits. You enter information about a location only once. Subsequently, when you set up other workforce structures you select the location from a list.
When you create a location, you must associate it with a set. Only those users who have access to the set's business unit can access the location set and other associated workforce structure sets, such as those that contain departments and jobs.
You can also associate the location to the common set so that users across your enterprise can access the location irrespective of their business unit. When users search for locations, they can see the locations that they have access to along with the locations in the common set.
The following figure shows how locations sets restrict access to users.
If you have a list of locations already defined for your enterprise, you can upload them from a spreadsheet. To use this option, you first download a spreadsheet template, then add your location information to the spreadsheet, and then upload directly to your enterprise configuration. You can upload the spreadsheet multiple times to accommodate revisions.
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.
From the Manage Locations page in Oracle Fusion Global Human Resources.
To appear on the Create or Edit Location pages, your inventory organization must be effective on today's date and must exist in the location set that you selected.
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.
The calendar events that were created for the geographical node start to apply for the location and may impact the availability of worker assignments at that location. The geographical hierarchy nodes available for selection on the Locations page display from a predefined geographic hierarchy.
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.
Managing multiple businesses requires that you segregate them by their strategic objectives and measure their results. Responsibility to reach objectives can be delegated along the management structure. Although related to your legal structure, the business organizational hierarchies do not need to reflect directly the legal structure of the enterprise. The management entities and structure can include divisions and subdivisions, lines of business, and other strategic business units, and include their own revenue and cost centers. These organizations can be included in many alternative hierarchies and used for reporting, as long as they have representation in the chart of accounts.
A division refers to a business oriented subdivision within an enterprise, in which each division organizes itself differently to deliver products and services or address different markets. A division can operate in one or more countries, and can be comprised of many companies or parts of different companies that are represented by business units.
A division is a profit center or grouping of profit and cost centers, where the division manager is responsible for attaining business goals including profit goals. A division can be responsible for a share of the company's existing product lines or for a separate business. Managers of divisions may also have return on investment goals requiring tracking of the assets and liabilities of the division. The division manager reports to a top corporate executive.
By definition a division can be represented in the chart of accounts. Companies may choose to represent product lines, brands, or geographies as their divisions: their choice represents the primary organizing principle of the enterprise. This may coincide with the management segment used in segment reporting.
Oracle Fusion Applications supports a qualified management segment and recommends that you use this segment to represent your hierarchy of business units and divisions. If managers of divisions have return on investment goals, make the management segment a balancing segment. Oracle Fusion applications allows up to three balancing segments. The values of the management segment can be comprised of business units that roll up in a hierarchy to report by division.
Historically, divisions were implemented as a node in a hierarchy of segment values. For example, Oracle E-Business Suite has only one balancing segment, and often the division and legal entity are combined into a single segment where each value stands for both division and legal entity.
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.
This example shows how to restructure your enterprise after acquiring a new division.
You are part of a senior management team at InFusion Corporation. InFusion is a global company with organizations in the United States (US), the United Kingdom (UK), France, China, Saudi Arabia, and the United Arab Emirates (UAE). Its main area of business is in the high tech industry, and it has just acquired a new company. You must analyze their current enterprise structure and determine what new organizations you need to create to accommodate the new company.
The acquired company is a financial services business based in Germany. Because the financial services business differs significantly from the high tech business, you want to keep the financial services company as a separate business with all the costs and reporting rolling up to the financial services division.
The following table summarizes the key decisions that you must consider when determining what new organizations to set up and how to structure the enterprise.
Decision to Consider |
In This Example |
---|---|
Create location? |
The financial services company is based in Frankfurt as are the departments, so you need to create only one location. |
Create separate division? |
Yes. Although the new division will exist within the current enterprise structure, you want to keep the financial services company as a separate line of business. Creating a separate division means you can manage the costs and reporting separately from the InFusion Corporation. It also means you do not have to modify any existing organizations in the enterprise setup. |
Create business unit? |
Yes. The financial services business requires you to create several jobs that do not exist in your high tech business. You can segregate the jobs that are specific to financial services in a new business unit. |
How many departments? |
The financial services company currently has three departments for sales, accounting, and marketing. As you have no plans to downsize or change the company, you can create three departments to reflect this structure. |
How many cost centers? |
Although you can have more than one cost center tracking the costs of a department, you decide to create one cost center for each department to track costs. |
How many legal entities? |
Define a legal entity for each registered company or other entity recognized in law for which you want to record assets, liabilities, and income, pay transaction taxes, or perform intercompany trading. In this case, you need only one legal entity. You must define the legal entity as a legal employer and payroll statutory unit. As the new division operates in Germany only, you can configure the legal entity to suit Germany legal and statutory requirements. Note When you identify the legal entity as a payroll statutory unit, the application transfers the legal reporting unit that is associated with that legal entity to Oracle Fusion HCM as a tax reporting unit. |
Create legislative data group? |
Yes. Because you currently do not employ or pay people in Germany, you must create one legislative data group to run payroll for the workers in Germany. |
Based on the analysis, you must create the following:
One new division
One new location
Three new departments
Three new cost centers
One new legal entity
One new legislative data group
The following figure illustrates the structure of InFusion Corporation after adding the new division and the other organizations.
A cost center represents the smallest segment of an organization for which costs are collected and reported. A department is an organization with one or more operational objectives or responsibilities that exist independently of its manager and has one or more workers assigned to it.
The following two components need to be considered in designing your enterprise structure:
Cost centers
Departments
A cost center also represents the destination or function of an expense as opposed to the nature of the expense which is represented by the natural account. For example, a sales cost center indicates that the expense goes to the sales department.
A cost center is generally attached to a single legal entity. To identify the cost centers within a chart of accounts structure use one of these two methods:
Assign a cost center value in the value set for each cost center. For example, assign cost center values of PL04 and G3J1 to your manufacturing teams in the US and India. These unique cost center values allow easy aggregation of cost centers in hierarchies (trees) even if the cost centers are in different ledgers. However, this approach will require defining more cost center values.
Assign a balancing segment value with a standardized cost center value to create a combination of segment values to represent the cost center. For example, assign the balancing segment values of 001 and 013 with cost center PL04 to represent your manufacturing teams in the US and India. This creates 001-PL04 and 013-PL04 as the cost center reporting values.
The cost center value of PL04 has a consistent meaning. This method requires fewer cost center values to be defined. However, it prevents construction of cost center hierarchies using trees where only cost center values are used to report results for a single legal entity. You must specify a balancing segment value in combination with the cost center values to report on a single legal entity.
A department is an organization with one or more operational objectives or responsibilities that exist independently of its manager. For example, although the manager may change, the objectives do not change. Departments have one or more workers assigned to them.
A manager of a department is typically responsible for:
Controlling costs within their budget
Tracking assets used by their department
Managing employees, their assignments, and compensation
Note
The manager of a sales department may also be responsible for meeting the revenue targets.
The financial performance of departments is generally tracked through one or more cost centers. In Oracle Fusion Applications, departments are defined and classified as Department organizations. Oracle Fusion Human Capital Management (HCM) assigns workers to departments, and tracks the headcount at the departmental level.
The granularity of cost centers and their relationship to departments varies across implementations. Cost center and department configuration may be unrelated, identical, or consist of many cost centers tracking the costs of one department.
A department can be classified as a project organization, sales and marketing organization, or cost organization.
Oracle Fusion Human Capital Management (HCM) uses trees to model organization hierarchies. It provides seeded tree structures for department and other organizational hierarchies that can include organizations with any classification.
Classify departments as a project owning organization to enable associating them with projects or tasks. The project association is one of the key drivers for project access security.
In addition, you must classify departments as project expenditure organizations to enable associating them to project expenditure items. Both project owning organizations and project expenditure organizations can be used by Oracle Fusion Subledger Accounting to derive accounts for posting Oracle Fusion Projects accounting entries to Oracle Fusion General Ledger.
In Oracle Fusion Customer Relationship Management (CRM), you can define sales and marketing organizations. Sales organization hierarchies are used to report and forecast sales results. Sales people are defined as resources assigned to these organizations.
In some enterprises, the HCM departments and hierarchies correspond to sales organizations and hierarchies. It is important to examine the decision on how to model sales hierarchies in relationship to department hierarchies when implementing customer relationship management to eliminate any possible redundancy in the definition of the organizations.
The following figure illustrates a management hierarchy, in which the System Components Division tracks its expenses in two cost centers, Air Compressors and Air Transmission. At the department level, two organizations with a classifications of Department are defined, the Marketing Department and Sales Department. These two departments can be also identified as a Resource Organizations, which will allow assigning resources, such as sales people, and other CRM specific information to them. Each department is represented in the chart of accounts by more than one cost center, allowing for granular as well as hierarchical reporting.
Oracle Fusion Costing uses a cost organization to represent a single physical inventory facility or group of inventory storage centers, for example, inventory organizations. This cost organization can roll up to a manager with responsibility for the cost center in the financial reports.
A cost organization can represent a costing department. Consider this relationship when determining the setup of departments in HCM. There are no system dependencies requiring these two entities, cost organization and costing department, be set up in the same way.
A job family is a group of jobs that have different but related functions, qualifications, and titles. They are beneficial for reporting. You can define competencies for job families by associating them with model profiles.
A job set is an organizational partition of jobs. For example, a job set can be global and include jobs for use in all business units, or it can be restricted to jobs for a specific country or line of business. When you select a job, for a position or an assignment, the available jobs are those in the set associated with the business unit in which you are working, and also those in the Common set.
As part of your initial implementation, you specify whether to use jobs and positions, or only jobs. Jobs are typically used without positions by service industries where flexibility and organizational change are key features.
Basic details for a job include an effective start date, a job set, a name, and a code.
A job code must be unique within a set. Therefore, you can create a job with the code DEV01 in the US set and another job with the same code in the UK set. However, if you create a job with the code DEV01 in the Common set, then you cannot create a job with the same code in any other set.
You can identify a job as being a benchmark job. A benchmark job represents other jobs in reports and salary surveys. You can also select the benchmark for jobs. Benchmark details are for informational purposes only. A progression job is the next job in a career ladder.
Progression jobs enable you to create a hierarchy of jobs and are used to provide the list of values for the Job field in the Promote Worker and Transfer Worker tasks. The list of values includes the next three jobs in the progression job hierarchy. For example, assume that you create a job called Junior Developer and select Developer as the progression job. In the Developer job, you select Senior Developer as the progression job. When you promote a junior developer, the list of values for the new job will include Developer and Senior Developer. You can select one of these values, or select another one.
You can assign grades that are valid for each job. If you are using positions, then the grades that you specify for the job become the default grades for the position.
You can define evaluation criteria for a job, including the evaluation system, a date, and the unit of measure for the system. One predefined evaluation system is available, and that is the Hay system. An additional value of Custom is included in the list of values for the Evaluation System field, but you must add your own criteria and values for this system.
If you have a list of jobs 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 job information to the spreadsheet, and then upload directly to your enterprise configuration. You can upload the spreadsheet multiple times to accommodate revisions.
Jobs are typically used without positions by service industries where flexibility and organizational change are key features.
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.
The strength of the relationship between the person performing a gallery search and each person whose assignment appears in the search results can determine the order of the results: the stronger the relationship, the closer to the top of the results an assignment appears. The search relevance profile options control how the strength of the relationship between the searcher and the search result is calculated.
Using the following profile options, you can change the weighting applied to the relevant factors.
Profile Option |
Description |
---|---|
HR: Organization Hierarchy Weight |
Specifies the weighting applied to the relationship strength value for the organization hierarchy proximity factor. |
HR: Position Hierarchy Weight |
Specifies the weighting applied to the relationship strength value for the position hierarchy proximity factor. |
HR: Manager Hierarchy Weight |
Specifies the weighting applied to the relationship strength value for the manager hierarchy proximity factor. |
HR: Location Proximity Weight |
Specifies the weighting applied to the relationship strength value for the location proximity factor. |
HR: Selection History Weight |
Specifies the weighting applied to the relationship strength value for the selection history factor. |
HR: Social Network Weight |
Specifies the weighting applied to the relationship strength value for the social network factor. |
The default value of each weighting profile option is 0.5. To increase the relevance of a factor relative to other factors, you increase its weighting; to decrease its relevance, you reduce its weighting.
The number of times the searcher selects a person's assignment from the search results during a specified period, which is 7 days by default, is recorded automatically. You can specify this period for the enterprise on the HR: Selection History Timeout profile option.
When the searcher's primary assignment is in the same organization, position, or manager hierarchy as a person's assignment, the strength of the relationship depends on their proximity to each other in the hierarchy. The maximum number of hierarchy boundaries to include in the calculation is 4 by default. You can set this value for the enterprise on the HR: Maximum Hierarchy Proximity profile option.
The searcher can specify a rating for a search result, and each rating is associated with a multiplying factor. On this profile option, you can specify the highest possible multiplying factor that can be applied to a search result. By default, the multiplying factor is 2. If you increase its value, you increase the significance of the searcher's own ratings relative to other factors.
Schedules are comprised of workday patterns and exceptions. Workday patterns are comprised of shifts. You can also create exceptions, nonworking days, to the schedules.
Begin by creating shifts and then assigning those shifts to workday patterns. Next, create a schedule that is a collection of workday patterns and any exception dates.
A shift is a period of time, typically expressed in hours, and it can be defined by a start time and an end time, or a duration. A shift can be for a work period or a off period. You can create time, duration, and elapsed shifts.
A workday pattern is a collection of shifts for a specific number of days. You can create time, duration, and elapsed workday patterns.
An exception is a record of a date that overrides the availability of a resource to which a schedule has been assigned. For example, a resource is assigned a schedule that includes December 25 as a working day. An exception can be created for December 25 and applied to that schedule to override resource availability for that date. Exceptions can also be for a date time period such as 9 a.m. to 11 a.m. on December 25th.
A schedule is defined by a start date, an end date, and a sequence of workday patterns to be followed between those dates. A schedule can also contain exception dates that override the availability of resources to which the schedule is assigned. Quarter types such as 4-4-5, 4-5-4 are supported.
A shift is a period of time, typically expressed in hours, that is used to build workday patterns. Workday patterns are used to build schedules. There are multiple types of shifts you can create. The following scenarios illustrate each type.
Next month you are adding a second shift for your manufacturing operations. This new shift will start right after your regular first shift. You can create a time shift that starts at 4:00 p.m. and ends at 12:00 a.m. There are restrictions in updating existing shifts and patterns. Shifts and patterns cannot be updated if the change affects a schedule, that is they are associated to a schedule. If a shift is created but not assigned to a pattern (or assigned to a pattern but the pattern is not assigned to a schedule) it can be updated. If a pattern is created and not assigned to a schedule it can be updated.
Your division has decided that the employees in the office must clock in and out for lunch starting next week. All employees will take the same lunch hour. Add punch shift details to the existing shift so that employees punch in at 8:00 a.m.; they punch out for lunch from 11:30 a.m. to 12:30 p.m.; they punch back in at 12:30 p.m.; and they punch out for the day at 5:00 p.m.
Jorge Sanchez is a contractor who is starting work in your department next week. His hours will be flexible, so you need to create a new time shift with flexible details that he can use to record his time. He will have a flexible start time from 7:00 a.m. to 9:00 a.m. and a flexible end time from 4:00 p.m. to 6:00 p.m. His core work hours will be from 9:00 a.m. to 4:00 p.m.
One of the divisions in your organization does not use fixed start and end times for its daily shifts; the division only records the total duration of the shift and indicates if resources are available or not during that time. All of the employees in the division are available for 24 hours straight, and then they are not available for the next 24 hours. You should create a duration shift that indicates that resources are available for 24 hours, and create a second duration shift that indicates that resources are not available for 24 hours.
The employees in the Human Resources department all work 8 hours a day, but the start and end times vary by employee. Some employees start at early as 6:00 a.m., while others don't start until 9:00 a.m. Create an elapsed shift with a duration of 8 hours, where all employees are assumed to be available for the number of hours in the shift at any time during the day.
A workday pattern is a collection of shifts for a specific number of days. There are multiple types of workday patterns you can create. The following scenarios illustrate each type.
Your department works a Monday through Friday workweek with 8 hour shifts each day. Time patterns always have time shifts. That is, the shift will have start time and end time. You can create a time workday pattern with a length of 7 days and details of an 8 hour time shift for days 1 through 5. Days 6 and 7 are considered nonworking days.
A new group of employees starts next month, and each employee will work a schedule where he or she is available for 10 hours, and then not available for the next 16 hours, and then available for 10 hours again, and so on. This pattern starts on midnight of the first day of the next month. Create a duration workday pattern with a 10-hour available duration shift, followed by a 16-hour not available duration shift. Do not specify the pattern length or start and end days, and the pattern will repeat for the length of the schedule to which it is associated.
In the summer, several divisions in your organization work only 4 hours on Fridays. They work extended hours on Wednesdays and Thursdays to cover the 4 hours they will not work on Fridays. Create an elapsed workday pattern with a length of 7 days. Days 1 and 2 will have an 8-hour shift assigned, while days 3 and 4 will have a 10-hour shift assigned. Finally, day 5 will have a 4-hour shift assigned. As in the time workday pattern, days 6 and 7 are considered nonworking days.
An inventory organization is a logical or physical entity in the enterprise that is used to store definitions of items or store and transact items.
You select the following usages in the inventory organization's properties:
Item management
Item and inventory management
Inventory organizations used for item management, which are the same as item organizations, store only definitions of items. Use inventory organizations for item management when the storage or movement of inventory does not need to be physically or financially tracked. For example, in a retail implementation you can create an inventory organization for item management to store the names of items that are listed by and sold through each retail outlet, while a different system tracks physical inventory and transactions. If it is necessary in the future, you can change an inventory organization's usage from item management to item and inventory management in the inventory organization's properties.
Inventory organizations used for item and inventory management store and transact items, in addition to item definitions. An inventory organization used for item and inventory management is associated with one business unit, one legal entity, and one primary ledger. Use inventory organizations for item and inventory management when the storage or movement of inventory needs to be physically and financially tracked. Inventory organizations used for item and inventory management can represent facilities such as manufacturing centers, warehouses, or distribution centers. You cannot change an inventory organization's use from item and inventory management to item management.
In Oracle Fusion, storage facilities, warehouses, and distribution centers are implemented as inventory organizations.
Inventory organizations are:
Managed by a business unit, with the materials management business function enabled.
Mapped to a legal entity and a primary ledger.
There are two types of inventory organizations:
Manufacturing facilities
Storage facilities
Storage and manufacturing facilities are related to other organizational entities through a business unit that stores, manufactures, and distributes goods through many factories, warehouses, and distribution centers. The material parameters are set for both the facilities, enabling movement of material in the organization. This business unit has the business function of Materials Management enabled. Oracle Fusion Applications allow many inventory organizations to be assigned to one business unit.
Note
Currently, Oracle Fusion Applications do not include manufacturing capabilities, so setup your manufacturing facilities outside of Oracle Fusion applications.
A distribution center can store inventory that is the responsibility of different business units. In this situation, assign an inventory organization to each business unit as a representation of the inventory in the distribution center. The multiple inventory organizations representing the inventory are defined with the same location to show that they are a part of the same distribution center.
In the following figure the two business units, Air Compressors and Air Transmission, share one distribution center in Atlanta. The two inventory organizations, Air Compressors and Air Transmission represent the inventory for each business unit in the Atlanta distribution center and are both assigned the Atlanta location.
A legal entity owns the inventory located in a storage or manufacturing facility. This ownership is assigned through the relationship of the inventory organization representing the inventory and the legal entity assigned to the inventory organization. The legal entity assigned to the inventory organization shares the same primary ledger as the inventory organization's business unit.
The inventory is tracked in the inventory organization owned by the legal entity of which the business unit is part. All transactions are accounted for in the primary ledger of the legal entity that owns the inventory.
The figure below illustrates the inventory owned by InFusion Air Quality legal entity. The InFusion Air Quality legal entity is associated with the Air Compressors business unit, which is associated with the two Air Compressors inventory organizations. Therefore, InFusion Air Quality legal entity owns the entire inventory in both the Dallas and Atlanta locations.
A prerequisite to defining an inventory organization is to define a facility schedule. Oracle Fusion Applications allow you to associate an inventory organization with a schedule.
Facility schedules allow creating workday calendars for inventory organizations that are used in the Oracle Fusion Supply Chain Management product family. For example, use workday calendars in the scheduling of cycle counts and calculating transit time.
You can create a new inventory organization, or select an existing organization to define as an inventory organization.
Before creating inventory organizations:
Set up inventory organization dependencies
Plan inventory organization parameters
When you create an inventory organization, you must associate it to dependencies, such as business units and legal entities. For this reason, create these dependencies before creating an inventory organization.
Before creating an inventory organization, plan the inventory organization's parameters
Consider the following when planning to configure an inventory organization's parameters
Which schedule to use
Which inventory organization to serve as the item master organization
Whether to configure locator control and if so, the level at which to enforce the locator control
How you want to configure movement request settings such as pick slip batch size and replenishment movement request grouping
Consider the size of your operation, your usage of subinventories, and the type of labor or equipment required when considering whether you want to use organization- or subinventory-level replenishment movement request grouping.
How you want to configure lot, serial, and packing unit generation settings
To make appropriate choices for these settings, you should be familiar with:
Your company's guidelines for creating lot names, serial numbers, and packing unit numbers
Whether your company requires you to assign the same lot number to multiple items in the same organization, or a specific lot number to only one item in the same organization
Whether your company requires you to place purchase order or shipping order material under lot control
How you want to configure item sourcing details, such as the picking rule to use, and whether to specify the inventory organization as a logistics services organization
When you specify to round reorder quantities, min-max planning reorders for item subinventories are automatically rounded up or down.
Reorder quantities for an item subinventory are calculated based on:
The setting that you select for the Round Order Quantity parameter on the Manage Inventory Organization Parameters page, General tab, of the inventory organization containing the item subinventory
The value that you specify for the Fixed Lot Multiple text box on the Add Item to Subinventory window
If you enable rounding the reorder quantity for the inventory organization, and specify the fixed lot multiple for the item subinventory, the reorder quantity is rounded up. If you disable rounding the reorder quantity for the inventory organization, and specify the fixed lot multiple for the item subinventory, the reorder quantity is rounded down.
Note
To round reorder quantities, you must specify a fixed lot multiple.
Assume that the reorder quantity is 24. If you enable rounding the reorder quantity and specify 10 for the fixed lot multiple, the reorder quantity is rounded up to 30. If you disable rounding the reorder quantity and keep the fixed lot multiple at 10, the reorder quantity is rounded down to 20.
Select one of the following lot number uniqueness control options to apply to the items in your inventory organization:
No uniqueness control
Across items
You can assign the same lot number to multiple items in the same inventory organization and across inventory organizations. The following table provides an example of how lot numbers are generated when uniqueness control is not applied, both within and across inventory organizations.
Within Inventory Organization |
Across Inventory Organizations |
---|---|
Item AS100 (printer) / Lot LN100 |
Item AS100 (printer) / Lot LN100 |
Item AS101 (laptop computer) / Lot LN100 |
Item AS101 (laptop computer) / Lot LN100 |
You can only assign a unique lot number to a single item in one inventory organization. If the same item is also in a different inventory organization, you must assign that item a unique lot number. The following table provides an example of how lot numbers are generated when uniqueness control is applied across items, both within and across inventory organizations.
Within Inventory Organization |
Across Inventory Organizations |
---|---|
Item AS100 (printer) / Lot LN100 |
Item AS100 (printer) / Lot LN300 |
Item AS101 (laptop computer) / Lot LN200 |
Item AS101 (laptop computer) / Lot LN400 |
Items are replenished from an external supplier.
The inventory organization is not costed, and shipment lines from different logistics service provider customers cannot be packed in the same packing unit.
An item organization defines an item when inventory balances are not stored and inventory storage or inventory movement is not reflected in the Oracle Fusion Applications. For example, you would use an item organization in a retail scenario, if you need to know the items that are listed by and sold through each retail outlet even though inventory and transactions are recorded in another system. In Oracle Fusion Customer Relationship Management (CRM), item organizations are used to define sales catalogs.
Note
Items belong to an item organization.
Item attributes that are associated with financial and accounting information are hidden from the item if it exists within the item organization.
Item organizations can be changed by administrators to an inventory organization by updating the necessary attributes. There is no difference in the way items are treated in these two types of organizations except that there cannot be any financial transactions in the downstream applications for items that are assigned to an item organization.
An item master organization lists and describes items that are shared across several inventory organizations or item organization.
The following example shows the choice between inventory organizations that track inventory transactions, stored in two warehouses, and item organizations that just track items, listed in two sales catalogs.
For the most efficient processing, you should:
Have a single item master
Include an item and its definition of form, fit, and function only once in the item master
Separate the item master organization from organizations that store and transact items
Note
Oracle Fusion allows multiple item masters, however, use this capability cautiously. If you acquire a company, there may be value in allowing the old item master to exist for a transition period. If you manage your subsidiaries as separate businesses, there may be reduced value in a single item master.