Search Results g_completion_transaction

Overview

WIP_RES_UTIL is a utility package in the Oracle E-Business Suite Applications (APPS) schema that supports the Work in Process (WIP) resource transaction and cost interface infrastructure. Its classification as a UTIL package indicates that it does not implement a business API in the transactional sense; rather, it provides generic row-level data manipulation and query helpers used by higher-level resource processing logic that stages resource transactions into the WIP cost interface for subsequent cost processing and accounting.

The package is declared AUTHID CURRENT_USER, meaning that its SQL statements execute under the privileges of the invoking session rather than the package owner. This is consistent with the standard EBS approach of relying on APPS synonyms and database grants to control access to underlying tables. The header comment dates the source to release 11.5 era maintenance (115.5, 2002), reflecting a long-lived component that has been carried forward relatively unchanged into the 12.1.1 and 12.2.2 releases.

A prominent characteristic of WIP_RES_UTIL is its use of positional global constants. Rather than referencing columns by name in generic row-handling routines, the package assigns each attribute of the underlying record a numeric ordinal. Values such as G_ACCT_PERIOD (1), G_ACTIVITY (2), G_ACTIVITY_NAME (3), and G_ACTUAL_RESOURCE_RATE (4) map to the leading fields of the resource transaction record, while subsequent constants (G_ATTRIBUTE1 through G_ATTRIBUTE15, G_AUTOCHARGE_TYPE, G_BASIS_TYPE, G_COMPLETION_TRANSACTION, and the standard WHO columns) index the remaining descriptive and auditing attributes. The constant G_ACTIVITY at position 2 is the identifier used to reference the activity column within this ordinal scheme.

Key Procedures and Functions

The package exposes eight documented procedures, all of a general-purpose row management nature:

• INSERT_ROW — Inserts a new row into the target resource table, populating columns according to the package's positional attribute mapping and defaulting auditing columns.
• UPDATE_ROW — Updates an existing row, identifying it by primary key and writing the supplied attribute values.
• DELETE_ROW — Removes a row from the target table based on its identifying key.
• LOCK_ROW — Acquires a row-level lock (SELECT FOR UPDATE semantics) to serialize concurrent modification.
• QUERY_ROW — Retrieves a single row and returns its attributes for processing by the caller.
• QUERY_ROWS — Retrieves a set of rows, supporting bulk or list-based processing.
• CONVERT_MISS_TO_NULL — Normalizes Oracle Forms "missing" values to database NULLs, a common need when Forms-built record structures feed PL/SQL table operations.
• PRINT_RECORD — Produces a diagnostic rendering of a record, used for debugging and trace output.

These routines constitute a lightweight CRUD and diagnostic layer rather than a functional business API.

Tables Accessed

Two tables are documented as referenced through APPS synonyms:

• WIP_COST_TXN_INTERFACE — The WIP cost transaction interface table, which stages resource and cost transactions for validation and transfer to the cost management and accounting modules. This is the principal data target of the row-level DML procedures.
• PLITBLM — A PL/SQL table used for bulk operations, typically passed as an IN OUT NOCOPY parameter carrying collections of records between the caller and the package's utility routines.

Usage Notes

WIP_RES_UTIL is not intended to be called directly by end users or by external integration code. It is an internal helper invoked by other WIP packages and by Oracle Forms-based maintenance screens that manipulate resource transaction interface records. The ETRM metadata records that the package is referenced by one other package, confirming its role as a subordinate utility rather than an entry point.

Because the procedures operate on ordinal attribute positions, callers must construct their PL/SQL record and table types consistently with the package's constant definitions; mismatch between caller record layout and the constant ordinals is the most common source of errors when extending or maintaining this code. Customizations should generally avoid modifying the shipped package and instead extend behavior through the calling packages, preserving the standard upgrade path for 12.1.1 and 12.2.2 patch levels.