Inventory Tech Details

Oracle Inventory
Overview
Copyright Oracle, 2007. All rights reserved.
Oracle Inventory 374114190.doc

Effective mm/dd/yy Page 1 of 86 Rev 1
Oracle Inventory
System References
None
Distribution
Job Title*
Ownership
The Job Title [list@YourCompany.com?Subject=374114190.doc] is responsible for ensuring that
this document is necessary and that it reflects actual practice.

Oracle Inventory

Objectives

Agenda

Inventory Features
Inventory Features
Item and Organization Definition
Set up inventory structure.
Group inventory organizations into multilevel, hierarchical trees for managing large
organization structures.
Define stock and nonstock parts.
Establish planning and purchasing attributes.
Track inventory by item, item revision, serial number, or lot number.
Transactions and Maintenance
Receive parts from and return parts to suppliers.
Transfer inventory between organizations directly or as in-transit shipments.
Create move orders for subinventory transfers.
Receive alerts or notifications about material shortages.
Add material overhead to the cost of a part.
Conduct inventory cycle counts based on ABC classification.

Record physical inventory counts and adjustments.
Track serial controlled items from receipt through work in process and inventory to the
customer sale.
Forecasting and Planning
Generate forecasts for future product demand.
Generate requisitions using the min/max or the reorder point planning methods.
Instructor Note:
Refer participants to to the Oracle Inventory Users Guide.

Overview
Overview
Oracle Inventory treats many different types of things as inventory. Inventory can be:
Finished goods that you sell to customers
Services that you sell to customers
Spare parts for maintenance
Raw materials for manufacturing processes
Inventory you purchase from a supplier on consignment

Inventory Capabilities

Inventory Capabilities (Cont)

Inventory Items
What Is an Item?
An item is a part or service you:
Purchase
Sell
Plan
Manufacture
Stock
Distribute
Prototype
Items can also be containers for items as well as components you build into other items.

Inventory Organizations
Inventory Organizations
An inventory organization is a facility where you store and transact items. Before you can use
Oracle Inventory, you must define one or more inventory organizations. Inventory
organizations represent distinct entities in your enterprise and can be one of the following:
A physical entity such as a manufacturing facility, warehouse, or distribution center.
A logical entity such as an item master organization, which you use to define items.
An inventory organization may have the following attributes:
An inventory organization can have its own location, ledger, costing method, workday
calendar, and items.
An inventory organization can share one or more of these characteristics with other
organizations.

Inventory Organization Structure
Inventory Organization Structure

An inventory organization, where you store and transact items can have one or more
subinventories. Subinventories are unique physical or logical separations of material inventory,
such as raw material inventory, finished goods inventory, or defective goods inventory. In
Oracle Inventory, all material within an organization is held in a subinventory. You must define
at least one subinventory for every organization. You can track item quantities by subinventory
as well as restrict items to specific subinventories.
The subinventories in an inventory organization may be made up of one or more locators. You
use locators to identify physical areas where you store inventory items. You can track items by
locator and restrict items to a specific locator. Locator control is optional in Oracle Inventory.
Instructor Note:
Mention that you can set up an inventory organization without subinventories; however, you
cannot transact items without a subinventory.

Item Attributes
Item Attributes
Item attributes are the collection of information about an item.

Item Attribute Groups

Control Levels
Master-Level Control
An attribute you maintain at the master level has identical values across all organizations that
use the item.
Organization-Level Control
An attribute you maintain at the organization level may have different values for each
organization that uses it.
Attribute Control
Some attributes can be maintained at only the master level or the organizational Level. Units of
measure are controlled at the master level. If you are using multiple organizations, then you
should maintain min-max planning at the organization level.
Technical Note
Master-Level Control
For example, suppose you want to ensure that items defined in two organizations are
transactable at the same time in both organizations. If you make the item not transactable in
one organization, you want the same item to become not transactable in the other organization.
Organization-Level Control

Suppose only one of the two organizations in your Oracle Inventory implementation performs
manufacturing operations, while the other organization is strictly a distribution warehouse.
For a finished good item used in both organizations, you would want the flexibility to select the
Build in WIP status attribute check box in the manufacturing organization, and clear the Build
in WIP status attribute check box in the distribution organization.

Item Statuses and Attributes
Item Statuses and Attributes

You define an item status by selecting the value check boxes for the status attribute. You can
control status attributes and item status at the item level or organization level.

Life Cycle of a Part
Life Cycle of a Part

This graph depicts the usage of status and attributes to indicate the stages an item (or part)
might go through in its life cycle. For example, if a part is still in the prototype stage, it will not
be stockable and there will be no transaction activity allowed. However, it will be defined in
the bill of material in order to build the prototype part originally.

Item Control
Item Control
You can implement locator, revision, lot, and serial number control for your items. Inventory
controls are optional for all items. You can implement any combination of the four controls for
each item.
Revision Control
A revision is a particular version of an item, bill of material, or routing. Use a revision
when you change the form, fit or function of an item. You can use letters, numbers, and
characters, such as *, &, and #, to label revisions. Letters are always in upper case and
numbers may include decimals. To ensure that revisions sort properly, decimals should
always be followed by a number. Valid revisions can include: A, B, 01, 02, A1, B1, 1A,
1B, 0.0, 0.1, A.0, A.1, and so on. Revisions are sorted according to ASCII rules. Each
revision must be greater than the previous revision. Therefore, you cannot use revision 10
after revision 9 because, according to ASCII sorting, 10 precedes 9. The value you entered
in the Starting Revision field in the Organization Parameters window displays as the
starting revision for the item.
Locator Control

