Search Results aso_payments_pkg




Overview
Explore in AI Chat

Overview

ASO_PAYMENTS_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Oracle Advanced Supply Chain Planning / Order Capture foundation layer, specifically the ASO (Order Capture / Sales Order) module, where it supports maintenance of payment information associated with sales orders and related transaction documents. The package encapsulates the application logic used to create, modify, lock, and remove rows in the ASO_PAYMENTS entity, exposing this logic through the standard EBS table-handler (row-level API) pattern. It is classified as an "OTHER" API in the ETRM repository, meaning it is not part of the formally published public API surface but is a supporting internal package.

The body depends on ASO_PAYMENTS_S (the database sequence used to generate primary keys), ASO_UTILITY_PVT (shared order-capture utilities), FND_API (the generic EBS API error-handling and message framework), and FND_MESSAGE (message lookup). Its design reflects the conventional Oracle Applications pattern of pairing a sequence-driven table handler with the FND_API error stack and APP_EXCEPTION for controlled error propagation.

Key Procedures and Functions

ETRM documents five program units within the package body, with four named procedures explicitly listed. No parameter lists are published in the metadata; the descriptions below reflect the documented purpose of each unit.

  • INSERT_ROW — Creates a new payment record. It derives the new primary key from the ASO_PAYMENTS_S sequence, populates the WHO columns (created_by, creation_date, and related audit attributes) through FND_API conventions, performs the physical insert, and registers any error condition on the FND_API message stack.
  • UPDATE_ROW — Modifies an existing payment record. It applies changed column values, refreshes the WHO update columns, and uses the standard optimistic-locking comparison against the stored last_update_date to detect concurrent modifications.
  • LOCK_ROW — Acquires a row-level lock on a payment record without altering its data, allowing a caller to serialize subsequent updates and enforce concurrency control during multi-step transaction processing.
  • DELETE_ROW — Removes a payment record from ASO_PAYMENTS. Like the other handlers, it validates the operation and routes failures through the FND_API error stack rather than raising unhandled exceptions.
  • Fifth documented unit — ETRM records five program units but names only the four handlers above; the remaining unit is typically a private helper or validation routine invoked internally by the handlers and is not part of the callable surface documented here.

Tables Accessed

The package operates against two documented database objects, both reached through APPS synonyms:

  • ASO_PAYMENTS — the base transactional table holding payment records for order-capture documents. This is the target of the INSERT_ROW, UPDATE_ROW, LOCK_ROW, and DELETE_ROW operations.
  • ASO_PAYMENTS_S — the sequence supplying the unique primary key for each new ASO_PAYMENTS row during INSERT_ROW.

The package body also references DUAL and STANDARD from the SYS schema, consistent with sequence value retrieval and standard PL/SQL constructs.

Usage Notes

ASO_PAYMENTS_PKG is an internal table-handler package. It is not referenced by any other database object, and ETRM records that it itself references ASO_PAYMENTS, ASO_PAYMENTS_S, ASO_UTILITY_PVT, FND_API, FND_MESSAGE, and APP_EXCEPTION. In practice, packages of this type are invoked from Oracle Forms-based order-capture screens through the corresponding block-level triggers, or from concurrent programs and custom extensions that need to manipulate payment data while preserving EBS audit columns, sequence-generated keys, and FND_API error semantics. Because it is classified as OTHER rather than a public API, direct invocation from custom code should be undertaken with care; the supported approach is to drive changes through the owning application forms or through the higher-level order-capture APIs that ultimately delegate to this handler.