Results for “return_reason_code”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

ASO_I_RETURN_CODES_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite. It belongs to the ASO - Order Capture product family and is documented with a status of VALID in both Release 12.1.1 and 12.2.2. The view exposes a lightweight, denormalized list of return reason values that Order Capture and related order-management flows use as a list of values (LOV). Its stated purpose in the ETRM documentation is concise: the view "is used as an LOV for return reasons."

Functionally, the view is not a transaction-bearing object. It is a reference data source. Rather than storing or persisting return reason definitions itself, it projects a filtered subset of Oracle Receivables lookup values so that ASO-based forms, concurrent programs, and integrations can present a controlled pick-list of valid return reasons without querying AR_LOOKUPS directly. This separation lets Oracle maintain a single source of truth for credit memo and return reason codes while giving Order Capture a purpose-built view whose column names reflect the business concept ("return reason") rather than the underlying lookup taxonomy.

Because the view is defined over a lookup table, its content is configuration-driven. Rows appear only where a system administrator or implementer has enabled a lookup of the relevant type. Ordering, enablement dates, and descriptive meaning all derive from the base lookup record.

Underlying Base Objects

The documented view text is:

SELECT LOOKUP_CODE, MEANING FROM AR_LOOKUPS WHERE LOOKUP_TYPE = 'CREDIT_MEMO_REASON'

The single referenced base object is AR_LOOKUPS, itself a view in the Oracle Receivables schema. AR_LOOKUPS is the standard EBS lookup construct that stores code-and-meaning pairs categorized by LOOKUP_TYPE. ASO_I_RETURN_CODES_V imposes a fixed filter on that source, restricting output to rows whose LOOKUP_TYPE equals the literal value 'CREDIT_MEMO_REASON'.

The relationship is therefore one of projection and filtering rather than aggregation or joining. No additional tables are joined, and no columns beyond the lookup code and its meaning are surfaced. Because AR_LOOKUPS is itself a view, the resolution chain extends further into the underlying lookup base tables, but the ETRM metadata documents only AR_LOOKUPS as the direct reference. This means the view inherits the security, enablement, and multi-organization characteristics of the standard lookup mechanism.

Key Columns

• RETURN_REASON_CODE — the code value presented to the user or calling program. In the view text this is sourced from LOOKUP_CODE and represents the stored, language-independent identifier for the return reason.
• RETURN_REASON — the descriptive, user-facing text for the return reason. It is sourced from MEANING and is the value typically displayed in an LOV or printed on documentation.

An important observation is that the view text selects LOOKUP_CODE and MEANING, while the documented column list presents these as RETURN_REASON_CODE and RETURN_REASON. Implementers should therefore confirm the exposed column names against the deployed database definition rather than assuming the view text aliases match the cataloged names identically. The filter column (LOOKUP_TYPE) is not projected and is not selectable from the view.

Common Use Cases and Queries

The primary use case is populating a return-reason LOV within Order Capture, Returns, or RMA-adjacent flows. A typical query retrieving all currently defined return reasons is:

SELECT return_reason_code, return_reason FROM apps.aso_i_return_codes_v ORDER BY return_reason;

A lookup of a single reason by code, common in validation routines and integration mappings:

SELECT return_reason FROM apps.aso_i_return_codes_v WHERE return_reason_code = :p_reason_code;

The view also serves as a translation aid when converting an external system's return reason into an EBS-recognized value, and as a domain list for reports that must display a friendly label instead of a raw code. Because the view is driven by the 'CREDIT_MEMO_REASON' lookup type, administrators extend or retire available reasons by maintaining that lookup in Receivables; no change to the view itself is required. Integrators relying on the view should treat its contents as configuration data subject to change and should not hard-code reason values.