Oracle Applications uses multiple types of organizations to build the business execution structure. At the top of the structure is the accounting set of books SOB), defined in the General Ledger. Next, different types of organizations are used to further define the organization structure and relationships. All organizations are defined and updated with the Define Organization form.
Set of Books. A
General Ledger SOB, linked to the inventory organization, controls the financial
accounting of inventory transactions. A SOB is made up of a chart of accounts,
a financial calendar, and a currency. The general ledger secures transactions
(journal entries, balances) by SOB.
Legal Entity. A legal
entity organization defines the tax and fiscal reporting
level. The legal entity represents the legal company.
level. The legal entity represents the legal company.
Operating Unit. An
operating unit organization defines the Purchasing, Order Entry, Accounts
Payable and Accounts Receivable level of operation. An operating unit may span
multiple manufacturing facilities, distribution points and sales offices, or it
may be limited to a single site.
Inventory Organization. Two flavors of inventory organizations are found in Oracle Applications. They are defined the same, and both are assigned a set of books, a legal entity organization, an operating unit organization, and a location. An item master organization is used for item number maintenance and validation. This master organization serves as a data repository storing items
and item attributes, master level categories and category sets, master level cross references, and numerous data defaults. On-hand balances, inventory movements, and other on-going inventory activities are not performed in an item master organization. Generally, the master organization is used as the validation organization for Purchasing and Order Entry. It is recommended that a single item master organization be defined, even in multiple organization, multiple sets of books environments.
In addition to the item master organization
there are one or more non-master inventory organizations. Like the item master
inventory organization, the non-master organizations are assigned a set of
books, a legal entity organization and an operating unit organization. The
non-master inventory organization points to a master organization and looks to
the master organization for master level item attributes, master level
categories, and other master level controlled data.
Note that each organization has its own set of books/legal entity/operating unit relationship, so inventory organizations with differing SOB’s or operating units may share the same master organization.
Note that each organization has its own set of books/legal entity/operating unit relationship, so inventory organizations with differing SOB’s or operating units may share the same master organization.
These non-master inventory
organizations are the execution level organizations. They hold on-hand balances
and transaction history. Here is where inventory users execute their daily
activities, such as receiving and issuing material, performing cycle counts,
and viewing material availability and transaction history. A single
organization therefore generally represents a single manufacturing site or
distribution center.
Locations. A location
code is an address. Each inventory organization must
be assigned at least one location code.
be assigned at least one location code.
Subinventories. A
subinventory is used as a holding point for on-hand inventory and generally
represents a stockroom, stocking area or cage used for storing material.
Subinventories are defined within inventory organizations. An inventory
organization may have any number of
subinventories, and an asset account is assigned to each subinventory. Since the subinventory entity is logical, as there is not an address or physical location description associated with it, clients may define subinventories for any physical or logical grouping of inventory.
subinventories, and an asset account is assigned to each subinventory. Since the subinventory entity is logical, as there is not an address or physical location description associated with it, clients may define subinventories for any physical or logical grouping of inventory.
Examples of subinventories:
Stores. Used for the
primary stockroom for storing raw materials and sub-assemblies
FG. Used for Finished
Goods inventory if finished goods are stocked
WIP. Used for raw
material and sub-assemblies stored in production areas and issued at operation
or job completion (backflush).
MRB. Used for Material
Review Board goods. This is generally material that requires engineering review
before disposition as scrap, rework, return to supplier or use as is.
Stock Locators. Stock
locators are an optional entity that may be used to represent physical
locations within a subinventory. You may choose to use stock locators for
selected subinventories or selected items within selected subinventories. If
locators are used, subinventory and locator track on-hand balances. Therefore,
if locators are defined to represent a shelf within a
stockroom, on-hand balances on the system would show the item and quantity down to the physical location within the facility. Oracle Inventory uses a key flexfield for stock locators. This presents a few limitations for its use. Only one locator flexfield definition is allowed per install. Therefore, if the stockroom (subinventory) wants to track material by row, bin and shelf, it will likely define a three-segment flexfield with segments for row, bin, and shelf. If locators are desired for another subinventory, even in another organization, the structure will again be 3 segments for row, bin and shelf. In addition to this limitation, locators must be unique within an organization; you cannot use the same locator in different subinventories within an organization, but you can use the same locator in subinventories in a different organization.
stockroom, on-hand balances on the system would show the item and quantity down to the physical location within the facility. Oracle Inventory uses a key flexfield for stock locators. This presents a few limitations for its use. Only one locator flexfield definition is allowed per install. Therefore, if the stockroom (subinventory) wants to track material by row, bin and shelf, it will likely define a three-segment flexfield with segments for row, bin, and shelf. If locators are desired for another subinventory, even in another organization, the structure will again be 3 segments for row, bin and shelf. In addition to this limitation, locators must be unique within an organization; you cannot use the same locator in different subinventories within an organization, but you can use the same locator in subinventories in a different organization.
Organization Setup Steps
The Following steps should be taken in the order listed. These are the MINIMUM steps necessary to successfully define an Organization for the Oracle Inventory module. Further information on these steps and other Optional steps can be found in the Oracle Manufacturing Implementation
Manual under Inventory Setup.
1. Define your set of books (GL function)
2. Define your Key Flex Fields in the following order. Navigation Path: Setup/Flexfields/Key. Flexfields to setup: System Items, Item Categories, Item Catalog Group, Stock Locators, Account Alias, Sales Order.
3. Define locations (used for a variety of functions including receiving and default delivery locations).
Note: If you populate the organization field of this form it will only show on the LOV for that organization.
4. Define a workday calendar, also called the manufacturing calendar. Each organization references this calendar for planning and scheduling activities. Optionally; define the calendar exceptions sets. Once this is completed, click on 'Special' and Build the calendar. It is suggested
that the calendar start on the first day of the work week. For example, if the primary work schedule consists of working Monday through Friday with Saturday and Sunday off, then make the start date on the calendar coincide with a Monday date and end with a Sunday date.
Note: A calendar must have at least 1 shift and 1 workday pattern defined. Use the Dates button to review the calendar for accuracy before building it.
5. Define organizations. Assign and enable the appropriate Organization classifications to each organization defined (based on the desired structure).
Note: Must have at least 1 INV and 1 GRE/Legal entity Organization. The Business Group classification should not be used unless multi-org functionality will be used.
6. Complete the minimum required 'other' information for each classification selected;
a) GRE/Legal entity; must define an employer identification number and Set of Books.
b) Operating Unit; must define a legal entity. Operating Units are optional.
c) Inventory Org;
i) Accounting information; Set of Books (SOB), Legal Entity, Operating unit (dependant).
ii) Inventory information; Org code, Item Master Org, and calendar, costing Org and method, and Account information (this is located in the costing, inter-org, and other accounts zones), other settings are optional based on the features the customer intends to use.
iii) The Receiving and Customer/Supplier information are optional.
7. Define the Unit of Measure classes. Then define the Units of Measure. Then define the Unit of Measure conversions for the application.
Note: Remember; each class can only have 1 base unit of measure. Base units of measure should generally be the smallest unit of measure in the class. Units of measure should have a logical connection to the class they are assigned. When disabling Units of Measure; disable the conversions first, then the Unit of Measure, and if it is a base unit, the class should be disabled also. Caution, once an item has been defined in the Item Master the primary unit of measure for that item may not be modified.
8. Define subinventories that represent the physical or logical locations for items within an organization. Must complete name and description. All other information is optional base on what features of the application the customer is going to use. You must define at least 1 subinventory per Organization.
9. The remaining Organization setup sections are optional, based on what features and modules the customer intends to utilize.
a) Define locators that represent storage structures (for example, aisles or bins) within subinventories.
b) Define Shipping Networks and Methods to facilitate Inter-Org Transfers.
c) Define Freight Carriers.
d) Define Organization Access. Remember that if a customer defines any access information in this screen for an organization, they MUST define access for ALL responsibilities that they want to have access to that organization. Failure to do this will cause the unlisted responsibilities
to no longer function in that organization!
The Following steps should be taken in the order listed. These are the MINIMUM steps necessary to successfully define an Organization for the Oracle Inventory module. Further information on these steps and other Optional steps can be found in the Oracle Manufacturing Implementation
Manual under Inventory Setup.
1. Define your set of books (GL function)
2. Define your Key Flex Fields in the following order. Navigation Path: Setup/Flexfields/Key. Flexfields to setup: System Items, Item Categories, Item Catalog Group, Stock Locators, Account Alias, Sales Order.
3. Define locations (used for a variety of functions including receiving and default delivery locations).
Note: If you populate the organization field of this form it will only show on the LOV for that organization.
4. Define a workday calendar, also called the manufacturing calendar. Each organization references this calendar for planning and scheduling activities. Optionally; define the calendar exceptions sets. Once this is completed, click on 'Special' and Build the calendar. It is suggested
that the calendar start on the first day of the work week. For example, if the primary work schedule consists of working Monday through Friday with Saturday and Sunday off, then make the start date on the calendar coincide with a Monday date and end with a Sunday date.
Note: A calendar must have at least 1 shift and 1 workday pattern defined. Use the Dates button to review the calendar for accuracy before building it.
5. Define organizations. Assign and enable the appropriate Organization classifications to each organization defined (based on the desired structure).
Note: Must have at least 1 INV and 1 GRE/Legal entity Organization. The Business Group classification should not be used unless multi-org functionality will be used.
6. Complete the minimum required 'other' information for each classification selected;
a) GRE/Legal entity; must define an employer identification number and Set of Books.
b) Operating Unit; must define a legal entity. Operating Units are optional.
c) Inventory Org;
i) Accounting information; Set of Books (SOB), Legal Entity, Operating unit (dependant).
ii) Inventory information; Org code, Item Master Org, and calendar, costing Org and method, and Account information (this is located in the costing, inter-org, and other accounts zones), other settings are optional based on the features the customer intends to use.
iii) The Receiving and Customer/Supplier information are optional.
7. Define the Unit of Measure classes. Then define the Units of Measure. Then define the Unit of Measure conversions for the application.
Note: Remember; each class can only have 1 base unit of measure. Base units of measure should generally be the smallest unit of measure in the class. Units of measure should have a logical connection to the class they are assigned. When disabling Units of Measure; disable the conversions first, then the Unit of Measure, and if it is a base unit, the class should be disabled also. Caution, once an item has been defined in the Item Master the primary unit of measure for that item may not be modified.
8. Define subinventories that represent the physical or logical locations for items within an organization. Must complete name and description. All other information is optional base on what features of the application the customer is going to use. You must define at least 1 subinventory per Organization.
9. The remaining Organization setup sections are optional, based on what features and modules the customer intends to utilize.
a) Define locators that represent storage structures (for example, aisles or bins) within subinventories.
b) Define Shipping Networks and Methods to facilitate Inter-Org Transfers.
c) Define Freight Carriers.
d) Define Organization Access. Remember that if a customer defines any access information in this screen for an organization, they MUST define access for ALL responsibilities that they want to have access to that organization. Failure to do this will cause the unlisted responsibilities
to no longer function in that organization!
e) Define Inter-Company Relations
for inter-company functionality.
Once these steps are completed the Organization is setup and usable. The user should then proceed with setting up the rest of the inventory system. See the Oracle Manufacturing Implementation guide, or the Oracle Inventory Users guide for instructions on setting up Items, Categories, Costs, Transaction Defaults, and other features of the Oracle Inventory system. It is always advisable to consult Oracle Worldwide Support Services or Oracle Metalink for the current
Critical patch list for the Inventory Module prior to implementing a new Inventory system.
Profile Options
MO:Operating Unit= {the users Operating Unit name}
Used primarily in a multi-org environment. This points the responsibility to the appropriate Operating unit. Set the site level to the default operating unit. If there is more than 1 Operating unit defined this profile must be set at the responsibility level for each responsibility.
Primary Organization Tables
HR_LOCATIONS
Stores information about organization locations. Address, Org_id, ship_to / bill_to site, receiving site, etc LOCATION_ID is the primary key on this table. This table is accessed by forms or reports from the following modules; HR, INV, PO/REC.
(See Oracle Inventory Technical or Oracle HR Technical Reference Manual for more detail)
HR_ORGANIZATION_INFORMATION
Stores the information on all organizations defined in the system. It also stores most of the organization classification specific information. The table is populated through the Define Organization form (PERWSDOR). Each organization defined will have 1 row for the organization and 1 row for each organization classification defined on the form. ORG_INFORMATION_ID is the primary key on this table.
(See Oracle Inventory Technical or Oracle HR Technical Reference Manual for more detail)
HR_ORGANIZATION_UNITS
Stores generic information about the organizations. This is an excellent place to go if you need to see the relationship between org id and Business group id when troubleshooting a multi-org problem. ORGANIZATION_ID is the primary key for this table. BUSINESS_GROUP_ID is a foreign key. This table is used by a variety of org setup and item setup forms.
(See Oracle Inventory Technical or Oracle HR Technical Reference Manual for more detail)
MTL_PARAMETERS
Stores the set of general default options like GL accounts, locator, lot and serial number controls, costing method, inter-org options, costing org and item master, etc This table is populated by the org parameters form INVSDOIO. It is accessed by a wide variety of forms, reports, user exits, and concurrent programs throughout the manufacturing modules. ORGANIZATION_ID is the primary
key. This is the most heavily used Organization table in the manufacturing products.
(See Oracle Inventory Technical Reference Manual for more detail)
RCV_PARAMETERS
Stores receiving options for each organization that is setup to receive items.There is 1 row for each receiving organization. This table is populated by the org parameters form, receiving options, or from PO setup receiving options.
(See Oracle Inventory Technical or Oracle Purchasing Technical Reference Manual for more detail)
ORG_ACCESS
Stores the data on which responsibilities are granted access to the existing organizations. Frequently customers will partially populate the Organization Access form (INVSDORA), and effectively lock themselves out of their organizations.This table stores that information. If all else fails, you can frequently resolve this issue by truncating this table and having the user re-populate the Organization Access form correctly.
(See Oracle Inventory Technical Reference Manual for more detail)
Once these steps are completed the Organization is setup and usable. The user should then proceed with setting up the rest of the inventory system. See the Oracle Manufacturing Implementation guide, or the Oracle Inventory Users guide for instructions on setting up Items, Categories, Costs, Transaction Defaults, and other features of the Oracle Inventory system. It is always advisable to consult Oracle Worldwide Support Services or Oracle Metalink for the current
Critical patch list for the Inventory Module prior to implementing a new Inventory system.
Profile Options
MO:Operating Unit= {the users Operating Unit name}
Used primarily in a multi-org environment. This points the responsibility to the appropriate Operating unit. Set the site level to the default operating unit. If there is more than 1 Operating unit defined this profile must be set at the responsibility level for each responsibility.
Primary Organization Tables
HR_LOCATIONS
Stores information about organization locations. Address, Org_id, ship_to / bill_to site, receiving site, etc LOCATION_ID is the primary key on this table. This table is accessed by forms or reports from the following modules; HR, INV, PO/REC.
(See Oracle Inventory Technical or Oracle HR Technical Reference Manual for more detail)
HR_ORGANIZATION_INFORMATION
Stores the information on all organizations defined in the system. It also stores most of the organization classification specific information. The table is populated through the Define Organization form (PERWSDOR). Each organization defined will have 1 row for the organization and 1 row for each organization classification defined on the form. ORG_INFORMATION_ID is the primary key on this table.
(See Oracle Inventory Technical or Oracle HR Technical Reference Manual for more detail)
HR_ORGANIZATION_UNITS
Stores generic information about the organizations. This is an excellent place to go if you need to see the relationship between org id and Business group id when troubleshooting a multi-org problem. ORGANIZATION_ID is the primary key for this table. BUSINESS_GROUP_ID is a foreign key. This table is used by a variety of org setup and item setup forms.
(See Oracle Inventory Technical or Oracle HR Technical Reference Manual for more detail)
MTL_PARAMETERS
Stores the set of general default options like GL accounts, locator, lot and serial number controls, costing method, inter-org options, costing org and item master, etc This table is populated by the org parameters form INVSDOIO. It is accessed by a wide variety of forms, reports, user exits, and concurrent programs throughout the manufacturing modules. ORGANIZATION_ID is the primary
key. This is the most heavily used Organization table in the manufacturing products.
(See Oracle Inventory Technical Reference Manual for more detail)
RCV_PARAMETERS
Stores receiving options for each organization that is setup to receive items.There is 1 row for each receiving organization. This table is populated by the org parameters form, receiving options, or from PO setup receiving options.
(See Oracle Inventory Technical or Oracle Purchasing Technical Reference Manual for more detail)
ORG_ACCESS
Stores the data on which responsibilities are granted access to the existing organizations. Frequently customers will partially populate the Organization Access form (INVSDORA), and effectively lock themselves out of their organizations.This table stores that information. If all else fails, you can frequently resolve this issue by truncating this table and having the user re-populate the Organization Access form correctly.
(See Oracle Inventory Technical Reference Manual for more detail)
No comments:
Post a Comment