Oracle Cloud Inventory cheat sheet

Inventory organization is the unit that holds on-hand balances; it must be linked to a legal entity, an operating unit, and at least one inventory organization-level business function (e.g., Inventory Management, Manufacturing, Receiving).

Subinventory = physical or logical storage area inside one inventory organization; it carries its own locator control flag and asset/expense designation.

Locator control options are None, Prespecified, Dynamic entry, and Item level; when set to Item level, the item's Locator Control attribute decides behavior.

Locator structure is defined by a locator flexfield with up to 5 segments (e.g., Aisle-Rack-Bin-Level-Position); segment count is fixed at implementation and cannot be changed later.

Restrict locators to a subinventory by enabling locator/subinventory restriction; unrestricted locators can be used by any subinventory in the organization.

Item-subinventory (Item/Subinventory) relationships must exist before an item can transact in a subinventory unless the organization allows unrestricted item/subinventory assignment.

Organization parameters control negative balances (Allow/Do not allow), default locator, default material status, FIFO/LIFO cost method, and inter-organization transfer settings.

Material statuses (Active, Hold, Quarantine) control transaction and reservation eligibility; status is assigned at subinventory, locator, lot, or serial level.

Item master organization owns item definition; child organizations inherit attributes and may override only attributes flagged as organization-assigned.

Item attributes that drive behavior: Inventory Item flag, Stockable, Transactable, Reservable, Lot Control, Serial Control, Shelf Life, and Locator Control.

Costing attributes (costing enabled, inventory asset value) must be set before any transaction; changing them after transactions exist requires careful handling and may be blocked.

Template (attribute group) assignment copies a predefined set of attribute values at item creation; templates reduce manual entry but do not lock later edits unless attributes are read-only.

Item categories belong to a category set; each category set has a controlled-at level (Item, Organization, or both) that determines where the category assignment lives.

Lot control options: No lot control, Full lot control, and Lot control at subinventory transfer; serial control: No serial control, Predefined serial, and Dynamic serial.

Units of measure: primary UOM is fixed once transactions exist; dual UOM (secondary UOM) supports catch-weight items and converts via UOM conversion classes.

Item statuses (Active, Inactive, Pending) restrict transaction entry; an inactive item blocks new transactions but existing on-hand remains visible.

Receipt routing options: Standard (direct to inventory), Inspection Required, and Direct Delivery (to a customer/sales order destination).

Standard receipt flow: create receipt (ASN or manual) → receive → deliver to inventory destination; inspection flow inserts an 'inspect' step before delivery.

Receiving is performed against a purchase order, an inter-organization transfer, or an RMA; each receipt line references the source document and shipment.

Put away rules map receipt lines to destination subinventory/locator based on item, category, or source; without a rule, the default receiving subinventory is used.

Over-receipt tolerance and receipt date tolerances are set on the PO/ purchasing options; exceeding tolerance requires override authority.

Return to vendor (RTV) reverses a receipt and can be performed before or after delivery to inventory, depending on the return reason.

Correcting a receipt: unreceive returns quantity to the shipment stage; correcting a delivered receipt requires an inventory adjustment or RTV.

Receiving inspection results (accept, reject, accept-with-deviation) determine whether quantity moves to inventory or to a reject subinventory.

Transaction types are seeded (Miscellaneous Issue, Miscellaneous Receipt, Subinventory Transfer, Direct Org Transfer, WIP issue, Sales Order Issue) and each has a transaction source and action.

Miscellaneous issue decreases on-hand and posts to the specified account; miscellaneous receipt increases on-hand and posts to the receipt account.

Subinventory transfer moves quantity within one organization; direct organization transfer moves between inventory organizations and is the basis for inter-org transfers.

Movement request (transfer order) is a two-step flow: ship from source organization, then receive into destination organization; in-transit inventory is tracked between steps.

Reservations allocate on-hand to a demand source (sales order, work order); reservable must be enabled on the item and the subinventory must allow reservations.

Transaction reasons are configurable codes attached to adjustments and issues; they drive reporting and can be tied to account aliases.

Transaction date defaults from the current date; backdated transactions are allowed only within open inventory periods and may affect costing.

Pending transactions can be viewed in the transaction interface; failed transactions require correction of the error and resubmission.

Physical inventory: freeze the organization (or subinventory) to prevent transactions, generate count tags, enter counts, approve adjustments, then unfreeze.

Cycle counting: ABC classifications drive count frequency; counts can be scheduled by subinventory, locator, item, or category with a defined count frequency.

Count adjustments post to the adjustment account; approval workflow can be enabled so adjustments above a threshold require approval before posting.

Adjustment types: increase/decrease quantity, change material status, change lot/serial attributes; each creates a transaction record for audit.

Cost methods: Standard, Average, FIFO, LIFO, and Periodic Average; the method is set at organization level and applies to all items in that organization.

Standard costing uses a defined cost per item; variances (purchase price, usage, rate) are recorded separately and do not change on-hand value.

Average costing recalculates the average unit cost on each receipt; issues use the current average at the time of the transaction.

Period close: run cost processor, review and resolve cost errors, transfer to general ledger, then close the inventory period; a period cannot close with pending cost adjustments.

Inventory integrates with Purchasing (receipts), Order Management (reservations and shipping), Manufacturing (WIP issues and completions), and Cost Management (periodic cost processing).

Open interfaces / import: item import, on-hand balance import, transaction import, and count import; each uses a defined interface table and validation program.

REST APIs and web services expose inventory organizations, on-hand quantities, transactions, and movement requests for external integration.

Standard reports: on-hand quantity, item valuation, transaction history, subinventory transfer, and cycle count variance; scheduled reports can be delivered to a BI Publisher output.

Period close checklist: verify all transactions are processed, resolve costing errors, run cost processor, reconcile inventory to GL, close subledger period, then close GL period.

Reconciliation compares inventory valuation to the GL inventory account balance; differences usually trace to unprocessed transactions or cost adjustments.

Subledger accounting (SLA) derives journal entries from inventory transactions using journal line rules and account derivation rules; account aliases can override default accounts.

Integration errors are typically visible in the transaction interface, cost interface, or import error tables; correct the source data and resubmit.

Inventory roles are job-based (e.g., Inventory Manager, Warehouse Operator, Cost Accountant); privileges are granted through roles, not directly to users.

Data security policies restrict access by inventory organization, business unit, or subinventory; users see only organizations in their assigned security profile.

Function security controls access to pages and actions (e.g., create adjustment, approve count); a user needs both function privilege and data access.

Approval workflows (e.g., inventory adjustment approval, cycle count approval) use the approval management framework with rules on amount, item, or organization.

Transaction reasons and account aliases are extensibility points that let you drive accounting and reporting without code changes.

Sandbox customization and application composer enable page layout changes; extensions should be layered on top of seeded objects rather than modified directly.

Audit: transaction history and adjustment records are retained; use the audit trail or transaction inquiry to trace who changed quantity, cost, or status.

Segregation of duties: the person who counts should not be the person who approves the adjustment; enforce via role design and approval rules.