Search Results as_lead_orders_pk

Overview

AS_LEAD_ORDERS is a transactional table in the Oracle E-Business Suite Sales Foundation module (product code AS). It resides in the OSM schema and holds the association between sales leads (opportunities) and the orders that are generated from them. In practical terms, the table records which order header resulted from a given lead, providing the traceability link between the pre-sales pipeline and the order management fulfillment chain. The object is marked VALID in the documented release and is available in both Oracle EBS 12.1.1 and 12.2.2.

Under a heuristic Data Vault classification derived from its foreign key structure, AS_LEAD_ORDERS is satellite-leaning. This reflects its role as a dependent record that carries descriptive context (the order linkage, audit attributes, and descriptive flexfield columns) rather than serving as a standalone business hub or an independent intersection entity. The primary key is the surrogate AS_LEAD_ORDERS_PK, defined on the LEAD_ORDER_ID column.

Key Information Stored

The table contains 29 documented columns. The most significant are summarized below.

• LEAD_ORDER_ID — Surrogate primary key and the sole column of the AS_LEAD_ORDERS_PK constraint. Also defined by the unique index AS_LEAD_ORDERS_U1.
• LEAD_ID — Foreign key to AS_LEADS_ALL. Identifies the sales lead or opportunity from which the order originated.
• ORDER_HEADER_ID — References the order header created as a result of that lead. Together with LEAD_ID it forms the unique index AS_LEAD_ORDERS_U2, a documented business-key candidate asserting that a single lead may not be linked twice to the same order header.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, enforcing multi-org and data-security scoping.
• Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN capture standard Oracle EBS who-did-what tracking.
• Concurrent program columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE identify the batch process and request that inserted or last modified the row.
• Descriptive flexfield columns — ATTRIBUTE_CATEGORY plus ATTRIBUTE1 through ATTRIBUTE15 provide extensibility for customer-specific lead-to-order attributes without schema changes.

Common Use Cases and Queries

The table is principally used for pipeline-to-order reporting: quantifying conversion rates from opportunity to booked order, attributing revenue to the sales lead that generated it, and auditing whether an order header already has an originating lead. Typical query patterns join to AS_LEADS_ALL and to the order header table via ORDER_HEADER_ID.

A representative query retrieving all orders linked to a specific lead:

• SELECT LEAD_ORDER_ID, LEAD_ID, ORDER_HEADER_ID, CREATION_DATE FROM AS_LEAD_ORDERS WHERE LEAD_ID = :p_lead_id;
• Bulk extraction for reconciliation of leads against created orders: SELECT l.LEAD_ID, o.ORDER_HEADER_ID FROM AS_LEAD_ORDERS o, AS_LEADS_ALL l WHERE o.LEAD_ID = l.LEAD_ID;

Because AS_LEAD_ORDERS_U2 enforces uniqueness on (LEAD_ID, ORDER_HEADER_ID), existence checks before inserting new lead-order associations are standard practice in integration and data-migration scripts.

Related Objects

• AS_LEADS_ALL — Parent table of the lead referenced by AS_LEAD_ORDERS.LEAD_ID; the primary dependency for lead-level reporting.
• FND_SECURITY_GROUPS — Referenced by SECURITY_GROUP_ID for data-security enforcement.
• OE_ORDER_HEADERS_ALL — The order header identified by ORDER_HEADER_ID; the join target for order details, line, and pricing data.
• OE_ORDER_LINES_ALL — Reached through the order header for line-level order analysis.
• AS_LEAD_ORDERS_PK / _U1 / _U2 — Primary key and unique index constraints enforcing identity and business-key integrity.

Together these objects support the full lead-to-order lineage within the Sales Foundation and Order Management integration points.