Search Results line_qty

Overview

INL_EBTAX_LINES_V is a reporting view owned by the APPS schema within the Oracle Landed Cost Management (INL) product. It presents line-level information used by the tax determination engine (EBTax) when landed cost charges and shipment lines must be evaluated for tax applicability. The view consolidates two distinct transaction streams — shipment lines and charge lines — into a single, uniformly shaped result set so that downstream tax calculation, reporting, and integration processes can consume them through one interface.

The SOURCE column is the discriminator: rows originating from shipment lines carry the literal value 'SHIP_LINE', while rows originating from charge lines carry 'CHARGE'. Preserving the column list unchanged across both branches lets callers query landed cost tax lines without regard for the underlying origin, which simplifies both ad hoc analysis and programmatic integration with EBTax.

Underlying Base Objects

The view is defined as a UNION ALL over two views, both in the APPS schema:

• INL_ADJ_SHIP_LINES_V — supplies the 'SHIP_LINE' branch, aliased OL in the view text. This branch carries the full set of shipment line attributes, including item, UOM, quantity, unit price, fiscal classification, and party/location identifiers.
• INL_ADJ_CHARGE_LINES_V — supplies the 'CHARGE' branch, aliased CL. Charge lines contribute charge line identifiers and numbers where the shipment branch would carry shipment line identifiers.

Because both branches are themselves views, INL_EBTAX_LINES_V inherits their security and column semantics. No base tables are referenced directly, and the documented metadata lists only these two view dependencies.

Key Columns

The view exposes a deliberately consistent column list across both UNION ALL branches. Notable columns include:

• SOURCE — literal discriminator ('SHIP_LINE' or 'CHARGE').
• SHIP_LINE_ID, SHIP_LINE_GROUP_ID, SHIP_LINE_NUM, SHIP_LINE_TYPE_ID, SRC_TYPE_CODE, SRC_ID — identifiers for the originating line and its source transaction.
• SHIP_HEADER_ID — header reference for the landed cost shipment.
• UNIT_PRICE, LINE_AMT, LINE_QTY — line unit price, computed line amount (NVL(TXN_QTY * TXN_UNIT_PRICE, 0)), and line quantity.
• ASSESSABLE_VALUE — the assessable value of the line, sourced directly from OL.ASSESSABLE_VALUE; the field commonly searched by tax and landed cost analysts.
• INVENTORY_ITEM_ID, UOM_CODE, PRODUCT_FISCAL_CLASS, PRODUCT_CATEGORY, PRODUCT_TYPE, USER_DEF_FISCAL_CLASS, TAX_CLASSIFICATION_CODE — classification attributes used by EBTax for determination.
• TRX_BUSINESS_CATEGORY, INTENDED_USE — transaction context attributes.
• TAX_ALREADY_CALCULATED_FLAG — indicator that tax has previously been computed for the line.
• SHIP_FROM/ SHIP_TO / BILL_FROM / BILL_TO / POA / POO party, site, organization, and location IDs — the full set of party and location identifiers required for tax rules.
• CURRENCY_CODE, CURRENCY_CONVERSION_TYPE, CURRENCY_CONVERSION_DATE, CURRENCY_CONVERSION_RATE — currency and conversion context.
• ADJUSTMENT_NUM — adjustment reference for the line.

The 'CHARGE' branch maps NULL into columns that have no shipment-line equivalent (for example SHIP_LINE_GROUP_ID and PARTY_ID) while retaining the same column names and positions.

Common Use Cases and Queries

Typical scenarios include auditing assessable values feeding tax determination, reconciling landed cost charge lines against shipment lines, and extracting line data for EBTax integration.

List all shipment-line tax rows with their assessable value:

• SELECT ship_line_id, inventory_item_id, tax_classification_code, assessable_value, line_amt FROM apps.inl_ebtax_lines_v WHERE source = 'SHIP_LINE';

Summarize charge lines by adjustment:

• SELECT adjustment_num, COUNT(*) FROM apps.inl_ebtax_lines_v WHERE source = 'CHARGE' GROUP BY adjustment_num;

Identify lines already taxed before recalculation:

• SELECT source, ship_line_id, assessable_value FROM apps.inl_ebtax_lines_v WHERE tax_already_calculated_flag = 'Y';

Because the view is read-only and owned by APPS, queries should be issued with appropriate APPS privileges and joined to inventory and party master views when descriptions rather than IDs are required.