Stock locators are structures within subinventories and are the third level in the enterprise
structuring scheme of Oracle Inventory. Locators may represent rows, aisles, or bins in
warehouses. You can transact items into and out of stock locators. Item quantities can be
tracked by locator. Items can also be restricted to specific locators.
Lot Control
A lot identifies a specific batch of an item you receive and store in your organization. Lot
control is a technique for enforcing the use of lot numbers during material transactions,
thus enabling the tracking of batches of items throughout their movement in and out of
inventory. If lot control is turned on for an item, you must indicate the lot number to
perform a transaction. Oracle Inventory provides complete lot number support for
inventory transactions.
Serial Number
A serial number is an alphanumeric piece of information you assign to an individual unit
of an item. Serial number control is a system technique for enforcing the use of serial
numbers during a material transaction. You can use serial numbers to track items over
which you want to maintain very tight control.

Receipt to Issue Life Cycle
Receipt to Issue
Oracle Inventory uses the receipt to issue process to manage your inventory. When inventory
arrives in your warehouse you receive it. After you receive inventory, you can transfer it
within your organization or to another organization. Finally, you can issue material out of
Oracle Inventory.

Receiving Inventory
Receiving Inventory
There are different ways you can receive material into your organization.
Purchasing
You can use Oracle Purchasing to receive material from outside of your organization. You can
receive:
Purchase order receipts
Internal requisitions
In-transit receipts
Return material authorizations
Unexpected receipts
Work in Process
You can use Oracle Work in Process to receive material from the manufacturing floor. You can
receive:
Component returns
Negative component issues
Assembly returns

Inventory
You can use Oracle Inventory to receive material in to your warehouse. You can receive:
Miscellaneous account receipts
Receipt from projects
User-defined receipts
Interorganization transfers

Receiving Inventory

Transferring Inventory
Transferring Inventory
Different applications can generate requests to transfer inventory.
Shipping
You can use Oracle Shipping Execution to generate a transfer to move material from a storage
area to a staging to for shipping.
Order Management
You can use Oracle Order Management to generate a transfer to move material from a storage
area to a staging area for shipping.
Work in Process
You can use Oracle Work in Process to generate a transfer to acquire components for a project.
Inventory
You can use Oracle Inventory to:
Transfer material between organizations
Transfer material within an organization
Replenish materials
Request transfers

Issuing Inventory
Issuing Inventory
You can use the following applications to issue material:
Order Management
Oracle Order Management can generate an inventory issue through:
Sales orders
Internal orders
Purchasing
Oracle Purchasing can generate an inventory issue for:
Return to vendor materials
Work in Process
Oracle Work in Process can generate an inventory issue through:
Component issues
Assembly returns
Inventory
Oracle Inventory can issue stock through:

User-defined material issues
Interorganization transfers
Cycle count negative issue
Issue requests

Transaction Flows
Transaction Flows
A transaction is an item movement into, within, or out of inventory. A transaction changes the
quantity, location, planning responsibility and/or cost of an item.
Oracle Inventory supports a number of predefined and user-defined transaction types.
Every material movement has a corresponding set of accounting transactions that Oracle
Inventory automatically generates.
All transactions validate the various controls (revision, locator, lot number, and serial number)
you enable for your items.
You can choose your own transaction processing methods to use available computing resources
most effectively.

Inventory Transactions
Inventory Transactions
Inventory transactions enable you to:
Receive items into your organization.
Issue items out of your organization.
Transfer items from one subinventory in your organization to another subinventory in the
same organization
Transfer items between organizations
On-hand Quantity
On-hand quantity is the physical quantity that resides in your subinventory. For example, the
Bulk subinventory has 15 items that reside in it. Therefore, the on-hand quantity for the Bulk
subinventory is 15.
Reservations
A reservation is a link between a supply source and a demand source. A reservation creates a
permanent data link between a supply source and a demand source, and represents a guaranteed
allotment of material to a specified demand source. Item reservations prevent the allocation of

material you previously set aside for a sales order, account, account alias, inventory allotment,
user-defined source, process batch components or, Oracle Complex Maintenance and Repair
Overhaul work order components. You can also create reservations for different types of
supplies such as on-hand inventory, purchase orders, internal requisitions, discrete jobs, shop
floor jobs, and process manufacturing batches. In addition, you can create reservations for
advanced shipment notices (ASNs) and material in receiving for Oracle Warehouse
Management enabled organizations.

Availability
To Planning functions, avail = supply - demand for a particular time period

To Inventory, avail = on hand-res-pending transactions
Availability to Inventory is not the same as availability to Planning- Planning looks at
inbound supply in addition to on hand quantity and deducts other demand. Inventory only
looks at what is on hand and subtracts what is committed to other uses (i.e reserved or about
to be moved or issued out the door)
Availability to Inventory depends on what you want to use the material for. For example, if
you have material that is in a non-reserved subinventory, that quantity will not be available to
reserve but it may be available to transact (for miscellaneous issues etc).

Inventory Forecasting
Inventory Forecasting
Forecasts generated by Oracle Inventory are based on historical transaction activity only. When
creating a forecast, you can select the type of transactions that you want to use. You can also
specify how far into the future that you want to forecast demand.
After you complete a forecast, you can use it to determine reorder-point planning. You can also
load forecasts into the master schedule, which is a component of the Oracle Material
Requirements Planning (MRP) application.
Note: If you install only Oracle Inventory, you can manually create forecasts. Manually created
forecasts can be based on transaction activity other than historical data.
Forecast Types
Forecast generation uses mathematical algorithms to calculate a prediction of future demand.
You can calculate estimated future demand for items using historical data and focus or
statistical forecasting techniques. You can create multiple forecasts and group complimenting
forecasts into forecast sets. Oracle Inventory supports the following forecast types:
Focus
Statistical

Focus forecasting enables you to simulate various methods of calculating demand so that you
can select the best forecasting model. Statistical forecasting enables you to use detailed history
and applies weighting factors to exponentially smooth the data. Statistical forecasting also
enables you to apply exponentially weighted trend and seasonality factors to predict demand.
You typically use Focus forecasting to produce single period forecasts, whereas you can use
Statistical forecasting to forecast any number of periods into the future.

Inventory Planning and Replenishment
Inventory Planning and Replenishment

