Search Results inv_trx_mgr

Overview

INV_TRX_MGR is a core Oracle Inventory transaction management package owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. The package body provides the server-side entry points used to process material transaction batches and to generate or validate serial numbers for serial-controlled items. Its documented header comment traces the source to INVJTRXB.pls, version 120.1, last shipped in June 2005, indicating that the package has been stable across the 12.x release family and is reused largely unchanged in 12.2.2.

The body is architecturally significant because it acts as a thin PL/SQL veneer over Java-based transactional logic. The primary batch routine is declared with a LANGUAGE JAVA clause and maps directly to the class oracle.apps.inv.transaction.server.TrxProcessor.processTrxBatch, so most of the heavy processing of inventory transaction headers and lines occurs outside the database in the Oracle Inventory transaction server. The PL/SQL wrappers exist to expose that Java logic to Forms, concurrent programs, and other PL/SQL callers.

Key Procedures and Functions

• PROCESS_TRX_BATCH — This is documented in two forms. The first is the base Java-bound declaration, which accepts a transaction header identifier, commit and atomicity flags, a business flow code, and an OUT message parameter, and delegates execution to the Java TrxProcessor. The second is an overloaded PL/SQL wrapper that supplies a default business flow code of 0 and forwards all other arguments to the Java-bound version. Together they drive the processing of a staged inventory transaction batch identified by its header ID, controlling whether the work is committed or held, and whether the batch is treated atomically.
• GENERATE_SERIALS — Documented as an overloaded function and explicitly described as a wrapper for GENERATE_SERIALSJ with autonomous transaction support. The autonomous transaction pragma allows serial number generation to commit independently, which is essential when serial numbers must be reserved even if the calling transaction later fails or rolls back. Documented inputs include organization ID, item ID, quantity (count of serial numbers to create), WIP entity ID, revision, and lot number. Documented outputs include the starting serial, ending serial, and a process message, with a return status of 0 for success and 1 for error. The wrapper delegates the actual work to INV_SERIAL_NUMBER_PUB.GENERATE_SERIALS.
• VALIDATE_SERIALS — A counterpart routine used to validate serial numbers against the inventory organization, item, and related attributes before they are consumed or transacted. It confirms that supplied serials are valid, available, and consistent with the item and organization context.

The ETRM metadata lists four documented procedures or functions in total, comprising the two PROCESS_TRX_BATCH declarations, GENERATE_SERIALS, and VALIDATE_SERIALS.

Tables Accessed

The ETRM metadata does not enumerate specific base tables accessed through APPS synonyms for this package body. In practice, because the substantive logic is implemented in Java, direct table access from the PL/SQL body is limited. The serial number routines interact with serial number definition and assignment data maintained by INV_SERIAL_NUMBER_PUB, and transaction batch processing operates on material transaction header and line data through the Java transaction server rather than through SQL embedded in this package.

Usage Notes

INV_TRX_MGR is typically invoked indirectly. Material transaction batches are submitted through Oracle Inventory forms and concurrent programs, which call PROCESS_TRX_BATCH to hand a fully staged batch to the transaction server. GENERATE_SERIALS is called when an organization must pre-generate a range of serial numbers, such as during work in process completion or receipt processing, and its autonomous transaction behavior means callers should treat generated serials as already committed even if their own transaction is subsequently rolled back. VALIDATE_SERIALS is used as a pre-transaction check. Custom code should call the supplied wrappers rather than the Java-bound base declarations, and should observe the documented return status convention. The ETRM metadata notes that this package is referenced by one other package, confirming its role as a shared, low-level dependency rather than a top-level application entry point.