Search Results opi_edw_cogs_log

Overview

OPI_EDW_COGS_LOG is a legacy Oracle E-Business Suite table residing in the OPI (Operations Intelligence) product schema. Operations Intelligence was an early analytical and data-warehousing layer bundled with Oracle EBS releases in the 11i and early 12.x timeframe. In Oracle EBS 12.1.1 and 12.2.2, OPI is classified as obsolete; the product has been superseded by Oracle Business Intelligence (OBIEE) and the Enterprise Data Warehouse (EDW) offerings. Consequently, OPI_EDW_COGS_LOG is not implemented in a standard, current EBS database, and documentation for it is retained largely for upgrade and historical reference.

Functionally, the table name suggests it served as a log or staging artifact for Cost of Goods Sold (COGS) data flowing into the Enterprise Data Warehouse. Its recorded schema is minimal — only two columns — indicating it captured a lightweight status or control record rather than transactional COGS detail. From a Data Vault modeling perspective, the heuristic classification mined from the foreign-key structure is standalone. It does not resolve cleanly to a hub, link, or satellite; the single relationship to CS_SYSTEMS_ALL_B_TEMP is an ID-based reference rather than a true business-key dependency. Modelers should treat it as an isolated control/staging table rather than part of a conformed dimensional or Data Vault construct.

Key Information Stored

The documented physical schema for OPI_EDW_COGS_LOG under ETRM 12.1.1 contains exactly two columns. The complete column inventory is as follows:

• ROW_ID — The primary identifier column. It is defined with a foreign-key relationship to CS_SYSTEMS_ALL_B_TEMP.ROW_ID, making it the surrogate-style key through which the log row is anchored to the EBS systems/application context. ROW_ID is the only documented key candidate and the natural join point for this table.
• STATUS — A control or state indicator. Given the table's likely role as a processing log for COGS extraction into the EDW, STATUS would have recorded the disposition of a COGS load or extraction run (for example, pending, completed, or failed), enabling downstream monitoring of the warehouse feed.

No other columns are documented. There is no evidence of a composite business key, no date-stamped audit columns, and no COGS amount fields. The absence of a second unique index confirms that ROW_ID alone carries the uniqueness constraint. Because the ETRM metadata lists only these two attributes, the table should be regarded as a thin control record rather than a repository of financial detail. Analysts querying a production 12.1.1 or 12.2.2 instance should expect the table to be empty or absent entirely.

Common Use Cases and Queries

In the rare environment where OPI was formerly implemented, OPI_EDW_COGS_LOG would have been consulted for operational troubleshooting: confirming whether a COGS extraction into the EDW completed, and identifying which system context initiated it. A typical pattern joins the log to its parent systems table:

• Status monitoring: SELECT l.ROW_ID, l.STATUS FROM OPI.OPI_EDW_COGS_LOG l WHERE l.STATUS = '&status';
• Context enrichment: SELECT l.ROW_ID, l.STATUS FROM OPI.OPI_EDW_COGS_LOG l JOIN CS.CS_SYSTEMS_ALL_B_TEMP s ON l.ROW_ID = s.ROW_ID;

Because the table is obsolete and unimplemented, the practical reporting recommendation is not to build new logic against it. Any historical reports referencing OPI_EDW_COGS_LOG should be re-pointed to the current OBIEE subject areas or the EBS subledger COGS tables (for example, inventory and receivables costing tables) that now supply the same information. During upgrades from 12.1.1 to 12.2.2, the table may appear as a residual object; DBAs can confirm its presence with SELECT table_name, num_rows FROM dba_tables WHERE table_name = 'OPI_EDW_COGS_LOG'; and treat any populated rows as archival read-only data.

Related Objects

The relationship data identifies a single documented dependency. The following objects are the most significant to consider:

• CS_SYSTEMS_ALL_B_TEMP — Referenced via OPI_EDW_COGS_LOG.ROW_ID → CS_SYSTEMS_ALL_B_TEMP.ROW_ID. This is the only documented foreign key and the primary join target for the log.
• CS_SYSTEMS_ALL_B — The base systems registration table; the _B_TEMP variant is a temporary/interface counterpart and shares the same ROW_ID lineage in the CS (Systems) product.
• OPI schema objects (general) — Other OPI_EDW_* staging and log tables that followed the same extract-control naming convention and would have been processed together in OPI warehouse loads.
• EDW staging and control tables — Successor artifacts in the Oracle EDW/OBIEE stack that replaced OPI's extract-logging function.

No views, PL/SQL APIs, or triggers are documented against this table in the ETRM metadata. Given its obsolete status and two-column structure, OPI_EDW_COGS_LOG should be treated as a deprecated control table with no active downstream dependencies in Oracle EBS 12.1.1 or 12.2.2.