Inventory planning involves answering two questions:
When should you place a new order?
How much should you order?
Using the Oracle Inventory application, you can set up the following types of inventory
replenishment plans:
Min-Max planning
Reorder-point planning
Kanban replenishment planning
Replenishment counting (for non-quantity tracked replenishment)
Oracle Inventory planning interfaces with Oracle Purchasing, and indirectly with Oracle Order
Management.
Reorder-Point Planning
With Reorder-point planning, you order a quantity when the quantity falls to a predetermined
reorder-point. Ideally, it is best to reorder at some point before inventory levels fall into the

safety zone. Safety stock typically provides a buffer from which to fill orders, between reorder-
points. At the end of the lead time, the on-hand quantity should equal the safety stock.
The essential feature of Reorder-Point planning is that it projects what the stock level will be
based on forecast demand and no visibility of sales ordersat the end of the item's lead time.
This projection is then used to decide whether or not the reorder-point has been reached.
The reorder-point is calculated by adding expected demand during lead time to safety stock.
You perform reorder-point planning for the entire organization. You can use Reorder-Point
planning for items under independent demand. That is, demand for items (or materials) that are
independent of the demand for other items (or materials). When you define an item, you can
specify Reorder-Point planning as the inventory planning method.
Min-Max Planning
Min-Max planning is a method of inventory planning that determines how much to order
based on user-defined minimum and maximum inventory levels. In contrast to Reorder-Point
planning, Min-Max planning is not based on demand projections and does not consider lead
time. With Oracle Inventory, you can perform Min-Max planning at the both the organization
and the subinventory levels. To perform organization-level Min-Max planning for an item, you
must specify organization-level minimum and maximum quantities. Min-Max planning is
typically used to control low value inventory items that do not need great control. To perform
subinventory-level Min-Max planning for an item, you must specify subinventory-level
minimum and maximum quantities.
Kanban Replenishment
Kanban is a means of supporting pull-based replenishment in manufacturing systems. A kanban
system is a self-regulating pull system that leads to shorter lead times and reduced inventory.
Kanban systems are typically applied to items with relatively constant demand and medium-to-
high production volume.
Kanbans represent replenishment signals that are manual and highly visible, such as a color-
code card that moves with the material, a light that goes on when replenishment is required, or
an empty bin that is moved to the supply location to trigger replenishment.
Kanban systems typically provide support for external devices, such as bar code readers to read
kanban cards and trigger a replenishment signal.
Replenishment Counting
A non-tracked subinventory is an expense subinventory for which Oracle Inventory does not
maintain on-hand quantity information. When you move valued material to a non-tracked
subinventory, Oracle Inventory automatically charges the appropriate expense account, and
discards that quantity. Non-tracked subinventories typically store items of low value, such as
office stationary. You can also use replenishment counting if you do your own planning. In this
case you may order either a specific quantity, or the maximum quantity specified in the Min-
Max values. Other non-tracked subinventories might include hospital drug trolleys, where there
is no opportunity to record accurate and timely issue transaction information.

Inventory Control and Accuracy
Inventory Control and Accuracy

Oracle Inventory Management provides several tools to aid users in controlling and improving
the accuracy of inventory records:
ABC Analysis
Cycle Counting
Physical Inventory
ABC Analysis
An ABC analysis determines the relative value of a group of inventory items based on a user
specified valuation criterion. ABC refers to the rankings you assign your items as a result of
this analysis, where A items are ranked higher than B items, and so on. This array is then
normally split in to three classes A, B, and C:
A Group - The A group usually represents 10% to 20% by number of items, and 50%-70%
by projected dollar volume.
B Group - The B group usually represents about 20% of the times and about 20% of the
dollar volume.

C Group - The C group contains 60%-70% of the items and represents about 10%-30% of
the dollar volume.
You can optionally use the ABC analyses you compile to drive your cycle counts, where you
might count items of high value (A items) very frequently, items of lower value less frequently,
and items of lowest value very infrequently.
Cycle Counting
Cycle counting is the periodic counting of individual items throughout the course of the year to
ensure the accuracy of inventory quantities and values. Accurate system onhand quantities are
essential for managing supply and demand, maintaining high service levels, and planning
production.
You can perform cycle counting instead of taking complete physical inventories, or you can use
both techniques sidebyside to verify inventory quantities and values.
Most effective cycle counting systems require the counting of a certain number of items every
workday with each item counted at a prescribed frequency. With ABC analysis you can use
cycle counting to count items of greater importance more frequently than those of less
importance. Cycle counting supports scheduled counting based on value or counting by
location, and can be set up at the organization level or the subinventory level.
Physical Inventory
A physical inventory is a periodic reconciliation of system on-hand balances with physical
counts in inventory. You can perform physical inventories whenever you choose to verify the
accuracy of your system on-hand quantities. You can perform a physical inventory for an entire
organization or for particular subinventories within an organization. Physical inventories are
usually performed once every six months, or once a year depending on organization
requirements. Accurate system onhand quantities are essential for managing supply and
demand, maintaining high service levels, and planning production.

Inventory Process

Agenda

Defining Organizations

Organizations
MTL_PARAMETERS
MTL_PARAMETERS is an inventory organization with which an item is associated. The
primary key is the ORGANIZATION_ID.
MTL_INTERORG_PARAMETERS
This table identifies the receiving organizations linked to a particular organization. You must
define the interorganizational relationship before you perform any interorganization transfers.
Units of measure, distance, transfer charge, and accounting information are also specified in
this table. The primary key is FROM_ORGANIZATION_ID, TO_ORGANIZATION_ID.
GL_SETS_OF_BOOKS
GL_SETS_OF_BOOKS stores information about the sets of books you define in your general
ledger application. Each row includes the set of books name, description, functional currency,
and other information. This table corresponds to the Define Set of Books form. The primary
key is SET_OF_BOOKS_ID.
GL_CODE_COMBINATIONS
This table stores valid Accounting Flexfield segment value combinations for each accounting
flexfield structure within your general ledger application. The primary key is
CODE_COMBINATION_ID.

