Search Results oe_ak_order_headers_v

Overview

OE_AK_ORDER_HEADERS_V is an Oracle E-Business Suite (EBS) reporting view owned by the APPS schema and defined within the Order Management (ONT) product module. It exposes order header information from the core order management tables in a form optimized for inbound interface processing, integration, and reporting. The view is valid and present in both EBS 12.1.1 and 12.2.2. The "AK" prefix in the name reflects its association with the Oracle Application Framework (OAF) / Ak region-style interface layer historically used to expose order data to external systems and self-service flows.

Its principal design objective is type standardization. The view text explicitly converts several numeric columns from the fixed-precision NUMBER(15) datatype found in the underlying base table to a generic NUMBER type. This conversion ensures that consumers of the view — whether interface programs, Java-based components, or integration middleware — receive values in a predictable numeric format that will not be truncated or rejected by tooling expecting an unconstrained NUMBER. As the embedded comment states, the conversion applies so that ACCOUNTING_RULE_ID and INVOICING_RULE_ID are of type NUMBER rather than NUMBER(15) as defined in OE_ORDER_HEADERS_ALL.

Underlying Base Objects

Per the ETRM 12.2.2 metadata, the view is defined over the following referenced base objects:

• OE_ORDER_HEADERS_ALL (synonym) — the primary transactional table holding order header records, from which the majority of columns are projected.
• OE_ORDER_TYPES_V (view) — provides order type classification and document type attributes joined to the header.
• HZ_CUST_ACCOUNTS (synonym) — the Trading Community Architecture customer account table, supplying sold-to account context.
• HZ_PARTIES (synonym) — the TCA party table, supplying party-level customer identity and naming.

The relationship is a join of the order header record to its order type and to the customer account and party records, producing an enriched header view suitable for downstream consumption.

Key Columns

The view exposes a wide column set, most of which map directly to OE_ORDER_HEADERS_ALL. Representative columns include:

• HEADER_ID — the unique identifier of the order header, used as the primary join key.
• ORDERED_DATE, BOOKED_DATE, BOOKED_FLAG, CANCELLED_FLAG — order lifecycle status attributes.
• ACCOUNTING_RULE_ID, ACCOUNTING_RULE_DURATION, INVOICING_RULE_ID — converted to NUMBER type by the view definition.
• CUST_PO_NUMBER, CONVERSION_RATE, CONVERSION_TYPE_CODE, CONVERSION_RATE_DATE — commercial and currency conversion data.
• AGREEMENT_ID, DEMAND_CLASS_CODE, EXPIRATION_DATE, EARLIEST_SCHEDULE_LIMIT — agreement, demand, and scheduling attributes.
• FREIGHT_CARRIER_CODE, FREIGHT_TERMS_CODE, FOB_POINT_CODE — shipping and freight terms.
• INVOICE_TO_ORG_ID, INVOICE_TO_CONTACT_ID, DELIVER_TO_ORG_ID, DELIVER_TO_CONTACT_ID — party and location references.
• ATTRIBUTE1 through ATTRIBUTE20, GLOBAL_ATTRIBUTE1 through GLOBAL_ATTRIBUTE20, GLOBAL_ATTRIBUTE_CATEGORY, CONTEXT — the standard DFF extensibility columns.
• CREATED_BY, CREATION_DATE — audit columns.

Common Use Cases and Queries

OE_AK_ORDER_HEADERS_V is commonly referenced when header-level data is required for integration or reporting where numeric type consistency matters. A typical lookup by header is:

• SELECT header_id, ordered_date, booked_flag, cust_po_number FROM oe_ak_order_headers_v WHERE header_id = :p_header_id;
• Interface staging programs that load order headers frequently select this view to obtain headers with a normalized numeric ACCOUNTING_RULE_ID and INVOICING_RULE_ID, avoiding type-width mismatches during validation or insert.
• Reporting queries joined to customer data can rely on the view's inclusion of invoice-to and deliver-to organization and contact identifiers.

Because the view is defined in APPS, access should be granted through standard EBS responsibility and menu configuration. Consumers should be aware that the view is a presentation-layer object and that underlying business validation logic resides in the Order Management APIs rather than in the view itself.