Search Results gmi_move_order_lines_pvt




Overview
Explore in AI Chat

Overview

GMI_MOVE_ORDER_LINES_PVT is a private PL/SQL package in the Oracle EBS Process Manufacturing (OPM/GMI) application, owned by the APPS schema. It encapsulates the server-side logic required to validate and process move order lines used in inventory and warehouse transfer transactions. Move orders represent requests to relocate material from one inventory location to another, and the line-level records capture the item, quantity, source and destination subinventories, and related transaction attributes. Because the package is classified as PVT (private), its routines are not intended to serve as a public integration point and are instead consumed internally by the parent GMI_Move_Order public APIs and their supporting components. The package explicitly declares AUTHID CURRENT_USER, meaning it executes with the privileges of the calling schema rather than the definer, a design choice that aligns with Oracle's standard API security model. Originating from the Oracle TVP development group in Reading, England, the package has been part of the OPM code line since 2000 and remains shipped in both the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The package exposes two documented program units:

  • PROCESS_MOVE_ORDER_LINES — The principal processing routine. It accepts an API version number, an initialization flag for the message list, a validation level flag, and a commit flag, together with an input table of move order line records. It returns an output table of move order lines, a return status, a message count, and message data. In keeping with Oracle API conventions, callers are expected to inspect the return status before relying on the output table, and to loop through the message stack when the message count exceeds one. The routine performs validation according to the supplied validation level, applies the required business rules to each line, and optionally commits the resulting changes.
  • CHECK_REQUIRED — A Boolean function that evaluates a single move order line record and determines whether the mandatory attributes for that line have been supplied. It is a supporting validation utility used internally during processing to enforce data integrity before any database write is attempted. Because it returns BOOLEAN, it cannot be called directly from a SQL statement and is only usable within PL/SQL.

Tables Accessed

The package reads and writes several inventory and transaction tables through APPS synonyms:

  • IC_TXN_REQUEST_LINES and MTL_TXN_REQUEST_LINES_S — the core move order line tables in OPM and Oracle Inventory respectively, holding the pending line records being processed.
  • IC_TRAN_PND — the pending inventory transaction table where validated move order movements are staged.
  • IC_ITEM_MST and MTL_SYSTEM_ITEMS — item definition tables used to validate the item on each line.
  • IC_WHSE_MST — the OPM warehouse master, used to validate source and destination warehouse context.
  • DUAL and PLITBLM — utility objects used for single-row selection and for concatenating or buffering message text within the API message stack.

Usage Notes

This package is invoked indirectly rather than as a standalone integration API. In a standard Oracle EBS deployment it is called by the public OPM move order processing logic — for example, when a user submits a move order through the OPM inventory forms or when a concurrent program or workflow activity processes pending move order lines in batch. It is referenced by one other package in the documented dependency set, confirming its role as a subordinate component. Custom code that has a genuine requirement to process move order lines should generally call the corresponding public API rather than this private package, since Oracle does not guarantee the private interface across patches or upgrades. Where direct invocation is unavoidable, callers must supply a correctly populated line table, honor the commit flag (passing FND_API.G_FALSE when the caller owns the transaction boundary), and always evaluate x_return_status and the message stack before proceeding.