HR_ALL_ORGANIZATION_UNITS
HR_ALL_ORGANIZATION_UNITS stores generic information about organizations. An
organization can be used for various purposes in Oracle Manufacturing applications. For
example, one organization can represent a business group, an ECO department, a planning
organization, and an inventory organization. The primary key is ORGANIZATION_ID.

Defining Subinventories

Defining Locators

Subinventories and Locators
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the definitions for
inventory items, engineering items, and purchasing items. The flexfield code is MSTK. The
primary key for an item is the INVENTORY_ITEM_ID and the ORGANIZATION_ID. The
same item could be defined in more than one organization. Each row represents an item in an
organization.
MTL_SYSTEM_ITEMS_TL
MTL_SYSTEM_ITEMS_TL is a table holding translated Description column for Items. The
primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID, LANGUAGE.
flexfield structure within your general ledger application. The primary key is
MTL_SECONDARY_INVENTORIES
MTL_SECONDARY_INVENTORIES is the definition table for the subinventory.
Subinventories are assigned to items, indicating a list of valid places in which this item may be
located. The primary key is SECONDARY_INVENTORY_NAME, ORGANIZATION_ID.

MTL_ITEM_SUB_INVENTORIES
MTL_ITEM_SUB_INVENTORIES maintains a listing of subinventories assigned to an
inventory or engineering item. The subinventories make up the valid list of subinventories
when transacting a specific item if the user has specified that the item must use subinventories
from a predefined list. The primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID,
SECONDARY_INVENTORY
MTL_ITEM_LOCATIONS
MTL_ITEM_LOCATIONS is the definition table for stock locators. The associated attributes
describe the subinventory to which this locator belongs, and the locator physical capacity. The
primary key is INVENTORY_LOCATION_ID, ORGANIZATION_ID.
MTL_SECONDARY_LOCATORS
MTL_SECONDARY_LOCATORS stores all locators within a subinventory for a specific
item. The locators make up the valid list of locators when transacting that specific item to/from
the subinventory when the user has specified that the item must use locators from a predefined
list. The primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID,
SECONDARY_LOCATORS.
MTL_PARAMETERS

Defining Items

Item Master
MTL_SYSTEM_ITEMS_B
organization.
MTL_ITEM_ATTRIBUTES
MTL_ITEM_ATTRIBUTES stores the item attributes, their user-friendly names if the item is
maintained at the item or item/organization level, and the kind of validation required for each
attribute. This table is seeded on install or upgrade. The primary key is ATTRIBUTE_NAME.
MTL_ITEM_TEMPL_ATTRIBUTES
MTL_ITEM_TEMPL_ATTRIBUTES stores the attributes and attribute values for a template.
When a template is created, a row is inserted for each available item attribute. When the
template is applied to an item, the enabled attribute values are propagated to the item. The
primary key is TEMPLATE_ID, ATTRIBUTE_NAME.
MTL_ITEM_STATUS

MTL_ITEM_STATUS is the definition table for a material status code. The status code is a
required item attribute and indicates the item status (for example, active, pending, or obsolete).
You may define as many additional status codes as you want. The values of the individual
status attributes associated with an item status are stored in
MTL_STATUS_ATTRIBUTE_VALUES. The primary key is
INVENTORY_ITEM_STATUS_CODE.
MTL_ITEM_TEMPLATES
MTL_ITEM_TEMPLATES is the definition table for item templates. It contains the user-
defined name and description. When the template is applied to an item, the enabled item
attributes are propagated to the item. The primary key is TEMPLATE_ID.
MTL_STATUS_ATTRIBUTE_VALUES
MTL_STATUS_ATTRIBUTE_VALUES stores the attribute values associated with an item
status code. One record is created for each of the function-enabling attributes for each defined
item status code. The primary key is INVENTORY_ITEM_STATUS_CODE,
ATTRIBUTE_NAME.
MTL_PARAMETERS

Defining Item Controls

Item Controls
MTL_SYSTEM_ITEMS_B
organization.
MTL_ITEM_REVISIONS
MTL_ITEM_REVISIONS stores revision levels for an inventory item. When an item is
defined, a starting revision record is written out to the table; every item will have at least one
revision. The primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID, REVISION.
MTL_SERIAL_NUMBERS
MTL_SERIAL_NUMBERS stores the definition and current status of all serial numbers in
Oracle Inventory. These serial numbers are also used in other areas of Oracle Manufacturing
applications.
A serial number can have one of four statuses:
Defined, but not used
Resides in stores

Issued out of stores
Resides in transit
The primary key is INVENTORY_ID, SERIAL_NUMBER,
CURRENT_ORGANIZATION_ID.
MTL_LOT_NUMBERS
MTL_LOT_NUMBERS stores the definition and expiration date of all lot numbers in
inventory. A lot number can exist in more than one organization or for different items. The
primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID, LOT_NUMBER.

Defining Item Status Codes

Item Status
MTL_SYSTEM_ITEMS_B
organization.
MTL_ITEM_ATTRIBUTES
MTL_ITEM_ATTRIBUTES stores the item attributes, their user-friendly names if the attribute
is maintained at the item or item/organization level, if the attribute is controlled by an items
status, and the kind of validation required for each attribute. This table is seeded on install or
upgrade. The top eight item attributes are as follows:
1. Stockable
2. Transactable
3. BOM allowed
4. WIP allowed
5. Purchasable

6. OE Orderable
7. Internal Orderable
8. Billable
The primary key is ATTRIBUTE_NAME.
MTL_STATUS_ATTRIBUTE_VALUES
MTL_STATUS_ATTRIBUTE_VALUES stores the attribute values associated with an item
status code. One record is created for each of the function-enabling attributes for each defined
item status code. The primary key is INVENTORY_ITEM_STATUS_CODE,
ATTRIBUTE_NAME.
MTL_ITEM_STATUS
MTL_ITEM_STATUS is the definition table for a material status code. The status code is a
required item attribute and indicates the item status (for example, active, pending, or obsolete).
You may define as many additional status codes as you want. The values of the individual
status attributes associated with an items status are stored in
MTL_STATUS_ATTRIBUTE_VALUES. The primary key is
INVENTORY_ITEM_STATUS_CODE.
MTL_PENDING_ITEM_STATUS
MTL_PENDING_ITEM_STATUS is used to define and store the history of the item statuses
that have been or will be assigned to an item. This table maintains the status history for each
item. This table also stores pending status information. The primary key is
INVENTORY_ITEM_ID, ORGANIZATION_ID, STATUS_CODE, EFFECTIVE_DATE.

