Search Results ar_cmgt_dnb_elements_b_pk

Overview

The AR_CMGT_DNB_ELEMENTS_B table is a Receivables (AR) module object that belongs to the Oracle Credit Management (CMGT) subsystem. It identifies the intersection between where Dun & Bradstreet (D&B) Global Data Product report data is physically stored and how that data is retrieved for display within Oracle Credit Management. Each D&B report contains a number of discrete data points, and this table defines those elements, including which source column holds the returned value and how the value should be formatted and typed when surfaced to the credit analyst.

The object is owned by the AR schema and is classified as VALID in both Oracle EBS 12.1.1 and 12.2.2. Its physical signature is modest: thirteen documented columns and a single documented unique index. In Data Vault terms, the heuristic classification of this table is satellite-leaning. This should be treated as a modeling suggestion rather than a hard rule: the table stores descriptive attributes about individual D&B data elements, which is characteristic satellite behavior, but the presence of a foreign key to FND_APPLICATION and the use of a dedicated surrogate key (DATA_ELEMENT_ID) give it a degree of link-like structure as well. It is best understood as a configuration/reference satellite that anchors descriptive metadata to an application context.

Key Information Stored

The table's surrogate primary key is DATA_ELEMENT_ID, enforced by the constraint AR_CMGT_DNB_ELEMENTS_B_PK. A separate unique index, AR_CMGT_DNB_ELEMENTS_B_U1, spans DATA_ELEMENT_ID and ZD_EDITION_NAME, making that pair the effective business-key candidate and confirming that this object participates in Oracle's editioning model. The most significant columns are:

• DATA_ELEMENT_ID — the surrogate primary key identifying each D&B data element.
• SCORABLE_FLAG — indicates whether the element can participate in credit scoring logic.
• SOURCE_TABLE_NAME — the underlying table from which the D&B return value is read.
• SOURCE_COLUMN_NAME — the specific column within that source table holding the value.
• RETURN_DATA_TYPE — the datatype expected for the returned value.
• RETURN_DATE_FORMAT — the display format applied when the returned value is a date.
• APPLICATION_ID — foreign key to FND_APPLICATION, scoping the element to its owning application.
• ZD_EDITION_NAME — the edition identifier supporting edition-based redefinition.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS WHO columns providing audit traceability.

Common Use Cases and Queries

This table is primarily consumed by Credit Management configuration and D&B integration reporting. Typical scenarios include auditing which source tables and columns feed each element, verifying which elements are scoreable, and validating datatype and date-format metadata before report rendering.

A representative query retrieves scorable elements with their source mapping:

• SELECT DATA_ELEMENT_ID, SOURCE_TABLE_NAME, SOURCE_COLUMN_NAME, RETURN_DATA_TYPE, RETURN_DATE_FORMAT FROM AR.AR_CMGT_DNB_ELEMENTS_B WHERE SCORABLE_FLAG = 'Y' AND ZD_EDITION_NAME = '...';

Join to FND_APPLICATION to resolve the owning application name:

• SELECT a.APPLICATION_NAME, e.DATA_ELEMENT_ID, e.SOURCE_COLUMN_NAME FROM AR.AR_CMGT_DNB_ELEMENTS_B e, FND_APPLICATION a WHERE e.APPLICATION_ID = a.APPLICATION_ID;

Because the unique index spans DATA_ELEMENT_ID and ZD_EDITION_NAME, edition-aware queries should always filter or join on ZD_EDITION_NAME to avoid ambiguity in 12.2.x environments where edition-based redefinition is active.

Related Objects

The documented foreign key relationship is to FND_APPLICATION via AR_CMGT_DNB_ELEMENTS_B.APPLICATION_ID, making FND_APPLICATION the principal referenced object and the natural join target for application-name reporting. Beyond the documented FK, the table functions within the broader Credit Management and D&B integration area, so its most significant related objects include the D&B report and data-element storage structures referenced by SOURCE_TABLE_NAME, the Credit Management scoring and case tables that consume scorable elements, and the standard EBS WHO audit columns that tie back to FND_USER through CREATED_BY and LAST_UPDATED_BY. Analysts should treat APPLICATION_ID as the authoritative documented link and validate any additional relationships against the current ETRM and the actual foreign-key constraints in their instance, since only the FND_APPLICATION relationship is confirmed in the supplied metadata.