Search Results def_rec_pp_set_option_code

Overview

AP_PREPAY_DEF_TAX_EXTRACT_V is a public Oracle E-Business Suite view owned by the APPS schema within the Oracle Payables (AP) module. It exposes prepayment-related tax distribution and tax line information in a renamed column format that is purpose-built for the prepayment tax extract process. The view is documented as VALID in ETRM metadata for EBS 12.1.1 and 12.2.2.

Functionally, the view is a thin projection layer over the E-Business Tax (ZX) extract view ZX_AP_DEF_TAX_EXTRACT_V. Its role is to surface tax extract data using AP-specific column aliases (for example REC_NREC_PP_TAX_DIST_ID rather than REC_NREC_TAX_DIST_ID), so that downstream Payables reporting, extraction, and integration logic can reference prepayment tax attributes under a consistent AP naming convention. Because it filters nothing and joins nothing, it is best understood as an aliasing interface between the E-Business Tax engine and Payables-side consumers rather than an independent data source.

Underlying Base Objects

The view is defined exclusively over a single referenced base object:

• ZX_AP_DEF_TAX_EXTRACT_V (VIEW) — the E-Business Tax extract view that supplies the underlying tax distribution, summary tax line, and tax line identifiers, along with recoverability, settlement option, tax account, operating unit, and ledger attributes.

The relationship is a straightforward one-to-one SELECT projection. Every column returned by AP_PREPAY_DEF_TAX_EXTRACT_V originates from the corresponding column in ZX_AP_DEF_TAX_EXTRACT_V; the only transformation applied is column renaming. No WHERE clause, aggregation, or join is present, so one row in the ZX view produces exactly one row in the AP view. Practically, this means the cardinality, performance characteristics, and data content of AP_PREPAY_DEF_TAX_EXTRACT_V are entirely inherited from ZX_AP_DEF_TAX_EXTRACT_V, and any tuning or diagnostic work should target the ZX base view and its own underlying tax tables.

Key Columns

The view exposes eight renamed columns, each mapping directly to a Tax view column:

• REC_NREC_PP_TAX_DIST_ID — from REC_NREC_TAX_DIST_ID; the recoverable/non-recoverable tax distribution identifier for the prepayment.
• SUMMARY_TAX_PP_LINE_ID — from SUMMARY_TAX_LINE_ID; the summary-level tax line identifier associated with the prepayment distribution.
• TAX_PP_LINE_ID — from TAX_LINE_ID; the detailed tax line identifier.
• TRX_PP_LINE_DIST_ID — from TRX_LINE_DIST_ID; the transaction line distribution identifier linking the tax record to the Payables distribution.
• RECOVERABLE_PP_FLAG — from RECOVERABLE_FLAG; indicates whether the tax amount is recoverable.
• DEF_REC_PP_SET_OPTION_CODE — from DEF_REC_SETTLEMENT_OPTION_CODE; the default recovery settlement option code applied to the tax line.
• TAX_PP_ACCOUNT_CCID — from TAX_ACCOUNT_CCID; the chart of accounts combination identifier for the tax accounting entry.
• ORG_PP_ID and LEDGER_PP_ID — from ORG_ID and LEDGER_ID; the operating unit and ledger identifiers, providing the multi-org and ledger context for the extract row.

Common Use Cases and Queries

This view is typically consumed by prepayment tax extraction programs and by reporting that must present Payables prepayment tax data using AP column semantics. Typical scenarios include reconciling recoverable versus non-recoverable prepayment tax, verifying the tax account CCID assigned to prepayment tax lines, and auditing default recovery settlement options across operating units and ledgers.

A representative query listing prepayment tax distributions with their recovery status and accounting context:

• SELECT REC_NREC_PP_TAX_DIST_ID, SUMMARY_TAX_PP_LINE_ID, TAX_PP_LINE_ID, TRX_PP_LINE_DIST_ID, RECOVERABLE_PP_FLAG, DEF_REC_PP_SET_OPTION_CODE, TAX_PP_ACCOUNT_CCID, ORG_PP_ID, LEDGER_PP_ID FROM APPS.AP_PREPAY_DEF_TAX_EXTRACT_V;
• Filtered to a single operating unit and ledger: ... WHERE ORG_PP_ID = :p_org_id AND LEDGER_PP_ID = :p_ledger_id;
• Isolating non-recoverable tax lines for review: ... WHERE RECOVERABLE_PP_FLAG = 'N';

Because no filtering is applied at this layer, callers should always constrain results by ORG_PP_ID, LEDGER_PP_ID, or the relevant distribution identifier to avoid full scans of the inherited ZX extract result set.