Search Results tax_point_code




Overview

APPS.OE_AK_TAX_POINT_V is a lightweight reporting and integration view in the Oracle E-Business Suite Order Management module. It exposes the set of valid tax point codes that Order Management recognizes when determining the point in the order-to-cash flow at which tax becomes applicable. The view is defined as a simple filter over the seeded lookups table, returning the lookup codes whose lookup type equals 'TAX_POINT_CODE'. Because the view isolates a single lookup type, it provides a stable, reusable interface for retrieving tax point code values without requiring callers to know the underlying lookup type string or the structure of the source lookup table.

The view is registered in ETRM for release 12.2.2 under the APPS schema, and it is equally valid in 12.1.1, where the same lookup-driven configuration model applies. It contains no business logic beyond the type filter, so it is effectively a curated list of coded values. This makes it a natural reference source for tax calculation engines, order entry screens, and interfaces that must validate or translate a tax point before passing it to Oracle Tax or a third-party tax provider.

Underlying Base Objects

The only documented base object referenced by the view is OE_LOOKUPS, which is itself a view rather than a physical table. In the ETRM metadata, OE_LOOKUPS is listed as a VIEW, and OE_AK_TAX_POINT_V selects from it using the predicate WHERE lookup_type = 'TAX_POINT_CODE'. OE_LOOKUPS is the Order Management-specific projection over the core FND_LOOKUPS lookup repository, exposing lookup types and codes used throughout the order management schema. Thus the dependency chain runs from OE_AK_TAX_POINT_V to OE_LOOKUPS, and from OE_LOOKUPS to the underlying Application Object Library lookup tables.

Because the view is defined over a view, it is read-only for practical purposes and inherits whatever access and row-level behavior OE_LOOKUPS provides. It is typically granted to the APPS schema and made available to other application schemas and custom code through the standard APPS synonym mechanism. No joins, aggregations, or outer queries are documented in the view text; the definition consists solely of the SELECT and the lookup type predicate.

Key Columns

The view exposes a single projected column, LOOKUP_CODE, which carries the tax point code value. In the context of the search term "tax_point_code," this is the column that holds the actual codes returned to the caller. A typical row contains one such code, for example a value indicating that tax is determined at invoice, at shipment, or at order entry, depending on how the lookup has been configured in the implementation.

Because OE_LOOKUPS in turn exposes additional lookup attributes, implementations sometimes extend access through the parent view to obtain the meaning, description, tag, and enabled flag associated with each code. However, the documented definition of OE_AK_TAX_POINT_V projects only LOOKUP_CODE, so consumers requiring display text should query OE_LOOKUPS or FND_LOOKUPS directly rather than assuming those columns are present on this view.

Common Use Cases and Queries

The primary use case is supplying a validated list of tax point codes to order entry, pricing, and tax integration logic. A reporting query might simply enumerate the available codes for validation or for populating a selection list:

  • SELECT lookup_code FROM apps.oe_ak_tax_point_v; — returns all configured tax point codes.
  • SELECT lookup_code FROM apps.oe_ak_tax_point_v WHERE lookup_code = :p_tax_point; — validates a single code supplied by an interface.
  • Embedding the view in a larger join against order or line tables to confirm that a stored tax point value corresponds to a seeded code.
  • Driving tax engine mapping logic in a concurrent program or PL/SQL API that must translate a tax point code before calling the tax service.

Where display text is required, the same code values can be resolved against OE_LOOKUPS or FND_LOOKUPS using lookup_type 'TAX_POINT_CODE'. The view should be treated as read-only, and any customization should be limited to adding lookup rows rather than modifying the view text, preserving upgrade safety across 12.1.1 and 12.2.2.