Search Results as_lead_lines_log




Overview
Explore in AI Chat

Overview

The AS_LEAD_LINES_LOG table is a transactional history table in the Oracle E-Business Suite Sales Foundation (AS) product family, owned by the OSM schema. It captures the change history of lead lines, recording modifications made to purchase line records associated with sales leads. The table is documented in ETRM for release 12.2.2 with a status of VALID and comprises 23 physical columns. Its primary function is to provide an auditable trail of modifications—including insertions and updates—applied to lead line data, enabling historical reconstruction and analytical reporting on lead pipeline activity.

From a dimensional modeling perspective, the metadata classifies this object heuristically as a standalone Data Vault construct. In practice, this classification suggests that AS_LEAD_LINES_LOG functions primarily as a satellite-like history table anchored to the lead line and lead entities rather than as a pure hub or link. While it carries foreign key references to parent entities, the mined structure does not surface it as a true link or hub, so it is best modeled as an effectivity or audit satellite when building a Data Vault representation.

Key Information Stored

The table's surrogate primary key is LOG_ID, enforced by the constraint AS_LEAD_LINES_LOG_PK and reinforced by the unique index AS_LEAD_LINES_LOG_U1 on the same column. LOG_ID uniquely identifies each history row and is the only documented business-key candidate.

Among the most significant columns are the entity reference keys that tie each log row to its originating business record:

Standard audit columns—CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN—provide user and timestamp attribution for each logged change.

Common Use Cases and Queries

Typical usage centers on auditing and reconstructing lead line changes over time. Common scenarios include tracing who modified a lead line, comparing forecast snapshots, and reporting on pipeline movement by organization or category.

  • Reconstructing the full change history of a specific lead line:
    SELECT * FROM AS_LEAD_LINES_LOG WHERE LEAD_LINE_ID = :p_line_id ORDER BY CREATION_DATE;
  • Auditing user activity for a given lead:
    SELECT LOG_ID, LOG_MODE, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM AS_LEAD_LINES_LOG WHERE LEAD_ID = :p_lead_id;
  • Forecast reporting by organization and item across logged changes:
    SELECT ORGANIZATION_ID, INVENTORY_ITEM_ID, FORECAST_DATE, ROLLING_FORECAST_FLAG FROM AS_LEAD_LINES_LOG WHERE FORECAST_DATE BETWEEN :p_from AND :p_to;
  • Detecting concurrent modification issues using OBJECT_VERSION_NUMBER.

These queries support SOX-style audit reporting, pipeline analytics, and troubleshooting of lead line discrepancies.

Related Objects

The documented foreign key relationships identify the principal objects that this table references and, by extension, the tables most relevant to joins and drill-down reporting:

  • AS_LEAD_LINES_ALL — Joined on AS_LEAD_LINES_LOG.LEAD_LINE_ID = AS_LEAD_LINES_ALL.LEAD_LINE_ID; the primary parent entity.
  • AS_LEADS_ALL — Joined on AS_LEAD_LINES_LOG.LEAD_ID = AS_LEADS_ALL.LEAD_ID; provides lead header context.
  • AS_INTEREST_TYPES_B — Joined on AS_LEAD_LINES_LOG.INTEREST_TYPE_ID = AS_INTEREST_TYPES_B.INTEREST_TYPE_ID; supplies interest type descriptions.

Additional dependencies typically include inventory item master and organization tables referenced through INVENTORY_ITEM_ID, ORGANIZATION_ID, and ORG_ID, as well as product category tables referenced through PRODUCT_CATEGORY_ID and PRODUCT_CAT_SET_ID. These relationships make the log table valuable as a reporting bridge between lead management and product reference data.