Search Results ar_vat_tax_all_tl




Overview
Explore in AI Chat

Overview

AR_VAT_TAX_ALL_TL is the multi-lingual support (MLS) table that stores translated, language-specific descriptive attributes for every tax code defined in Oracle Receivables. In Oracle EBS 12.1.1 and 12.2.2, the base tax code definition resides in AR_VAT_TAX_ALL_B, while AR_VAT_TAX_ALL_TL holds the translatable text — most importantly the printed tax name presented to users and on transactional and tax reporting output. The table is owned by the AR schema and is documented as VALID within the Receivables product.

Because the object carries only descriptive, translatable attributes keyed to the parent tax code, its heuristic Data Vault classification is a satellite. It is mined as a standalone object with no outgoing foreign keys to independent hubs, and its grain is one row per tax code per installed language. This modeling suggestion reflects the fact that the table is entirely dependent on AR_VAT_TAX_ALL_B for its business identity and contributes no independent key structure of its own.

Key Information Stored

The table is defined with 10 documented columns. The structural anchor is the composite primary key AR_VAT_TAX_ALL_TL_PK, comprising VAT_TAX_ID and LANGUAGE. A second unique index, AR_VAT_TAX_ALL_TL_U1, enforces the same (VAT_TAX_ID, LANGUAGE) combination, confirming this pair as the business-key candidate and guaranteeing one translation row per tax code per language.

  • VAT_TAX_ID — surrogate identifier of the parent tax code; part of the primary key and the join column back to AR_VAT_TAX_ALL_B.
  • LANGUAGE — the installed language code for the translated row; the second component of the primary key.
  • SOURCE_LANG — the language from which the translation was derived, used by the MLS/translation framework.
  • PRINTED_TAX_NAME — the translated tax name printed on documents and reports; the primary descriptive payload of the table.
  • ORG_ID — the operating unit context associated with the tax code record, supporting multi-org reporting.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns tracking row creation and modification.

Note that the surrogate primary key (VAT_TAX_ID, LANGUAGE) coincides with the unique business-key candidate, so no separate alternate business key exists.

Common Use Cases and Queries

The most frequent use of this table is retrieving the localized tax name for a given tax code during reporting, tax register extraction, and interfacing to external tax engines. A typical query joins translated text to the base definition and filters on a single language:

  • Localized tax name lookup: SELECT b.VAT_TAX_ID, t.PRINTED_TAX_NAME FROM AR.AR_VAT_TAX_ALL_B b, AR.AR_VAT_TAX_ALL_TL t WHERE b.VAT_TAX_ID = t.VAT_TAX_ID AND t.LANGUAGE = USERENV('LANG').
  • Translation completeness audit: compare row counts per VAT_TAX_ID between AR_VAT_TAX_ALL_B and AR_VAT_TAX_ALL_TL to detect tax codes missing a translation in a required language.
  • Multi-language comparison reports: self-join or pivot on LANGUAGE to present the printed tax name across all installed languages.
  • Operating-unit reporting: filter by ORG_ID alongside the parent table for multi-org tax listings.

Related Objects

  • AR_VAT_TAX_ALL_B — the base (non-translatable) tax code definition; joined on VAT_TAX_ID and the parent of this MLS row.
  • AR_VAT_TAX_ALL_VL — the MLS view that presents the translated tax name based on the session language; resolves through VAT_TAX_ID and LANGUAGE.
  • AR_VAT_TAX_ALL — the synonym/view commonly referenced by Receivables forms and reports.
  • FND_LANGUAGES — reference for valid LANGUAGE and SOURCE_LANG values.
  • AR_VAT_TAX / AR_VAT_TAX_LINES — tax configuration consumers that rely on tax code identity and its localized printed name.
  • ZX_TAXES_B / ZX_REGIMES_B — E-Business Tax setup tables related indirectly where Receivables tax codes are mapped into the tax engine.

Because the object is classified as a standalone satellite, referential integrity is maintained upward through the composite primary key rather than through child foreign keys pointing into this table.