Search Results ship_to_loc_id




Overview
Explore in AI Chat

Overview

GMF_MTL_GET_ORG_ID is a Process Manufacturing (OPM) utility package owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its business function is narrow and infrastructure-oriented: it resolves the organization code of an inventory organization under a set of filter criteria that include a date range, a lookup code, and a location identifier. The package therefore acts as a lookup service rather than as a transactional API, and it is classified in the ETRM repository as API classification OTHER. The header comment embedded in the source, $Header: gmforgib.pls 115.1 2002/10/29, indicates that the body has remained stable since the 11.5 code line, and the 115.x version numbering is consistent with the fact that the package was carried forward largely unchanged into the 12.x releases.

Key Procedures and Functions

Exactly one procedure is documented in the metadata for this package.

  • PROC_INV_GET_ORG_ID — The single public entry point. It opens (or reuses) the package cursor, fetches a single organization code, and returns it through an OUT parameter. Its parameter set is deliberately generic and carries the same shape as the cursor: a start date, an end date, a lookup code, a ship-to location identifier, the returned organization identifier, a row-to-fetch counter, and an error status. The procedure follows the classical OPM utility idiom in which caller-supplied parameters are declared IN OUT NOCOPY and the ERROR_STATUS OUT parameter is populated with an Oracle error number rather than raised as an exception. A value of 100 in ERROR_STATUS signals that the cursor returned no rows; otherwise the exception handler populates ERROR_STATUS with SQLCODE. The procedure closes the cursor when no row is found or when ROW_TO_FETCH equals 1, which allows a caller to page through multiple organization codes using the same open cursor.

Tables Accessed

The package references a single documented table through an APPS synonym:

  • ORG_ORGANIZATION_DEFINITIONS — The inventory organization definition table. The cursor selects ORGANIZATION_CODE from this table. In the documented source the predicate is the minimal WHERE ORGANIZATION_ID > 0, meaning the date range, lookup code, and ship-to location parameters supplied to the procedure are accepted and propagated to the cursor but do not restrict the result set in the code as shipped. This is significant for developers: the parameters are effectively placeholders, and the procedure returns the first qualifying organization code encountered.

No other tables, views, or package-level state are documented for this object, and the ETRM repository records zero packages that reference it.

Usage Notes

Because the package is not referenced by any other documented package and exposes a single low-level procedure, it is best understood as a private helper that has been exposed as a public database object rather than as a supported integration API. Typical invocation patterns are:

  • PL/SQL from OPM concurrent programs or custom code — A caller declares the IN OUT variables, invokes APPS.GMF_MTL_GET_ORG_ID.PROC_INV_GET_ORG_ID, then inspects ERROR_STATUS for 100 (no data) or a SQL error code, and consumes the returned organization code from INV_ORG_ID.
  • Cursor paging — Callers that need successive organization codes invoke the procedure repeatedly with ROW_TO_FETCH set to values other than 1 so the cursor remains open between calls, and finally set ROW_TO_FETCH to 1 to force the close.
  • Forms or reports — No documented Oracle Forms block or concurrent program is bound to this package in the ETRM metadata, so direct form-level invocation should be treated as unsupported.

The search term ship_to_loc_id matches the fourth formal parameter of PROC_INV_GET_ORG_ID. Developers tracing that column should note that the value is passed through to the cursor but is not used in the documented query predicate, so it has no filtering effect in this version of the body. Customizations that require true ship-to location filtering must be implemented by wrapping or replacing this procedure rather than by relying on its parameters.