Results for “transactional_cost”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

EDW_BIM_LIST_SRCLSTS_LTC is a table owned by the BIM schema in Oracle E-Business Suite. Per the ETRM documentation, it belongs to the BIM — Marketing Intelligence product, which is flagged as obsolete in releases 12.1.1 and 12.2.2. The table is documented as a "Source List Level Table," indicating that it stores source-list definitions at the level used by the Marketing Intelligence extraction and warehouse layer. Its physical schema in 12.2.2 comprises 34 columns, and the object is reported as VALID.

The ETRM metadata classifies this object as standalone for Data Vault modeling purposes. This is a heuristic mined from the foreign-key structure: the table carries several outbound references but no documented inbound dependencies, so the suggested model would treat it as a standalone hub or a self-contained entity rather than a strict link between two business keys. Practically, the table functions as an operational staging or detail table that captures source-list attributes, costs, vendor references, and status information used by the marketing intelligence extraction processes.

Key Information Stored

The table is keyed by SRCLST_PK, the surrogate primary key column. Two unique indexes are documented: EDW_BIM_LIST_SRCLSTS_LTC_U1 on SRCLST_PK_KEY and EDW_BIM_LIST_SRCLSTS_LTC_U2 on the combination of SRCLST_PK and SRCLST_PK_KEY. SRCLST_PK_KEY therefore serves as the principal business-key candidate, with the composite index providing the alternate uniqueness constraint. The generic pairing ALL_FK and ALL_FK_KEY appears to be the referential key used to join back to the base AMS source-list records.

Business attributes include NAME and SOURCE_LIST_NAME for the list identity, DESCRIPTION, and LIST_SOURCE_TYPE and LIST_SOURCE_TYPE_ID for classification, the latter referencing AMS_LIST_SRC_TYPES. Status is tracked through USER_STATUS_ID, STATUS_CODE, and STATUS_DATE. Financial columns TRANSACTIONAL_COST, FUNCTIONAL_COST and their respective currency codes, TRANSACTIONAL_CURRENCY_CODE and FUNCTIONAL_CURRENCY_CODE, capture cost values at both transactional and functional levels.

Relationship and ownership columns include IMPORT_LIST_HEADER_ID, VENDOR_ID and VENDOR_FK alongside VENDOR_FK_KEY, PIN_ID, ORG_ID, and SECURITY_GROUP_ID. SOURCE_SYSTEM and KEYWORDS support lineage and search. A set of descriptive and auditing columns completes the structure: INSTANCE, USER_ATTRIBUTE1 through USER_ATTRIBUTE5, LAST_UPDATE_DATE, and CREATION_DATE.

Common Use Cases and Queries

The primary use case is reporting on source-list composition and costs within the marketing intelligence warehouse, particularly for reconciliation between transactional and functional cost figures, and for listing vendors associated with a given source list. Typical queries join the header and source-type reference tables:

• SELECT s.SRCLST_PK_KEY, s.SOURCE_LIST_NAME, s.TRANSACTIONAL_COST, s.FUNCTIONAL_COST FROM BIM.EDW_BIM_LIST_SRCLSTS_LTC s WHERE s.STATUS_CODE = 'ACTIVE';
• SELECT s.NAME, t.LIST_SOURCE_TYPE FROM BIM.EDW_BIM_LIST_SRCLSTS_LTC s JOIN AMS_LIST_SRC_TYPES t ON s.LIST_SOURCE_TYPE_ID = t.LIST_SOURCE_TYPE_ID;
• SELECT s.NAME, h.HEADER_NAME FROM BIM.EDW_BIM_LIST_SRCLSTS_LTC s JOIN AMS_IMP_LIST_HEADERS_ALL h ON s.IMPORT_LIST_HEADER_ID = h.IMPORT_LIST_HEADER_ID;

Because SOURCE_SYSTEM and INSTANCE are present, the table also supports lineage and data-origin audits across extraction runs.

Related Objects

The documented foreign keys identify the most significant related objects:

• AMS_IMP_LIST_HEADERS_ALL — joined via IMPORT_LIST_HEADER_ID; supplies the import list header context.
• AMS_LIST_SRC_TYPES — joined via LIST_SOURCE_TYPE_ID; provides the source-list type classification.
• BEN_PIN — joined via PIN_ID; links to person/party identification.
• FND_SECURITY_GROUPS — joined via SECURITY_GROUP_ID; enforces multi-org security at query time.

Given the obsolete status of BIM — Marketing Intelligence, these references should be validated against the target release before designing dependent extracts or reports.