Search Results rcv_transactions_util2




Overview
Explore in AI Chat

Overview

The APPS.RCV_TRANSACTIONS_UTIL2 package is a utility package within the Oracle E-Business Suite Receiving (RCV) module. Its documented API classification is OTHER, indicating that it is not a formalized public API but rather an internal helper package that supports the broader receiving transaction and receipt confirmation infrastructure. The package provides the procedural plumbing required to send receipt confirmation documents, maintain receiving transaction history records, and manage the workflow bookkeeping associated with these activities.

In Oracle EBS 12.1.1 and 12.2.2, receiving confirmation can be initiated as a workflow-driven business event, where notifications and documents must be dispatched to suppliers, requesters, or internal parties. RCV_TRANSACTIONS_UTIL2 encapsulates the low-level operations that support these processes, ensuring that transaction history is recorded consistently and that workflow items are correctly keyed. The package has a VALID status in the APPS schema and exhibits a small, focused dependency footprint, consistent with a utility rather than a business-facing API.

Key Procedures and Functions

The package exposes four documented procedures and functions:

  • SEND_DOCUMENT — Dispatches a document as part of the receiving confirmation flow, typically used to generate and transmit the confirmation output to the intended recipient.
  • SEND_RECEIPT_CONFIRMATION — Drives the sending of a receipt confirmation, orchestrating the notification logic so that the appropriate confirmation is delivered based on the receiving transaction context.
  • UPDATE_TXN_HISTORY — Writes or updates records in the receiving transaction history, capturing the state or outcome of a receiving transaction for audit and reporting purposes.
  • UPDATE_TXN_HIST_SUCCESS_WF — Updates the transaction history to reflect a successful workflow outcome, linking the history record to the workflow process that completed the confirmation.

These routines work collectively to bridge the receiving transaction data model with the workflow and notification layer. No parameter lists are documented, and consumers should not assume a public signature; the procedures are intended for internal invocation by the parent receiving packages.

Tables Accessed

The package references the following tables through APPS synonyms:

  • MTL_TXNS_HISTORY — The primary transaction history table, read and written by UPDATE_TXN_HISTORY and UPDATE_TXN_HIST_SUCCESS_WF to record receiving transaction outcomes.
  • HZ_CUST_ACCOUNTS — The customer account registry, consulted to resolve party and account information used when sending confirmation documents.
  • MTL_CLIENT_PARAMETERS — Stores client-level configuration settings, read to determine confirmation behavior and document handling options.
  • PO_WF_ITEMKEY_S — The purchasing workflow item key sequence, used to generate or reference workflow item keys that tie transaction history records to their originating workflow process.
  • DUAL — The standard Oracle dummy table, used for single-row evaluations and sequence/expression selection.

Usage Notes

RCV_TRANSACTIONS_UTIL2 is an internal utility and is not intended as a standalone extension point. It is referenced by the RCV_RECEIPT_CONFIRMATION package, which is the primary orchestrator of receipt confirmation workflow, and by RCV_TRANSACTIONS_UTIL2 itself through recursive calls. Custom code should generally invoke the higher-level RCV_RECEIPT_CONFIRMATION entry points rather than calling this package directly, because the utility routines assume a specific calling context and workflow state.

Typical invocation occurs during receipt confirmation processing, whether triggered from the Receiving forms, from the Receipt Confirmation concurrent program, or through workflow background engine activity. In 12.2.2, the same behavior is preserved within the Online Patching (adop) framework; the package remains VALID and is maintained as an internal dependency. Developers diagnosing confirmation or history-update issues should trace calls through RCV_RECEIPT_CONFIRMATION into this package, examining the MTL_TXNS_HISTORY records and workflow item keys as the primary evidence of execution.