1. Inventory Overview
The modules typically considered to be included in the Inventory cycle is: Inventory, Order Management and Purchasing. Depending upon the client's manufacturing environment, Oracle Bills of Material and Work in Progress may also be included within the Inventory cycle. The Inventory cycle is fully integrated into the Oracle Financial Applications and the Inventory Modules interface directly with other Oracle modules. This is an illustration of the cross-module integration points:
Within the Inventory cycle, there are a number of potential relevant areas, including:
· Business Setups
o Inventory Module
o Organisations
o Subinventories
o Items
o Costing
· Standing Data Overview
o Item Master
o Item Entry
o Item Costs
o ABC Analysis
|
· Transactions Overview
o Inventory Transfers & Movements
o Inventory Counts
o Open Interfaces
o Period End Procedures
· Inventory Security
· Access and Segregation of Duties
|
Items and several of their attributes (configurations) can be defined either at the "Master" or "Organization" level. If designated as a "Master" level, the item and/or its attribute are the same across all defined organizations. If an attribute or item is defined at the "Organisation" level, each item or attribute can have different values in each organization. This concept will be discussed further in each applicable section.
D. Business Setups Overview
The inventory cycle includes several one-time business setups:
· Inventory Module
· Organisations
· Subinventories
· Items
· Costing
The chart below illustrates how these business setups interface with Inventory standing data and transactions.
1. Inventory Module
1.1. Inventory Key Flexfields
The use of Oracle Inventory module generally requires the use of 4 Inventory-specific key flexfields, as outlined below.
1.1.1. Item Catalogs
Item catalogs partition the Item Master into groups of items that share common characteristics. In order for item catalogs to be created, an Item Catalog key flexfield must be defined. Once this flexfield is created, an item catalog can be created. For more information on item catalogs, refer to the item catalog section of this document.
1.1.2. Item Categories
Since all items must be assigned to a category, the Item Categories Flexfield must be defined. When Oracle Inventory or Purchasing is installed, two item category flexfield structures are seeded, Item Categories and PO Item Category. Multiple item category structures can be defined, with each structure corresponding to a different category grouping scheme. Each item category can then be associated with defined category sets. (Refer to the Category Sets section of this document for more information).
1.1.3. Sales Orders
The Sales Orders Flexfield is a key flexfield used by Oracle Inventory to uniquely identify sales order transactions that Oracle Order Management interfaces to Oracle Inventory. Sales Orders Flexfield should be defined as Order Number, Order Type, and Order Source. This combination guarantees each transaction to Inventory is unique.
1.1.4. Stock Locators
Stock Locators Flexfield capture information about stock locators within inventory. In order to track of specific locators such as aisle, row, bin indicators for items, this flexfield must be configured, and implement locator control must be enabled for each organization. If item location is not used, it is not necessary to set up this flexfield.
1.1.5. System Items
This flexfield, also known as the Item flexfield, defines how item values (identifiers) are structured. The number and order of segments (such as product and product line) can be defined. The Item Flexfield must be configured before items can be defined. In the example below, only one Item Flexfield segment is defined:
1.2. Units of Measure
Units of measure are used by a variety of functions and transactions to express the quantity of items. At least one unit of measure class should be defined. This predefined unit of measure (such as each, dozen, carton) is then used when an item is defined within a particular organisation.
1.3. Planners
In order to track of the names of the parties responsible for planning certain items or groups of items, planners must be defined. Once defined, planners can then be assigned to planning entities or planners can be assigned to items. Material planners or planning entities can be assigned to inventory items at the organisation level.
1.4. Freight Carriers
A freight carrier is a commercial company used for internal transfers between organisations, as well as shipments to and from customers and suppliers. In order to record and report upon freight costs, freight carriers must be defined. In addition, when defining a freight carrier, a general ledger account must be associated with each carrier.
1.5. Inventory Transaction Types
A transaction type is used to classify a particular transaction for reporting and querying purposes. Oracle Inventory also uses transaction types to identify certain transactions to include in historical usage calculations, for ABC analysis or forecasting.
Transaction types come pre-defined when Oracle is installed. However, the client has the option of either updating these pre-defined transaction types, or creating new transaction types. The client can also inactivate transaction types and/or sources and reasons they do not want to utilise.
The transaction types window is used to define additional transaction types to customise transaction entry. A client-defined transaction type is a combination of a user-defined transaction source type, a predefined transaction action, a transaction reasons, and optionally, a shortage message. Transaction types are defined by combining transaction actions and transaction source types.
1.5.1. Transaction Sources
Oracle Inventory pre-defines a list of transaction source types for the client. They can add more source types to this list or update the pre-defined sources. However, they cannot delete those that are pre-defined, and they can only delete those that are user-defined (defined by the client) and not associated with a transaction type.
The client can add source types for miscellaneous transactions, inter-organisation and subinventory transfers, and account transactions. Examples of transaction source types include: Job or Schedule, Account, Account Alias, Inventory, User-defined and Move Order.
1.5.2. Transaction Actions
A transaction action is a generic type of material movement or cost update with no specificity regarding the source of the transaction. Oracle Inventory provides the following transaction actions which cannot be updated or deleted: Issue from stores, Subinventory transfer, Direct organisation transfer, In-transit shipment, Cost update, Receipt into stores, Negative component issue, Negative component return, Staging transfer, WIP assembly scrap, Assembly completion and Assembly return. It is important to note that new transaction actions cannot be created.
1.5.3. Transaction Reasons
A transaction reason is a standard means of classifying or explaining the reason for a transaction. Transaction reasons can be used in all transaction forms with any type of material transaction. Although not required to define Inventory Transaction Types, Transaction Reasons impact the handling of transactions. Oracle Inventory provides transaction reporting and inquiring capabilities by transaction reason. Examples include: “Theft”, “Misplaced items”, and “Damaged items” entered during cycle count or physical inventory. In addition, the client can assign a workflow name and workflow process to a transaction reason.
1.5.4. Shortage Messages
The client can choose to receive an online shortage alert, a workflow-based notification, or both for system-defined and user-defined transaction types that have transaction actions of: Receipt into stores, Intransit receipt, Direct organisation transfer, Assembly completion or Negative component issue.
1.6. Inventory-Related Profile Options
Profile Option Name
|
Setting
|
Comments
|
INV: Override Neg for Backflush
|
Indicates whether backflush transactions can drive the inventory negative even if the inventory organisation parameter Allow Negative Balances is unchecked.
A value of No does not allow backflush transactions to drive on-hand inventory negative even when the inventory organisation parameter Allow Negative Balances is unchecked.
|
Inventory predefines a value of Yes for this profile option upon installation. This profile is updateable at all levels and should be set to No at all defined levels.
|
INV:Inter-Organisation Currency Conversion
|
Indicates the currency conversion for inter-organisation transfers between organisations using different currencies. Available values are:
Corporate: An exchange rate defined to standardise rates for the company. The corporate exchange rate is generally a standard market rate determined by senior financial management for use throughout the organisation.
Spot: An exchange rate entered to perform conversion based on the rate on a specific date. It applies to the immediate delivery of a currency.
User :An exchange rate specified when a foreign currency journal entry is entered.
|
Inventory predefines a value of Corporate for this profile for all levels upon installation. This is the preferred option as it allows foreign exchange rates to be controlled at the corporate level. This profile is updateable at all levels.
|
INV: Intercompany Currency Conversion
|
Indicates the currency conversion for inter-company invoices using different currencies. Available values are:
Corporate: An exchange rate defined to standardise rates for the company. The corporate exchange rate is generally a standard market rate determined by senior financial management for use throughout the organisation.
Spot: An exchange rate entered to perform conversion based on the rate on a specific date. It applies to the immediate delivery of a currency.
User: An exchange rate specified when a foreign currency invoice is entered.
|
Inventory predefines a value of Corporate for this profile upon installation. This is the preferred option as it allows foreign exchange rates to be controlled at the corporate level. The profile is updateable at the Site, Application, and Responsibility levels.
|
INV: RC Requisition Approval
|
Indicates the status of Subinventory Replenishment requisitions created by the replenishment processor. Available values are:
Approved: Requisitions created by the replenishment processor are approved.
Unapproved: Requisitions created by the replenishment processor are not approved.
|
Inventory predefines a value of Approved for this profile for all levels upon installation. If Unapproved is chosen, Subinventory Replenishment requisitions as unapproved can be optionally loaded and the document approval functionality in Oracle Purchasing can be used. This profile is updateable at all levels.
|
INV:Accounting Category Set
|
Indicates the default category set for defining category references the ’Product Line Accounting’ function.
|
This profile is updateable only at the Site level.
|
INV:Item Master Flexfield
|
Indicates which flexfield is used to define items in MTL_SYSTEM_ITEMS.
|
Inventory predefines a value of System Items for this profile for all levels upon installation. This profile is updateable at all levels.
|
INV:Transaction Date Validation:
|
Controls the date a client can enter for transactions. Available values:
Allow date in any open period: Allows entry of a past date if it is in an open period.
Do not allow past date. Does not allow entry of a date before the current date.
Do not allow date in past period. Allows entry of dates in the current period only.
Provide warning when date in past period. Allows entry of dates in prior periods after a warning.
|
Inventory predefines a value of Allow date in any open period for all levels upon installation.
The profile is updateable at the Site, Application, and Responsibility levels.
|
INV: Replenishment Move Order Grouping
|
Enables the client to create only one move order header per request, with each item having its own item. MinMax has been enhanced to permit the optional execution for all subinventories or for a group of subinventories. Available values are:
Organisation: The organisation for which to run the report.
Destination Subinventory: The subinventory for which to run the report.
| |
INV: Move Order Fill & Kill
|
Enables the client to close a partially allocated and transacted replenishment move order line. Available values are:
No: Does not allow cancelling of replenishment move order lines.
Yes: Allows cancelling of move order lines.
|
The default value is No.
|
INV: Intercompany Invoice for Internal
|
Option enables the creation of Intercompany Invoices for Internal Orders.
This profile is used in a concurrent program to create accounts payable, and accounts receivable to decide if Internal Order transactions should be invoiced.
|
The default value is No. This profile option is updateable only at site level.
|
INV: Advanced Pricing for Inter-Org Transfers
|
This profile option determines whether to use advanced pricing engine or customer price list for Inter-Org Transfers.
|
The available values are Yes and No. This profile option is updateable only at the Site level.
|
INV: Allow Count Adjustments to Drive Onhand Negative
|
This is the Profile which controls the option of Allowing Cycle Count Adjustments to Drive Onhand Negative
| |
INV: Always suffix inter-Company AP Invoice number
|
This option appends AP Invoice number with shipping organization Id. (11.5.10.2)
| |
INV: Material Status Support
|
This profile option determines whether material status is enforced. The available values are Yes and No. This profile option is updateable only at the site level.
|
If the installation never uses material status, and set this profile option to No and system performance can improve slightly.
|
INV: Receive shipped Lot quantity
|
This profile option allows receiving the entire transaction quantity in to a single lot in receiving organization even when shipped more than one lot from the shipping organization in inter-org transit.
| |
INV: Summarize consumption releases by Need By Date
|
This profile summarize consumption releases by Need By Date.
| |
INV: Target Preferred Grade
|
Determines whether data for picking and reservations must be filtered to match the preferred grade that is defined on the order line.
|
The available options are Yes and No. This profile option is updateable at all levels.
|
INV: Transaction Reasons Security
|
This profile option enables Transaction Reason Security.
|
The available options are Yes and No. This profile option is updateable only at the site level.
|
INV: Use Backorder Caching
|
This profile option improves performance during pick release by caching backordered items. Receipts that are performed during pick release will not be available for allocation.
|
The available options are Yes and No. This profile option is updateable at all levels.
|
INV: Use Intercompany AR Tax for inter-Company AP
|
This option selects Intercompany AR tax code for intercompany AP. Within Oracle Applications 11.5.10, intercompany invoice gets a tax variance hold due to incorrect rounding of the tax amount. With this profile option, 'INV: Use Intercompany AR Tax for inter-Company AP' decides what tax code to be used; but NOT the tax rate. With this profile option turns on, it will choose Intercompany AR tax code for intercompany AP. (11.5.10.2)
| |
INV:Create Locators in Autonomous Mode
|
This profile value specifies whether the locators should be created in autonomous mode or not. In the past, Inventory Transaction Workers were causing deadlocks when running multiple workers in parallel with dynamic locator segments populated in the interface table.
|
Now, Inventory Transaction Workers would not cause deadlocks when running multiple workers in parallel with dynamic locator segments populated in the interface table, when the below profile is set to Yes. INV:Create Locators in Autonomous Mode. (in 11.5.9)
|
INV:Override Reservation for Backflush
|
This profile option overrides reservation of current allocation for backflush. In the past, even if there are reservations/allocations for the component, backflush transfer will go through if the organization allows negative inventory balances and the profile "INV:Override Rsv for Backflush" is YES A new profile INV_OVERRIDE_RSV_BACKFLUSH' has been created in 11.5.10.2. This profile option will show be shown as "INV:Override Reservation for Backflush".If this profile is set to YES, then a backflush transaction which consumes existing reservation is allowed. (11.5.10.2)
| |
INV:Validate Returned Lot
|
This profile option determines whether a component lot that is returned from WIP should be validated against lots that are issued to the same job.
|
The available options are Yes and No. This profile option is updateable only at site level.
|
INV:Validate Returned Serial
|
This profile option determines whether component serials that are returned from WIP should be validated against serials that are issued to the same job.
|
The available options are Yes and No. This profile option is updateable only at site level.
|
INV: Use new Trx.Mngr. for processing
|
There are two transaction managers in inventory. There is the option to user either for transactions processed in the background. Transactions processed online or with immediate concurrent always as Inventory recommends the new manager. If it is set to No, Inventory uses the old transaction manager.
|
The setting of this option does not affect certain transactions such as WIP and receiving transactions. All mobile WIP and VMI Receiving transactions use the new transaction manager. All desktop WIP and non–VMI Receiving transactions use the old transaction manager. This profile is updateable at all levels.
|
1.7. Control Considerations
1.7.1. Business Process Variables
o Companies can define Transaction Types in many different ways, in order to meet specific business requirements. If incorrect transaction types have been defined by management and are not used in a structured way for inventory transactions, transactions may not process as a user expects due to setup differing from the name of the transaction type.
1.7.2. Control Dependencies
o The Sales Order flexfield must be defined before placing demand, making reservations, or booking orders in Oracle Order Management.
o Oracle Assets and Oracle Order Management also have access to the Units of Measure window. UOM should not be entered via Oracle Assets or Oracle Order Management unless these modules are used without Oracle Inventory or Oracle Purchasing. Because item definition is completed in these modules, UOM should be defined via Purchasing or Inventory modules wherever possible.
1.7.3. Control Limitations
o None
1.7.4. Testing Notes
o System reports used to support Financial Statements may need to be assessed by management in order to promote good and reliable information. These reports rely on transaction type setups to report inventory information correctly.
1.7.5. Multi-Org Access Control
o Users are able to easily inquire about, plan for and receive expected shipments against purchase orders or requisitions or RMAs originating in multiple operating units without needing to close windows and change responsibilities.
1.7.6. Dual Unit of Measure Control
o It enables users to transact inventory in two unrelated units of measure where the conversion between the measures varies from lot to lot or from one transaction to the next.
1.7.7. Material Status Control
o Enables users to assign a material status to the material in an inventory lot, serial, sub-inventory, or locator and to use that status to restrict transactions. This functionality was previously available to Oracle Warehouse Management only.
2. Organisations
In Oracle, organisations are a required component of employee assignments and inventory, order management and purchasing. A company may define as many organisations as needed within a business group. Within the Oracle application, Organisations can be created for various reasons including:
· Business groups
· External organisations (for example, tax offices, insurance carriers, disability organisations, benefit carriers, or recruitment agencies)
· Internal organisations (for example, departments, sections or cost centers/other companies)
· GREs (selected legislations only)
Within Oracle Inventory, 2 organizations are often defined, Inventory and Cost Organizations.
2.1. Inventory Organizations
An organization must have the "Inventory Organization" classification enabled in order for the Organization to be used as an Inventory Organization. Within Inventory, organisations can be defined as a business unit such as a plant, warehouse, division, department, etc. For each Inventory Organisation, certain configurations must be defined, including Accounting, Organisation and Receiving Parameters, as outlined in the sections below.
In Oracle Manufacturing, each inventory organisation must have a cost structure defined.
The Copy Inventory Organization feature is enhanced and now allows users to copy existing inventory structures to new ones.
2.2. Costing Organizations
The organisation that holds the costs is called the cost master organisation. Costs are maintained within the cost master organisation. The cost master organisation can be the same organization as the item master or can be a manufacturing organisation using Work in Process (WIP).
If costs are to be shared across organizations, the two item attribute controls, Costing Enabled and Inventory Asset Value determine whether costs are shared across organizations. If the client plans to share costs across standard costing organisations, the attributes' control level must be set to the item level. Costs across standard cost organisations can be shared as long as the child cost organisations have not enabled WIP.
2.3. Accounting Organization
The client can define the Primary Ledgers, Secondary Ledgers, , name of the Legal Entity, Operating Unit of the Organization, Reporting Currencies, and Accounting Rules in the Subledgers.
2.4 Organisation Parameters
Organisation Parameters are a set of controls, default options, and default account numbers that determine how an Inventory organisation functions. They include 6 different sets of configurations, as outlined below.
2.4.1. Inventory Parameters
Inventory Parameters
|
Setting
|
Comments
|
Item Master Organisation
|
Each inventory must be associated with an Item Master.
| |
Calendar
|
Assigns a calendar to the Organization.
|
Refer to the GL Practice Aid for more information on Calendars.
|
Process Enabled checkbox
|
Configuration is enabled if the inventory organisation is a Process Manufacturing organisation.
| |
Demand Classes
|
Demand classes segregate scheduled demand and production into groups, allowing the client to track and consume those groups independently.
|
Oracle Master Scheduling/MRP and Oracle Supply Chain Planning uses this demand class during forecast consumption, and shipment and production relief.
|
Move Order Timeout Period
|
Specifies the number of days a move order requisition can wait for approval.
|
The workflow approval process sends a notification to the item planner when a move order requisition requires approval. After the first timeout period, if the recipient has not approved or rejected the order, a reminder notice is sent. After the second timeout period, the order is automatically approved or rejected, depending on the Move Order Timeout Action value.
|
Move Order Timeout Action
|
Determines the process flow if requisitions are not approved within a specified period.
Approve automatically: After the second timeout period, move order requisitions are automatically approved.
Reject automatically: After the second timeout period, move order requisitions are automatically rejected,
|
Select this option and set the Move Order Timeout Period to 0 if the move order approval process wants to be bypassed and automatically approved move order requisitions.
|
Locator Control
|
An Oracle Manufacturing technique for enforcing use of locators during a material transaction. Values include:
· None: Inventory transactions within this organisation do not require locator information.
· Prespecified only: Inventory transactions within this organisation require a valid, predefined locator for each item.
· Dynamic entry allowed: Inventory transactions within this organisation require a locator for each item. The client can choose a valid, predefined locator, or define a locator dynamically at the time of transaction.
· Determined at subinventory level: Inventory transactions use locator control information that can be defined at the subinventory level.
| |
Allow Negative Balances
|
Determines whether inventory transactions can drive the inventory balance of an item negative.
|
If insufficient quantity on hand exists in a supply subinventory to satisfy backflush demand, Oracle Work in Process forces the supply subinventory balance negative, ignoring this option setting.
|
Capacity
|
The Inventory's total maximum load weight, maximum volume, and their units of measure.
|
2.4.2. Costing Info
Costing Parameters
|
Setting
|
Comments
|
Costing Method
|
One method has to be chosen, out of two options:
· STANDARD: This type of costing is for material and resource costs and is the default for Oracle Inventory.
· AVERAGE: This type of costing is for material costs.
|
For more information on costing, refer to the costing section of this document.
|
Project Cost Collection Enabled
|
If the Project Cost Collection Enabled check box is selected, and the Enable Project References check box, located in the Project Manufacturing Parameters is also selected, the cost collector process can transfer costs to project accounting.
| |
Rates Cost Type
|
When the Costing Method is Average, the Average Rates Cost Type can be entered.
| |
Transfer to GL
|
This indicates if all Inventory transactions are transferred in detail to the General Ledger.
In Detail: all transactions and all accounting lines are transferred to the General Ledger.
Summary: all transactions and the total of each general ledger accounting lines are transferred to the general ledger.
None: No accounting distributions are transferred to the general ledger.
|
This should not be set to 'None'. The purpose of the 'None' option was so that accounting distributions are not created for Perpetual Accounting if Periodic Accounting is used. The 'None' option is not to be used for eliminating accounting distributions all together.
|
Cost cut-off date
|
All transactions on or later than this date will not be costed. The default time is the first day of the instance's installation, although another time can be chosen optionally.
If blank, all available transactions will be costed.
If a date is entered, all transactions prior to this date will be costed.
|
For inter-organisation transfers, using standard costing, a receiving organisation will not cost a receipt if the sending organisation did not already cost the transaction.
The standard cost update process can be performed on the cost cutoff date. Cost processing can be restarted by changing the cutoff date to blank, or a future date.
|
Valuation Accounts
|
Accounts are defined which are used the value the goods held within the inventory, including:
Material: An asset account that tracks material cost. For average costing, this account holds inventory and in-transit values.
Material Overhead: An asset account that tracks material overhead cost.
Resource: An asset account that tracks resource cost.
Overhead: An asset account that tracks resource and outside processing overheads.
Outside processing: An asset account that tracks outside processing cost.
Expense: The expense account used when tracking a non-asset item.
|
These values default from the organization's cost group, but can be overwritten for each organization.
Once transactions are performed against the material account, it cannot be changed.
|
2.4.3. Revision, Lot, Serial
Revision/Lot/Serial Parameters
|
Setting
|
Comments
|
Starting Revision
|
A starting revision needs to be entered, and serves as the default for each new item.
| |
Lot Control - Uniqueness
|
One of the 2 values must be selected:
· Across items: Enforces unique lot numbers for items across all organisations.
· None: Unique lot numbers are not required.
| |
Lot Control -Generation
|
One of the 3 values must be selected:
· User-defined: Configuration allows users to define lot numbers when receiving items.
· At organisation level: Configuration drives the system to automatically generate lot numbers for the items when they are received. The system auto-creates the lot numbers using values entered in the Prefix, Zero Pad Suffix, and Total Length fields.
· At item level: Configuration allows users to enter starting lot number prefix and the starting lot number when the item is defined.
| |
Lot Control - Zero Pad Suffix:
|
Indicates whether to add zeroes to right-justify the numeric portion of lot.
| |
Lot Control - Prefix
|
An alphanumeric lot number prefix can be defined to use for system-generated lot numbers when generation is at the organisation level.
| |
Lot Control - Total Length
|
The maximum length for lot numbers can be defined.
|
If Oracle Work in Process is used and the WIP parameter is set to default the lot number based on inventory rules, then WIP validates the length of the lot number against the length that is defined in this field.
|
Serial Control - Uniqueness
|
One of the 3 values must be selected:
· Within organisation: Enforces unique serial numbers within the current organisation.
· Within inventory items: Enforces unique serial numbers for inventory items.
· Across organisations: Enforces unique serial numbers throughout all organisations.
| |
Serial Control - Generation
|
One of the 2 values must be selected:
· At organisation level: Defines the starting prefix and serial number information for items using the information the client enters in the following fields of this window.
· At item level: Defines the starting serial number prefix and the starting serial number when the client defines the item.
| |
Serial Control - Allocate Serial Numbers
|
Indicates whether the system will suggest serial numbers as part of the move order line allocating process. One of the 3 values must be selected:
· Yes
· No
· Yes, User Defined
|
If the "Yes, User Defined" option is enabled, a user must manually enter the serial numbers in order to transact the move order.
|
Genealogy Enhancements
|
In order to support increased product composition visibility in Oracle Inventory, the lot and serial genealogy inquiries have been consolidated. In addition, for Oracle Discrete manufacturing users, operators performing the WIP issue transactions can tie their component lot and/ or serial numbers with a parent assembly.
| |
Enhanced Lot Transactions
|
In order to support both lot and serial controlled items in some business processes, Oracle Inventory's lot split, merge and translate transactions can now be performed on items that are both lot and serial controlled.
| |
Support for Indivisible Lots
|
In this feature, the item attribute will indicate to the system that, during reservations and allocation, the system must allocate the entire lot quantity in a given location or none at all.
|
2.4.4. ATP, Pick, Item-Sourcing Parameters
ATP, Pick, Item-Sourcing Parameters
|
Setting
|
Comments
|
ATP Default - Rule
|
ATP rules define the options used to calculate the available to promise quantity of an item. A default ATP rule must be selected.
|
If the client uses Oracle Order Management, the default is the ATP rule for the Master organisation.
|
Picking Defaults - Rule
|
This value is the default picking rule used within Order Management to define the priority in which items are picked.
|
This rule will not be employed in a WMS enabled organisation. The WMS picking rules will be used.
|
Picking Defaults - Subinventory Order
|
This value indicates the priority with which the client picks items from a subinventory, relative to another subinventory.
|
The value that is entered here displays as the default when a subinventory is defined.
|
Picking Defaults - Locator Order
|
This value indicates the priority with which the client picks items from a locator, relative to another locator.
|
The value that is entered here displays as the default when the client defines a locator.
A picking order of 1 means that order management functions pick items from that subinventory or locator before others with a higher number (such as 2, 3, and so on).
|
Picking Defaults - Pick Confirmation Required
|
If the configuration is enabled, pick confirmation will occur automatically. If disabled, pickers will be required to manually pick confirm the item.
|
In WMS (Warehouse Management System)-enabled organizations, this configuration should be disabled so that picking tasks can be tasked to users.
|
Item Sourcing Detail - Type
|
One of 3 source types for item replenishment must be defined:
· Inventory: Replenish items internally from another subinventory in the same organisation or another organisation.
· Supplier: Replenish items externally, from a supplier the client specifies in Oracle Purchasing.
· None: No default source for item replenishment.
| |
Item Sourcing Detail - Organisation
|
If the Item Sourcing Detail Type value is Inventory, a sourcing organization can be defined.
|
If the Item Sourcing Detail Type value is Supplier, this value is disabled.
|
Item Sourcing Detail - Subinventory
|
If the Item Sourcing Detail's Type value is Inventory, a sourcing subinventory organization can be defined.
|
If the Item Sourcing Detail Type value is Supplier, this value is disabled.
|
2.4.5. Inter-Org Information
Inter-Org Information Parameters
|
Setting
|
Comments
|
Inter-organisation Transfer Charge
|
One of 4 must be selected:
· None: Do not add transfer charges to a material transfer between organisations.
· Predefined percent: Automatically add a predefined percent of the transaction value when the client performs the inter-organisation transfer.
· Requested value: Enter the discrete value to add when the client performs the inter-organisation transfer.
· Requested percent: Enter the discrete percentage of the transfer value to add when the client performs the inter-organisation transfer.
|
If Predefined percent is selected in the Inter-Organisation Transfer Charge field, a percentage value needs to be added to add to a material transfer.
|
Inter-organisation Transfer Accounts
|
Default inter-organisation cost accounts are used as defaults when defining shipping information in the Inter-Organisation Shipping Networks window. They include:
· Transfer Credit: The default general ledger account (usually an expense account) used to collect transfer charges when this organisation is the shipping organisation.
· Purchase Price Variance: The default general ledger account (usually an expense account) used to collect the purchase price variance for inter-organisation receipts into standard cost organisations.
· Receivable: The default general ledger account (usually an asset account) used as an inter-organisation clearing account when this organisation is the shipping organisation.
· Payable: The default general ledger account used as an inter-organisation clearing account (usually a liability account) when this organisation is the receiving organisation.
· Intransit Inventory: The default general ledger account (usually an asset account) used to hold intransit inventory value.
|
For average cost organisations, the Intransit Inventory account is the default material account.
|
2.4.6. Other Accounts
Other Accounts Parameters
|
Setting
|
Comments
|
Receiving Accounts
|
Receiving accounts are used to record receiving transactions:
· Purchase Price Variance: The variance account used record differences between purchase order price and standard cost.
· Invoice Price Variance: The variance account used by Payables to record differences between purchase order price and invoice price.
· Inventory AP Accrual: The liability account that represents all inventory purchase order receipts that are not matched to Payables invoices.
· Encumbrance: An expense account used to recognise the reservation of funds when a purchase order is approved.
|
Purchase Price Variance account is not used with the average cost method.
The Invoice Price Variance account is usually defined as an expense account.
|
Profit and Loss Accounts
|
Additional accounts are defined when creating the organisation, including:
· Sales: The income statement account that tracks the default revenue account.
· Cost of Goods Sold: The income statement account that tracks the default cost of goods sold account.
| |
Project Clearance Account
|
When performing miscellaneous issues to capital projects, the project clearance account is used to post the distributions.
| |
Cost Variance Account
|
When average costing is enabled, this account is used to cost negative quantity balances caused by issuing inventory before receipts.
|
2.5. Control Considerations
2.5.1. Business Process Variables
o All Oracle installed applications share the information entered in the Organisation window, which is accessible via HR, Inventory, Order Management, and Purchasing Modules. Therefore organisation names should be unique within a business group, and business group names should be unique across the applications network.
o Although it is possible to create two organisations with the same name in different business groups, this is not recommended. This is because a profile option exists within the HR module (HR: Cross business group profile option) that allows sharing of certain information across all business groups. (Refer to HR practice aid for further details on organisations setup).
o All account combinations will differ per client. However they should be assigned the correct account type classification, (For example, a 'Material' or 'Material inventory' GL account should be defined in the Material account field, and an asset account should not be used in the Expense Valuation account field).
o Under average costing, Valuation accounts (except for Expense) are used for subinventory transactions and cannot be updated.
o For standard costing, only the Purchase Price Variance, Inventory A/P Accrual, Invoice Price Variance, Expense, Sales and Cost of Goods Sold accounts are required. The other accounts are used as defaults.
o For average costing, only the Material, Average Cost Variance, Inventory A/P Accrual, Invoice Price Variance, Expense, Sales and Cost of Goods Sold accounts are required. The other accounts are used as defaults or are not required.
2.5.2. Control Dependencies
o None
2.5.3. Control Limitations
o Under standard costing, valuation accounts are defaulted when subinventories are defined and can be overridden.
o The Move Order approval process can be overridden (automatically approving move order requisitions) by setting to 0 days for the “Move Order Timeout Period” and select Automatically Approve for the Move Order Timeout Action. This can also be done by assigning the planner who approves move order lines to the item or the organisation.
2.5.4. Testing Notes
o Clients should have a valid reason for allowing negative balances, as negative quantities can not be physically counted & adjustment processes should ensure reasons for negatives are resolved prior to physical counting and/or period end.
3. Subinventories
Subinventories are unique physical or logical separations of material inventory, such as raw inventory, finished goods, or defective material. All material within an organisation is held in a subinventory therefore; at least one subinventory should be defined. For each subinventory, header, main, and account parameters must be defined.
3.1. Subinventory Setup - Header
Header Parameters
|
Setting
|
Comments
|
Name
|
Defines a unique alphanumeric name for the subinventory.
| |
Status
|
Indicate the material status of this subinventory (for example, active, QC hold, quarantine). This controls whether the subinventory's materials are transactable.
|
This status is not overridden by the status of any locator, lot or serial within this subinventory. This field is used if the client has Oracle Warehouse Management installed.
|
Default Cost Group
|
Indicates the default cost group for this subinventory.
|
This feature is available if the client has Oracle Warehouse Management installed, and they are working with a WMS enabled organisation.
If the cost group assignment rules fail to identify a cost group for newly received material, this cost group will be assigned. This cost group will remain with the material, even through subinventory transfers, until the client performs a cost group change transaction.
|
Type
|
Indicate the type of subinventory, Storage or Receiving.
|
3.2. Subinventory Setup - Main
The following may be defined when creating subinventories:
Main Parameters
|
Setting
|
Comments
|
Quantity Tracked
|
Indicates whether each transaction for this subinventory updates the quantity on hand for the subinventory.
|
If disabled, on-hand balances are not maintained and they cannot enable the Asset Inventory, Include in ATP, Reservable, or Nettable options.
This value can only be updated if there is no on-hand quantity within the subinventory.
|
Asset Subinventory
|
Indicates whether to maintain the value of this subinventory on the balance sheet.
|
This value can only be updated if there is no on-hand quantity within the subinventory.
|
Depreciable
|
Indicates whether this subinventory is depreciable.
| |
Include in ATP
|
Indicates whether to include items in this subinventory in ATP calculations.
| |
Allow Reservation
|
Indicate whether to include this subinventory when the client performs available-to-reserve calculations.
| |
Nettable
|
Indicates whether the planning process uses the on-hand balance of these subinventory items as available inventory.
| |
Enable PAR Level Planning
|
Indicate if Periodic Automatic Replenishment (PAR) is enabled.
|
If enabled they cannot perform min-max planning for this subinventory.
|
Locator Control
|
One of 4 must be selected:
· None: Inventory transactions within this subinventory do not require locator information.
· Prespecified: Inventory transactions within this subinventory require the client to enter a valid predefined locator for each item.
· Dynamic entry: Inventory transactions within this subinventory require the client to enter a locator for each item. The client may choose a valid predefined locator, or define a locator dynamically at the time of transaction.
· Item level: Inventory transactions use locator control information that the client defines at the item level.
|
The client can select an option only the Locator Control field in the Organisation Parameters window is set to "subinventory".
This value can only be updated if there is no on-hand quantity within the subinventory.
.
|
Default Locator Status
|
Indicate the default locator status of the locators in this subinventory.
|
This feature is available only if the client has Oracle Warehouse Management installed.
|
Picking Order
|
Enter a picking order value for use by Oracle Warehouse Management to sequence picking tasks. This value indicates the priority with which the client picks items from this subinventory, relative to another subinventory.
|
If the client has Oracle Warehouse Management installed, this field determines the picking path through the warehouse and not the order in which material is allocated for a sales order.
A picking order of 1 means that order management functions pick items from that subinventory or locator before others with a higher number (such as 2).
|
Dropping Order
|
Enter a numeric dropping order to indicate the priority for dropping items in this locator relative to another locator.
|
Oracle Warehouse Management uses this value to sequence tasks.
|
Inactive On
|
Optionally, enter an inactive date for the subinventory.
|
Before a subinventory is disabled, no open jobs or schedules within Oracle Work in Process and no active bills in Oracle Bills of Material should exist.
|
Location
|
Optionally, enter a location for the subinventory.
| |
Picking UOM
|
Indicate the picking unit of measure used to store material in this subinventory. This value is used by the WMS rules engine to divide picks across subinventories in the warehouse.
|
This feature is available if the client has Oracle Warehouse Management installed, and they are working with a WMS enabled organisation.
|
Default Replenishment Count Type
|
This field defaults the default count type on the Replenishment Lines window
· Order Maximum
· Order Quantity
|
It does not affect existing Default Count Type headers.
|
Lead Times - Pre-Processing
|
Optionally, enter a pre-processing lead time for items in this subinventory.
|
This lead time is used when the client uses min-max planning at the subinventory level.
|
Lead Times - Processing
|
Optionally, enter a processing lead time for items in this subinventory.
|
This lead time is used when the client uses min-max planning at the subinventory level.
|
Lead Times - Post-Processing
|
Optionally, enter a post-processing lead time for items in this subinventory.
|
This lead time is used when the client uses min-max planning at the subinventory level.
|
Sourcing - Type
|
One of 3 source types for item replenishment must be defined:
· Inventory: Replenish items internally, from another organisation.
· Supplier: Replenish items externally, from a supplier the client specifies in Oracle Purchasing.
· Subinventory: Replenish items internally, from another subinventory in the same inventory organisation.
| |
Sourcing - Organisation
|
Select the organisation used to replenish items in this subinventory.
|
The client must enter a value in this field if they entered Inventory in the sourcingType field. The organisation they select must have a shipping network defined.
|
Sourcing - Subinventory
|
Select the subinventory used to replenish items in this subinventory.
|
The client must enter a value in this field if they entered their current organisation in the sourcing Organisation field.
|
3.3. Subinventory Setup - Accounts
Accounts Parameters
|
Setting
|
Comments
|
Subinventory Accounts
|
Accounts are defined when setting up subinventories, including:
· Material: A general ledger account (usually an asset account) to accumulate material costs for items received into this subinventory.
· Outside Processing: A general ledger account (usually an asset account) to accumulate outside processing costs for this subinventory.
· Material Overhead: A general ledger account (usually an asset account) to accumulate material overhead or burden costs for this subinventory.
· Overhead: A general ledger account (usually an asset account) to accumulate resource or department overhead costs for this subinventory.
· Resource: A general ledger account (usually an asset account) to accumulate resource costs for this subinventory.
· Expense: A general ledger account to accumulate expenses for this subinventory. For expense subinventories, this account is charged when the client receives any item. For asset subinventories, this account is charged when they receive an expense item.
· Encumbrance: A general ledger account to hold the value of encumbrances against items in this subinventory. This account is used for purchase order receipts and returns.
|
The default values for these accounts are the accounts assigned for the subinventory's organization.
When using average costing, valuation accounts can be entered, but they are not used. Average costing uses only the Expense and Encumbrance accounts. When using standard costing, and Oracle Bills of Material is installed, all asset accounts are required. When using standard costing and Oracle Bills of Material is not installed, only entering the Material and Material Overhead accounts is required.
The Encumbrance account is used only in conjunction with Oracle Purchasing.
|
4. Items
Items are important as for example, they may be set up with accounting rules, which affect revenue recognition. Also, the settings at the Item level override any parameters set at the Inventory Organization level. Before a physical item can be entered into Oracle Inventory, a number of configurations must be defined. These include Default Category Sets, Categories, Category Sets, Item Catalogs, Item Attribute Controls, and Statuses.
4.1. Default Category Sets
Upon installation of Oracle Inventory, default category sets are created to each of the following functional areas: Inventory, Purchasing, Order Management, Costing, Engineering, and Planning. Inventory makes the default category set mandatory for all items defined for use by a functional area. Default category sets are required so that each functional area has at least one category set that contains all items in that functional area. These defined values are utilized by other configurations to drive item controls, costing and accounting.
When entering an item, the item's "Item Defining Attribute" can be enabled. Once this configuration is enabled, the item is then available for use in the associated functional area. The following table presents item defining attributes and their functional relationship:
Functional Area
|
Item Defining Attribute
|
Enabling Value
|
Inventory
|
Inventory Item
|
Yes
|
Purchasing
|
Purchased or
|
Yes
|
Internal Ordered Item
|
Yes
| |
Master Scheduling/ MRP
|
MRP Planning Method
|
MRP Planning, MPS Planning
|
Cost Management
|
Costing Enabled
|
Yes
|
Engineering
|
Engineering Item
|
Yes
|
Order Management
|
Customer Ordered Item
|
Yes
|
Service
|
Support Service, or
|
Yes
|
Serviceable Product
|
Yes
|
Refer to the Item Attribute Controls section for more information on Item Defining Attributes.
4.2. Categories
Categories, also known as Category Codes, are codes used to group items with similar characteristics, such as plastics, metals, or glass items. Categories must be defined, as all items must be assigned to a category.
4.3. Category Accounting
Once Categories are defined, General Ledger accounts must be assigned for each category within a subinventory. These GL accounts include the Material, Material Overhead, Overhead, Resource, Outside Processing and Expense accounts, as noted below.
4.4. Category Sets
Category sets are used to group categories for various reports and programs. In addition to the category set Inventory, which is seeded when the client installs Oracle Inventory, the client can also create other category sets such as John's Priority or Jane's Priority. Category sets can be controlled at the Master or Organization Level. Categories can belong to multiple category sets, and each category set may be used as a means to develop custom lists of items on which to report and sort.
4.5. Item Catalogs
When defining an item catalog, distinct item catalog groups are defined. Each group has unique characteristics (called descriptive elements) that completely describe items belonging to the group. For example, an item catalog group called Computer could have a descriptive element called Processing Speed. Possible values for Processing Speed might be 100MHZ, 133MHZ, and so on. Items are then assigned to a specific item catalog.
4.6. Item Attribute Controls
Item attributes are the collection of information about an item. Using the Item Attribute Controls window, the client can designate whether an item attribute is defined/maintained at the Master level or the Organisation level. The control level they define for an attribute applies to all items. Defining attribute controls does not determine the value of an attribute, only the level at which it is controlled. The client assigns a value to the attributes when they define an item.
Attributes at the Master level are the same across all organisations, giving the client centralised control over the values assigned. If an attribute is maintained at the Organisation level, they can have different attribute values in each organisation the item is assigned to. For example, the client can define and maintain an item’s unit of measure at the Master level. This means that the unit of measure is always the same for the item, no matter in which organisation they assign the item. Or, the client can designate that an item’s unit of measure is maintained at the Organisation level. This means that each organisation they assign the item to can have a different unit of measure for the item.
There are several steps to defining Item Attribute Controls:
Group Name: Displays the name for a group of attributes. Attributes are grouped by function, such as Main, Inventory, and Receiving. When the client defines or updates items, defines templates, or views item attributes, they can display the attributes for a particular group.
Control Level
Master Level: Define and maintain this attribute at the Master level. For the same item, the values of this attribute are identical across all organisations.
Org Level: Define and maintain this attribute at the Organisation level. For the same item, each organisation may define a different value for this attribute.
Status Setting
Defaults Value: Value of this attribute, as defined by the status code, defaults when the client assigns the status to an item. They can change this default value.
Not Used: Use neither default nor status control.
Sets Value: Value of this attribute, as defined by the status code, defaults when the client assigns the status to an item. Once assigned, they cannot change the default.
4.7. Item Status and Status Attributes
When an item is defined, the item's status (active, production, obsolete, inactive, for example), provides default values for certain item attributes. These specific attributes, called Status Attributes, control the functionality of an item. The following Status Attributes can be defined:
Status Attribute
|
Description
|
BOM Allowed
|
A bill of material can be created for the item.
|
Build in WIP
|
The item can be built on a discrete job, and/or repetitive schedule.
|
Customer Orders Enabled
|
The item can be utilized on a sales order.
|
Internal Orders Enabled
|
The item can be used when creating an internal sales order.
|
Invoice Enabled
|
The item can be used when creating an invoice.
|
Transactable
|
The item can be transacted in Oracle Inventory, Oracle Order Management, Oracle Purchasing and Oracle Work in Process.
|
Purchasable
|
The item can be used on a purchase order.
|
Stockable
|
The item can be stocked in an asset inventory.
|
Associated with each status attribute is a Status Setting option. This option determines whether a status attribute value is not updatable, defaulted and updatable, or not used when an item is defined. Certain attributes should not be updatable for certain statuses. For example, when defining an 'inactive' status code, all status attributes should be disabled, and for each status attribute, its usage should be set to not updatable.
4.8. Control Considerations
4.8.1. Business Process Variables
o Status codes defined should have their attributes established in such a way that it will cause the desired effect once the item status is applied. In the least a status code of 'Active' and 'Inactive' would be expected, with all attributes being enabled for 'Active' status and all attributes being disabled for 'Inactive'.
o When the values for a status are updated, all items to which it is assigned are also updated.
o The client may change a functional area's default category set under certain conditions. They should ensure that every item within the functional area belongs to the new default category set (which replaces the existing default category set). If the item defining attribute of the functional area is controlled at the Organisation level then the new default category set should also be controlled at the Organisation level.
4.8.2. Control Dependencies
o For each purchasing category, a valid category set must be defined before transactions can be entered into Oracle Purchasing.
4.8.3. Control Limitations
o None
4.8.4. Testing Notes
o None
5. Costing
There are several parameters that must be set in order operate, process and control costing within Oracle Inventory. The following sections discuss the required system parameters.
5.1. Cost Types
A cost type is a set of costs (uniquely identified by name) used for historical, current and future costs, as well as for simulation purposes. Cost Types must be defined before item costs can be entered. Two cost types are predefined, Frozen (for standard costs) and Average (for average costing). Each cost type has its own set of cost controls. The following key values can be defined for each cost type:
Default Cost Type: Reflects the current organisation’s costing method, either Frozen or Average.
Multi-Org: If enabled, this cost type is shared with other organisations. Note the only the cost type name is shared and not the costs. If disabled, this cost type name is only available to the inventory organisation that creates it.
Allow Updates: If enabled, this cost type can be changed by processes such as mass edits, copy cost information, cost rollup, and cost update. To freeze the cost information in this cost type, disable Allow Updates. Even if updates are not allowed, this cost type can be used to report, inquire, and update Frozen costs. If Multi–Org is checked, Allow Updates is disabled.
In a manufacturing average costing organization, two costs types are required for inventory valuation and transaction costing, the Average cost type and a user-defined Average Rates cost type. These two cost types are defined as follows:
Average: This cost type holds the current average unit cost of items on hand, and is used to value transactions such as issues and transfers. This cost type is seeded and does not have to be defined.
Average Rates: This cost type holds any user-defined costs used to in costing transactions.
5.2. Cost Groups
A Cost Group (also known as a project cost group) is a collection of valuation accounts used to group items with similar GL accounts. If the Project Cost Collection Enabled parameter is defined for the Inventory Organisation, cost groups can be utilized. The organisation’s default cost group is seeded if the client installs Cost Management. For each cost group, five elemental subinventory valuation accounts must be defined, including:
Valuation Account
|
Setting
|
Material:
|
A general ledger account to accumulate material costs for this cost group. This is usually an asset account.
|
Material Overhead
|
A general ledger account to accumulate material overhead or burden costs for this cost group. This is usually an asset account.
|
Resource:
|
A general ledger account to accumulate resource costs for this cost group. This is usually an asset account.
|
Outside Processing:
|
A general ledger account to accumulate outside processing costs for this cost group. This is usually an asset account.
|
Overhead:
|
A general ledger account to accumulate resource overhead or department overhead costs for this cost group. This is usually an asset account.
|
Average Cost Variance:
|
A general ledger account to accumulate the balances that may occur when transactions are processed for an item whose on-hand inventory is negative. This account represents the inventory valuation error caused by issuing inventory before receiving it.
|
These values default into the organization's cost group, but can be overwritten for each organisation. WIP accounting classes can also be defined with a project cost group. This association defines which WIP accounting classes are valid for use with the project or projects belonging to this cost group.
5.3. Activities
Activities are actions or tasks performed that uses a resource or incurs a cost. Activities may be directly related to building items, such as runtime or setup time; or they may be indirect, such as purchase order generation, payroll, and engineering activities. Activities can be used to assign indirect costs to items based upon the effort expended to obtain or produce the item, rather than as a percentage of a direct cost or an amount per item. The goal of activity based cost accounting is to accurately identify product costs, especially overhead costs.
For each defined activity, 3 fields are generally defined.
Activity/Description: A description of the activity.
Multi Org: If this configuration is disabled, the activity name is only available to the organization that creates it. If enabled, only the activity name is shared, not the activity across organizations.
Default Basis: Default basis is the method used to charge a transaction or apply product costs. This value is defaulted into the sub-element when defining item costs. One of 3 values should be selected:
o Activity: Used to apply activity costs to items.
o Item: Used to earn and apply item costs for all subelements.
o Lot: Used to earn and apply lot costs for all subelements.
In addition, a cost can be associated with an activity. If the activity is to be costed, a cost type has to be associated with the activity. For more information on Sub-elements, refer to the subelement section below.
5.4. Cost Elements
Product costs are the sum of their elemental costs. Oracle has five predefined, seeded cost elements. They are:
Element
|
Element Description
|
Material
|
The raw material/component cost at the lowest level of the bill of material determined from the unit cost of the component item.
|
Material Overhead
|
The overhead cost of material, calculated as a percentage of the total cost, or as a fixed charge per item, lot, or activity.
|
Overhead
|
The overhead cost of resource and outside processing, calculated as a percentage of the resource or outside processing cost, as a fixed amount per resource unit, or as a fixed charge per item or lot passing through an operation. Overhead is used as a means to allocate department costs or activities.
|
Resource
|
Direct costs, such as people (labour), machines, space, or miscellaneous charges, required to manufacture products.
|
Outside Processing
|
This is the cost of outside processing purchased from a supplier. Outside processing may be a fixed charge per item or lot processed, a fixed amount per outside processing resource unit, or the standard resource rate times the standard units on the routing operation.
|
5.5. Sub Elements
Each cost element must be associated with one or more sub-elements. Sub-elements can be used as smaller classifications of the cost elements. As many sub-elements as needed can be created. A common configuration found in sub-elements is the Basis Type. Basis types determine how costs are assigned to the item. Basis item values include:
Lot: Used by all 5 sub-elements. For material and material overhead sub-elements, lot is used to assign a fixed lot charge to items or operations. The cost per item is calculated by dividing the fixed cost by the item's standard lot size for material and material overhead sub-elements. For a resource, outside processing, or overhead sub-elements, the cost per item is calculated by dividing the fixed cost by the standard lot quantity moved through the operation.
Item: Used with material and material overhead sub-elements to assign a fixed amount per item, generally for purchased components. Used with resource, outside processing and overhead sub-elements to charge a fixed amount per item moved through an operation.
Resource Value: Used with the overhead sub-element only and usually expressed as a rate. It applies overhead to an item, based on the resource value earned in the routing operation. The overhead calculation is based on resource value: resource value earned in the operation X overhead rate.
Resource Units: Used with the overhead sub-element only. Used to allocate overhead to an item, based on the number of resource units earned in the routing operation. The overhead calculation is based on resource units: resource units earned in an operation X overhead rate or amount.
Total Value: Used with the material overhead sub-element only, this assigns material overhead to an item, based on the total value of the item. Used to directly assign the activity cost to an item, the material overhead calculation is based on activity: activity occurrences / number of items X activity rate.
A description of each sub-element and its use is below.
5.5.1. Resource
A resource is anything required to perform, schedule, or cost, including but not limited to: employees, machines, outside processing services, and physical space. Resource Sub-elements are used to define the time an assembly spends at an operation and the cost incurred at the operation. A resource and usage rate for all scheduled activities is required in a routing. Used generally for Bill of Material Transactions, Resources can also be used for Inventory Costing Transactions. For more information on how to define resources, refer to the Bill of Material User Guide at http://www.oracle.com/technology//index.html
5.5.2. Material
Material Sub-elements classify material costs, such as plastic, steel, or aluminum. Each material subelement has the following components:
o Material Description: A freeform description of the material subelement.
o Default activity: This activity is defaulted each time the subelement is used to define an item cost. The default activity value is taken from the previously defined activities.
o Default basis: This value (either Item or Lot) is used as the default cost basis when defining an item's cost.
5.5.3. Material Overhead
Material Overhead is used to distribute costs associated with materials. Material overhead is earned when an item is received into inventory or completed from work in process. The Material Overhead cost subelement adds indirect costs to item costs on either a percentage basis or as a fixed amount. Both Overhead and Material subelement are entered within the same form (Overheads). Material Overhead subelements can contain:
o Cost Element: Material Overhead.
o Absorption Account: The GL account value defined here is used to offset the corresponding overhead cost pool in the general ledger.
o Default Basis: Activity is defaulted each time the subelement is used to define an item cost. The default activity value is taken from the previously defined activities.
o Default basis: This value (Item, Lot, Resource Unit, Resource Value, Total Value, or Activity) is used as the default cost basis when defining an item's cost.
o Resource: For resources associated with the Material Overhead Cost Type, a cost type and the resource names must be associated with the appropriate Material Overhead subelement.
5.5.4. Overhead
Overhead is used as a means to allocate department costs or activities. The Overhead cost subelement adds indirect costs to item costs on either a percentage basis or as a fixed amount. Overheads can be defined based on the number of units or lot moved through the operation, or based on the number of resource units or value charged in the operation. Multiple overhead sub-elements can be defined to cover both fixed and variable overhead, each with its own rate. Multiple overhead sub-elements can be assigned to a single department, and vice versa. In addition to the fields contained in the Material Overhead section, Overhead subelements can also contain Rates. Each Cost Type has an associated department and rate, which will be used during item costing.
5.5.5. Outside Processing
Outside Processing represents services provided by suppliers. Outside processing may be a fixed charge per item or lot processed, a fixed amount per outside processing resource unit, or the standard resource rate times the standard units on the routing operation. To implement outside processing costs, a routing operation must be defined, and an outside processing resource must be used.
5.6. Control Considerations
5.6.1. Business Process Variables
o By restricting the use of a WIP class to only one cost group, commingling of Work in Process costs for multiple projects into one set of valuation accounts can be avoided.
5.6.2. Control Dependencies
o None
5.6.3. Control Limitations
o None
5.6.4. Testing Notes
o None
The Inventory Cycle has several key standing data points, including:
Item Master
Item Entry
Item Costs
ABC Analysis
The chart below illustrates how standing data interfaces with key Inventory transactions.
1. Item Master
Items are defined in one Organisation, called the Item Master. For each Inventory-defined organization, there is no functional or technical difference between the Item Master organisation and other defined organisations. However, for simplicity, Oracle recommends that only one Item Master is defined. This is because:
Multiple item masters are distinct entities, with no relationship to each other.
Items cannot be associated in one item master organisation with another item master organisation.
Items across item master organisations cannot be copied.
However, items defined in the master organisation can be assigned to any other organisation. These other organisations (child organisations) refer to the Item Master for the item's definition and attributes.
Some of System Options when setting up an Item Master for R12 version:
- “Inventory” tab:
- Lot: maturity days and hold days. Maturity day is the number of days added to the lot creation date to determine the lot maturity date. If no number is entered, the system assumes the lot is mature at creation. Lot Creation Date + Maturity Days = Default Lot Maturity Date. Hold day is the number of days added to the lot creation date before the lot can be released.
- Lot divisible: This feature enables you to allocate, reserve, or move partial lot quantities. If this is not selected, then one must transact the full lot quantity for the item. This field cannot be modified if transactions already exist.
- Child lot enabled: If child lot control is enabled, one must specify a parent lot and a child lot for transactional purposes.
- “Purchasing” tab:
- Outsourced assembly: This is an indication on whether this is an outsourced assembly item and has subcontracting components. This attribute can be selected only if charge base chargeable subcontracting is enabled.
- “MPS/MRP” tab:
- Repair: The repair program set to indicate the relationship with the vendor for the repair of an item. The repair yield indicates the yield when you upgrade or repair a defective part. The repair lead-time is the time to repair the part at the supplier site.
- “Order Management” tab:
- Change periodicity: It indicates the time the system uses to price a persistent or recurring service or product. The system derives the list of values for this attribute from the profile option OM: UOM Class for Charge Periodicity. Each UOM in this class is a periodicity value. An item has only one periodicity value, and the default value is null.
- “Process manufacturing” tab - a totally new tab:
- Process quality enabled: it indicates that the process manufacturing quality module with this item is used.
- Process costing enabled: it indicates that the process costing module is used. The system stores costs for each organization.
- Recipes enabled: it indicates that use of the item with recipes or formulas in process manufacturing.
2. Item Entry
Items, in essence, are comprised of three basic components, the item's name/description, its organisation, and the item's collection of attributes. Items can be created at an item master organisation level or at an individual organisation level. Oracle shares the item master with the Inventory, Purchasing, Order Management and Receivables modules. Therefore, for consistency, items should be created at the master organisation level and assigned to child organisations on a per item basis.
Attributes are a collection of configurations and settings that drive the item's functionality, controls and accounting. Because there are over 600 available attributes, the process of adding new items can be quite complicated and time consuming, Item templates, which have predefined attributes for the type of item being created, can be used to speed data entry (refer to the "Item Templates" portion of this section for more information)
There are two ways the client can define items from the Master Items window. They can use the Attribute Groups tab, or the Item Folder tab. The Attributes Group tab allows them to select individual attributes, and use the tool menu to apply templates and assign organisations The Item Folder tab enables the client to create an item, apply a default template, and assign the item to an organisation all in one window. Most of the item information is optional. The client defines only the information they need to maintain the item. A listing of key attributes is listed in the following sections.
2.1. Inventory Master Items - Main
Main Attributes
|
Setting
|
Comments
|
Unit of Measure - Primary
|
Indicates the stocking and selling unit of measure.
This attribute is not updatable once the new item is saved.
|
Any necessary conversions are based on this unit of measure.
The primary unit of measure is the default for invoices and credit memos entered in Oracle Receivables.
If an item belongs to both a master organisation and a child organisation, and these organisations belong to the same costing organisation, the primary unit of measure for the item must be the same within both organisations.
|
Unit of Measure - Deviation Factor +
|
Indicates acceptable deviations as decimal values. This produces a plus or minus tolerance of acceptability.
|
For example, if the allowable transaction quantity deviation for the item is 10 percent higher than the established conversion, the client would enter 0.10 in this field.
|
Unit of Measure - Deviation Factor -
|
Indicates acceptable deviations as decimal values. This produces a plus or minus tolerance of acceptability.
|
For example, if the allowable transaction quantity deviation for the item is 10 percent lower than the established conversion, the client would enter 0.10 in this field.
|
Unit of Measure - Conversions
|
· Both: Use both item-specific and standard unit of measure conversions.
· Item specific: Use only unit of measure conversions unique to this item.
· Standard: Use only standard unit of measure conversions.
|
If the client defined an item-specific and a standard conversion for the same unit of measure, the item-specific conversion is used.
|
Item Status
|
Defines the status of the item, and defaults the status attributes as defined in the Item Status window.
|
2.2. Inventory Master Items - Inventory
Inventory Attributes
|
Setting
|
Comments
|
Inventory Item
|
Indicates whether to stock and transact items in Oracle Inventory.
This setting should be enabled in order to activate the following item attributes:
· Stockable
· BOM Allowed
· Transactable
· Build in WIP
|
If enabled, the item is automatically assigned to the default category set for the Inventory functional area.
|
Stockable
|
Indicates if an item is able to be stocked within an Inventory organisation.
This attribute is only available when the Inventory Item configuration is enabled.
|
For 'service' or non-tangible items, this setting would be expected to be disabled.
|
Transactable
|
Indicates whether Inventory transactions can be placed for this item.
This attribute can be set only when the Stockable configuration is enabled.
|
Oracle Order Management uses this along with Stockable and Returnable to determine which authorised returned items can be physically received into inventory.
|
Reservable
|
Indicates whether this item can be reserved when entering orders in Order Management.
| |
Lot and Serial
|
Values determine the Lot shelf life, lot numbering, locator controls, and serial number generations.
| |
Cycle Count Enabled
|
Indicates whether to include this item in automatically scheduled cycle counts.
|
2.3. Inventory Master Items - Bills of Material
Bills of Material Attributes
|
Setting
|
Comments
|
BOM Allowed
|
Defines a bill of material for an item, or assigns the item as a component on a bill.
|
This setting should be enabled only for items that are components of a bill of material.
|
BOM Item Type
|
Select a type to control bill functionality. The client must enter a value here if BOM Allowed is enabled:
· Model: The item's bill of material lists option classes and options available when the client places and order for the model item.
· Option Class: This item's bill of material contains a list of related options. Option classes group like options together. Oracle Order Management does not allow ordering of classes outside a model.
· Planning: This item's bill of material contains a list of items and planning percentages. A planning item can represent a product family or demand channel. Its bill of material facilitates master scheduling and/or material planning. The total component planning percentages on a planning bill can exceed 100%. Oracle Order Management does not allow ordering of Planning bills.
· Product Family: This item can be used as a product family for planning at an aggregate level.
· Standard: Any item that can have a bill or be a component on a bill, except planning, model, or option class items. Standard items include purchased items, subassemblies, or finished products.
|
This attribute is controlled at the Master level only.
|
2.4. Inventory Master Items - Costing
Costing Attributes
|
Setting
|
Comments
|
Costing Enabled
|
Indicates whether to report, value, and account for any item costs.
For example, disabling costing for reference items or for invoice only (non-stock) items that are never shipped and never held in inventory.
|
Organisations using average costing always maintain their own item costs, regardless of the control level set for the Costing Enabled.
When enabled, the item is automatically assigned to the default category set for the Oracle Cost Management functional area.
|
Inventory Asset Value
|
Indicates whether to value an item as an asset in Inventory. Disabling this indicates an expense item.
| |
Cost of Goods Sold Account
|
Indicates the general ledger account used as a source for the Cost of Goods Sold (COGS) Account in order to record and account for costs related to goods sold.
|
This attribute is controlled at the Organisation level only.
The default cost of goods sold account is set when the client defines organisation parameters.
|
2.5. Inventory Master Items - Purchasing
Purchasing Attributes
|
Setting
|
Comments
|
Purchased
|
Indicates whether this item can be purchased via suppliers/vendors and received into Inventory.
Enabling this option allows the Purchasable attribute to be enabled.
|
If enabled, the item is automatically assigned to the default category set for the Purchasing functional area.
|
Purchasable
|
Indicates whether an item can be placed on a purchase order.
This value can only be enabled if the Purchased attribute is enabled. Disabling this attribute temporarily restricts the ability to buy this item.
| |
RFQ Required
|
Indicate whether to require an item quotation when requesting an item. Oracle Purchasing defaults this value on requisition lines for this item.
|
If defined, this value overrides the value defined in the Organization's Purchasing Options window.
|
Receipt Close Tolerance
|
Indicates a percentage tolerance that Oracle Purchasing uses to automatically close purchase order shipments.
|
Oracle Purchasing automatically closes a shipment when the unreceived quantity is within the quantity tolerance percentage of the shipment. For example, if the original shipment quantity is 50, and 10 has been entered here (10%), Oracle Purchasing automatically closes the shipment for receiving when 45 or more are received.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Price Tolerance
|
Indicates the maximum price percentage over the normal price range for an item.
|
For example, if the tolerance percent is 5, the maximum acceptable price on a purchase order is 5% over the requisition price. Any purchase order price 5% above the requisition price is unacceptable, and the PO cannot be approved.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Invoice Tolerance
|
Indicates the percentage tolerance Oracle Purchasing uses to automatically close purchase order shipments.
|
Oracle Purchasing automatically closes a shipment when the un-invoiced quantity is within the quantity tolerance percentage of the shipment. For example, if the original shipment quantity is 50, and entered 10 here (10%), Oracle Purchasing automatically closes the shipment for invoicing when the invoice match is 45 or more.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Expense Account
|
Indicates the default inventory account for expense items.
|
Oracle Purchasing debits this account when receiving items into inventory only if the item is expensed. If received into an expense subinventory, Oracle Purchasing uses the expense account assigned to the subinventory.
This attribute is used only when Inventory Asset Value is turned off.
|
Invoice Matching - Receipt Required (3-way match)
|
Indicates whether an item must be received before the invoice can be paid.
|
This setting should be "Yes" for "Receipt Required" for 3-way matched items and "blank" for 2-way matched (typically service or non-tangible items) in order to prevent the payment of un-received items.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Invoice Matching - Inspection Required (4-way match)
|
Indicates whether to inspect an item upon receipt from the supplier, before paying the corresponding invoice.
If this field is blank, inventory will use the value defined in the Purchasing Options window for transactions involving this item.
|
Inspection required is optional and only necessary for manufacturing type organisations where quality of received goods requires a separate inspection / quality assurance process.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
2.6. Inventory Master Items - Receiving
Receiving Attributes
|
Setting
|
Comments
|
Receipt Date Controls - Days Early
|
Indicates the number of days before the promise date that the System is allowed to receive an item without warning or rejection.
|
This setting should be set in order to prevent the receiving of goods too early.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Receipt Date Controls - Days Late
|
Indicates the number of days after the promise date that the System is allowed to receive an item without warning or rejection.
|
This setting should be set in order to prevent the receiving of goods too late.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Receipt Date Controls - Action
|
· None: No tolerance is enforced.
· Reject: Rejects receipts when the receive date is outside the range defined by Days Early Receipt Allowed or Days Late Receipt Allowed.
· Warning: A warning message displays if the client attempts to receive an item outside the range defined by Days Early Receipt Allowed or Days Late Receipt Allowed.
|
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Overreceipt Quantity Control - Tolerance
|
Indicates the maximum acceptable over-receipt percentage, used by the Over-Receipt Quantity Control Action attribute.
|
For example, if the tolerance percent is 5, then the acceptable quantity on a receipt transaction is within 5% of the quantity ordered on a purchase order line.
Any quantity more than 5% over the order quantity is unacceptable.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Overreceipt Quantity Control - Action
|
· None: No tolerance is enforced.
· Reject: Rejects receipts over the tolerance quantity. The client receives an error message and is prevented from receiving quantities exceeding the order quantity by more than the Quantity Received Tolerance percent.
· Warning: A warning message displays if the client enters receipts over the quantity determined by the Overreceipt Quantity Control Tolerance percent.
|
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Valid Transactions - Allow Substitute Receipts
|
If enabled, items other than those ordered can be received. Item substitutes must be defined with the Item Relationships window.
|
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
Refer to the Oracle Inventory User Guide for further details on item relationships.
|
Valid Transactions - Allow Unordered Receipts
|
If this option is disabled, all receipts for an item must have a corresponding purchase order.
|
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
2.7. Inventory Master Items - General Planning
General Planning Attributes
|
Setting
|
Comments
|
Consigned
|
If selected, the item is consigned, meaning residing at the client's location, but owned by the supplier. Use the consumption setup window to designate which transaction to use when consuming either consigned or VMI (Vendor Managed Inventory).
|
2.8. Inventory Master Items - Order Management
Order Management Attributes
|
Setting
|
Comments
|
Customer Ordered
|
Indicates whether to allow an item to be ordered by external customers. In addition, any item with this value enabled can be added to a price list within Oracle Order Management.
|
This attribute must be turned off if the BOM Item Type attribute is set to Planning.
Additionally, items that are purchase order items would typically not also be saleable to a customer if it is a component of a manufactured item.
This is an item defining attribute. If turned on, the item is automatically assigned to the default category set for the Oracle Order Management functional area.
|
Customer Orders Enabled
|
Indicates whether an item is currently customer orderable. If enabled, this item can be selected for a Sales Order within Oracle Order Management.
|
This should be disabled for discontinued items no longer available for sale, or for items that are not ready to be sold.
If the Customer Ordered configuration is enabled, but the Customer Orders Enabled value is disabled, prices can be defined for the item, but no orders can be placed for it.
|
Internal Ordered
|
Indicates whether to allow an item to be ordered internal requisition.
|
This is an item defining attribute. If turned on, the item is automatically assigned to the default category set for the Oracle Purchasing functional area.
|
Internal Order Enabled
|
Indicates whether an item is currently available for internal requisitions. If enabled, this item can be selected for an internal requisition within Oracle Purchasing.
|
If the Internal Ordered configuration is enabled, but the Internal Order Enabled configuration is disabled, this value is temporarily exclude from being used on requisitions.
|
OE Transactable
|
Indicate whether demand can be placed for an item by Oracle Order Management, and whether shipment transactions are interfaced to Oracle Inventory.
|
Most items with the Shippable attributed enabled also have OE Transactable enabled on. For non-shipped items, OE Transactable can be enabled if the item is used in forecasting or planning.
This attribute cannot be disabled if demand exits.
|
Shippable
|
Indicates whether an item is shippable. Shippable items are released by Oracle Shipping Execution’s Pick Release program, creating confirmable shipping lines, and are printed on the pick slip
|
This setting should be enabled for physical items (and not for services).
This attribute must be disabled if the BOM Item Type attribute is set to Planning.
|
Returnable
|
Indicates whether customers can return an item. Order Management uses this attribute along with Stockable and Transactable to determine which returned items can be physically received into inventory.
|
Generally only "Customer Ordered" enabled items would be expected to be "Returnable".
|
Tolerances - Over Shipment
|
Indicates the amount of that the shipment can exceed at the time of ship confirmation.
|
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Tolerances - Under Shipment
|
Indicates the amount of the shipment that can be shipped below at the time of ship confirmation.
|
Setting this to 0% does not prevent a client from partially fulfilling an order line, but determines whether the order line is closed once the shipment occurs or not.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Tolerances - Over Return
|
Indicates the amount of the shipment that can exceed at the time of receiving or receipt creation.
|
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
Tolerances - Under Return
|
Indicates the lower limit of the received quantity to be considered as full receipt.
|
Setting a value other than 0% will allow a user to return less than the quantity specified on the return, and gain credit for the full value of the return, and not just the returned items.
Refer to the Control Limitations section on where this item-level value overrides other system defaults.
|
2.9. Inventory Master Items - Invoicing
Invoicing Attributes
|
Setting
|
Comments
|
Invoice Enabled
|
Indicates whether to activate an item for invoicing in Oracle Receivables.
If enabled, the item can be used to create a manual invoice line in Oracle Receivables. In addition, via the AutoInvoicing process, a systematically generated receivables invoice line can be created using that item's Order Management sales order line.
| |
Invoiceable Item
|
Indicates whether to include an item on an Oracle Receivables invoice.
This value can only be enabled if the Invoice Enabled attribute is enabled. Disabling this attribute temporarily restricts the ability to invoice this item.
|
This should be enabled for all "Customer Ordered" items and items that are sold. However, purchasing items used in BOMs as components, and that are not sold externally, might have this disabled.
|
Accounting Rule
|
Indicates the default accounting rule to identify revenue recognition rules for an item.
|
Accounting Rules defined should normally be "Immediate" for most physical goods.
If blank, the accounting rule defined to the transaction type defaults into the item's Sales Order line.
|
Sales Account
|
Indicates the general ledger account (usually a sales or revenue account) which Oracle Receivables uses to record revenue when billing customers.
|
This attribute is controlled at the Organisation level only.
|
2.10. Item Templates
Templates are defined sets of item attributes that can be re-used to create many similar items. Templates make initial item definition easier for data entry. Oracle recommends using its pre-defined (or system-defined) templates or the client can create their own user-defined (client-defined) templates for item entry.
Item template attributes are not validated; therefore it is possible to define a template with contradictory attributes. Only when using a template to define an item does Oracle Inventory verify that the attributes are valid for a given item. To enter an item using the item template, the client navigates to the item window and then selects Tools>Copy From. Once a template is selected, the template's defined attributes are automatically entered for the item. However, if a template has contradictory attributes, the following will occur:
If an attribute is not updatable for an item, the value from the template is not applied.
If a combination of attributes is invalid a warning appears when trying to save the item.
If a disabled attribute is defined within the item template, the attribute value found within the Item Template will not be applied to the item.
2.11. Item Entry via Open Interface
Items can be imported, along with their category assignments, from any external source into Oracle Inventory and Oracle Engineering. With Oracle Open Interface, clients 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. When clients import items through the Item Interface, they create new items in the Item Master organization or assign existing items to additional organizations. Clients can specify values for all the item attributes, or specify just a few attributes and let the remainder default or remain null. The Item Interface also lets clients import revision details, including past and future revisions and effectivity dates. Validation of imported items is done using the same rules as the item definition forms, so clients are insured of valid items.
2.12. Control Considerations
2.12.1. Business Process Variables
o Each organisation should utilise one and the same item master, and items can be assigned to individual organisations as required. Relationships between items on different item masters cannot be created, therefore any updates to an item would have to be performed in multiple item masters.
o Individual item attributes are highly variable depending upon many factors including:
§ The client's industry
§ The client's business
§ Client's range of products
§ Whether or not it manufactures goods
§ Is a service organisation
§ Purchases from outside vendors
o Control over consigned items should be in place to avoid Inventory accounting balance misstatement, in case of inventory Items been valued in the General Ledger.
2.12.2. Control Dependencies
o A listing of item "types" and their typical attribute dependencies are below:
Example item
|
Typical settings
|
Service item
|
"Inventory" and "Stockable" attributes should be disabled.
Since no 'inventory' of service items can be kept, "Invoice Matching" should be set to 'BLANK' (as 2 way matching is relevant for services)
|
Sales item
|
"Invoiceable Item" and "Invoice Enabled" should be enabled as this item should be revenue accounted for.
|
Purchase order item
|
"Expense Account" field should be defined to an expense account combination if this item is not to be accounted for as an asset ("Inventory Asset Value" in the costing attribute region should then be disabled)
|
Manufacturing item
|
These items may or may not be available for sale, as components are often only used in manufacturing and are not sold individually.
"Costing Enabled" should be enabled, as generally manufactured items will have an associated cost.
"Inventory Asset Value" should be enabled as manufactured goods are normally inventory asset items and are not immediately expensed.
"Cost of Goods Sold Account" should be defined to a Cost of Goods Sold expense account distribution.
|
2.12.3. Control Limitations
o If an item is assigned a status whose status attributes are defaults, these attributes can be overridden for each individual items.
o If defined at the item level, the "RFQ required" value overrides the "RFQ required value" defined in the Organization's Purchasing Options window
o If the Receipt Date and Overreceipt actions are set to "Warning", this allows the end user to enter receipts in violation with the defined tolerances…since the warning can be overridden.
o Although these Purchasing Options are defined only once, they default in the following descending order: Purchasing Options, Purchase Order Line and Item Master. The setting at the Item Master overrides the settings at all other levels. The following table lists the important purchasing options that can be overridden at various levels.
Purchasing Option
|
Can be overridden at:
| |||
Supplier Level (Receiving Tab)
|
Supplier Site Level
|
Purchase Order Line Shipment Level (applied to transaction)
|
Item Master Level (Purchasing Tab)
| |
Receipt Close %
|
NA
|
NA
|
a
|
a
|
Invoice Close %
|
NA
|
NA
|
a
|
a
|
Price Tolerance %
|
NA
|
NA
|
NA
|
a
|
Match Approval Level: 3-Way Match (Receipt Required)
|
a
|
NA
|
a
|
a
|
Match Approval Level: 4-Way Match (Inspection Required)
|
a
|
NA
|
a
|
a
|
o Although these Subinventory Setups are defined only once, they default in the following descending order: Purchase Order Line and Item Master. The setting at the Item Master overrides the settings at all other levels. The following table lists the important purchasing options that can be overridden at various levels.
Subinventory Setup
|
Can be overridden at:
| |||
Supplier Level
|
Supplier Site Level
|
Purchase Order Line Shipment Level (applied to transaction)
|
Item Master Level (Purchasing Tab)
| |
Expense Account (PO Charge Account)
|
NA
|
NA
|
a
|
a
|
o Although these Receiving Options are defined only once, they default in the following descending order: Receiving Options, Supplier, Purchase Order Line and Item Master. The setting at the Item Master overrides the settings at all other levels. The following table lists the important receiving options that can be overridden at various levels.
Receiving Option
|
Can be overridden at:
| |||
Supplier Level
(Receiving Tab)
|
Supplier Site Level
|
Purchase Order Line Shipment Level (Receiving Controls Button)
|
Item Master Level (Receiving Tab)
| |
Allow Unordered Receipts
|
a
|
NA
|
NA
|
a
|
Quantity Received Tolerance
|
a
|
NA
|
a
|
a
|
Quantity Received Exception Action
|
a
|
NA
|
a
|
a
|
Receipt Date – Days Early
|
a
|
NA
|
a
|
a
|
Receipt Date – Days Late
|
a
|
NA
|
a
|
a
|
Receipt Date Exception Action
|
a
|
NA
|
a
|
a
|
Allow Substitute Receipts
|
a
|
NA
|
a
|
a
|
o Although these Order Management options are defined only once, they default in the following descending order: Order Management Profile Options, Customer, Sales Order and Item Master. The setting at the Item Master overrides the settings at all other levels. The following table lists the important Order Management profile options that can be overridden at various levels.
Order Management Profile Option
|
Can be overridden at:
| |||
Customer Level
(Order Management Tab)
|
Customer Site Level
|
Sales Order Level
|
Item Master Level (Order Management Tab)
| |
Over Shipment Tolerance
|
a
|
NA
|
a
|
a
|
Under Shipment Tolerance
|
a
|
NA
|
a
|
a
|
Over Return Tolerance
|
a
|
NA
|
NA
|
a
|
Under Return Tolerance
|
a
|
NA
|
NA
|
a
|
o Although this Order Management Transaction Type option is defined only once, it defaults in the following descending order: Order Transaction Type, Sales Order, and Item Master. The setting at the Item Master overrides the settings at all other levels. The following table lists the important Order Management Transaction Type setting that can be overridden at various levels.
OM Transaction Type (Finance Tab)
|
Can be overridden at:
| |||
Customer Level
|
Customer Site Level
|
Sales Order Level
|
Item Master Level (Invoicing Tab)
| |
Accounting Rule
|
NA
|
NA
|
a
|
a
|
o There is no possibility for overriding Consignment inventory items. They should not be valuated in the General Ledger, due to the fact that items are only residing at the Company, but owned by the supplier or a third party.
2.12.4. Testing Notes
o Clients should have a process established that proactively controls change to the item master and item attributes. Generally these change control processes will stand apart from and be independent of the IT General Computer Controls system change control processes. Change control processes over item master could include:
§ Periodic review of old / obsolete items (either an inactive date is applied to an item, or the item status is changed)
§ Processes to control new versions of existing products (new item created vs. new version created)
§ Processes to add new items.
o Through the use of item templates, item statuses, and defaults, items will take on attributes defined at those levels. However these are individually overrideable on a per item basis. Consequently, the level of risk will determine whether and to what extent the items in the item master need to be audited. Examples of financial statement risks include:
§ If the Expense Account combination is an asset account, then the item will still be reflected as an asset in the financial statements instead of being expensed immediately. Reviewing this value at the item and at the subinventory level will identify where this financial risk exists.
§ Enabling the shippable configuration for services or non-tangible items runs the risk that the service / non-tangible item, not being listed as an inventory item, will not be able to ship and consequently the sales order will not be processed (will be stuck in the pick release / ship confirm stage) and consequently not invoice or revenue account.
§ A risk exists that revenue items are not "Invoiceable Item" enabled and consequently may allow pick release and shipping of the goods, but will be rejected in the AutoInvoice process and consequently not be revenue accounted.
§ If an item is not "Cost Enabled" but is a "Stockable" and "Inventory Asset Value" is enabled, the item may not be correctly valued in the subinventory.
o For further details on stratifying the item master population and selecting a sample, or performing CAATs on the item master, refer to the local region's PwC Audit Guide.
3. Item Costs
Item costing is driven by each Organization's defined Costing Method. Frozen costing processes are used in an Organization using the Standard costing method, while Average costing processes are used in an Organization using the Average costing method. When an item is defined, the system creates a cost record. Each cost record is then maintained differently, depending upon the Organizations' defined cost method. These cost processes are outlined below.
3.1 Average Cost Items
3.1.1. Defining Average Cost Items
The Item Costs window cannot be used to enter average costs. Under the average cost system, the unit cost of an item is automatically calculated using the average value of all receipts of that item into inventory. Each receipt of material to inventory updates the unit cost of the item received. Issues from inventory use the current average cost as the unit cost. By using Oracle Cost Management’s average costing method, clients can perpetually value inventory at an average cost, weighted by quantity (inventory cost = average unit cost * quantity). For purchased items, this is a weighted average of the actual procurement cost of an item. For manufactured items, this is a weighted average of the cost of all resources and materials consumed. Under average costing, organizations cannot share costs; average costs are maintained separately in each inventory organisation.
3.1.2. Updating Average Cost Items
An item's average cost can be directly updated in four different ways:
o New average cost: By entering a new total cost, the value of the on-hand inventory in all subinventories will be revalued. ). In the example below, the cost of this item is being changed from $16.89 to $1.00, and the resultant inventory value is decreasing from $1,689. to $100.
o % Change: By entering a % change value, the on-hand inventory in all subinventories in will be revalued, with the percentage change automatically applied.
o Inventory Value Change: By entering a Value Change, the system will revalue on-hand inventory by that amount and recalculate the item's average cost for the cost group. If there is no inventory quantity on-hand, the cost cannot be updated by this method.
o Cost Element Change: Each item's sub-element costs can be adjusted.
When the client updates an item's average costs, the item's cost in all asset subinventories are updated (revalued). The inventory adjustment value resulting is posted to the average cost adjustment account that is specified in the Update Average Cost form. Items in Work in Progress are not revalued by an average cost update, nor are expense items or any item in an expense subinventory.
3.2. Frozen Cost Items
3.2.1. Defining Frozen Cost Items
When an item is entered, the automatically created item cost record is viewable in the Item Costs Detail window. In order to assign costs to an item, the "Inventory Asset" configuration must be enabled, as noted below.
Using the cost button, clients can enter costs for the item. For each item, the item's element, sub-element, basis and rate must be entered. In addition, the item's activity and the activity's occurrence (the number of times the activity is expected to occur during the cost period) can be defined. The basis is multiplied by the rate or amount to calculate the unit cost of the subelement.
3.2.2. Updating Frozen Cost Items
The standard cost update procedure enables the client to define and roll up pending costs, simulate changes to standard costs for analysis, and then update the item's pending costs to Frozen status. Only once the item costs are frozen can the updated cost be used in transactions.
3.2.2.1. Frozen Cost Setups
Prior to using the frozen cost method, cost types for pending standard costs and pending costs must be defined for each of the cost elements: material (inventory items, both components and assemblies), material overhead, resources, overhead, and outside processing. An example is below:
For more information regarding Cost Types, refer to the Cost Type section of this document.
3.2.2.2. Pending Cost Rollup
The Pending Cost Rollup Concurrent Process adds up pending costs for all cost elements of an assembly and creates a new pending cost for the assembly. Bills and routings (found in Bills of Material and Work in Process modules) define the foundation for cost rollups, elemental distribution, and all related manufacturing costing functions. Pending costs must be rolled up before they can be frozen. For more information on Bills of Materials and Work in Process transaction processes, refer to the modules' user guide found at www.oracle.com.
3.2.2.3. Pending Cost Stimulation
The Report Pending Adjustments concurrent process launches two processes. One simulates a cost update from the cost type specified to the Frozen cost type, and one to launch the Inventory, Intransit, and WIP Standard Cost Adjustment reports. These reports allow clients to preview changes the standard cost update would perform for current inventory balances.
3.2.2.4. Updating Pending Costs to Frozen Standard Costs
The Update Standard Cost request is run to update pending costs to frozen standard costs. Updating pending costs to Frozen standard costs does the following:
§ Updates the existing standard costs with the costs created in the new cost type and creates the resulting adjustment accounting entries.
§ Creates item cost history.
§ Prints the Inventory, Intransit, and WIP Standard Cost Adjustment reports that detail the valuation changes in the client's inventory due to the change in the standard costs.
§ If the client shares costs across inventory organizations, the standard cost update automatically revalues the on-hand balances in all organizations that share costs.
The client can only update standard costs from the master costing organization, which must use standard costing. The following concurrent request parameters affect the freezing of item costs:
§ A Cost Type. Cost information (a set of costs for items, activities, resources, outside processing, and overhead) is copied from this cost type into the Frozen cost type.
§ Adjustment Account: This account is used to collect the changes in value to each item, and to automatically generate transactions that adjust the client's inventory accounts.
§ Item Range and Update Option. The update option is based upon the item range selected. These are outlined below:
Item Range selected:
|
Update Options available:
|
Additional Procedures/Comments:
|
All Items
|
· Overhead, resource, activity, and item costs
· Resource, overhead, and item costs
|
The Resource, overhead, and item costs option is only available if the client uses Inventory with Bills of Material. If they use Work in Process, choose this option to reflect resource and overhead cost changes for actual charges to standard and non-standard asset jobs.
|
Specific item
|
· Overhead, resource, activity, and item costs
· Resource, overhead, and item costs
· Activity, and item costs
· Item costs only
|
If Specific item selected, then a Specific Item to be updated must also be selected.
|
Category
|
· Overhead, resource, activity, and item costs
· Resource, overhead, and item costs
· Activity, and item costs
· Item costs only
|
In addition, select a Category Set. The default is the category set defined for the costing functional area and select a specific category.
|
Range of items
|
· Overhead, resource, activity, and item costs
· Resource, overhead, and item costs
· Activity, and item costs
· Item costs only
|
In addition, select beginning and ending Item From and To values. Standard costs are updated for all items in this range, inclusive.
|
Based on rollup items, Not based on rollup items, and Zero cost items
|
· Overhead, resource, activity, and item costs
· Resource, overhead, and item costs
· Activity, and item costs
· Item costs only
|
3.3. Control Considerations
3.3.1. Business Process Variables
Deferred COGS Recognition
o Users have the flexibility to de-couple the physical event of shipping goods from the recognition of COGS. It can now defer the recognition of cost of goods sold until all contract contingencies have been fulfilled and revenue has been recognised in Oracle Receivables.
o z
Financially, this it may affect the revenue recognition process.
3.3.2. Control Dependencies
o None
3.3.3. Control Limitations
o None
3.3.4. Testing Notes
o None
4. 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 the client assigns to their items as a result of this analysis, where "A" items are ranked higher than "B" items, and so on. The ABC analyses are often used to drive cycle counts, where the client might count items of high value (A items) very frequently, items of lower value less frequently, and items of lowest value very infrequently. ABC analysis involves 6 steps, as defined below.
4.1. ABC Compiles
The client can define and compile an ABC analysis for their entire organization or for a specific subinventory within the client's organization. They choose the compilation criterion, the scope of their analysis, the cost type to use in determining item values, and any additional information that may be conditionally necessary, based on their compilation criterion. The combination of all these parameters constitutes an ABC compile header, identified by the ABC compile name. The client uses this name to identify any activity pertaining to this ABC analysis. ABC compiles are defined in the Define ABC Compile window.
4.1.1. Content Scope
Determines the scope of the analysis by selecting the content level for items to include in the compile. If the client uses the entire organization, Oracle Inventory includes all items defined for their current organization in the ABC compile, even those with zero cost or zero quantity. If they use a particular subinventory, Oracle Inventory includes all items for which they have defined an item/subinventory relationship. The client cannot compile an ABC analysis for a subinventory that is defined as a non-quantity tracked subinventory. They can, however, use non-asset (expense) subinventories for which they track quantities.
4.1.2. Valuation Scope
The valuation scope for determining the ranking of items must also be selected. Ranking must be done at the Organization level if the client did not select a subinventory in the Content Scope field. If they only want to include items in a subinventory but they want the ranking to be done based on the organization wide ranking, they must select Organization.
4.1.3. Compile Specification
The compile criterion or method of ranking items in the ABC compile is required. Oracle Inventory uses the compile criterion to value the items the client includes in their ABC compile. After determining each item's compile value, Oracle Inventory ranks all the items in the client's ABC compile.
In addition, a cost type must be entered. The client can select a value here only if they selected Current on-hand quantity, Current on-hand value, Forecasted usage quantity, Forecasted usage value, MRP demand usage quantity, or MRP demand usage value in the Criterion field. If the client is compiling by quantity criterion, the cost type is used for reporting purposes only.
4.1.4. MRP Parameters
MRP forecast name can only be selected if the client selected Forecasted usage quantity or Forecasted usage value in the Criterion field. MRP plan name can only be selected if the client entered MRP demand usage quantity or MRP demand usage value in the Criterion field.
4.1.5. Start (from) date and End (to) date
These are required fields if the client selected an option other than Current on-hand quantity or Current on-hand value in the Criterion field.
4.1.6. Running an ABC Compile
Once entered, the defined ABC must be compiled. ABC compiles are run in the ABC Compiles window via the Compile button. This submits a request to run the compile program. Once complied, the ABC compile can be used to define the ABC classes and associate items with the classes.
4.2. ABC Classes
The client uses ABC classes to identify the value groupings to which their items belong. They define these classes using their own terminology. For example, they might define classes High, Medium, Low, and later assign their items of highest rank to the High class, and so forth. ABC Classes are defined in the ABC Classes window. Once defined, the classes are used in the definition of Assignment Groups, as outlined in the next section.
The client can use ABC classes to group items for a cycle count where they count "A" items more frequently than "B" items. When they use ABC classes in this way, they perform an ABC analysis and assign items to classes based on the results of that analysis. They can also use ABC classes to group items for planning purposes.
4.3. ABC Assignment Groups
ABC assignment groups link a particular ABC compile with a valid set of ABC classes. This allows them to assign items to different ABC classes in different groups. For example, suppose the client defines ABC groups "Cycle Counting" and "Planning". They can assign different ABC classes to these two groups. They can then assign an item to a different ABC class in each group. This allows the client to prioritize items differently for cycle counting and planning.
4.3.1. ABC Assignment Groups-Header
ABC assignment groups are defined in the ABC Assignment Groups window. A unique ABC group name must be entered. To assign items to this ABC group using an ABC compile, enter the name of a valid ABC compile for the client's organization. If an ABC compile name is entered, Oracle Inventory displays the subinventory (if any) and the valuation associated with that ABC compile.
4.3.2. Group Classes
Group Classes to use with an ABC group are entered in the Group Classes region. The sequence number in which classes are ordered must be entered. The lower the number, the higher the importance of the class. Oracle Inventory defaults to the next available integer along with the name of the class to use with this ABC group.
4.3.3. Assign Items
The Assign Items region is used to assign items to the group if the client associated an ABC compile to the group. The client has the ability to assign and update ABC classes to an ABC assignment group where an ABC compile was also entered. From the ABC Descending Value Report they can determine the cut-off points for assigning ABC classes. The client can then use the classifications for other purposes such as determining how often they cycle count a given item. Choosing the Assign button launches the concurrent request to assign the items to the classes in the ABC group.
4.3.4. Update Item Assignments
After the automatic ABC assignment process is completed, if an item's ABC class needs be adjusted, this can be accomplished. In addition, an ABC group can be updated to include those items that were not a part of the initial ABC compile. This allows for expansion of existing ABC compiles without having to rerun any processes.
For example, assume a client compiled their ABC analysis based on historical usage value, and there is a relatively new item in their inventory. Since there is very little transaction history on record, the item was assigned to a low-rank ABC class. However, it's known that this item will have a high usage value and should really be classified as a high rank item. The client can use the Update ABC Assignments form to reclassify this item to now be a high rank item.
4.4. Control Considerations
4.4.1. Business Process Variables
o None
4.4.2. Control Dependencies
o None
4.4.3. Control Limitations
o None
4.4.4. Testing Notes
o None
F. Transactions Overview
Transactions in Inventory largely consist of movements between organisations and subinventories, and counting of inventory. These are often processed on an ad-hoc basis as the need is identified.
1. Inventory Transfers & Movements
Inventory can be transferred between Organisations/Companies or between Sub-Inventories. In addition, inventory can be moved within a single organization. Primarily, movements of items in inventories should be processed via the Order to Cash and Procure to Pay processes and should not be done via direct inventory transaction processing. However, there are instances in which movements must be recorded directly in Inventory. Each Inventory movement process is described below.
1.1. Transferring Between Organisations
Material can be transferred from the current organisation to another organisation, or from the current organisation to intransit inventory. The client can define multiple inventories, warehouses, and manufacturing facilities as distinct organisations. With Oracle Inventory they can perform direct inter-organisation movements or they can transfer expense and asset items from one organisation to another using intransit inventory.
1.1.1. Direct Inter-Organisation Transfers
The client can use a direct inter-organisation transfer to move inventory directly from a shipping organisation to a destination organisation. Using the Inter-Organization Transfer window, the client can transfer one or more items in a single transaction. The following information is usually entered with Inter-Organisation Transfers:
1.1.1.1. Transfer Header
The date of entry for the transaction is entered. along with the organization to which to transfer the material. ). In the same window, a transaction type needs to be entered, along with indicating if inventory information should be defaulted from the serial number.
1.1.1.2. Items to be Transferred
Items to be transferred are selected in the Transaction Lines region. The client can transfer the same item more than once. For example, they can specify an item more than once to transfer partial quantities to different subinventories or stock locators. Note: For a direct transfer, if the item is under revision control in either organization, enter a revision that is common to the item in both organizations.
1.1.1.3. Subinventory
A subinventory from which to transfer the material must be entered. Optionally, enter the subinventory to which to transfer the material. However, the client must enter a value in this field for direct inter-organization transfers. If the client has established locator control for the item, they must enter from and to locators.
1.1.1.4. Unit of Measure and Quantity
A unit of measure is required. This can be the primary unit of measure (the default) or any valid alternate unit of measure. If the client enters an alternate unit of measure, Oracle Inventory issues the quantity you specify in this unit of measure. Oracle Inventory also converts the quantity to the primary unit of measure so that it can correctly update the on-hand quantity. In addition, enter the quantity of the item to transfer.
1.1.1.5. Internal Transfer Charges
To enter internal transfer charges to assign to the To organization, enter a value in the Added Value field that represents the transfer charge. The client can enter a value here only if they entered Requested value in the Inter-Organization Transfer Charge field in the Organization Parameters window. In addition, enter the percent of the transaction value that represents the transfer charge. The client can enter a value here only if they have entered Requested percent in the Inter-Organization Transfer Charge field in the Organization Parameters window.
1.1.1.6. Freight Information
To enter freight information costs to assign to the From (current) organization, enter the transportation cost to physically transfer the material; that is, the freight carrier charges. In addition, enter the general ledger account to which to charge the value the client entered in the Transportation Cost field. Oracle Inventory displays the account they defined for the freight carrier as the default.
1.1.1.7. Unit Numbers
If Oracle Project Manufacturing is installed and if the client has enabled its end item model/unit effectivity feature, they can enter a unit number for the item. See: Model/Unit Effectivity, Oracle Project Manufacturing Implementation Manual. Note: The Unit Number field is visible only if the client has installed Project Manufacturing.
1.1.1.8. Lot/Serial Numbers
A lot number for the item must be entered. The client may enter multiple lot numbers, in the Lot/Serial button to display the Lot Entry window.
For receipt transactions, if the client enters a lot number, they must enter the date the lot expires. They can enter a value here only if the Lot Expiration (Shelf Life) Control attribute is set to User-defined Expiration Date.
1.1.1.9. Quantity
The following fields are reviewed to view quantity available and quantity on hand values:
§ Available: Displays the quantity available to transfer, based on the unit of measure the client specified. The available quantity is the quantity on hand less all reservations for the item. The available quantity is specific to the revision level, lot number, From subinventory, and From locator the client specifies for the transfer.
§ On hand: Displays the current on-hand quantity for the item, based on the unit of measure the client specified. The on-hand quantity is specific to the revision, lot number, From subinventory, and From locator they specify for the transfer. On-hand includes quantities for pending transactions in the MTL-MATERIAL-TRANSACTIONS table.
1.1.1.10. Movement Statistics
Use either of the following methods to record and maintain information associated with the movement of goods:
1. Navigate to the Movement Statistics window and record information manually.
2. Automate the collection of this information by setting up parameters in the Movement Statistics Parameters and Economic Zones windows.
. 1.1.11. Material Aging Workflow
This workflow can be leveraged to create work orders, send notifications to planners, update material status or request a movement of expired product to a quarantine or inspection area.
The validity of a transfer transaction depends on the controls the client has defined in both the shipping and destination organisations for the items they want to transfer. For example, they can transfer item A from organisation X to organisation Y, even though item A is under lot control only in organisation X (the client can specify the lot numbers for item A in organisation X during the transfer transaction). However, they cannot transfer item B from organisation X to organisation Y if item B is under lot control only in organisation Y (they cannot specify lot numbers for item B in the destination organisation because you are performing a direct transfer). The following charts outline how organization controls affect the ability for one organization to transfer items to another organization.
Off (Shipping Organisation)
|
On (Shipping Organisation)
| |
Off (Destination Organisation)
|
OK
|
OK
|
On (Destination Organisation)
|
OK
|
Off (Shipping Organisation)
|
On (Shipping Organisation)
| |
Off (Destination Organisation)
|
OK
|
OK
|
On (Destination Organisation)
|
OK
|
Off (Shipping Organisation)
|
On (Shipping Organisation)
| |
Off (Destination Organisation)
|
OK
|
OK
|
On (Destination Organisation)
|
OK
|
Expense sub and/or Expense item
|
Asset sub and Asset item
| |
Expense sub and/or Expense item
|
OK
| |
Asset sub and Asset item
|
OK
|
OK
|
1.1.2. Inter-Organisation Transfers via Intransit Inventory
Intransit Transfers are generally used when transportation time is significant. When clients perform the transfer transaction, the same Inter-Organization Transfer window is used. However, a delivery location is not specified. They only need to enter the subinventory they are shipping from, a shipment number, the freight information, and, depending on the inter-organisation transfer charge that applies between the organisations, a percentage of the transaction value or a discrete amount that Oracle Inventory uses to compute transfer charges.
If the FOB (Freight on Board) point is set to Receipt in the Shipping Networks window, the destination organisation owns the shipment when they receive it. If it is set to Shipment, the destination organisation owns the shipment when the shipping organisation ships it, and while it is intransit. While their shipment is intransit, they can update shipping information such as the freight carrier or arrival date in the Maintain Shipments window.
At the time of shipment, the client must define your receiving parameters for the destination organisation. They can receive and deliver your shipment in a single transaction or they can receive and store their shipment at the receiving dock.
The following charts outline how organization controls affect the ability for one organization to transfer items to another organization via intransit Inventory.
Off (Shipping Organisation)
|
On (Shipping Organisation)
| |
Off (Destination Organisation)
|
OK
|
OK
|
On (Destination Organisation)
|
Receive any revision
|
Receive only the revision you ship
|
Off (Shipping Organisation)
|
On (Shipping Organisation)
| |
Off (Destination Organisation)
|
OK
|
OK
|
On (Destination Organisation)
|
OK
|
OK
|
Off (Shipping Organisation)
|
On (Shipping Organisation)
| |
Off (Destination Organisation)
|
OK
|
OK
|
On (Destination Organisation)
|
OK
|
OK
|
Asset Subinventory
|
Expense Subinventory
| |
Asset Item
|
OK
| |
Expense Item
|
OK
|
OK
|
1.2. Transferring Between Subinventories and Locators
Material can be transferred within the current organisation between subinventories, or between two locators within the same subinventory. The client can transfer from asset to expense subinventories, as well as from tracked to non-tracked subinventories.
1.2.1 Entry of Subinventory Transfers
Subinventory transfers are entered in the Subinventory Transfer window. The following items are entered when transferring items between subinventory and locators:
1.2.1.1. Header
The date and time of entry for the transaction is entered, along with the transaction type for the subinventory transfer.
1.2.1.2. Items to be Transferred
Items to be transferred are selected in the Transaction Lines region. The subinventories from and to which material is transferred are also entered here. If an item has a restricted list of subinventories, they can only transfer material from and to subinventories in that list. To transfer material between locators, enter the same subinventory in the Sub and To Sub fields. Optionally, enter the locators from and to which to transfer the item. The client must enter a value here if they established locator control.
In addition, a unit of measure must be entered. This can be the primary unit of measure (the default) or any valid alternate unit of measure. If the client enters an alternate unit of measure, Oracle Inventory issues the quantity they specify in this unit of measure. Oracle Inventory also converts the quantity to the primary unit of measure so that it can correctly update the on-hand quantity. Based on the unit of measure specified, the quantity of the inventory item to transfer must be entered.
1.2.1.3. Lot or Serial Numbers
Enter lot or serial number information in the Lot/Serial region.
1.2.1.4. Quantity
The following fields are reviewed to view quantity available and quantity on hand values:
§ Available: Displays the quantity available to transfer, based on the unit of measure the client specified. The available quantity is the quantity on hand less all reservations for the item. This amount could include the amount they have reserved if they enter a transaction source that has reservations against it. The available quantity includes reservations against current transaction source. The available quantity is specific to the revision level, lot number, From subinventory, and From locator the client specifies for the transfer.
§ On hand: Displays the current on-hand quantity for the item, based on the unit of measure the client specified. The on-hand quantity is specific to the revision, lot number, From subinventory, and From locator they specify for the transfer. On-hand includes quantities for pending transactions in the MTL-MATERIAL-TRANSACTIONS table.
1.3. Move Orders
Move orders are requests for the movement of material within a single organisation. It allows planners and facility managers to request the movement of material within a warehouse or facility for purposes like replenishment, material storage relocations, and quality handling. Move orders can be either manually or automatically generated depending on the source type used.
The following items are entered when manually entering a move order:
1.3.1. Header
A move order number can either be entered or generated by the system. A description can be entered but it is not necessary and the Status field displays Incomplete until the move order is approved. Information in the Header block defaults to the tabbed regions, however, these fields can be overridden at the move order line level.
1.3.2. Default
The following need to be either entered or selected:
o Transaction type:
§ Account transfer: Transfer items from a subinventory to a destination account.
§ Subinventory transfer: Transfer items from one subinventory to another within the same inventory organization.
§ Move order issue: Issues items to a designated location.
§ Issue to project: Issues items to a designated project.
o Ship to Location: If the transaction type is move order issue, or issue to project, the ship to organization can be entered.
§ Source Subinventory: The source subinventory.
§ Destination Subinventory: The destination subinventory for subinventory transfers.
o Destination Account: The destination account number for account transfers.
o Date Required: The date the items are required to be transferred.
1.3.3. Item Tab
In the Item tabbed region, the following information needs to be entered or updated:
o Line: The line number.
o LPN: The LPN put away. This field will display if Oracle Warehouse Management is installed.
o Item: The item number for which a move order will be performed.
o Quantity: The quantity to be moved.
o Rev: Revision control number (if the item is under revision control).
o UOM: The unit of measure.
o Date Required: The date the items are required to be in the destination subinventory.
1.3.3. Project and Task Tab
If Project Manufacturing is installed the following in the Project and Task tabbed region can be selected:
o LPN: The LPN put away. This field will display if Oracle Warehouse Management is installed, and the client is working with a WMS enabled organization.
o Task: The task associated with this item.
1.3.4. Source Tab
The following can be optionally entered or updated in the Source tabbed region:
o LPN: The LPN put away. This field will display Oracle Warehouse Management is installed, and the client is working with a WMS enabled organization.
o Subinventory: The source subinventory for this item.
o Locator: The source locator.
o Lot Number: The lot number (if the item is under lot control).
o Serial From: The beginning serial number (if the item is under serial number control).
o Serial To: The ending serial number (if the item is under serial control).
1.3.5. Destination Tab
If the transaction type is Subinventory Transfer, the following needs to be entered or updated:
o LPN: The LPN put away. This field will display Oracle Warehouse Management is installed, and the client is working with a WMS enabled organization.
o Subinventory: The destination subinventory.
If the transaction type is Account Transfer, the following needs to be entered or updated:
o Account: The destination account.
o Locator: The destination locator.
1.4. Control Considerations
1.4.1. Business Process Variables
o None
1.4.2. Control Dependencies
o None
1.4.3. Control Limitations
o None
1.4.4. Testing Notes
o Inventory movements, transactions and activities should be controlled and monitored for accuracy, recorded in the proper period and all required information should be sent to General Ledger Module. Movement activities directly affect the inventory balance from each Company, Organisation and Sub-inventory.
o Inventory balances should be periodically analysed by management for reasonableness. Current period balance should be compared to different periods to identify unexpected variations or possible errors when closing the current accounting period.
o Management also should review the inventory activity to identify slow-moving, obsolete, scrapped or damaged items (using the Movement statistics report and Shortages Summary Report).
2. Inventory Counts
Within Oracle, there are 2 methods to verify inventory quantities. Physical inventory counts and/or cycle counting can be used to verify inventory quantities and values. Accurate system on–hand quantities are essential for managing supply and demand, maintaining high service levels, and planning production. The general process flow for Inventory counts is below, and each count's process is described in detail below.
2.1. Physical Inventory Count
A Physical Inventory Count is the counting of all items in an organization, inventory or location. The process of setting up and completing a Physical Inventory Counts are described in detail below.
2.1.1. Defining Physical Inventory
An unlimited number of Physical Inventories Counts can be defined. Multiple physical inventories can be defined to count selected portions of inventory, or the total inventory can be counted. To define a Physical Inventory Count, the following must be created within the Defined Physical Inventory form.
2.1.1.1. Approval Required
For each defined Physical Inventory Count, approval of counting variances can be always required, only required when the variance is outside of defined tolerances, or never required.
2.1.1.2. Approval Tolerances
If approval is required for adjustments out of tolerance, approval tolerances must be defined. Values can be either:
§ Qty: Positive and Negative limits (expressed as a percentage) can be defined for the difference between the system-tracked on-hand quantity and the actual tag count quantity.
§ Value: Positive and Negative limits can be defined for the total value of a physical inventory adjustment.
2.1.1.3. Physical Inventory Scope
Determines whether the physical inventory count is for all subinventories or for one or more specific subinventories.
2.1.1.4. Allow Dynamic Tags
Determines whether manually created tags can be dynamically entered. If disabled, all tags must generated before use.
2.1.1.5. Snapshot
Before tags can be generated for a physical inventory a snapshot of all system on-hand quantities for your items must be taken. This concurrent process saves all current item on-hand quantities and costs. Oracle Inventory uses this information as the basis for all physical inventory adjustments.
2.1.2. Generate Tags
Physical inventory tags are used to record the physical counts of inventory items. Physical inventory tags represent actual hard copy tags that some companies use to count inventory items. A tag contains the count for a group of a given item. Although only one item can be noted on a tag, multiple tags can reference the same item, with each tag referring to a unique physical location for an item.
2.1.3. Enter Counts
After physically counting the inventory items, the item quantity must be entered for each tag. Once the quantities have been entered and saved, Oracle Inventory determines whether any adjustments need to be approved.
2.1.4. Approve Adjustments
After the tag counts are entered, Oracle automatically compares the item's entered tag count quantity to the snapshot's item quantity. Based upon the approval configurations defined within the inventory count, any variances can be subject to approval. Any variance that requires approval is listed in the Approve Physical Adjustments window. From this form, each item's adjustments can be viewed, rejected, or approved.
2.1.5. Processing Adjustments
After all tag counts are entered and all adjustments are approved, a process can be submitted that automatically creates the physical inventory adjustments. The Process Physical Inventory Adjustments concurrent program creates a material transaction adjusting the item quantity and a journal entry debiting or crediting the adjustment account specified within the inventory. Once this program is run for the physical inventory, Oracle Inventory does not allow new tag generation does not allow any other changes to that physical inventory.
2.2. Cycle Counts
Cycle counting is the periodic counting of individual items throughout the course of the year to ensure the accuracy of inventory quantities and values. A cycle count can be defined at either the organisation or sub-inventory level, and an unlimited number of cycle counts can be defined and maintained in Oracle Inventory.
2.2.1. Defining Cycle Counts
A combination of parameters constitutes a cycle count header, identified by the cycle count name. An unlimited number of cycle counts can be entered and maintained in Oracle Inventory. For example, separate cycle counts can be defined representing different sets of subinventories or high theft risk items in a warehouse. A number of variables can be defined for each cycle count, as outlined below.
2.2.1.1. Potential Scope and Controls
Configuration Name
|
Setting
|
Count Controls
|
· Inactive On: Determines the date in which the cycle count is no longer active.
· Late Days: Number of workdays that can pass after the date the count request was generated, before a scheduled count becomes a late count.
· Starting Sequence: The sequence number is used as the starting number in the next count request generator. The count sequence number uniquely identifies a particular count and is used in ordering the cycle count listing.
· Unscheduled Entries: If enabled, items not scheduled to be counted can be added to the cycle count.
· Display System Quantity: If enabled, the system on-hand quantities are displayed during count entry.
|
Automatic Recount
|
Determines whether Inventory automatically assigns a status of Recount to out-of-tolerance counts and includes them in the next cycle count listing. If enabled, the Maximum field value must be defined. This value is the maximum number of times Inventory can generate an automatic recount request. Once this number is reached the adjustment must be approved or rejected
|
Count Subinventories
|
Determines if all subinventories or only specific subinventories are included in the cycle count. If only selected subinventories are to be counted, they must be defined.
|
2.2.1.2. Serial and Schedule
Configuration Name
|
Setting
|
Serial Control Option-Count
|
These options determine whether to exclude serialized items from the cycle count.
· Not Allowed
· One Per Request: Creates one count request for each serial number
· Multiple Per Request: Create multiple serial details in a count request
If either One Per Request or Multiple Per Request is selected, the remaining Serial Control fields must be completed.
|
Serial Control Option-Detail
|
· Quantity and Serial Numbers: Serial number and quantity are required and are validated when entering adjustments.
· Quantity Only: Serial number entry is optional if the count quantity matches the system quantity, regardless of whether the serial numbers match. If serial numbers are not entered, the count is marked as completed, and no adjustments are performed. If serial numbers are entered, both quantity and serial numbers are validated when determining whether adjustments are required.
|
Serial Control Option-Adjustment
|
· Adjust if Possible: If a discrepancy exists between the count quantity and system quantity or if the entered serial numbers do not correspond to the serial numbers already in the specified location, then the system will attempt to make adjustments if the adjustment variance and value are within tolerances. These adjustments consist of receipts and issues of the appropriate serial numbers to and from the specified location and are applicable only to instances in which new serial numbers or shipped serial numbers are counted.
· Review All Adjustments: No automatic adjustments are attempted.
|
Serial Control Option-Discrepancy
|
Indicates whether an adjustment is attempted when a count includes a serial number already assigned to the same item elsewhere in the system.
|
Auto Schedule-Frequency
|
Indicates whether to schedule cycle counts Daily, Weekly, or By period.
Inventory uses this information, along with the count frequency of each cycle count class, when performing automatic cycle count scheduling. The value entered here dictates the window of time within which counts can be entered against a schedule bucket.
|
Auto Schedule-Count Zero Quantity
|
If enabled, the application will automatically generate requests to count items with an on-hand quantity of zero.
|
Auto Schedule-Last Date
|
Inventory displays the last date this cycle count was automatically scheduled.
|
Auto Schedule-Next Date
|
Inventory displays the first workday for the next schedule interval when this cycle count is scheduled. You can enter a later date in this field if you want to override the automatic schedule and skip one or more intervals. If your schedule interval is Weekly or By period, the date you enter must be the first workday of the period for which you want to generate schedule requests.
|
2.2.1.3. Adjustments and ABC
Configuration Name
|
Setting
|
Approval-Required
|
For each defined cycle count, approval of counting variances can be:
· Always required
· If out of Tolerance
· Never
|
Tolerance Quantity Variance and Adjustment Value
|
If approval is required for adjustments out of tolerance, approval tolerances must be defined. Values can be either:
· Qty: Positive and Negative limits (expressed as a percentage) can be defined for the difference between the system-tracked on-hand quantity and the actual tag count quantity.
· Value: Positive and Negative limits can be defined for the total value of an inventory adjustment.
|
Tolerance-Hit/Miss Analysis
|
Defines percentage variances of count quantity to on-hand quantity beyond which Inventory considers a count entry a miss for hit/miss reporting.
|
ABC Initialization-Group
|
This value is the ABC group name on which to base the cycle count item initialization or update.
|
ABC Initialization-Option
|
Choose one of the following options:
· None: Do not change to the list of cycle count items.
· (Re)initialize: Use the ABC group you specified to load all items and their ABC assignments into the list of items to include in your cycle count. If you already had items defined for your cycle count, this action deletes existing information and reloads the items from the ABC group.
· Update: Use the ABC group you specified to insert new cycle count items.
|
ABC Initialization-Update Classes
|
If the update option is chosen, this value must be enabled or disabled. If enabled, if an item's ABC class assignment in the ABC group specified is different from the cycle count class this item is assigned, Inventory updates the cycle count class for the item with the ABC assignment in the specified ABC group.
|
ABC Initialization-Delete Unused Items
|
If enabled, the application will delete unused item assignments that are no longer referenced in the specified ABC group.
|
2.2.1.4. Item
The Cycle Count Items window is used to add items to a cycle count. This form can be used to schedule, generate count requests for, and count only those items that are included in this list. In addition, approval variance quantities can be defined for individual items.
2.2.1.5. Classes
The Cycle Count Classes window is used to add classes to a cycle count. This form can be used to schedule, generate count requests for, and count only those classes that are included in this list. In addition, approval variance values, quantities, and hit/miss values can be defined for individual classes.
2.2.2. Scheduling Cycle Counts
Oracle Inventory allows for 2 methods to schedule cycle counts, as outlined below.
2.2.2.1. Automatic Scheduling
Oracle Inventory uses the number of items in each cycle count class, the count frequency of each class, and the workday calendar of the organization to determine how many and which items to be counted during the scheduling frequency. In order for Inventory to perform automatic scheduling the following must be defined:
§ Set the Cycle Count Enabled item attribute to Yes for the items to be included in the cycle count.
§ Enable automatic scheduling when cycle counts are defined.
§ Request the schedule using the Generate Automatic Schedule Requests window.
Each time the auto scheduler runs, it schedules counts only for the schedule interval defined for the cycle count header. For example, if the schedule interval is weeks, Inventory schedules all items that need to be counted on all of the workdays in the current week. If the schedule interval is days, then Inventory only schedules those items that are due for counting on the current date.
2.2.2.2. Manual Scheduling
Manually scheduled counts can be used in addition to, or instead of those generated with automatic scheduling. Request counts can be created for specific subinventories, locators, and items, and set the count for any inventory date.
For example, a request can be entered to count item A wherever it can be found in subinventory X. Or a request can be entered to count all item quantities in subinventory Y, locator B–100. Since manually scheduled counts have no impact on automatically scheduled counts, some items may be counted more frequently than initially planned.
2.2.3. Generate Count Requests
After counts have been scheduled, a process must be submitted to generate count requests. This process takes the output of the automatic scheduler and the manual schedule entries, and generates a count request for each item number, revision, lot number, subinventory, and locator combination for which on-hand quantities exist. Oracle Inventory assigns a unique sequence number to each count request that can be used for reporting, querying, and rapid count entry. Because the count requests are derived from the state of on-hand balances at the time the Generate Cycle Count Requests process is run, this should not be run until just prior to the actual count.
2.2.4. Enter Counts
After physically counting the cycle count items, the item quantity must be entered for each item. These counts can be entered via the Cycle Count entry form. In addition, counts can be also be uploaded via the Oracle Open Interface program, and updated via the form shown below.
Once the quantities have been entered and saved, Oracle Inventory determines whether any adjustments need to be approved.
2.2.5. Automatic Recounts
If the Automatic Recount option is enabled for the Cycle Count, Oracle Inventory automatically submits recount requests for items that are outside the limits of the defined approval tolerances. Inventory submits recounts as many times as necessary, limited by the maximum automatic recounts specified for the cycle count. After the maximum number of recounts is reached, Inventory holds the count for approval. Any count request with the Recount status automatically appears on the next cycle count listing. Recounts can also be manually requested during the adjustment approval process. recounts when you are approving adjustments.
2.2.6. Approve Adjustments
After the cycle counts are entered, Oracle automatically compares the item's entered count quantity to the count request item quantity. Based upon the approval configurations defined within the cycle count, any variances can be subject to approval. Any variance that requires approval is listed in the Approve Cycle Count Adjustments window. From this form, each item's adjustments can be viewed, rejected, submitted for recount, or approved.
2.2.7. Processing Adjustments
After all tag counts are entered and all adjustments are approved, a process can be submitted that automatically creates the physical inventory adjustments. The Process Physical Inventory Adjustments concurrent program creates a material transaction adjusting the item quantity and a journal entry debiting or crediting the adjustment account specified within the inventory. Once this program is run for the physical inventory, Oracle Inventory does not allow new tag generation does not allow any other changes to that physical inventory.
2.3. Control Considerations
2.3.1. Business Process Variables
o Pending transactions and the Transactions Open Interface should be cleared before taking a snapshot.
o Oracle Inventory does not stop inventory processing during a physical inventory. Therefore procedures should be in place to ensure that no transaction activities occur until after all counts and adjustments have been performed.
2.3.2. Control Dependencies
o Oracle Inventory posts no physical inventory adjustments if any adjustments are still pending approval. All of the adjustments should be approved or rejected before they can be processed.
o If the client does not have any tolerances defined for an item, it uses the tolerances defined for that item's cycle count class. If there are not any defined for the class, it uses the tolerances at the cycle count header level. If there are no tolerances defined for the header, Inventory assumes that there is no limit to the approval tolerance.
o The approval process for serialised items differs from that for non-serialised items. Serial numbers that are misplaced (at a different location or for a different item) cannot be adjusted.
2.3.3. Control Limitations
o If the approval option is set to “Never”, adjustments are processed with no regard to whether tags have been generated or whether counts were actually entered for all tags. For any tag that has no count entered, Oracle Inventory assumes a count of zero and performs adjustment transactions accordingly. Clients should exercise caution when setting this option to “Never” in order to ensure approval is required before adjustments are posted.
o Default adjustment accounts (set when defining cycle count) can be overridden when entering cycle count entries and when approving adjustments.
2.3.4. Testing Notes
o Approval options / tolerances should be set to appropriately limit the amount of differences that can be posted without management approval. These could be different depending on the type of goods: for example expensive electronic goods (0% tolerance) vs. newspapers/magazines. In the first case the “Approval Required” option should be set to “Always”. For low value or high volume goods, management could decide to use higher tolerance levels (e.g. 5%).
o Furthermore the Physical Inventory Missing Tag Listing should be reviewed as part of physical inventory procedures before adjustments are processed.
o Inventory at all locations should be subject to periodic physical counts to ensure inventory balances are complete and accurate.
3. Open Interfaces
Open interfaces are a functionality provided by Oracle Inventory to import inventory movements and cycle counts can be from external systems into Oracle Inventory. Transactions can be viewed, edited, and corrected for the current organization, or for multiple organizations in a given organization hierarchy, received through the transaction open interface. Using the folder or single row windows, the client can choose how to view the information appropriate for a particular transaction. The client can also resubmit transactions for processing.
3.1. Control Considerations
3.1.1. Business Process Variables
o None
3.1.2. Control Dependencies
o None
3.1.3. Control Limitations
o None
3.1.4. Testing Notes
o None
4. Period End Procedures
The period close process for Oracle Inventory enables summarising of costs related to inventory and manufacturing for a given accounting period. These costs are then transferred to the General Ledger for posting.
Oracle inventory provides the following features related to period end procedures:
Transfer inventory and manufacturing costs to the General Ledger.
Transfer summary or detail accounting information to the general ledger.
Independently open and close periods for each inventory organisation.
Perform interim transfers to the General Ledger without closing the period.
Maintain the same set of periods and fiscal calendar as for the General Ledger.
4.1. Procedures
The following steps could be considered in performing period-end processing for Oracle Inventory:
a) Complete All Transactions for the Period Being Closed
b) Check Inventory and Work in Process Transaction Interfaces
c) Check Oracle Order Management Transaction Processes
d) Review Inventory Transactions
e) Balance the Perpetual Inventory
f) Validate the Work in Process Inventory
g) Transfer Summary or Detail Transactions
h) Close the current Oracle Payables and Oracle Purchasing Periods
i) Close the Current Inventory Period
j) Open the Next Inventory Period
k) Run Standard Period-End Reports (Optional)
Client may have a checklist that contains the majority of these steps as relevant to their business. These may include:
4.1.1. Complete All Transactions for the Period Being Closed
Ensure that all issues, receipts, and adjustments have been entered and verify that no hard copy records exist or are awaiting data entry, e.g. packing slips in receiving. This may include verifying with Revenue & Receivables and Purchase to Payables that all shipments and goods receipts are complete for the period.
4.1.2. Check Inventory and Work in Process Transaction Interfaces
This configuration verifies that there are no background or concurrent programs unprocessed (Transactions Interface, Internal Transactions, and Demand Interface) and to fix any rejected transactions.
The interface managers which need to be run are as follows:
§ Material Transaction Manager
§ Material Cost Transaction
§ Move Transaction Manager
§ Resource Cost Transaction Manager
§ Check the Reservation Managers window
§ Demand Reservation Manager
Note: These may be run as part of a scheduled request.
4.1.3. Check Oracle Order Management Transaction Processes
This configuration ensures all sales order (Pick Release) issues through Oracle Order Management have been completed and transferred successfully to Oracle Inventory. If orders have not been released, they do not have to be completed.
4.1.4. Review Inventory Transactions
Before closing a period, review all of the transactions for the period that have a high dollar value and/or a high transaction quantity. Verify that the correct accounts have been charged. Correcting incorrect account charges before closing the period is easier than writing manual journal entries to resolve them later.
Prior to closing the inventory period, the client should verify which transactions are still pending. Transactions with the following status should be resolved:
o Resolution Required: displays the number of unprocessed material transactions, uncosted material transactions, and pending WIP costing transactions existing in this period. These must be resolved before the period is closed.
o Resolution Recommended: Displays the number of pending receiving transactions, pending material transactions, and pending shop floor move transactions existing in this period. The accounting period can be closed; however, after it is closed these transactions cannot be processed.
4.1.5. Balance the Perpetual Inventory
Check that the perpetual inventory value up to the end of the period being closed matches the value reported in the General Ledger. This balancing is usually effected automatically, but one of the following three sources may create a problem:
o Other inventory journal entries: Journal entries from products other than Oracle Inventory, that update the inventory accounts.
o Charges to improper accounts: For example, material issued from a sub-inventory to a miscellaneous account, but one of the sub-inventory accounts was used as that miscellaneous account.
o Transactions after period end reports: This occurs when the period-end inventory valuation reports are submitted before all transactions for the period have been completed. Use the Historical Inventory Balance Report to obtain period valuation information before the extra transactions.
o The following reports can be run to help with these reviews:
§ Inventory Value Report: Use the Inventory Value Report to show quantity, valuation, and detailed item information for the sub-inventories specified.
§ Period Close Value Summary Report: Use the Period Close Value Summary to see summary balances for sub-inventories. If this report is run for a closed accounting period, the report displays the sub-inventory values at the end of that period. If this report is run for an open period, the report displays the sub-inventory value at the point in time when the report is run. By running the Inventory Value Report, or the Elemental Inventory Value Report, more sub-inventory balance detail can be viewed.
§ Material Account Distribution Detail Report: Use the Material Account Distribution Detail Report to view the accounts charged for inventory transactions. Review inventory transaction values transferred to the general ledger by GL batch.
§ Material Account Distribution Summary Report: Use the Material Account Distribution Summary report to review inventory accounting activity.
§ Material Account Distribution Detail Report: Can be used to identify unusual accounts or amounts.
§ Material Account Distribution Summary Report : Can be used to verify inventory account activity against inventory valuation increases or decreases for the accounting period. Finally, use this report to reconcile an account across several periods.
4.1.6. Validate the Work in Process Inventory
If Oracle Work in Process is installed, check the work in process inventory balances against transactions with the WIP Account Distribution Report, by summary or detail.
The WIP Account Distribution Report details account information for work in process cost transactions, including resource, overhead and outside processing charges, cost updates, and period close and job close variances. The system groups the client's transactions by job or schedule, by transaction type, and orders the client's transactions by earliest transaction date. Detailed account information for specific accounts, general ledger batches, or both can be listed in order to help reconcile the general ledger.
The Material Account Distribution reports lists material cost transactions such as issues, completions, and scrap.
4.1.7. Transfer to GL
If time permits, it is recommended to run the Transfer transactions to GL process up to the period end date before closing the period. Closing a period automatically executes the general ledger transfer, but the process can be run without closing the period, using the General Ledger Transfer window. Since a period, once closed, cannot be reopened, running this process prior to closing the period facilitates proofing of the interfaces transactions and any adjustments to the period can be made via new inventory transactions as required.
When more than one period is open, the transfer selects transactions from the first open period up to the entered transfer date, and passes the correct accounting date and financial information into the general ledger interface.
When transferring detail entries, the accounting date in the GL_Interface table is populated with the period end date of the accounting period. When summary entries are with two periods open, and a transfer date is entered in the second period, the transfer process assigns the period one end date for all the summarised transactions in period one, and assigns the entered transfer date for the summarised transactions in period two.
View the General Ledger Transfer History to ensure that all transactions have been successfully transferred to the General Ledger. Navigate to the General Ledger Transfer window and search for all transfers with a status of Error.
The Journal Import Execution report should also be reviewed as part of the transfer to GL. This may be performed by the GL group (refer to General Ledger Practice Aid for additional details)
4.1.8. Close the current Oracle Payables and Oracle Purchasing Periods
Complete all steps required to close Oracle Payables and Oracle Purchasing. Oracle Payables is closed prior to Oracle Purchasing to enable running of purchase accruals to accrue expenses on un-invoiced receipts. If Oracle Purchasing or Oracle Inventory are closed, a receipt cannot be entered for that period. However, as a manual procedure, Oracle Purchasing should be closed before Oracle Inventory.
4.1.9. Close the Current Inventory Period
Closing the inventory period using the Inventory Accounting Periods window automatically transfers summary transactions to the general ledger interface table. The earliest accounting period with a status of Open or Error.
This process needs to be performed for each Inventory Organisation defined. The period close performs the following:
o Closes the open period for Oracle Inventory and Oracle Work in Process.
o Creates summary or detail inventory accounting entries in the GL interface.
o Creates summary or detail work in process accounting entries in the GL interface.
o Calculates period-end sub-inventory balances.
For each sub-inventory, the period close period adds the net transaction value for the current period to the previous period’s ending value. This creates the period-end value for the current period. The period-end values by sub-inventory can be viewed via the Period Close Enquiry form, or reported with the Period Close Summary Report.
The period close process automatically transfers all job costs and variances by general ledger account. Discrete jobs and certain non-standard jobs are closed separately. Job close performs the necessary accounting for each job, including variance calculations. For expense non-standard jobs, the period close process writes off any remaining balances and transfers any period costs to the general ledger.
4.1.10. Open the Next Inventory Period
Open the next inventory period using the Inventory Accounting Periods window. This process needs to be completed for each Inventory Organisation defined.
4.1.11. Run Standard Period-End Reports (Optional)
o Inventory Value Report
o Reconcile Oracle Inventory with the General Ledger.
4.2. Control Considerations
4.2.1. Business Process Variables
o Period end procedures should be in place to ensure that all Inventory postings are accounted for in the correct period.
o Where more than one open period is determined, procedures should ensure they close within a few days after month end (2-5 days).
o For period-end adjustment purposes, it may be appropriate to hold more than one period open per inventory organisation at the same time, although at other times, having only one period open at a time ensures that transactions are correctly dated and posted to the correct accounting period.
4.2.2. Control Dependencies
o Closing an inventory period permanently closes the period and no further transactions can be charged to that period.
o The Transfer transactions to GL Process must be run for each Inventory Organisation. If this step was by-passed, and the period was closed, a GL Transfer would automatically be initiated, but no adjustments to that period could then be entered, since transactions cannot be posted to a closed period, and a closed period cannot be re-opened.
o Purchasing and receivables periods should be closed before Inventory period.
4.2.3. Control Limitations
o None
4.2.4. Testing Notes
o None
G. Inventory Security
1. Organisation Security
Clients can specify which organizations a responsibility can access by mapping responsibilities to organizations. Once this mapping is set up, a user logging into an Oracle Manufacturing product is restricted to the organizations mapped to the responsibility chosen. The Change Organization window is restricted as well.
Until an organization is assigned to a responsibility in this window, all responsibilities have access to all organizations. Once clients restricted any responsibility to an organization, they must then explicitly define the organizations which all responsibilities can access.
This feature does not restrict access once the user is in the application. Users with access to functions that cross multiple organizations (such as ATP, Inter-organization Transfers, Item Search, Multi-organization Quantity Report, and so on) can still specify any valid organization when running these functions.
System managers determine which responsibilities a user can access when they establish system security. Refer to the System Administration Practice Aid for more information on user assignments.
Users are able to easily inquire about, plan for and receive expected shipments against purchase orders or requisitions or RMAs originating in multiple operating units without needing to close windows and change responsibilities.
1.1. Control Considerations
1.1.1. Business Process Variables
o None
1.1.2. Control Dependencies
o None
1.1.3. Control Limitations
o None
1.1.4. Testing Notes
o None
2. Miscellaneous Transaction Form
2.1. Uses of Miscellaneous Transactions
Issue material to or receive material from general ledger accounts in the current organisation. This allows issuing material to groups that are not inventory, receiving, or working in process such as a research and development group or an accounting department.
Perform manual adjustments to the general ledger by receiving material from one account to inventory, and then issuing that material from inventory to another account.
Perform user-defined transaction types and sources to further classify and name the transactions. Use this feature to issue items to individuals, departments, or projects; or to issue damaged items to expense accounts such as scrap.
Receipt items that were acquired by means other than a purchase order from a supplier. Also this feature can be used to load all item on-hand quantities when the client starts implementing Oracle Inventory. If enabled, shortage alerts for the miscellaneous transaction type being performed can be set. Also, a miscellaneous transaction can trigger a shortage notification to be sent to various pre-defined individuals.
2.2. Control Considerations
2.2.1. Business Process Variables
o With a miscellaneous transaction, materials can be issued or received from general ledger accounts in the current organisation. This allows issuing material to groups that are not inventory, receiving, or working in process such as a research and development group or an accounting department inventory to another account.
2.2.2. Control Dependencies
o Access to Miscellaneous Transaction function should be restricted and monitored by management, in order to make sure that deliverables are physically received and transferred according to client requirements and avoid Inventory misstatement.
o Material Workbench lets users see material across organizations categorized into three buckets: Inbound, Receiving, On-hand.
o Professional Buyer Work Centre: buyers can view and manage documents like requisitions, purchase orders etc. across the entire operating unit they service. Similarly in Oracle Inventory, visibility to Purchase Orders, Advanced Shipment Notices, and Internal Orders across operating units through one form greatly increases the information available and facilitates better decision-making.
2.2.3. Control Limitations
o Deliverables can be physically received using the Miscellaneous Transaction function “Receipt items that were acquired by means other than a purchase order from a supplier”. Also, manual adjustments to the general ledger by receiving material from one account to inventory can be made.
2.2.4. Testing Notes
o None
H. Restricted Access/Segregation of Duties
When conducting an Oracle restricted access / segregation of duties review, there are three main access considerations:
· Application Setups
· Standing Data
· Segregation of Duties
1. Application Setups
Application Setups are defined as configurations that change the behaviour of the application. Examples of potential Application Setups within the Inventory process include:
- Inventory Module
- Organisations
- Subinventories
- Items
- Costing
These setups are generally only configured upon installation, upgrades, or major business events. Changes in business process setups could cause system failure and/or data inconsistencies. Therefore, access to these setups should be restricted to the IT department or similar technical role.
In addition, because of the potential impact on key financial controls associated with these setups, any changes to these should be implemented via the client’s stated change management process & controls. Please note that the definition of what constitutes application setups will vary from client to client, and practitioners should discuss these concepts with clients prior to commencing any Oracle work.
2. Standing Data
Standing Data are defined as either setups that affect the processing of transactions or is used in the processing of transactions that could have a financial statement impact. Examples of potential Standing Data within the Inventory Cycle include:
· Item Master
· Item Entry
· Item Costs
· ABC Analysis
These setups are generally configured upon installation, upgrades, or major business events. However, they may also need to be changed periodically to reflect ongoing changes to the business environment. Changes in standing data could cause financial processing difficulties and/or changes to standard transaction accounting procedures. Therefore, access to these setups should be limited to a select few business process or IT owners who do not have transactional access.
Changes to Standing data setups should be approved prior to implementation due to their potential impact on key financial controls and/or processes. Please note that the definition of what constitutes standing data will vary from client to client, and practitioners should discuss these concepts with clients prior to commencing any Oracle work.
3. Segregation of Duties
Segregation of Duties is defined as segregating access to two or more sensitive functions that, when combined, could present a risk of material misstatement, management override, fraud or theft.
3.1. Designing SoD
Segregation of Duties and Restricted access design could be complex and is dependent upon each client's environment. Clients should acknowledge the inherent accounting and unique business risks that require certain activities to be performed by different individuals. In either circumstance, the rules and related documentation developed should be associated with the client's significant financial risks.
Segregation of Duties and Restricted access design could include a balance between separating all conflicting activities and mitigating all segregation of duties violations. This decision making process should include formal elements of SoD analysis. When designing SoD principles, the following should be kept in mind:
· Envision the “ideal” environment, regardless of head count. However, risk and likelihood should be considered.
· Smaller areas / business units may not be able to implement proper SoD rules due to resource constraints.
· All high-risk financial systems should be considered, not just Oracle.
· When SoD is impossible, mitigating / compensating controls should be identified
Generally, the following SoD principles should be adhered to:
· Users with transactional access are restricted from standing data and application setup.
· Cross module (currency, ledger) and/or hidden access (process tab) should typically not exist
· Users should not be able to create and approve their own transactions.
· Custody of assets is separate from accounting transactions.
· IT support should not violate the SoD rules. Support procedures should be developed that will allow for the effective remediation of technical issues while giving the business process owners a stable, controlled, monitored accounting environment.
3.2. Documentation of Rules
Management should have a formal set of documents identifying the relevant segregation of duties and restricted access risks and conflicts that could exist for each in scope business cycle. This set of documentation should then include the relevant segregation of duties and restricted access controls that the client implemented to mitigate these risks. These controls could include a balance between segregation of duties, restricted access and/or other business mitigating controls.
Ideally, the client has developed a matrix of business processes (including Oracle functionality) that identifies the SoD and restricted access rules for a business process. An example of this matrix is identified below. The X's in the matrix identify the SoD conflict between the x and y axis of the matrix. The H's identify the agreed-upon sensitive business transactions that should also be tested with regards to restricted access.
3.3. SoD Monitoring
Once rules are established, the client can then determine the more effective cost of the control to mitigate the segregation of duties risk or to rely on the separation of conflicting activities. Small environments could leverage a manual approach to SoD management. Large environments will almost always require technology to manage SoD effectively. Typically SoD management is driven and managed by the technology group. Unless the business process owners sponsor and drive the project, SoD management is often much less effective.
3.3.1. Manual Monitoring
If the client chooses to sustain SoD on paper, then the following may be used:
o Access Authorisation: Testing the authorisation sign-off form is a common test for IT general control reviews. In this, evidence that existing user access was compared to requested access should be documented. Access authorisation makes an assumption that management understands the risk of granting the additional access and the functions associated with each responsibility
o SoD Maintenance: If the client's responsibility design is good, then the client might have a higher-level SoD matrix based on Oracle responsibilities. This responsibility-level SoD matrix would help management more quickly identify potential SoD issues before granting additional access.
3.3.2. Automated Monitoring
If the client chooses technology to help sustain their SoD environment, then the client should maintain testing over the design and implementation of the solution and document their daily use of the solution. On-going maintenance of the technology solution should follow the client's formal change management process and controls.
3.4. Control Considerations
3.4.1. Business Process Variables
o The challenge to our clients is that they either do not have the necessary time and staffing resources to identify and document the segregation of duties rules applicable to the company or they underestimate the commitment required.
o Not only should specific SoD issues be addressed, but clients should look to identify the root cause of these issues.
o RBAC (Role Based Access Control, described further in the system administration practice aid) is currently only applicable for self-service applications (iTime, iExpense, iProcurement, etc).
o Each client's Segregation of Duties principles must be considered in light of the client's specific business processes and risks.
3.4.2. Control Dependencies
o None
3.4.3. Control Limitations
o The majority of Oracle seeded responsibilities contain SoD conflicts.
o Clients tend to build their responsibilities based on functionality and often simply make copies of the default Oracle responsibilities, with minor modifications. It's highly likely that these revised responsibilities have SoD conflicts…oftentimes unbeknownst to clients.
3.4.4. Testing Notes
o For general guidance on Access and Segregation of Duties control considerations in the context of a financial audit or an audit of internal controls over financial reporting, refer to PwC Audit 4164 and 4164.01.
o For a suggested list of detailed SOD principles and their associated risks, refer to PwC GATE. GATE's standard reports contain baseline, generic rules that are industry agnostic and should be tailored/customized for each client's environment.
o PwC should recognise how the client manages SoD and make adjustments to the testing strategy accordingly.
o In complex environments such as Oracle EBS, practitioners should consider going beyond the access approval form and consider the overarching process management uses when deciding to approve access.
o Processes Tab Access: "AZN" menus are those menus that are associated with the Process Navigator Tab. When testing for segregation of duties, the reports generated from the tool will identify the menus associated with the issue.
o Without understanding the menu being used and the implications with the "AZN" menu, the segregation of duties analysis will appear to contain many false positives. Practitioners should be aware of the AZN menu and help the client understand where the excessive or conflicting access exists.
o As many concurrent processes have the similar financial impact as the direct entry of transactions (AutoInvoice, Automatic Journal Posting, Revenue Recognition), they should be included in SOD analysis; where those transactions are deemed to be relevant to the scope of procedures.
o PwC should also expect false positives in the SoD analysis. False positives are results in the SoD analysis that indicate where issues exist when they do not or are simply less pervasive.
o PwC should confirm the legitimacy of the SoD rules and test results prior to raising issues with the client.
o Currently, GATE scripts cannot be used with clients who have RBAC installed.
I. Key Inventory Reports
Report Name
|
Description
|
Physical Inventory Item Accuracy Report
|
Use the Physical Inventory Item Accuracy Report to report on physical inventory adjustments
|
Global Transaction Purge
|
Use the Global Transaction Purge Report to purge inventory transactions across multiple organizations set up in a hierarchy.
|
Open Period Status Control
|
Use the Open Period Status Control program to open a period across multiple organization and periods.
|
Close Period Status Control
|
Use the Close Period Status Control program to close a period across multiple organizations and periods.
|
Item Sub-inventory Report
|
This report lists items assigned to sub-inventories. You can also use this report to:
- Review items restricted to sub-inventories
- Identify items min-max planned at the sub-inventory level
- Review the default requisition information used by the replenishment processor for items assigned to sub-inventories.
|
Item Organization Assignment Report
|
Use the Item Organization Assignment program to assign an item, range of items, category set, or range of categories to multiple organizations belonging to the same Item Master Organization. This aids in the management of item setup and maintenance and is useful for companies that have a large number of inventory organizations utilizing the same item master.
|
PAR Replenishment Count Worksheet
|
This report addresses requirements that relate to the health care industry. This report is similar to the Item Replenishment Count Report, but it addition captures information that is specific to hospitals. This report captures the time and date when you captured the count. It also captures the locator information, item and item description, count type, UOM, PAR level, count quantity, supply quantity, Reorder Expense Quantity Account, Source Type, Source Organization, and Source Sub-inventory When you run this report, it reflects the changes made to the setup of the replenishment count header and lines.
|
Min-Max Planning Report
|
This report shows planning information for all items, or items with on-hand balances either below or above their assigned minimum or maximum on-hand quantities. You also have the option to generate internal or purchase requisitions for Buy items and WIP unreleased jobs for all items for which the on-hand quantity plus the on-order quantity is less than the min-max minimum amount.
|
Lot Inventory Report
|
This reports provides an overview of item lots, quantities, and lot statuses in all or the selected subinventories and locators within the organization. This aids the management in retrieving information regarding details of the lot inventory.
|
Material Status Definition Report
|
This report provides an overview of each material status and how it is used. This can help management identify enabled transactions for all material in each subinventory and also determines whether reservations are allowed for the subinventory, whether the material in the subinventory is included in ATP, or whether the material is nettable.
|
Lot Master Report
|
This report provides an overview of the information set up in the lot master. This report can be run for a specific item, or all items in the organization.
|
Grade Change History
|
This report provides a view to all of the grade changes made during a given time period for a particular item within an organization.
|
Item Cross-References Listing
|
User can use the Item Cross References Listing to report cross-references that associate with each item.
For example, it shows the relationships between new item numbers and other entities such as old item numbers by defining cross-reference types. Using these cross-reference types, one can define cross-references to store additional information about inventory items.
|
Move Order Pick Slip Report
|
Use the Move Order Pick Slip Report to print move order pick slips. You can run this report before or after you commit the move order transaction.
|
Create Deferred Logical Transactions
|
The Create Deferred Logical Transactions concurrent request enables you to defer the creation of logical transactions for a pure shipment across multiple operating units.
|
J. Key Terms
A number of terms that are used within the Oracle Inventory module are listed below with an associated definition.
Term
|
Description
|
Accounting Flex field
|
The code used to identify a general ledger account in an Oracle Financials application. Each Accounting flex field value corresponds to a summary or rollup account within the chart of accounts.
|
Action Set
|
A sequence of alert actions that are enabled for a particular alert. A sequence number to each action can be assigned.
An action set to specify the order in which the actions are performed can be included.
|
Adjustment Tolerance
|
Determines when Inventory does not make a cycle count adjustment. Inventory does not make an adjustment if the physical count differs from the on–hand inventory quantity by less than the specified tolerance. An adjustment tolerance can be defined when define an item is defined.
|
Alert
|
A mechanism that checks the database for a specific exception condition. An alert is characterised by the SQL SELECT statement it contains. A SQL SELECT statement tells the application what database exception to identify as well as what output to produce for that exception.
|
Alert Action
|
An action the client wants the alert to perform. An alert action can depend on the output from the alert. An action can include sending an electronic mail message to a mail ID, running an Oracle Applications program, running a program or script from the operating system, or running a SQL script to modify information in the database. It is possible to have more than one action for an alert, and an action can incorporate the output of the alert.
|
ATP
|
Available-To-Promise is an ability of Oracle to determine manufacturing / delivery dates from the estimated time it will take to manufacture. This is driven from customer requests for an item.
|
Audit Trail
|
Audit Trail tracks which rows in a database table(s) were updated at what time and which user was logged in using the form(s). Several updates can be tracked, establishing a trail of audit data that documents the database table changes.
|
Backflush
|
Backflush is the process of performing costing in a Just in Time environment, by flushing costs out of the system and charging them directly to the Finished Goods inventory account.
|
Bill of Material
|
A list of component items associated with a parent item and information about how each item relates to the parent item. Oracle Manufacturing supports standard, model, option class, and planning bills. The item information on a bill depends on the item type and bill type. The most common type of bill is a standard bill of material.
|
BOM item type
|
An item classification that determines the items that can be used as components in a bill of material. BOM Item types include standard, model, option class, and planning items.
|
Buyer
|
Person responsible for placing item resupply orders with suppliers and negotiating supplier contracts.
|
Category
|
Code used to group items with similar characteristics, such as plastics, metals, or glass items.
|
Cost Type
|
A set of costs for items, activities, resources, outside processing, and overheads. The client may have unlimited cost types for each organisation, but only one is used to record cost transactions. The Frozen Standard cost type is used for standard costing; the Average Costs type is used for Average costing. Others could be defined for simulation or temporary purposes.
|
Cost Variance
|
The difference between the actual and expected cost. Oracle Manufacturing and Payables supports the following cost variances: invoice price, resource rate, and standard cost variances.
|
Destination Organisation
|
An inventory organisation that received item shipments from a given organisation.
|
End Item
|
Any item that can be ordered or sold.
|
Finished Good
|
Any item subject to a customer order or forecast.
|
Fixed Lot Size Multiplier
|
An item attribute the planning process uses to modify the size of planned order quantities or repetitive daily rates for the item. For discretely planned items, when net requirements fall short of the fixed lot size multiplier quantity, the planning process suggests a single order for the fixed lot size multiplier quantity.
|
Fixed Order Quantity
|
An item attribute the planning process uses to modify the size of planned order quantities or repetitive daily rates for the item. When net requirements fall short of the fixed order quantity, the planning process suggests the fixed order quantity. When an item. A forecast for an item has a forecast date and an associated quantity.
|
General Ledger transfer
|
The process of creating a postable batch for the general ledger from summarised inventory/work in process activity for a given period. Using Journal Import in General Ledger, a postable batch in the general ledger can be created. After running Journal Import, the journal can be posted using the General Ledger posting process.
|
Internal orders
|
Orders that are performed between organisations within the same entity / group of companies. Records are maintained to identify these, but typically on consolidation they will net off (purchase order in Company A nets off against Sales orders in Company B for these sales orders).
|
Inventory Parameters
|
The set of controls, default options, and default account numbers that determine how Inventory functions.
|
Item Attribute control level
|
To maintain item attributes at the item master attribute level or the organisation specific level by defining item attribute control consistent with the company policies. For example, if the company determines serial number control at headquarters regardless of where items are used, serial number attribute control at the item master level can be defined and maintained. If each organisation maintains serial number control locally, they maintain those attributes at the organisation specific level
|
Item Attributes
|
Specific characteristics of an item, such as order cost, item status, revision control, COGS account, etc.
|
Item Master
|
This is the list of all items in an organisation.
|
Item Master Level Attributes
|
An item attribute the client controls at the item master level as opposed to controlling at the organisation level.
|
Lot
|
A specific batch of an item identified by a number.
|
Material Transaction
|
Transfer between, issue from, receipt to, or adjustment to an inventory organisation, sub inventory, or locator. Receipt of completed assemblies into inventory from a job or repetitive schedule. Issue of component items from inventory to work in process.
|
Organisation–Specific level Attribute
|
An item attribute the client controls at the organisation level.
|
Perpetual Accounting
|
Describes the inventory process whereby an organisation maintains inventory and cost of good sold records on a per transaction basis. Inventory transactions are accounted for as each sales order or purchase order is fulfilled.
|
Periodic Accounting
|
Describes the inventory process whereby stock counts are taken on a periodic basis to determine the cost of goods sold, and inventory values.
|
Picking Rule
|
A user–defined set of criteria to define the priorities Order Management uses when picking items out of finished goods inventory to ship to a customer. Picking rules are defined in Oracle Inventory.
|
Planned Purchase Order
|
A type of purchase order issued before actual delivery of goods and services for specific dates and locations are ordered. The client normally enters a planned purchase order to specify items the client wants to order and when the client wants delivery of the items. Later a shipment release against the planned purchase order can be entered when the client actually want to order the items.
|
Quantity Variance Tolerance
|
A limit that can be defined for the difference between the on–hand quantity and the actual cycle count quantity. A positive and negative quantity variance tolerances as percentages of the on–hand quantity can be expressed.
|
RMA
|
Permission for a customer to return items. Receivables allow the client to authorise the return of sales orders as well as sales made by other dealers or suppliers, as long as the items are part of the item master and price list.
|
Serial number
|
A number assigned to each unit of an item and used to track the item.
|
Serial Number Control
|
A manufacturing technique for enforcing use of serial numbers during a material transaction.
|
Serialised Unit
|
The unique combination of a serial number and an inventory item.
|
Set of Books
|
A financial reporting entity that partitions General Ledger information and uses a particular chart of accounts, functional currency, and accounting calendar. This concept is the same whether or not the Multi–organisation support feature is implemented. In R12, this is now a Ledger. See the Oracle R12 RL Practice aid for more information on this new concept.
|
Standard Item
|
Any item that can have a bill or be a component on a bill except planning items, option classes, or models. Standard items include purchased items, subassemblies, and finished products.
|
Standard Purchase Order
|
A type of purchase order issues when delivery of goods or services for specific dates and locations for the company are ordered. Each standard purchase order line can have multiple shipments and the quantity of each shipment across multiple accounts can be distributed.
|
Work in process
|
An item in various phases of production in a manufacturing plant. This includes raw material awaiting processing up to final assemblies ready to be received into inventory.
|
Work day calendar
|
A calendar that identifies available workdays for one or more set.
|
No comments:
Post a Comment