Defining Item Categories

Item Categories
MTL_SYSTEM_ITEMS_B
organization.
FND_ID_FLEX_STRUCTURES
FND_ID_FLEX_STRUCTURES stores structure information about key flexfields. The
primary key is APPLICATION_ID, ID_FLEX_CODE, ID_FLEX_NUM.
MTL_CATEGORIES_B
MTL_CATEGORIES_B is the code combinations table for item categories. Items are grouped
into categories within the context of a category set to provide flexible grouping schemes. The
primary key is CATEGORY_ID.
The item category is a key flexfield with a flexfield code of MCAT.
MTL_CATEGORIES_TL
MTL_CATEGORIES_TL is a table holding translated Description column for Item Categories.
The primary key is CATEGORY_ID, LANGUAGE.

MTL_CATEGORY_SETS_B
MTL_CATEGORY_SETS_B contains the entity definition for category sets. A category set is a
categorization scheme for a group of items. Items can be assigned to different categories in
different category sets, but can be assigned to only one category within a category set. The
primary key is CATEGORY_SET_ID.
MTL_CATEGORY_SETS_TL
MTL_CATEGORY_SETS_TL is a table holding translated Name and Description columns for
Category Sets. The primary key is CATEGORY_SET_ID, LANGUAGE.
MTL_CATEGORY_SET_VALID_CATS
MTL_CATEGORY_SET_VALID_CATS defines the valid category list for a particular
category set. If category validation is required, the list of valid categories is stored in this table
and is used to restrict category selection for the category set. The primary key is
CATEGORY_SET_ID, CATEGORY_ID.
MTL_DEFAULT_CATEGORY_SETS
MTL_DEFAULT_CATEGORY_SETS stores the identifier of the category set that acts as the
default for a particular functional area. This information is used to determine the mandatory
category sets for an item. It is also used to provide a default category set for forms and reports
that require a category set field value or parameter. The primary key is
FUNCTIONAL_AREA_ID, CATEGORY_SET_ID.
MTL_ITEM_CATEGORIES
MTL_ITEM_CATEGORIES stores the item assignments to categories within a category set.
For each assignment, this table stores the item, category set, and the category. Items can be
assigned to multiple categories and category sets, but can be assigned to only one category in a
given category set.
This table is populated through either the Define Item or the Update Item/Org Attributes forms.
It can also be populated by performing item assignments when a category set is defined. The
primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID, CATEGORY_SET_ID.

Defining Item Catalog Groups

Item Catalogs
MTL_ITEM_CATALOG_GROUPS
MTL_ITEM_CATALOG_GROUPS is the entity table for item catalog groups. An item catalog
group consists of items that can be described by the same set of descriptive elements or item
properties. The item catalog group assignment for an item is done at the item master
organization level.
The item catalog group is a key flexfield. The flexfield code is MICG. The primary key is
ITEM_CATALOG_GROUP_ID.
MTL_DESCRIPTIVE_ELEMENTS
MTL_DESCRIPTIVE_ELEMENTS stores the descriptive element definitions for an item
catalog group. Descriptive elements are defining properties used to describe the catalog group.
The primary key is ITEM_CATALOG_GROUP_ID, ELEMENT_NAME.
MTL_DESCR_ELEMENT_VALUES
MTL_DESCR_ELEMENT_VALUES stores the descriptive element values for a specific item.
An item can only be assigned to one item catalog group and will only have descriptive
elements for a single catalog group. The primary key is INVENTORY_ITEM_ID,
ELEMENT_NAME.
MTL_SYSTEM_ITEMS_B

organization.

Defining an ABC Compile

ABC Analysis
MTL_ABC_CLASSES
MTL_ABC_CLASSES contains information about ABC classes. Each row in this table defines
an ABC class. An ABC class is a category under which items with similar metrics are put
together. An ABC class can be used in more than one ABC group, but only once within a given
group. The primary key is ABC_CLASS_ID.
MTL_ABC_ASSIGNMENT_GROUPS
MTL_ABC_ASSIGNMENT_GROUPS contains information for ABC groups. Each row in
this table defines an ABC group and is populated by the Define ABC Group table. Oracle
Inventory uses this information as the basis for ABC class assignment and item assignment.
The primary key is ASSIGNMENT_GROUP_ID.
MTL_ABC_ASSGN_GROUP_CLASSES
MTL_ABC_ASSIGN_GROUP_CLASSES stores information about the ABC classes assigned
to an ABC group. An ABC class can be assigned to one or more ABC groups, but can be used
only once in each ABC group. The primary key is ASSIGNMENT_GROUP_ID,
ABC_CLASS_ID.
MTL_ABC_ASSIGNMENTS

MTL_ABC_ASSIGNMENTS holds assignments of inventory items to ABC classes and ABC
groups. Oracle Inventory uses this information to load the cycle count process. The primary
key is INVENTORY_ITEM_ID, ASSIGNMENT_GROUP_ID, ABC_CLASS_ID.
MTL_ABC_COMPILE_HEADERS
MTL_ABC_COMPILE_HEADERS contains information used for, and that results from, an
ABC compile or an ABC analysis. It holds user-specified information, such as the current
compile option and cost code chosen, the results of an ABC analysis, the cumulative quantity,
and the cumulative value.
Oracle Inventory uses this information during the ABC compile process to determine the
compile criterion and attributes used for the compile. The primary key is COMPILE_ID.
MTL_ABC_COMPILES
MTL_ABC_COMPILES stores information about each item within an ABC compiler. Each
row includes an items sequence number relative to other items in the given compiler, based on
the criteria defined in MTL_ABC_COMPILE_HEADERS. The primary key is
INVENTORY_ITEM_ID, COMPILE_ID.
MTL_SYSTEM_ITEMS_B
inventory items, engineering items, and purchasing items. The primary key for an item is the
INVENTORY_ITEM_ID and the ORGANIZATION_ID.

