Search Results zx_exemption_reason_code

Overview

PA_OUTPUT_TAX_REASON_V is a lightweight, read-only view owned by the APPS schema in Oracle E-Business Suite, 12.1.1 and 12.2.2. The ETRM documentation annotates the object with the description "10SC Only," indicating it was introduced for a specific localization or statutory release (10SC) and is not part of the general global feature set. Functionally, the view exposes the subset of Oracle Tax (E-Business Tax / ETRM, product code ZX) exemption reason codes that have been defined as Oracle Projects tax-exemption reasons and that are currently active.

The object is a validation and presentation view rather than a data-capturing table. It serves as the Projects-side lookup source so that forms, reports, and concurrent programs in the PA module can present a validated list of tax exemption reasons for output tax determination. Because it draws directly from the shared FND_LOOKUPS repository, it guarantees that Projects uses exactly the same code set that E-Business Tax references via the lookup type ZX_EXEMPTION_REASON_CODE, eliminating duplicated or drifting exemption reason lists. It is appropriate both for report data sources and for integration extraction, since the view applies its own ACTIVE-date and ENABLED_FLAG filtering at query time.

Underlying Base Objects

The documented base objects are FND_LOOKUPS (VIEW) and FND_GLOBAL (PACKAGE).

• FND_LOOKUPS (view): The single table-level source inside the SELECT. All rows originate from this application lookup view, which is the standard repository for Oracle EBS lookup codes and their translatable meanings.
• FND_GLOBAL (package): Listed as a referenced object by the view metadata. FND_GLOBAL is the standard EBS package that stores and returns session context (user id, responsibility, application id, login id, and related globalization attributes). Its inclusion indicates the view is designed to resolve lookup values within the caller's session context, consistent with EBS convention for lookup-backed validation views.

The defining query is a simple filter-and-project over FND_LOOKUPS: it restricts rows to LOOKUP_TYPE = 'ZX_EXEMPTION_REASON_CODE' and ENABLED_FLAG = 'Y', then applies an ACTIVE-date range test using the start and end dates, each individually defaulted to the system date when null. This means a lookup with no start or end date is always considered active. Results are ordered by MEANING, producing an alphabetical presentation sequence rather than a code sequence.

No Projects (PA) base tables are referenced in the documented view text. The "PA" prefix reflects the consuming module and packaging intent, not the underlying data source.

Key Columns

The view exposes two columns. Their documented names in the view differ from the underlying lookup source columns:

• TAX_EXEMPT_REASON_CODE — The code portion, selected from FND_LOOKUPS.LOOKUP_CODE. This is the value that should be stored on and passed between Projects transactions, interfaces, and tax determination calls. It is the same code consumed by E-Business Tax for the ZX_EXEMPTION_REASON_CODE lookup type.
• TAX_EXEMPT_REASON — The display portion, selected from FND_LOOKUPS.MEANING. This is the user-facing, translatable description shown on forms, reports, and list-of-values implementations. Because MEANING is translation-enabled in FND_LOOKUPS, the value returned follows the ambient language of the session.

Note that the view does not project ENABLED_FLAG, the ACTIVE dates, the lookup type, or any tag/language columns. Consequently, the view is not intended for administration of exemptions, only for their consumption. It also does not expose the alias mapping of the underlying LOOKUP_CODE and MEANING names; a caller migrating from a direct FND_LOOKUPS query must map LOOKUP_CODE to TAX_EXEMPT_REASON_CODE and MEANING to TAX_EXEMPT_REASON.

Common Use Cases and Queries

The principal use case is populating a tax exemption reason list of values or report parameter set in the Projects module, restricted to currently effective exemption reasons. A straightforward query returns the full active list:

SELECT tax_exempt_reason_code,
       tax_exempt_reason
FROM   apps.pa_output_tax_reason_v
ORDER  BY tax_exempt_reason;

A second scenario validates a stored exemption reason before transmitting it to tax determination, ensuring the code is still enabled and within its active window at the time of the interface:

SELECT 'VALID' AS status
FROM   apps.pa_output_tax_reason_v
WHERE  tax_exempt_reason_code = :p_exempt_reason_code;

A third, common in reporting, is joining the view to Projects transaction data so output reports show the descriptive reason rather than the raw code. Since the view already orders by MEANING and filters inactive lookups, this join is typically written as an outer join to avoid dropping transaction lines whose exemption reason has since been end-dated:

SELECT t.project_id,
       t.tax_exempt_reason_code,
       v.tax_exempt_reason
FROM   pa_transactions t,
       apps.pa_output_tax_reason_v v
WHERE  t.tax_exempt_reason_code = v.tax_exempt_reason_code (+);

Because the view is read-only and carries no DML capability, it is safe for concurrent-report inclusion and for extraction into downstream tax or data-warehouse staging tables. Given the "10SC Only" designation, implementations on standard global configurations should confirm availability of the object before building dependent logic.