Search Results reason_code_disp

Overview

APPS.RA_TAX_EXEMPTIONS_STRC_V is a read-only Oracle E-Business Suite view that exposes customer tax exemption records in a report-friendly, denormalized form. Its defining characteristic is that it presents the "STRC" (structure) of each exemption — that is, the raw identifiers, flexfield segments, and attribute columns — while resolving two coded lookup values into their user-visible meanings via outer and inner joins to AR_LOOKUPS. The view is owned by the APPS schema and is available in both 12.1.1 and 12.2.2; the 12.2.2 ETRM metadata confirms the owner and referenced objects, and the view text is identical across the two releases.

The view's principal purpose is reporting and integration. Rather than requiring Report Builder, Discoverer, OBIEE, or an interface program to independently join RA_TAX_EXEMPTIONS to AR_LOOKUPS, the view delivers the descriptive values STATUS_DISP and REASON_CODE_DISP directly alongside the coded columns STATUS and REASON_CODE. This is particularly relevant to the user's search term, "reason_code_disp": that column is the decoded meaning of the REASON_CODE lookup (LOOKUP_TYPE = 'TAX_REASON'), and it is the field most commonly selected when the exemption reason must appear on a printed or web-delivered report.

Underlying Base Objects

Per the documented view metadata, RA_TAX_EXEMPTIONS_STRC_V references two objects:

• AR_LOOKUPS (VIEW) — the Oracle Receivables lookup view over FND_LOOKUPS. It is joined twice in the view definition, using the aliases LK1 and LK2.
• RA_TAX_EXEMPTIONS (SYNONYM) — the synonym that resolves to the underlying tax exemption entity table. It is aliased EX in the SELECT.

The join to LK1 is an inner join: LK1.LOOKUP_TYPE = 'TAX_EXEMPT_STATUS' AND LK1.LOOKUP_CODE = EX.STATUS. Consequently, only exemption rows whose STATUS has a valid, enabled, non-disabled lookup row of that type are returned. The join to LK2 is an outer join (note the (+) operator on both LK2 predicates): LK2.LOOKUP_TYPE(+) = 'TAX_REASON' AND LK2.LOOKUP_CODE(+) = EX.REASON_CODE. This design guarantees that an exemption row is not lost when the reason code is null or has no corresponding lookup entry, in which case REASON_CODE_DISP returns null.

Key Columns

The view exposes EX.ROWID as ROW_ID, which permits row-level identification for certain Oracle Forms or client tools, plus the standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) and the concurrent-program audit columns (PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE, REQUEST_ID).

• TAX_EXEMPTION_ID — primary identifier for the exemption record; the principal join key to transaction or customer queries.
• ORG_ID — operating unit, enabling multi-org-restricted reporting.
• CUSTOMER_ID, SITE_USE_ID, INVENTORY_ITEM_ID — the exemption's scope: customer, customer site use, and (where applicable) item.
• EXEMPTION_TYPE, TAX_CODE, PERCENT_EXEMPT, CUSTOMER_EXEMPTION_NUMBER — core exemption detail: classification, associated tax code, exempt percentage, and the customer's exemption certificate number.
• START_DATE, END_DATE — the effective window for the exemption; these drive validity tests in reporting.
• STATUS / STATUS_DISP — the coded status and its decoded meaning from LOOKUP_TYPE 'TAX_EXEMPT_STATUS'.
• REASON_CODE / REASON_CODE_DISP — the coded exemption reason and the decoded meaning from LOOKUP_TYPE 'TAX_REASON'. REASON_CODE_DISP is the search target for this article.
• LOCATION_CONTEXT and LOCATION_ID_SEGMENT_1 … _10 — the location flexfield context and its segments.
• EXEMPT_CONTEXT and EXEMPT_PERCENT1 … EXEMPT_PERCENT10 — descriptive flexfield context and the ten exempt-percent attribute values.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 … ATTRIBUTE15 — the exemption record's descriptive flexfield columns.
• IN_USE_FLAG — controls whether the record is active for use by tax calculation.

Common Use Cases and Queries

The most frequent use case is a customer or audit report listing exemptions with human-readable status and reason. Because REASON_CODE is nullable and the LK2 join is outer, reports should tolerate or explicitly test for a null REASON_CODE_DISP. A second use case is validation of exemption data before migrating or reconciling it, where analysts compare coded versus decoded values across operating units. A third is integration extraction: interfaces that feed a downstream tax engine select the numeric identifiers and enumerated meanings from a single view, avoiding an additional lookup join.

A representative query returning active exemptions for an operating unit, sorted by customer and reason, is:

• SELECT tax_exemption_id, customer_id, site_use_id, tax_code, percent_exempt, start_date, end_date, status_disp, reason_code, reason_code_disp
• FROM apps.ra_tax_exemptions_strc_v
• WHERE org_id = :p_org_id
• AND in_use_flag = 'Y'
• AND TRUNC(SYSDATE) BETWEEN start_date AND NVL(end_date, SYSDATE)
• ORDER BY customer_id, reason_code_disp;

To isolate exemptions lacking a valid reason lookup — often an indication of setup or migration error — a report may filter on reason_code IS NOT NULL AND reason_code_disp IS NULL. Because the view contains a ROWID and performs no aggregation, it remains safe for row-level retrieval, though queries should always be restricted by ORG_ID where multi-org access is in force.