Defining Physical Inventory

Physical Inventory
MTL_PHYSICAL_SUBINVENTORIES
MTL_PHYSICAL_SUBINVENTORIES specifies which subinventories are involved in a
physical inventory when the physical inventory does not include all subinventories. The
primary key is ORGANIZATION_ID, PHYSICAL_INVENTORY_ID, SUBINVENTORY.
MTL_SECONDARY_INVENTORIES
MTL_SECONDARY_INVENTORIES is the definition table for the subinventory.
Subinventories are assigned to items, indicating a list of valid places in which this item is
located. The primary key is SECONDARY_INVENTORY_NAME, ORGANIZATION_ID.
MTL_PHYSICAL_INVENTORY_TAGS
MTL_PHYSICAL_INVENTORY_TAGS stores information regarding physical inventory tags,
including tag number, SKU information, tag quantity, and a pointer to the corresponding
adjustment in MTL_PHYSICAL_ADJUSTMENTS. A change to this table can require a
change to MTL_PHYSICAL_ADJUSTMENTS to ensure that the information therein remains
consistent with its tags. The primary key is TAG_ID.
MTL_PHYSICAL_ADJUSTMENTS
MTL_PHYSICAL_ADJUSTMENTS contains all information about the adjustment
transactions, including the size of the necessary adjustment, the accounts to which the

adjustment transaction was posted, and the approval status of each transaction. The primary
key is ADJUSTMENT_ID.
MTL_MATERIAL_TRANSACTIONS
MTL_MATERIAL_TRANSACTIONS stores a record of every material transaction or cost
update performed in Inventory. Records are inserted into this table either through the
transaction processor or by the standard cost update program. The primary key is
TRANSACTION_ID.
MTL_SYSTEM_ITEMS_B

Defining a Cycle Count

Cycle Count
MTL_SYSTEM_ITEMS_B
MTL_CYCLE_COUNT_ITEMS
MTL_CYCLE_COUNT_ITEMS stores information about all items eligible for cycle counting
within the scope of a cycle count name. Oracle Inventory uses this information to direct the
cycle count scheduling process, and as a validation table when entering manual schedule
requests. The primary key is CYCLE_COUNT_HEADER_ID, INVENTORY_ITEM_ID.
MTL_CYCLE_COUNT_CLASSES
MTL_CYCLE_COUNT_CLASSES stores information about cycle count classes, such as
associated cycle count name, approval tolerance limits, and minimum counting frequency.
Oracle Inventory uses Cycle Count Classes as units for specifying and defaulting cycle count
attributes. The primary key is ABC_CLASS_ID, CYCLE_COUNT_HEADER_ID.
MTL_CYCLE_COUNT_HEADERS
MTL_CYCLE_COUNT_HEADERS stores information about cycle count names. Oracle
Inventory uses this information to track defined cycle count names, to indicate

tolerance/approval limits, cycle count calendar and exception set, ABC initialization
information, scheduling options, and recount options. The primary key is
CYCLE_COUNT_HEADER_ID.
MTL_CC_SCHEDULE_REQUESTS
MTL_CC_SCHEDULE_REQUESTS stores cycle count schedule requests. Oracle Inventory
uses this information to feed the count generation process and generate Cycle Count Requests
that show up in the Count List Reports. The primary key is
CYCLE_COUNT_SCHEDULE_ID.
MTL_CC_SCHED_COUNT_XREFS
MTL_CC_SCHED_COUNT_XREFS links cycle counts entered to the schedule request that
generated it. Oracle Inventory uses this information to determine when a schedule request has
been completed and to update its status. The primary key is
CYCLE_COUNT_SCHEDULE_ID, CYCLE_COUNT_ENTRY_ID.
MTL_CYCLE_COUNT_ENTRIES
MTL_CYCLE_COUNT_ENTRIES stores the actual counts of a cycle count. A row in this
table without a count is considered to be a count request. Oracle Inventory uses this
information to determine and store cycle count adjustments, recounts, and approval
requirements. The primary key is CYCLE_COUNT_ENTRY_ID.
update performed in Inventory. Records are inserted into this table either through the
transaction processor or by the standard cost update program. The primary key is
TRANSACTION_ID.

Viewing Item Supply and Demand

Defining Item Reservations

Demand and Reservation Information
MTL_DEMAND
MTL_DEMAND stores demand and reservation information used in Available to Promise,
Planning, and other manufacturing functions. Four row types are stored in this table:
Summary Demand rows
Dependent Demand rows
Open Demand rows
Reservation rows
The primary key is INVENTORY_ITEM_ID, DEMAND_SOURCE_TYPE,
DEMAND_SOURCE_HEADER_ID, DEMAND_SOURCE_LINE (o),
DEMAND_SOURCE_DELIVERY (o), COMPONENT_SEQUENCE_ID (o).
MTL_SALES_ORDERS
MTL_SALES_ORDERS stores the Oracle Inventory local definition of sales orders and maps
sales orders between Oracle Inventory and other Oracle Manufacturing applications. The
primary key is SALES_ORDER_ID.
OE_ORDER_HEADERS_ALL

