Search Results cogs_amount




Overview

ICX_CST_MARGIN_DETAIL_V is a database view historically shipped within the Oracle iProcurement (ICX) product family in Oracle E-Business Suite. In the ETRM metadata for release 12.1.1 and 12.2.2, the object is explicitly flagged with the description "Obsolete" and is recorded as "Not implemented in this database." This status indicates that the view was retired from the shipped product and is no longer created by the standard installation scripts in current environments. References to it typically survive only through legacy customizations, older patch histories, or backward-compatibility artifacts carried forward in upgrades.

Where the view does exist in an earlier or patched environment, its role is to expose computed sales margin detail at the transaction level for reporting and integration purposes. It presents invoiced revenue, cost of goods sold, and the resulting margin alongside the organizational, customer, item, salesperson, and territory dimensions needed to analyze profitability. Because the object is documented as obsolete and not implemented, it should not be treated as a supported interface in a 12.1.1 or 12.2.2 implementation.

Underlying Base Objects

The documented view text selects exclusively from a single base object, ICX_MARGIN_ANALYSIS:

  • ICX_MARGIN_ANALYSIS — the source table supplying all columns projected by the view.

The view applies an organization-level filter in its WHERE clause. It compares the ORG_ID column against an operating unit or organization value derived from the session attribute USERENV('CLIENT_INFO'), decoding the client identifier into a numeric organization ID. When the client information is blank, the predicate defaults to a sentinel value of -99, effectively restricting rows to those matching the resolved organization context. This mechanism enforces multi-org (operating unit) data isolation so that a user querying the view sees only margin records belonging to the organization context established by the application session.

The ETRM metadata documents no other referenced base objects, and no additional joins, aggregations, or derived tables are present in the view definition.

Key Columns

  • BUILD_ID — identifier associated with the margin analysis build or collection process.
  • CUSTOMER_ID — surrogate key of the sold-to customer.
  • PRIMARY_SALESREP_ID — salesperson credited as primary on the transaction.
  • TERRITORY_ID — sales territory dimension for the record.
  • INVENTORY_ITEM_ID — inventory item involved in the margin calculation.
  • PERIOD — accounting or reporting period to which the margin data belongs.
  • PARENT_INVENTORY_ITEM_ID — parent item, supporting rollup where item hierarchies apply.
  • ORG_ID — organization/operating unit, also used by the view's row filter.
  • SOLD_TO_CUSTOMER_NAME — display name of the sold-to customer.
  • INVOICED_AMOUNT — revenue invoiced for the transaction line.
  • COGS_AMOUNT — cost of goods sold associated with the revenue.
  • MARGIN — computed margin, generally the difference between invoiced amount and COGS amount.

Common Use Cases and Queries

Margin reporting and integration extracts were the primary consumers of this view, combining revenue and cost detail by customer, item, salesperson, and period. Because the object is obsolete and not implemented, these scenarios now require replacement reporting sources, typically the underlying analysis tables or current costing and receivables reporting views.

A representative query follows:

  • SELECT PERIOD, SOLD_TO_CUSTOMER_NAME, INVENTORY_ITEM_ID, INVOICED_AMOUNT, COGS_AMOUNT, MARGIN FROM ICX_CST_MARGIN_DETAIL_V WHERE ORG_ID = :p_org_id ORDER BY PERIOD, SOLD_TO_CUSTOMER_NAME;
  • SELECT PRIMARY_SALESREP_ID, TERRITORY_ID, SUM(INVOICED_AMOUNT) revenue, SUM(COGS_AMOUNT) cost, SUM(MARGIN) margin FROM ICX_CST_MARGIN_DETAIL_V GROUP BY PRIMARY_SALESREP_ID, TERRITORY_ID;

Note that in a 12.1.1 or 12.2.2 instance the view is documented as not implemented; queries against it will fail unless it was manually recreated. The organization filter is applied by the view itself, so callers must ensure the correct multi-org context is initialized before execution.