Overview:
The Oracle Applications organization models define
organizations and the relationships among them in arbitrarily complex
enterprises.
It dictates how transactions flow through different
organizations and how those organizations interact with each other.
Features:
•Use a single installation of any Oracle Applications
product to support any number of organizations, even if those organizations use
different sets of books.
•Define different organization models.
•Support any number of legal entities within a single
installation of Oracle Applications.
•Secure access to data so that users can access only the
information that is relevant to them.
•Purchase products through one legal entity and receive them
in another legal entity.
•Sell products from a legal entity that uses one set of
books and ship them from another legal entity using a different set of books,
and automatically record the appropriate inter-company sales by posting
inter-company accounts payable and accounts receivable invoices.
•Can sell products through one legal entity and ship them
from another. The system automatically recognizes the inter-company sale
between the shipping organization and the selling organization by generating
inter-company invoices.
Levels of Organization:
•Set of Books
•Business Process
•Legal Entity
•Operating Units
•Inventory Units
Set of Books (SOB):
A financial reporting entity that uses a particular chart of
accounts, functional currency, and accounting calendar.
Oracle General Ledger secures transaction information (such
as journal entries and balances)by set of books. When we use Oracle General
Ledger, we choose a responsibility that specifies a set of books. We then see
information for that set of books only.
Business Group:
The business group represents the highest level in the
organization structure, such as the consolidated enterprise, a major division,
or an operation company. The business group secures human resources
information.
For example, when we request a list of employees, we see all
employees assigned to the business group of which our organization is a part.
Legal Entity:
A legal company for which we prepare fiscal or tax reports.
We assign tax identifiers and other legal entity information to this type of
organization.
Operating Unit:
An organization that uses Oracle Cash Management, Order
Management and Shipping Execution, Oracle Payables, Oracle Purchasing, and
Oracle Receivables.
It may be a sales office, a division, or a department. An
operating unit is associated with a legal entity.
Information is secured by operating unit for these
applications. Each user sees information only for their operating unit. To run
any of these applications, we choose a responsibility associated with an
organization classified as an operating unit.
Inventory Organization:
An organization for which we track inventory transactions
and balances, and/or an organization that manufactures or distributes products.
Examples include (but are not limited to) manufacturing plants, warehouses,
distribution centers, and sales offices.
The following applications secure information by inventory
organization:
Oracle Inventory, Bills of Material, Engineering, Work in
Process, Master Scheduling/MRP, Capacity, and Purchasing receiving functions.
To run any of these applications, we must choose an
organization that has been classified as an inventory organization.
Limitations on Multiple Operating Units per Set of Books:
•Multiple Organizations enabled products do not support
viewing secured data across operating units.
•Multiple Organizations enabled products, process
transactions within an operating unit. There is no additional support for
centralization/decentralization of business functions.
•When the Multiple Organizations enabled products post to
Oracle General Ledger, you need to run the posting process from each operating
unit. You cannot run the posting process for all operating units in the set of
books in a single process.
•In–transit shipments across organizations in different sets
of books are not supported.
•Supplier and customer tables are shared across operating
units. However, you must define supplier sites and customer addresses for each
operating unit. For example, if multiple operating units buy from the same
supplier site, the supplier site must be defined once for each operating unit.
•You should not specify any centralized statements site,
centralized dunning site, customer–level order type, or customer–level
salesperson because customer addresses, order types, and salespeople are not
shared across operating units.
•You should specify the tax code at the customer level only
if you have identical tax codes across operating units.
•The Customer Merge process allows you to merge only
addresses and sites within the same operating unit, since transactions are
secured by operating unit. If a customer has active addresses in other
operating units, the Customer Merge process does not make the customer
inactive.
•You can receive against purchase orders only in the
operating unit to which your responsibility is connected.
•Legal entity reporting (such as tax reporting) that
involves sub ledger products is done at the operating unit level. If all the
operating units for a given set of books belong to the same tax reporting
entity, you must sum the tax data manually.
No comments:
Post a Comment