|Oracle Financials Concepts Guide|
Part Number E13424-03
This chapter covers the following topics:
The Oracle E-Business Suite uses a variety of organizational constructs to capture corporate structures that exist in the real world. This chapter provides detailed information on the organizations you can set up in the Oracle E-Business Suite to represent your enterprise.
Oracle Financials can be implemented in multiple ways to reflect your real-world organization. Groups generally reflect a tension between their legal organization, management organization, and business divisions.
Our ability to buy and sell, own, and employ comes from our charter in the legal system. Commercial groups exist through corporate law. Units in the legal structure of a group are individual companies that share common ownership and control. In a public group, a company is owned by the public through shares sold on a stock market. In a private group, they are held by a privately held holding company. In other organizations, the legal entities are partnerships, funds, or government agencies.
A legally recognized entity can own and trade assets and employ people; while an entity without legal recognition cannot. When granted these privileges, legal entities are also assigned responsibilities to account for themselves to the public (statutory reporting and external reporting), comply with legislation and regulations, and pay income or profit and transaction taxes.
Most groups have many legal entities. They are created to facilitate legal compliance, segregate operations, optimize taxes, and for many other reasons. Legal entities establish your identity under the laws of each nation in which you operate, and provide vehicles for contractual relationships, compliance, and taxation.
The following diagram shows an archetypical group of companies operating various business and a standard functional organization.
A separate card represents each of a series of registered companies, that is, legal entities. The list of cards is the "Legal Axis".
Each company hosts parts or all of various subdivisions that management has made within its businesses. These are shown as vertical columns on each card. For example, a Group might have a separate company for each business in the United Kingdom, but have their Ireland company host all businesses in that country.
The subdivisions are linked across the cards so that a business can appear on some or all of the cards. For example, the chemical business might be operated by the Ireland, United Kingdom, and France companies. The list of business subdivisions is the "Business Axis".
Each company's card is also horizontally striped by functional groups, such as the sales team and the finance team. The functional list is the "Functional Axis".
The overall image suggests that information might, at a minimum, be tracked by company, business subdivision, and function in a group environment.
Successfully managing multiple businesses requires that you segregate them by the rewards and risks involved in making them profitable. You divide your organization accordingly and assign management personnel to each division.
Although related to your legal structure, the business organizational hierarchies do not need to be reflected directly in the legal structure of the firm. The management entities and structure include divisions and subdivisions, lines of business, and other strategic business units, and include their own revenue and cost centers.
Straddling the legal and business organizations is an organization structured around people and their competencies: sales force, operations, plants, researchers, finance people, human resource management, information technologists, and management. The income statement often reflects their efforts and expenses directly. Organizations must manage and report revenues, cost of sales, and functional expenses such as Research and Development (R&D) and Selling, General, and Administrative Expense (SG&A).
Oracle Financials formally recognizes several other organizational structures, that will exist in your enterprise, in the data schema. You will have processing structures along different business flows:
Personnel reporting structures that may or may not correspond with the business hierarchy or legal or external reporting dictates.
Product driven structures in your production environment that may or may not correspond with your market and delivery structures.
Your legal entities, whether commercial registered companies or entities incorporated under laws other than company laws, play a pivotal role in your processing systems.
Legal entities are formally the entities that actually enter into transactions. Individual legal entities own the assets of the enterprise, record sales and pay taxes on those sales, make purchases and incur expenses, and make other transactions.
All legal entities exist in particular legal jurisdictions, both national and regulatory, and must comply with the regulations of those jurisdictions. Legal entities have multiple compliance requirements placed on them, many of which define the form of the transactions into which that legal entity enters.
Many company statutes require that legal entities created in compliance with them publish specific and periodic disclosures. Annual or more frequent accounting reports, often referred to as "statutory accounts" and "external reporting," are required. These must be reported to specified national and regulatory authorities, for example the Securities and Exchange Commission (SEC) in the United States. Disclosure requirements are diverse. Local entities file locally using local regulations and currency, and through their holding company using parent Generally Accepted Accounting Principles (GAAP) and currency.
A given legal entity may or may not represent all or part of a management framework in its domain. For example, in a large country such as the United Kingdom or Germany, you might deploy individual companies to represent each business division, and you might control many companies in that country. In a smaller country, for example Austria, you might use a single legal entity to host all of your business divisions.
Legal entities have very specific relationships with shared service centers and with the ownership of the goods and transactions managed by such centers.
Oracle Financials has powerful schemas of organization units that support your legal, management, and functional organization. They are designed to:
Ease the management of your worldwide shared service organization and facilitate sourcing at the optimal mix of employee cost, data flow, and management control.
Provide access control and security, excluding those without authority, and facilitating access across units for those who need it.
Administer compliance and segregate transactions and administrative rules by jurisdiction.
Provide attributes for reporting and identify business events according to the relevant business dimensions.
Oracle Financials enables you to categorize and classify your transactions to the level of granularity required to reflect each of these organizations. A single transaction can be categorized as follows:
On the Legal axis: By company or other legal entity, by groups of companies, and by establishment. Establishment is the presence of a legal entity in a jurisdiction for purposes such as payment of transaction taxes.
On the Management axis: Business classification by several management entities.
On the Functional axis: By nature of the transaction (for example, detailed accounts involved such as marketing or cost of sales). By people and cost centers involved.
By Other attributes.
The core task of Oracle Financials applications is to track the appropriate business and accounting attributes of a transaction.
Business attributes are tracked in the product modules and include such details as trading partner, subject matter, quantity, price, agent, employee, tax, addresses, dates, and so on. Accounting attributes are generated from that data by our subledger accounting engine and are recorded in detail in the subledger accounting tables and at your choice of summary level in General Ledger.
Two vehicles, system organization entities and the chart of accounts, are the cornerstones for securing transactions and modeling an enterprise in the Oracle E-Business Suite. The assembly of these building blocks to model your enterprise will define the representation of your business and your process flows in the applications suite.
In general, a system organization entity might represent any real organizational unit within a business. Depending on their classification, system entities deliver specific features and controls, such as access control and shared service administration, policy, legal or compliance administration, data storage, and employee administration. Oracle Financials provides names that reflect that functionality. In general, assigning a system entity to represent a real world entity with the same nomenclature is an effective choice.
By contrast, a chart of accounts representation of a real world entity is an identifier for analysis and accounting, with fewer features and control associated with it. Important entities, such as cost center and legal entity, can be represented by both a system entity and as a value in a chart of accounts section.
Several system entities are so closely tied to accounting entities that we automatically correlate them; others have looser associations so that you can tune the relationship to your actual organization.
The Oracle E-Business Suite includes the following important system entities:
Business Group and Departments
Government Reporting Legal Entity (GRLE)
Human Resources Organization
Each system entity is assigned to a classification that determines its functionality and indicates how you might want to deploy it.
The business group is an organization that is set up and configured in Oracle Human Resources. The business group is partitioned into separate files of Human Resources information and is used to administer Human Resources payroll and benefits for employees.
A business group is often related to country-specific legislation. It may correspond to your entire enterprise or to a major grouping such as a subsidiary or operating division. One business group is needed for each major employment jurisdiction. These jurisdictions roughly correspond to nations. If a group of nations unite together on employment laws, it is possible to implement a single business group for them.
A business group is the highest level classification in the organization hierarchy of the Oracle E-Business Suite. If your payroll tax and employment authorities permit it, you can group employees of different registered companies together for reporting. The result is a business group that can serve as an administrative and legislative organizing structure for personnel across legal entities.
Oracle provides configured business groups for a number of countries. These business groups are seeded with appropriate legislative data and rules. You can customize business rules that are subsequently stored under the business group for Human Resources applications such as Oracle Payroll.
Even if you do not have Oracle Human Resources in a given country or region, it is a good idea to set up a business group during implementation. A business group cannot be set up once your applications are live.
Employees are employed by the system entity called "Government Reporting legal entity" or GRLE which represents the formal employer in the Human Resources Management System. Employees are assigned to departments.
A GRLE can represent a registered company or other registered legal entity: GRLEs are a particular type of system legal entity, and serve to connect your employees with the appropriate company or other entity in the legal world.
Oracle Human Resources further organizes employees into departments. You can create hierarchies of departments to roll up your employees into the management structure.
"Legal entity" in the Oracle system corresponds closely to "legal entity" or "company" in the legal world. You can store information about a registered company or other real world legal entity in the "legal entity". For example, you can store the registered address and director or officer names.
The legal entity administers transaction level rules in compliance with national laws.
A real world legal entity is a discrete legal personality characterized by the legal environment in which it operates.
In the real world, legal entities have the right to own property, the right to trade, and the responsibility to comply with appropriate laws. They also often have the responsibility to account for themselves (balance sheet, income statement, specified reports) to company regulators, taxation authorities, and owners according to rules specified in the relevant legislation.
The Oracle E-Business Suite reflects the real world for legal entities. The system legal entity is the first party on business transactions and is the transaction tax filer and payer. We recognize that for many groups, particularly in environments where the authorities allow you to treat many legal entities as one, you don't need or want to segment data or account separately for each entity that you have incorporated. Therefore, the system legal entity does not automatically account for itself.
Instead, we facilitate correlation of subledger activity with reporting legal structures by exploiting related system entities for operating units, ledgers, and company representation in the chart of accounts.
You can account for any real world legal entity separately if you need to do so;
You can account for a group of real world legal entities as if they were one when that fits your model;
And you can account for a part of a real world legal entity as if it were completely standalone when appropriate.
A system legal entity can account for its transactions in many ledgers, using different accounting conventions, or using different currencies.
Tip for Existing Oracle Financials User
You will find that a legal entity has more attributes in Release 12 and that a Legal Entity Configurator is provided. Tax calculation, intercompany processing, and bank ownership exploit legal entity attributes more assiduously than previously.
A system legal entity is the transactor and taxpayer for each third party transaction. It holds tax registration data, such as identification numbers. An individual legal entity can have exposure to several tax authorities, and be registered with each. For example, a California-registered company might have "establishments" in California and in several other states.
Tip for Existing Oracle Financials User
Establishment is an entity that was not expressly called out in previous releases and is useful in resolving transaction tax situations.
A fundamental concept in Oracle Applications is the "Ledger." The Ledger represents an accounting representation for an organization that is accountable in a self-contained way.
A ledger owner might be a legal entity, a group of companies in a common legal environment, a substantial operation within a legal entity but with legal entity attributes, or a foreign branch. Ledgers are also used to consolidate and manage reporting. In a pure implementation, "a legal entity accounts for itself in a ledger".
A ledger provides balanced ledger accounting for the accounting entity and serves as the repository of financial information. Consequently, it is the principal source of information for the analytical applications in the Oracle E-Business Suite.
Ledger balances have meaning - they assert that the balance:
on an account
at a given date
has a specific value in a particular currency and
is properly calculated.
This implies a consistent application of what we sometimes call "the 4 Cs": Chart of Accounts (COA), Calendar, Currency, and accounting Convention. The COA provides the account; Calendar the date; Currency the amount; and Convention the calculation.
Of course, you will need different currency and parent company GAAP representations of your overseas operations. One way to achieve this is to use multiple ledgers for an accounting entity.
An accounting entity can account for itself in ledgers that are prepared under different conventions with different charts of accounts, and value transactions in different currencies. One of the ledgers is the 'primary' ledger. The accounting for a subledger transaction can be set up so that multiple ledgers are populated according to different rules and in different currencies. You choose the appropriate accounting according to your needs.
When using a second ledger, you can elect to use an "all the detail” philosophy in which detailed transactions are posted to General Ledger. You might prefer to use a "just what matters" philosophy where only General Ledger balances are posted.
Ledgers can be grouped into "Ledger Sets". A Ledger Set is a collection of ledgers that you wish to manage as though they were one ledger. "Manage" includes reporting, opening and closing, running allocation calculations, and entries. For example:
You have 26 registered companies in Regmany. Regmany regulations require that each company maintains a distinct book of accounts. You set up a Ledger for each company and group them into a Ledger Set. Your finance staff can treat the collection as if they were one for all accounting activities, while the data remains distinct for each company.
You could create a Parent Currency and Parent GAAP ledger for each overseas operation. You can group all of them into a Parent View Ledger Set. Your corporate finance staff can treat them as one worldwide ledger for all accounting activities.
Tip for Existing Oracle Financials User
Ledger and Ledger Sets together replace Sets of Books. The data of a Set of Books is contained in a ledger. The management of the Set of Books (open and closing, reporting, allocating, and so on) is now at the Ledger Set level.
Multiple Ledgers is a new feature in Release 12.
Ledgers balance, that is, the sum of the debit and credit balances equal each other and you can prepare an income statement and balance sheet from them. Oracle Financials checks that imported data, subledger posting, and journal entries (adjustments) balance, in order to maintain this integrity. Ledgers in a Ledger Set also balance and are also used for financial reporting.
Within a ledger, you can nominate a segment of your chart of accounts to be a "balancing segment". The values (Balancing Segment Values or BSV) that you assign in that segment will represent entities in your organization for which you want to measure both income and wealth, that is, to prepare income statements and balance sheets, and to measure return on investment.
You might do this for divisions, plants, externally reportable segments, legal entities sharing a jurisdiction, and for other reasons.
Customers frequently combine entities into BSVs and report on groups of them. For example, if you want to track return on investment (ROI) on both "plants" and "divisions", you might create balancing segment values as shown in the following table.
|Division||Plant||Balancing Segment Values|
During setup, you can specify whether a system legal entity uses a whole Ledger or balancing segments.
Oracle Financials reflects the traditional segregation between the general ledger and associated subledgers.
Detailed transaction information is captured in the subledgers and periodically posted (in summary or detail form) to the ledger. You post from subledger to general ledger in real time, without any grouped processing, or you can post on a schedule corresponding to your practice.
In the financial applications of Oracle's E-Business Suite, an Operating Unit (OU) is a system organization that:
Stores subledger data separately from the data associated with other OUs that support a particular ledger ("Partitions").
Administers subledger rules such as those associated with transaction types, sequencing schemes, and other sales tax or VAT regulations ("Complies").
Administers user access to the data for processing and reporting ("Secures").
Is not product specific and automatically links all subledger products that post to a specific ledger.
Applies to subledger business transaction and document data and associated data such as customer details. Subledger accounting data is not tagged with OU identification unless you elect to do so. General ledger data is not managed through OUs.
Multiple Organizations is the name we give to the functionality that surrounds OUs and it is exploited by all products as appropriate.
You can use OUs to store data on behalf of a Legal Entity. As compliance with transaction tax auditing legislation is built into transaction types and transaction types are stored by an OU, this is an effective way to manage transaction compliance. An OU with the type "Legal Entity" (OU/LE) is often used in conjunction with a Ledger to manage a real world legal entity's paperwork. All subledger products share the legal entity's OU and post to the Ledger.
The real world legal entity's compliance obligations are administered by:
OU on subledger transactions and
Ledger for balancing, closing, and reporting rules.
Depending on the nature of the regulation with which you must comply, various combinations of real world company and system legal entity, OU, and Ledger are possible. In a worldwide deployment, one would expect to see all combinations in place in different situations.
One legal entity accounts for itself in one Ledger storing subledger data in one OU. This is a normal setup for a country or region that closely regulates subledger data by legal entity.
Several legal entities account for themselves in one Ledger storing subledger data in one OU, and use the Chart of Accounts balancing segment to produce financial statements for each legal entity. This is a normal setup for a country or region that regulates a group of companies as a whole.
A legal entity or group of legal entities account for themselves in one Ledger storing subledger data in several OUs. This is a normal setup for a group doing business in highly regulated industries in a given country or region.
A part of a legal entity accounts for itself in a ledger using one or several OUs. This is a normal situation for a large corporation using several instances or Enterprise Resource Planning (ERP) systems.
System legal entities, Ledgers, and OUs are defined in relationship to one another. A legal entity accounts for itself in the Primary Ledger and optionally in other ledgers, and stores its subledger data in one or more OUs.
OUs are often identified with security. In the Oracle E-Business Suite, users are given access to the data they handle though "responsibilities". A responsibility is associated with a specific OU, or with several OUs - this is a feature called "Multiple Organizations Access Control". By securing subledger data in this way users can access and process transaction information only for the particular operating unit or set of operating units to which they have been granted access. They view only what they need and have authorization to view.
This is very fundamental security. The Oracle E-Business Suite incorporates many other security models specific to circumstances that match the usage and deployment requirement needs that you have for those circumstances, and integrate with Multiple Organizations Access Control to provide comprehensive and appropriate security.
OUs can be used to model autonomous organizational units that create financial transactions. You create, process, and report on subledger financial data within the context of an OU.
Use an OU when you need to keep the data of one organization distinct - at arms length - from the data of another organization. You might have the right to prevent a state's transaction tax auditor from viewing the transactions of a neighboring state; consider storing each state's transactions in separate OUs. This right often exists when the states are independent nations, but seldom when they are federated.
Use an OU when you need to comply with transaction tax law that is substantially different (more than just the tax rates) to similar laws in neighboring state. You can use product "transaction types" to create similar transactions that follow different documentation and processing practices.
Use an OU when you wish to keep data of an operation private from management of another operation. For example, within a financial institution division, you may want to keep the transactions and data of the lending operation separate from that of the brokerage operations.
OUs divide the subledger document data in Oracle Financials applications into distinct segments. Standard reports and processes run within OUs; and 'special' reports and processes run across them. You can deploy OUs to provide barriers that require special access, reporting, and processing to cross.
While subledger transaction rules are governed by OU, subledger accounting rules are not OU dependent.
OUs store transaction types and rules that govern the transaction document such as invoices, and the business rules (for example, credit terms) that you want applied to those documents.
Subledger accounting rules are not stored by OU. They are stored centrally, but can refer to any data (including OU identifiers) associated with the transaction to derive the appropriate accounting.
The setup of operating units provides a powerful security construct in the applications by creating a tight relationship between the functions a user can perform and the data that a user 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 a worldwide deployment, this tight relationship provides an internal control on inappropriate processing. For example, in traditional local operations, an invoice of one OU (a system representation of, perhaps, a company in a country) cannot be paid by a payment from another (a system representation of, perhaps, a different company in a different country). This would amount to tax fraud.
By contrast, in a Shared Service Center environment, processes that allow one company to perform services for others, with appropriate intercompany accounting, require that users access the data of different companies, each complying with different local requirements.
To accommodate shared services we use Multiple Organizations Access Control to expand the relationship between functions and data. A Responsibility can be associated with a single OU or with multiple OUs. You can isolate your data by OU for security and local level compliance and also enable certain users and processes to work across them. This is the core of our shared service architecture.
Consider an environment where the orders are taken in several different OUs each representing different registered companies. These OUs segregate the orders and data appropriately. However, all of these orders can be managed from a "shared service" order desk in an outsourcing environment through a single Responsibility.
Tip for Existing Oracle Financials User
Multiple Organizations Access Control is a new feature for Release 12.
The Inventory Organization represents an organization for which you track inventory transactions and balances. These organizations might be manufacturing or distribution centers. Several modules and functions in the Oracle Manufacturing and Supply Chain Management suite secure information by Inventory Organization.
Inventory Organizations are associated with OUs. Each Inventory Organization has a parent OU and can serve other OUs.
Various functions in the Oracle E-Business Suite use this organization classification. For example, to activate the "Purchasing Receiving" function, your responsibility must have access to an organization that is classified as an Inventory Organization.
Through its parent Operating Unit, the Inventory Organization financially impacts the Ledger to which it rolls up. For example, requisition transactions or replenishment of supplies are created against an Inventory Organization, which then have a financial impact on the Ledger.
For the most part, we have discussed system entities (for example, Legal Entity, OU, Ledger) and their relationships with real world entities (for example, Company, Management Unit, Division) that you have in your organization. System entities are created though special setup screens and stored in tables.
We have discussed the "Balancing Segment" that is part of the chart of accounts rather than a stored system entity. The chart of accounts, your listing of account numbers, includes other segments that reflect your organization. You might have company codes, cost center codes, business organization codes, and other organization related codes, as well as non-organization codes such as natural accounts, product codes, or project codes.
The chart of accounts is a very flexible, almost free-form, combination of segments (as many as you like) of different lengths. You use these segments to flag transactions so that they are summarized in a meaningful way to your business. The chart is referred to as "flexfields", which is the underlying technology. The acronym "CCID" (Code Combination Identifier) or the term "Accounting Flexfield" refers to an individual combination of segment values, or a complete account number.
A specific chart of accounts (complete with values) is associated with each ledger and the same chart can be associated with many ledgers.
We specify only three segments, Natural Account, Balancing Segment, and Cost Center, as mandatory.
Cost Center is a focal point for a department's expenses. You might use the cost center to track "the Finance Department". In cases where labor is the most important element of expense, cost centers in your chart of accounts and the HR "Department" discussed earlier will refer to the same business unit in the real world. The Oracle E-Business Suite includes the ability to keep them synchronized. There are some important differences in the way you want them to behave.
When an employee leaves, you'd like HR to update the records immediately. But continuing expenses, if any, should be accounted for in the same cost center. If the employee was a manager, the resulting reorganization might not be reflected in the financial statements for some time.
Accordingly, the creation and maintenance of HR Departments and Ledger Cost Centers can be synchronized. However, we facilitate different update paths. Approval and expenses associated with employees are automatically associated with the cost center that relates to their HR department.
Many customers exploit naming conventions and ranges to facilitate the combination of individual cost centers in local companies into a worldwide view of similar cost centers. Ledger security includes a facility to control accounting access by ranges within chart of account segments that can be deployed usefully in this context.
Many customers also use cost centers, rather than natural accounts, to aggregate functional expense types such as "Research and Development" or "Finance".
We previously discussed Balancing Segment in the context of Ledgers and representations of Legal Entities. A Balancing Segment is a segment of the chart of account that forces balancing, meaning that the Ledger will calculate a receivable and payable between balancing segments for any entry that crosses them.
Example of 'Balancing'
My New York Division (01) ships to a California Division (03) customer. The entry as drafted is Credit 01-Sales, Debit 03, Receivables from Customer. The entry is posted as:
Credit 01, New York Sales
Debit 01, New York Receivable from 03, California
Credit 03, California Payable to 01, New York
Debit 03, Receivable from Customer
This facilitates the preparation of full balance sheet and income statements for each Balancing Segment value and makes them an excellent representation for any business unit for which you need to track balance sheets.
Our customers use balancing segments to identify registered companies that are accounted for together in a single ledger, divisions for which they wish to measure balance sheet data and return on investment, and externally reportable segments.
You can use a balancing segment value for each legal entity accounted for in a ledger: Companies 01, 02, and 03. Other than balancing, no additional functionality is attached to Balancing Segment, so using a Balancing Segment Value alone is recommended only in a federal environment that treats groups as one tax or statutory reporter or filer.
For many companies, natural account also has an organizational impact. Companies deploy the natural account in different ways. Some start "at the top" with their external reporting lines (for example, cash, revenue), expand the list to include their management reporting lines (different types of revenue), and then expand further to the level of granularity they wish. Others start "at the bottom" with detailed departmental expenditure types.
Companies that start with reporting lines often reach the point where "Finance Salaries", "Finance Benefits", and so on are natural accounts, and a report on all Finance accounts delivers the Finance expense. Those that start at the bottom often use "Salaries" and "Benefits" as the natural account and establish a list of cost centers to be the total finance.
When you are finished, you will have modeled your organization in the system using ledgers, ledger sets, and balancing segments to report your legal and management structure, and using different combinations of each as appropriate for statutory compliance and management needs.
You will have selected OUs to store and secure your data, reflecting transaction tax audit and filing needs that are mapped to your operating needs. You will also have selected accounting attributes through your chart of accounts, using natural accounts and cost centers together with other segments, to help you cut though the data to get to the heart of your operations.
In the earlier discussion forYour Organization , a diagram shows cards representing companies that are striped vertically by business subdivisions and horizontally by functional groups. The following diagram shows how some system entities can be mapped, often in alternate ways, to your organization. The system entities map to organizational characteristics as follows:
Legal Entities correspond to the company cards and keep their financial accounting in Ledgers within Ledger Sets.
Balancing Segments can represent both legal entities and business subdivisions.
Functional Groups map to Departments and Cost Centers in the system.
Natural Accounts classify the functional groups' activities.
Operating Units most often hold companies' data and can hold the data of different businesses at arms length from each other within a legal environment.
Just as legal entity and ledger structures furnish a strong degree of transactional control, business groups and department structures in Oracle Human Resources provide significant internal control in an enterprise.
In addition to direct relationships between headcount and spend rates, people and hierarchies are the primary means of authorization and security in an organization. For example, spending controls can be enforced by person and level in the hierarchy. Your internally controlled approval routing goes through a process that you can allow to default to the department hierarchy in Human Resources or to any other hierarchy that you create. Consider the following examples:
Purchase Approval Hierarchy: Purchase orders entered in Oracle Purchasing utilize workflow to route the purchase order for approval.
Journal Vouchers: Since journal vouchers can be unique in nature, their approval cannot be restricted to a hierarchy within a particular department. You can create workflow routing rules to personnel in a business group for the approval of journals in Oracle General Ledger.
Manual Invoices: Manual invoices use Oracle Approval Management Engine (AME) for approval. In turn, AME uses the Human Resources departmental hierarchy and spending authority at every level in the hierarchy to route the invoice.
Salary might be your primary expense. Oracle Human Resources breaks out salary by your departmental organizations. Broadly speaking, your Human Resources departments will map to Oracle General Ledger cost centers.
Note: The Oracle E-Business Suite comes with one predefined default business group. If you are implementing Oracle Financials without also implementing Oracle Human Resources, you can choose not to set up another business group.
The caveat here is that once you set up your operating units and assign employees to tasks in the various modules, it is difficult to subsequently configure and assign a new business group with your own choice of default information. Therefore, we recommend that you set up a business group while implementing Oracle Financials even if you do not plan to explicitly use it for Human Resource purposes.
In general, local user subledger application reporting respects the fundamental security implicit in operating units. General Ledger reporting respects the Ledger Set constraints. To provide for corporate and regional views of data, cross-organizational reporting presents information from different operating units or ledgers.
Reporting in general is discussed more fully in the Reporting chapter.
Selected standard reports for various applications in the Oracle E-Business Suite are designed to allow the user to report across OUs, Legal Entities, or Ledgers.
Oracle Daily Business Intelligence (DBI) is a system designed to publish the data you are collecting using the Oracle E-Business Suite directly to your management team from the line supervisors to the officers. It is series of pre-designed portlets and portal pages delivered with the product, and ready to deploy with minimal setup. DBI publishes data "as is". It is generated daily and is intended to allow managers to take immediate action to drive results. DBI functions across Ledgers, Operating Units, and other organization units, and standardizes data in parent, regional, or local currencies as appropriate.
Ledger Sets enable cross organizational processing and reporting on ledgers. Ledger Sets automatically aggregate the data from the Ledgers that they include.
Multiple Organizations Access Control enables cross organizational processing and reporting on operating units in subledgers.
The Oracle E-Business primary consolidation tool is the Oracle Financial Consolidation Hub. The Oracle Financial Consolidation Hub is a fully featured row and column based consolidation application, with specific consolidation features such as minority interest calculation and intercompany elimination. General Ledger also includes functionality termed the Global Consolidation System that performs simple consolidations inside General Ledger, and the aggregation facility of ledger sets can be used to perform consolidations too. All provide full reporting capabilities.
Oracle XML Publisher includes a data extraction tool for use in ad-hoc cross organization inquiries.
Oracle Discoverer is a business intelligence tool for analyzing data. Users can access and analyze data in a company's database without having to understand difficult database concepts. Users can also view workbooks and integrate database output onto a web site and portal that can be easily customized to conform to a particular web site look and feel, or to build custom Discoverer applications for the web.
Copyright © 2006, 2010, Oracle and/or its affiliates. All rights reserved.