Search Results input_tax_code

Overview

GL_TAX_OPTIONS_V is an APPS-owned reporting and inquiry view in the Oracle E-Business Suite General Ledger module. It exposes the tax configuration options defined at the ledger level, joining the tax options setup table to the ledger definition so that both the numeric ledger identifier and the user-facing ledger name are available in a single row. The view is a denormalized, read-only projection of the underlying setup data and is therefore intended for queries and integrations rather than for direct data manipulation.

The object gained particular attention because of the OUTPUT_AMT_INCL_TAX_FLAG column exposed by the view. This flag is central to tax calculation behavior: it indicates whether the tax engine should treat output (sales-side) amounts as already inclusive of tax, which in turn drives the tax extraction and rounding logic applied during transaction processing. Reporting users frequently search for this column when validating how tax is being computed for a given ledger.

The view is documented as VALID and is available in both Oracle EBS 12.1.1 and 12.2.2. Its structure is stable across these releases because it simply joins two setup entities without depending on multi-Org or subledger accounting architecture changes.

Underlying Base Objects

Per the ETRM metadata, the view is defined over two synonyms: GL_LEDGERS and GL_TAX_OPTIONS. The join is an inner join on LEDGER_ID, expressed as WHERE LGR.LEDGER_ID = GTO.LEDGER_ID. Each row of GL_TAX_OPTIONS is therefore matched to exactly one ledger, and only ledgers that have a tax options record are returned.

GL_LEDGERS supplies ledger identity and descriptive information, most visibly the LEDGER_NAME column, which the view renames from the ledger's NAME attribute. GL_TAX_OPTIONS supplies the operational tax settings, including currency, precision, calculation level, rounding rules, and the input and output tax inclusion flags. Because the view references synonyms in the APPS schema rather than the base tables directly, it inherits the standard EBS synonym layer and the associated grants and security model.

Key Columns

• LEDGER_ID / LEDGER_NAME — The ledger key and its user-facing name, used to group and filter tax options by ledger.
• ORG_ID — The operating unit context associated with the tax options record.
• TAX_CURRENCY_CODE — Currency in which tax amounts are maintained.
• TAX_PRECISION — Decimal precision applied to tax amounts.
• TAX_MAU — Minimum accountable unit governing rounding thresholds.
• CALCULATION_LEVEL_CODE — Indicates the level at which tax is calculated (for example, line or document).
• ALLOW_ROUNDING_OVERRIDE_FLAG, INPUT_ROUNDING_RULE_CODE, OUTPUT_ROUNDING_RULE_CODE — Control whether rounding may be overridden and which rounding rules apply to input and output tax respectively.
• INPUT_TAX_CODE / OUTPUT_TAX_CODE — Default tax codes for input (purchasing-side) and output (sales-side) transactions.
• INPUT_AMT_INCL_TAX_FLAG / OUTPUT_AMT_INCL_TAX_FLAG — Flags indicating whether input and output amounts are treated as inclusive of tax. The OUTPUT_AMT_INCL_TAX_FLAG is the column most frequently queried, as it determines tax extraction behavior on sales transactions.
• CONTEXT and ATTRIBUTE1–15 — Descriptive flexfield columns for customer-specific extensions.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard audit columns.

Common Use Cases and Queries

A typical validation query checks the output tax inclusion behavior for all ledgers:

• SELECT ledger_id, ledger_name, output_tax_code, output_amt_incl_tax_flag FROM apps.gl_tax_options_v ORDER BY ledger_name;

A more targeted query filters to ledgers where output amounts are treated as tax-inclusive, which often explains unexpected tax extraction results:

• SELECT ledger_name, output_tax_code, output_amt_incl_tax_flag, output_rounding_rule_code FROM apps.gl_tax_options_v WHERE output_amt_incl_tax_flag = 'Y';

Integration and reconciliation routines join this view to subledger tax tables to compare configured behavior against actual posted tax amounts, or feed the flags into downstream reporting extracts. Because the view is read-only and based on setup data, it is safe for high-frequency querying and does not require special handling beyond the standard APPS schema grants and responsibility-level security that govern access to GL setup information.