Search Results adjusted_doc_entity_code

Overview

OKL_TAX_SOURCES_V is a simple, read-only view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKL — Leasing and Finance Management product family. In EBS 12.1.1 and 12.2.2 the object carries a VALID status and exists to expose the taxable lines that are generated for leasing tax events. The underlying storage is the base table OKL_TAX_SOURCES, which records each line that becomes a candidate for tax calculation, tax reporting, or downstream tax determination. Because the view is a pass-through over that table, it presents the full column set without transformation, denormalization, or filtering, and it is intended purely as a reporting and integration surface rather than as a transactional entry point.

Functionally, the view plays a supporting role in the leasing tax pipeline. Tax events raised by leasing transactions — bookings, adjustments, asset-level charges, and the retrieval of tax rules — write taxable line records into OKL_TAX_SOURCES. OKL_TAX_SOURCES_V then provides the queryable representation of those lines for embedded reports, Oracle Discoverer workbooks, custom concurrent programs, OBIEE extracts, and integration interfaces that must read leasing tax data without touching the base table directly. This separation is consistent with the general EBS pattern of presenting base tables through APPS-owned views so that downstream consumers depend on a stable interface.

Underlying Base Objects

The documented metadata identifies a single referenced base object: the synonym OKL_TAX_SOURCES, which resolves to the physical table APPS.OKL_TAX_SOURCES. The view text is a straightforward projection of every column from that source, aliased with the prefix TXS. No joins, unions, aggregations, or analytic functions appear in the definition, and no WHERE clause is applied, so row counts and column values in the view are identical to those in the base table. Consequently, any change to the structure of OKL_TAX_SOURCES — column additions, datatype changes, or new attribute columns — is reflected directly in the view, and there is no independent logic that would need to be maintained. From a governance standpoint, this means the view should be treated as an alias of the table rather than as a distinct business object, and tuning or indexing performed on OKL_TAX_SOURCES benefits queries against the view equally.

Key Columns

The view exposes a wide column set that can be grouped into logical clusters. The primary key and identifying columns include ID, KHR_ID, KLE_ID, TRX_ID, TRX_LINE_ID, TRY_ID, and SEL_ID, which link a tax line back to the leasing contract, transaction, transaction line, and tax rule evaluation. Transaction classification is carried by ENTITY_CODE, EVENT_CLASS_CODE, TRX_LEVEL_TYPE, TRX_BUSINESS_CATEGORY, TAX_CALL_TYPE_CODE, TAX_LINE_STATUS_CODE, and REPORTED_YN. Adjustment and prior-document references are held in ADJUSTED_DOC_ENTITY_CODE, ADJUSTED_DOC_EVENT_CLASS_CODE, ADJUSTED_DOC_TRX_ID, ADJUSTED_DOC_TRX_LINE_ID, ADJUSTED_DOC_TRX_LEVEL_TYPE, ADJUSTED_DOC_NUMBER, and ADJUSTED_DOC_DATE.

Tax determination attributes include STY_ID, TAX_CLASSIFICATION_CODE, USER_DEFINED_FISC_CLASS, PRODUCT_FISC_CLASSIFICATION, PRODUCT_CATEGORY, PRODUCT_TYPE, LINE_INTENDED_USE, DEFAULT_TAXATION_COUNTRY, and TAX_REPORTING_FLAG. Amount-bearing columns comprise LINE_AMT, ASSESSABLE_VALUE, and TOTAL_TAX, with TRX_CURRENCY_CODE, CURRENCY_CONVERSION_TYPE, CURRENCY_CONVERSION_RATE, and CURRENCY_CONVERSION_DATE providing currency context. Party and location data are represented by SHIP_TO_PARTY_ID, SHIP_TO_PARTY_SITE_ID, SHIP_TO_LOCATION_ID, SHIP_TO_CUST_ACCT_SITE_USE_ID, BILL_TO_PARTY_ID, BILL_TO_PARTY_SITE_ID, BILL_TO_LOCATION_ID, and BILL_TO_CUST_ACCT_SITE_USE_ID. This pairing of ship-to and bill-to identifiers is central to tax jurisdiction derivation and is the reason users searching on "bill_to_party_site_id" are routed to this view. Standard WHO columns, PROGRAM_ID, REQUEST_ID, REQUEST_ID, OBJECT_VERSION_NUMBER, ORG_ID, LEGAL_ENTITY_ID, and fifteen ATTRIBUTEn flexfields complete the structure.

Common Use Cases and Queries

Typical usage centers on retrieving taxable lines for a contract or transaction, auditing tax determination inputs, and extracting data for reporting. A common pattern joins the view to transaction headers and filters on bill-to attributes:

• List all taxable lines for a contract: SELECT id, kle_id, trx_id, line_name, line_amt, total_tax FROM okl_tax_sources_v WHERE kle_id = :p_kle_id;
• Find lines by bill-to party site: SELECT id, trx_id, trx_line_id, bill_to_party_id, bill_to_party_site_id, total_tax FROM okl_tax_sources_v WHERE bill_to_party_site_id = :p_site_id;
• Reconcile ship-to and bill-to pairs for a date range: SELECT ship_to_party_site_id, bill_to_party_site_id, SUM(total_tax) FROM okl_tax_sources_v WHERE trx_date BETWEEN :from_date AND :to_date GROUP BY ship_to_party_site_id, bill_to_party_site_id;
• Isolate reported versus unreported lines: SELECT id, tax_line_status_code, reported_yn FROM okl_tax_sources_v WHERE reported_yn = 'N';

Because no filtering logic exists in the view, queries should always include selective predicates such as KLE_ID, TRX_ID, ORG_ID, or TRX_DATE to avoid full scans of OKL_TAX_SOURCES, particularly in high-volume leasing implementations where tax lines accumulate rapidly across many contracts.