Search Results aso_i_receipt_methods_v




Overview

The ASO_I_RECEIPT_METHODS_V view is a public, APPS-owned database object within the ASO (Order Capture) product family of Oracle E-Business Suite, available in both the 12.1.1 and 12.2.2 releases. Its documented purpose is to expose the receipt methods that are available in Oracle Receivables (AR) so that they can be referenced from the Order Capture and order management flows. The view is classified as a simple, non-materialized view with a status of VALID in the ETRM dictionary, meaning it is a query-time projection over its base table rather than a stored copy of the data.

Because receipt methods are maintained centrally in Receivables, yet are consumed during order capture, quotation, and order entry, a dedicated view provides a controlled read surface. Applications, concurrent programs, and form LOVs can query this view to present a valid list of payment/receipt instruments (for example cash, check, credit card, or electronic funds transfer) without directly coupling to the AR base table's full column set. This isolation supports the Oracle EBS practice of routing external product access through APPS synonyms and views.

Underlying Base Objects

The view is defined over a single referenced base object: AR_RECEIPT_METHODS. In the documented 12.2.2 ETRM metadata, this base object is recorded as a SYNONYM resolved within the APPS schema. AR_RECEIPT_METHODS is the Receivables entity that stores the master list of receipt methods and their lifecycle attributes.

The view text shows a direct, unfiltered projection:

SELECT RECEIPT_METHOD_ID, NAME, START_DATE, END_DATE, MERCHANT_ID
FROM   AR_RECEIPT_METHODS

No joins, unions, or aggregations are involved. Consequently, the view is updatable in principle (subject to constraints on the base table), and it carries precisely the five columns listed above. In practice it should be treated as a read-only reporting surface. Because the view selects all rows with no WHERE clause, row filtering is the responsibility of the calling query.

Key Columns

  • RECEIPT_METHOD_ID — The unique identifier and primary key for the receipt method. This is the column most frequently searched and joined upon, serving as the foreign key referenced from AR receipt and transaction tables. It is the value passed as the receipt_method_id parameter throughout the EBS integration layer.
  • RECEIPT_METHOD_NAME — The descriptive name of the receipt method as configured in Receivables. In the underlying table this attribute is stored in the NAME column; the view's column listing documents it as RECEIPT_METHOD_NAME. It is the human-readable value typically shown in list-of-values fields.
  • START_DATE — The effective start date from which the receipt method is active and eligible for use.
  • END_DATE — The date on which the receipt method becomes inactive. This is often NULL for methods with no defined expiry.
  • MERCHANT_ID — The identifier of the merchant associated with the receipt method, relevant for credit card and payment processor configurations.

Common Use Cases and Queries

The view is commonly used to validate user input, populate LOVs, and resolve foreign-key values during order capture. A frequent pattern is to retrieve only active receipt methods by combining the start and end date columns:

SELECT RECEIPT_METHOD_ID, RECEIPT_METHOD_NAME
FROM   ASO_I_RECEIPT_METHODS_V
WHERE  NVL(START_DATE, SYSDATE) <= SYSDATE
AND    (END_DATE IS NULL OR END_DATE >= SYSDATE);

Another routine scenario is looking up the descriptive name and merchant for a known identifier — the exact case implied by the user search for receipt_method_id:

SELECT RECEIPT_METHOD_NAME, START_DATE, END_DATE, MERCHANT_ID
FROM   ASO_I_RECEIPT_METHODS_V
WHERE  RECEIPT_METHOD_ID = :p_receipt_method_id;

Because the view maps directly to AR, the returned identifiers are interchangeable with those in Receivables, allowing order data to be reconciled against AR receipts. Queries are executed under the APPS schema, and standard EBS security applies, so access depends on the responsibility and MO: Security profile of the session. Given the single-table definition, no special tuning beyond indexing on RECEIPT_METHOD_ID in the base table is required.