OE_ORDER_HEADERS_ALL stores header information for orders in Oracle Order
Management. The primary key is HEADER_ID.
OE-ORDER_LINES_ALL
OE_ORDER_LINES_ALL stores information for all order lines in Oracle Order Management.
The primary key is LINE-ID.
flexfield structure within your general ledger application. Available material can be reserved
against a valid Accounting Flexfield combination. The primary key is
MTL_GENERIC_DISPOSITIONS
MTL_GENERIC_DISPOSITIONS stores the user-defined account alias. An account alias
provides a method to use accounting numbers and makes it easier to transact account issues
and receipts. Available inventory can be reserved against an account alias. The primary key is
DISPOSITION_ID, ORGANIZATION_ID.
update performed in Inventory. An issue transaction to an account number or account alias can
relieve a reservation against the account number or alias. The primary key is
TRANSACTION_ID.
MTL_DEMAND_INTERFACE
MTL_DEMAND_INTERFACE is the interface point between non-Inventory applications and
the Oracle Inventory demand module. Records inserted into this table are processed by the
Demand Manager concurrent program.
MTL_SYSTEM_ITEMS_B

Oracle Inventory Transaction Flow
MTL_TRANSACTIONS_INTERFACE
This is the interface point between non-Inventory applications and the Inventory transaction
module.
The Transaction Manager concurrent program polls this table at a user-specified process
interval and submits the transaction workers to process them. Processing consists of data
derivation, validation, and transfer of records from MTL_TRANSACTIONS_INTERFACE,
MTL_TRANSACTION_LOTS_INTERFACE, and MTL_SERIAL_NUMBERS_INTERFACE
into their respective TEMP tables, from where they are processed by the transaction processor.
MTL_MATERIAL_TRANSACTIONS_TEMP
This table is the gateway for all material transactions. Records are processed from this table
into Inventory through the transaction processor. All Inventory transaction forms write directly
to this table. Outside applications must write transaction records to
MTL_TRANSACTSIONS_INTERFACE to be processed through
MTL_MATERIAL_TRANSACTIONS_TEMP and the transaction processor by the
Transaction Worker concurrent program.
This table stores a record of every material transaction or cost update performed in Inventory.

Records are inserted into this table either through the transaction processor or by the standard
cost program. The primary key is TRANSACTION_ID.
MTL_TRANSACTION_ACCOUNTS
This table holds the accounting information for each material transaction in
MTL_MATERIAL_TRANSACTIONS. Oracle Inventory uses this information to track the
financial impact of your quantity moves.

Agenda

Inventory Open Interfaces
Open Interfaces for Oracle Inventory

Open Transaction Interface
You can load transactions from external applications and feeder systems using this
interface. These transactions could include sales order shipment transactions from an
external order entry system, or they could be simple material issues, receipts, or transfers
that are loaded from data collection devices.
This interface is used as an integration point with Oracle Order Management for shipment
transactions. Oracle Order Management uses the Inventory interface program to populate
the interface tables with transactions submitted through the Confirm Shipments window.
Open Replenishment Interface
This enables you to load replenishment requests from external systems, such as a bar-code
application. Such requests may be in the form of stock-take counts or requisition requests
for subinventories in which you do not track quantities.
You may also use the Replenishment Interface to process requisition requests generated by
external applications for tracked subinventories.
Open Item Interface

You can import items from any source into Oracle Inventory and Oracle Engineering using
the Item Interface. With this interface, you can convert inventory items from another
inventory system, migrate assembly and component items from a legacy manufacturing
system, convert purchased items from a custom purchasing system, and import new items
from a Product Data Management package. The Item Interface validates your data,
insuring that your imported items contain the same item detail as items you enter manually
in the Master Item window.
You can also import item category assignments. This can be done simultaneously with a
process of importing items, or as a separate task of importing item category assignments
only. For this purpose, the Inventory menu contains the Import submenu with the Import
Items and Import Item Category Assignments menu entries.
Customer Item and Customer Item Cross-Reference Open Interfaces
A number of manufacturing industries are characterized by a multi-tiered, just-in-time
supply chain structure. Todays manufacturing environment requires a close working
relationship between customers and suppliers along the entire supply chain. Suppliers
must be able to react quickly to their customers often changing requirements. By cross-
referencing customer items with their own inventory items, suppliers can achieve faster
order processing and shipments by allowing customers to place orders using customer
item numbers.
You can import customer items and customer item cross-references from any legacy
system into Oracle Inventory using the Customer Item Interface and the Customer Item
Cross Reference Interface. These interfaces validate all data that you import into Oracle
Inventory. They also perform foreign key validation and check for attribute inter-
dependencies, acceptable values, and value ranges. The interfaces ensure that the imported
customer items and cross-references contain the same detail as items entered manually
using the Customer Items and Customer Item Cross References windows. Error codes and
corresponding error messages for all errors detected during validation are written to the
interface tables.
Cycle Count Entries Interface
You can import cycle count entries from an external system into Oracle Inventory using
the Cycle Count Entries Interface. This interface validates all data that you import into
Oracle Inventory. It also performs foreign key validation and checks for attribute inter-
dependencies, acceptable values, and value ranges. The interface ensures that the imported
cycle count entries contain the same detail as items entered manually using the Cycle
Count Entries window. Errors detected during validation are written to the Cycle Count
Interface Errors table.

Inventory Application Program Interfaces
Inventory APIs
Cycle Count Application Program Interface
The Cycle Count API is a public API that enables you to perform on-line processing for
cycle count records. This API takes a cycle count interface row that has been passed
through the p_interface_rec parameter and processes it based on the values of the
parameter fields. The Cycle Count API includes the public procedure
import_countrequest.
Kanban Application Program Interface
The Kanban API is a public API that enables you to update the supply status of kanban
cards. To accomplish this task, you use the public procedure update_card_supply_status.
Lot Application Program Interface
The Lot API is a public API that enables you to insert a lot into the
MTL_LOT_NUMBERS table. It performs all the necessary validation before it inserts the
lot. This API derives the expiration date from the controls set for shelf_life_code and
shelf_life_days for the item. If the API is able to insert the lot, it returns a status of
success. If the lot already exists for the same item and organization, the API also returns a
status of success; however, it places a message on the stack to indicate that the lot already

