Search Results jl_zz_ar_tx_categ




Overview
Explore in AI Chat

Overview

The APPS.JL_ZZ_AR_TX_CAT_ATT_TN_V view is a tax configuration reporting object within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 releases, delivered as part of the Oracle Financials for Latin America (JL) localization family and specifically for the Taiwanese (TN) tax regime. It exposes the transaction-attribute rows that belong to the tax categories defined for the active tax rule set, presenting them in a denormalized, human-readable form suitable for reporting, integration, and diagnostics. Rather than returning raw identifier values, the view resolves lookup codes into descriptive meanings through calls to the JL_ZZ_AR_TX_LIB_PKG package, so downstream consumers can display attribute type and attribute descriptions without performing their own lookup joins. Its role is to support inquiry screens, tax setup verification, and integrations that require the mapping between a tax category and the transaction attributes that feed tax determination.

Underlying Base Objects

According to the ETRM metadata, the view is defined over four documented objects, all referenced as APPS synonyms: JL_ZZ_AR_TX_CAT_ATT, JL_ZZ_AR_TX_CATEG, AR_SYSTEM_PARAMETERS, and the package JL_ZZ_AR_TX_LIB_PKG. JL_ZZ_AR_TX_CAT_ATT is the primary driving table, storing the individual tax category attributes. JL_ZZ_AR_TX_CATEG supplies the tax category definition, and the join between these two tables is performed on TAX_CATEGORY_ID. AR_SYSTEM_PARAMETERS acts as a filtering mechanism: the view restricts results so that CAT.TAX_RULE_SET equals SYS.GLOBAL_ATTRIBUTE13, ensuring only attributes belonging to the currently active tax rule set are returned. JL_ZZ_AR_TX_LIB_PKG is not a table but a PL/SQL package invoked within the SELECT list to translate stored lookup codes into meaningful descriptions.

Key Columns

Common Use Cases and Queries

Typical usage includes verifying that transaction attributes are correctly assigned to a tax category, auditing priority and determining-factor settings before a cutover, and feeding reporting layers that need resolved descriptions. A representative query is:

SELECT tax_category, tax_attribute_name, attr_desc, mandatory_in_class, priority_number FROM apps.jl_zz_ar_tx_cat_att_tn_v WHERE tax_category = :p_category ORDER BY priority_number;

Integration developers frequently consume the same view to build extract files for external tax engines, joining its ATTR_DESC column to transaction data. Because the view already filters on the active tax rule set and on the TRANSACTION_ATTRIBUTE type, it is safe to query directly without re-applying those predicates, and its ROW_ID column supports row-level identification where the view participates in form-based maintenance.