Search Results g_item_name




Overview

INV_MWB_GLOBALS is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, validated as of the 12.1.1 and 12.2.2 releases. The name encodes its purpose: INV identifies the Oracle Inventory product family, MWB refers to the Material Workbench, and GLOBALS signals that the package holds shared state, debugging utilities, and helper logic used across the Material Workbench feature set rather than implementing a single business transaction. It is classified under the ETRM "OTHER" API category, meaning it is not a public, supported integration interface but an internal utility unit invoked by Oracle's own forms and concurrent program code.

In business terms, the Material Workbench is the consolidated Inventory window through which warehouse and planning users search, view, and manage on-hand balances, material transactions, and pending receiving or shipping activity. INV_MWB_GLOBALS supports that experience by providing the plumbing that captures runtime parameters, exposes developer diagnostics, and surfaces standardized message text to the user interface layer.

Key Procedures and Functions

ETRM documents three callable units within the package body:

  • PRINT_PARAMETERS — Renders the currently cached Material Workbench parameter values in a readable form. It is a diagnostic aid used to confirm exactly which search criteria, organization context, or session settings the workbench has captured before a query is executed.
  • DUMP_PARAMETERS — Writes the same global parameter state to a debug destination such as DBMS_OUTPUT or a log table. Whereas PRINT_PARAMETERS formats values for display, DUMP_PARAMETERS is intended for server-side troubleshooting when a form or concurrent request behaves unexpectedly.
  • PRINT_MSG — Centralizes message output for the workbench, allowing calling code to emit a consistent, translated message string rather than hard-coding text. This supports Oracle's multi-language (NLS) requirements and keeps user-facing feedback uniform.

No formal parameter signatures are documented in the ETRM metadata, and none should be assumed; these are internal helpers whose signatures are subject to change without notice.

Tables Accessed

The ETRM listing records no direct table references through APPS synonyms. The only database-level dependency shown is on the SYS.STANDARD package, which is the implicit PL/SQL base package present in every compiled unit. Practically, this confirms that INV_MWB_GLOBALS is a thin state-and-utility layer: it manipulates in-memory global variables and delegates any real data retrieval to other packages. The one documented package dependency is INV_TRX_UTIL_PUB, the public Inventory transaction utilities package, which suggests the globals package leverages shared transaction helper routines when formatting or validating context information. Because no base tables are touched, the package carries negligible direct I/O cost.

Usage Notes

INV_MWB_GLOBALS is not referenced by any database object according to ETRM, yet it is reported as being referenced by eleven other packages. This apparent contradiction is typical of Oracle's internal code: the references originate in PL/SQL source units whose dependencies are captured at a different granularity, and the callers are Oracle-owned Material Workbench and Inventory packages rather than customer objects. Typical invocation paths include the Material Workbench forms (INVTOMWB and related Inventory windows) during form initialization and query execution, and diagnostic sessions where a developer enables server output and calls DUMP_PARAMETERS to inspect the global state.

Because the package is classified as OTHER and is not a published API, it should not be called from custom extensions or concurrent programs. Oracle does not guarantee signature stability across patches or upgrades, so custom code that binds to these procedures risks breakage on application of a family pack or 12.2.x upgrade. Customers needing equivalent functionality should rely on supported Inventory public APIs or build independent logging utilities within their own schema.