exists. The Lot API returns an error status if there is any validation error. Standard WHO
information is used from the FND_GLOBAL API. The Lot API has one public procedure,
insertlot.
Material Reservation Application Program Interface
The Material Reservation API is a public API that enables you to do the following:
- Query existing reservations
- Create reservations
- Update existing reservations
- Transfer existing reservations
- Delete existing reservations
Reservations Manager Application Program Interface
The Reservations Manager API is a public API that enables you to call the reservation
manager on-line or submit reservation requests concurrently. The Reservations Manager
processes reservation requests from the MTL_RESERVATIONS_INTERFACE table for
creating, updating, transferring, and deleting reservations. The Reservations Manager API
includes the public procedure rsv_interface_manager.
Sales Order Application Program Interface
The Sales Order API is a public API that enables you to do the following:
- Create a sales order in Oracle Inventorys local definition of a sales order
- Update a sales order in Oracle Inventorys local definition of a sales order
- Get a corresponding Oracle Order Management order header identifier given a sales
order identifier
- Get a corresponding sales order identifier given an Order Management order header
identifier
Move Order Application Program Interface
The Move Order API is a public API that enables you to do the following:
- Create a move order header
- Create a move order line
- Process a move order (create or update)
- Lock a move order
- Get a move order for a given header or header identifier
- Process a move order line (cancel or update)
Pick Confirm Application Program Interface
The Pick Confirm API is a public API that enables you to perform pick confirmations on
move order line detail records. To transact the records, the API calls the transaction
processor, which then updates the move order line delivered quantity as well as shipping
and reservation information.
Refer to Practice - Creating an Employee [LAB3553Y]
Refer to Guided Demonstration - Creating a User ID [LAB3554Y]
Refer to Practice - Creating a User [LAB3555Y]
Refer to Practice - Finding a User ID [LAB3556Y]

Refer to Practice - Determining a User's Responsibility [LAB3557Y]
Refer to Practice - Finding Inventory and Master Organization IDs [LAB3558Y]
Refer to Practice - Defining a Subinventory [LAB3559Y]
Refer to Practice - Determining Subinventory Information [LAB356EY]
Refer to Practice - Defining a Subinventory and Locators [LAB355BY]
Refer to Practice - Determining Subinventory and Locator Information
[LAB355CY]
Refer to Guided Demonstration - Defining Item and Cost Information [LAB355EY]
Refer to Practice - Defining Items [LAB355DY]
Refer to Practice - Determining Item Information [LAB355FY]
Refer to Practice - Defining Item Cost Information [LAB3560Y]
Refer to Practice - Determining Item Cost Information [LAB3561Y]
Refer to Practice - Completing a Miscellaneous Receipt [LAB3562Y]
Refer to Practice - Determining Miscellaneous Receipt Information [LAB3563Y]

Inventory Application Program Interfaces
Move Order Admin Application Program Interface:

The Move Order Admin API is a public API that enables you to cancel a move order,
cancel a move order line, close a move order or close a move order line. The Move Order
Admin API includes the public procedures cancel_order, cancel_line, close_order and
close_line.
Line_Details_pub:
The Line Details public procedure releases a single move order line. This API takes in a
move order line and outputs the pick from and putaway to details for that line. These
details are returned in the out parameters in the procedure. The Line_Details_pub public
procedure includes INV_Replenish_Details.Line_Details_Pub.
Quantity Tree Application Interface:
The Quantity Tree API includes the following procedures:
The CLEAR_QUANTITY_CACHE procedure that deletes all quantity trees in memory
and you can use this procedure when you call rollback. Otherwise, the trees in memory
may not be in sync with the data in the corresponding database tables. The
QUERY_QUANTITIES procedure that is used to find the values for quantity
onhand,revervable quantity onhand, quantity reserved, quantity suggested, available to

transact (ATT), and available to reserve (ATR).
The UPDATE_QUANTITIES procedure that changes the quantity in the quantity tree at
the level specified by the input. It returns the quantities at the level after the update. The
quantity updated depends on the quantity type parameter.
The DO_CHECK procedure that checks to determine whether tree updates are still valid.
It should be called before committing quantity updates to the database. There can be
multiple quantity trees for each item and organization.
The QUERY_QUANTITIES procedure is used to find the values for quantity
onhand,reservable quantity onhand, quantity reserved, quantity suggested, available to
transact (ATT), and available to reserve (ATR).
Material Transaction Application Program Interface:
The Inventory Transaction Manager Program is a public API, that enables you to process
transactions from the interface table, mtl_transactions_interface. It also enables you to
process pending transaction from table, Mtl_Material_Transaction_Temp. The API will
process the transactions and create a historical record in mtl_material_transactions and
update on-hand quantity.
Inter-Company Transaction Flow Application Program Interface:
Intercompany Transaction flow API works with the entities Intercompany transaction
flows and Intercompany relations. This API provides the following public procedures for
creating, updating, checking intercompany transaction flows:
CHECK_TRANSACTION_FLOW, CREATE_TRANSACTION_FLOW,
GET_TRANSACTION_FLOW,
UPDATE_TRANSACTION_FLOW,UPDATE_TRANSACTION_FLOW_HEADER,UP
DATE_TRANSACTION_FLOW_LINE.
The API also provides public procedures updating and validating Intercompany relations
which are UPDATE_IC_RELATION,VALIDATE_IC_RELATION_REC.
Category Program Interface:
The Category API supports the CREATE, UPDATE, AND DELETE transaction types on
Categories,Item categories and Valid categories. The Category API has different
procedures to handle the CREATE, UPDATE, or DELETE transaction types and also
defines record CATEGORY_REC_TYPE, which is part of the argument list of most of the
calls to this API.
Item Category Assignment Application Program Interface:
The Item Category Assignment API supports CREATE, DELETE, and UPDATE of item
category assignments. Before you create an assignment, you must first define the item and
category (category_set).

Summary


Inventory Tech Details

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Inventory Tech Details

Hochgeladen von

Copyright:

Verfügbare Formate

Oracle Inventory

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Inventory Organization Structure

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Item Statuses and Attributes

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Life Cycle of a Part

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc

Copyright Oracle, 2007. All rights reserved.

Oracle Inventory 374114190.doc