Search Results ar_transaction_grp




Overview
Explore in AI Chat

Overview

APPS.AR_TRANSACTION_GRP is a server-side PL/SQL package belonging to the Oracle Receivables (AR) module of Oracle E-Business Suite. It is classified as a GRP (group) package, a designation Oracle reserves for programs that bundle a related set of operations rather than exposing a discrete business API. In practice, AR_TRANSACTION_GRP provides the low-level transaction lifecycle handling used to move an AR transaction (an invoice, credit memo, debit memo, chargeback, or on-account credit) between the "incomplete" and "complete" states within the RA_CUSTOMER_TRX model.

The package is owned by the APPS schema, carries a VALID status in both the 12.1.1 and 12.2.2 releases, and holds no subobjects beyond its specification and body. Its position in the dependency tree is deliberately narrow: it reads the core transaction table and a small set of Receivables setup tables, and it is referenced by only one other package plus a small number of external callers. This confinement confirms its role as an internal utility rather than a general-purpose extension point.

Key Procedures and Functions

The ETRM metadata documents two procedures. No parameter lists are published, and none should be assumed; the descriptions below reflect their documented purpose only.

  • COMPLETE_TRANSACTION — Transitions a Receivables transaction from the incomplete state to the complete state. Completion is the business event that makes an invoice or credit memo eligible for posting to the general ledger, for customer balance updates, and for downstream processing such as dunning, statements, and collections. The procedure applies the completion logic required by the associated transaction type and batch source.
  • INCOMPLETE_TRANSACTION — Performs the reverse transition, returning a completed transaction to the incomplete state so that it can be amended, corrected, or reprocessed before being completed again. This is the mechanism behind the standard Receivables behavior in which a posted or unposted transaction is reopened for editing.

Both procedures operate on the transaction identified by the calling context and record the resulting status on the transaction header.

Tables Accessed

The package accesses four tables through APPS synonyms:

  • RA_CUSTOMER_TRX — The transaction header table and the primary target of both procedures. Status columns on this table are updated to reflect the completed or incomplete state, and the row supplies the transaction type, batch source, and currency context used by the completion logic. This is also the only table listed in the ETRM dependency extract for earlier releases.
  • AR_SYSTEM_PARAMETERS — Supplies Receivables system-level options that govern transaction processing behavior.
  • RA_BATCH_SOURCES — Identifies the batch source of the transaction and its associated completion and numbering attributes.
  • RA_CUST_TRX_TYPES — Provides the transaction type definition, including its class and the rules that determine how completion behaves for that type.

Usage Notes

AR_TRANSACTION_GRP is an internal package and is not published in the Oracle Receivables Open Interfaces or public API documentation. It is normally invoked indirectly rather than called directly by customer code. The standard entry points are the Receivables transaction windows and related forms, where completing or incompleting a transaction triggers this logic, and any concurrent or batch program that relies on the same completion path. The dependency listing shows JL_JLZZRCVI_XMLP_PKG as a referencing program, indicating that a localized concurrent program report also depends on this package.

Because the package is a GRP object with an undocumented parameter interface, customizations should not call COMPLETE_TRANSACTION or INCOMPLETE_TRANSACTION directly. Direct invocation risks bypassing validation and locking that the supported API layer performs. Where custom code must complete or reopen a transaction, the supported Receivables APIs should be used instead. Confirm the package status and body version in the target instance after any patch or upgrade, as the specification may be regenerated.