Search Results gmi_quantity_wrp




Overview
Explore in AI Chat

Overview

GMI_QUANTITY_WRP is an Oracle Process Manufacturing (OPM) inventory wrapper package owned by APPS and classified under the ETRM repository as an "OTHER" API. Its principal business function is to expose the OPM Inventory Quantities API to callers that are not able to invoke the underlying quantity posting logic directly — most notably external or batch processes that supply transaction data through flat files rather than through native PL/SQL collections. The package therefore acts as a thin technical façade: it accepts a working directory, an input file name, an output file name, and a field delimiter, reads inventory transaction data from the flat file, passes it to the OPM Inventory Quantities API, and writes any resulting error messages back to a second flat file. As a wrapper, it contains almost no business logic of its own; its value lies in file handling, session-level logging, and status propagation. The header information recorded in the package source identifies it as part of the GMIPQTWB / gmigapib source control family, with a last revision dated 2003, which is consistent with the long-term stability of the OPM inventory interfaces across the 12.1.1 and 12.2.2 application releases.

Key Procedures and Functions

The ETRM metadata documents four procedures and functions within the body, listed as POST, GET_FIELD, and GET_SUBSTRING, with the count totalling four when the overloaded forms are considered.

  • POST (procedure): The public entry point. It accepts a working directory, an input file name, an output file name, and a delimiter character, and serves purely as a wrapper that calls the Post transaction API wrapper function. It returns no value to the caller but propagates the internal return status.
  • POST (function): The counterpart implementation that performs the actual OPM Inventory Quantities API call. It reads item transaction data from the supplied flat file, submits it to the inventory quantities API, and routes any error messages to the designated output file. It additionally generates a status log named in the form wrapper<session_id>.log in the /tmp directory, providing a session-scoped audit trail of the run.
  • GET_FIELD (function): A parsing utility used internally to extract an individual field value from a delimited record read from the input file. The delimiter supplied by the caller governs how field boundaries are identified.
  • GET_SUBSTRING (function): A string-manipulation helper that supports field extraction and record interpretation, typically invoked alongside GET_FIELD when the input layout requires positional or partial-field handling.

Tables Accessed

The package operates against two key OPM inventory journal tables, referenced through APPS synonyms, together with the UTL_FILE server-side file package.

  • IC_JRNL_MST: The inventory journal master table. This is the primary target into which posted inventory quantity movements are recorded, and it is where the wrapped inventory quantities API ultimately commits transaction details.
  • IC_ADJS_JNL: The inventory adjustment journal table, used to capture adjustment-type quantity movements generated from the input file data.
  • UTL_FILE: The Oracle-supplied PL/SQL file I/O package. It is used to open, read, and close the caller-supplied input file and to write error messages and status information to the output file, all under the directory alias passed in p_dir.

Usage Notes

GMI_QUANTITY_WRP is not referenced by any other documented package, so it is intended to be invoked directly rather than through an internal call chain. Typical invocations are from concurrent programs or batch scripts that need to load inventory quantity transactions from a flat file generated by an external system, an EDI feed, or a legacy interface. Because the package relies on UTL_FILE, the database directory object referenced by p_dir must be correctly configured and the APPS schema must hold read and write privileges on it. Callers should monitor the wrapper<session_id>.log file in /tmp and inspect the designated output file for error messages, since the procedure reports status internally rather than raising exceptions to the caller. In Oracle EBS 12.1.1 and 12.2.2 environments the package remains an APPS-owned object, and any customization should be layered on top of the wrapper rather than modifying the OPM API it protects.