Search Results ar_cmgt_cf_dnb_dtls




Overview
Explore in AI Chat

Overview

The AR_CMGT_CF_DNB_DTLS table is an Oracle Receivables (AR) repository object that supports Oracle Credit Management by recording the physical location of Dun & Bradstreet (D&B) Global Data Product report data purchased and imported for use within a credit review. Rather than storing the report payload itself, the table functions as a pointer or registry: it maps each Credit Management case folder to the external or staging table where the corresponding D&B data resides, along with the key required to retrieve that data. This indirection allows Oracle Credit Management to integrate third-party credit bureau content without embedding externally formatted report structures directly in its own model.

Under the heuristic Data Vault classification mined from its foreign-key structure, the object is identified as standalone. A standalone classification suggests that, from a modeling perspective, the table does not participate in the canonical hub/link/satellite relationships typically observed in integrated warehouses; it behaves instead as an independent reference or mapping construct anchored to the Credit Management case folder. Its primary key, AR_CMGT_CF_DNB_DTLS_PK, is a composite of CASE_FOLDER_ID, SOURCE_TABLE_NAME, and SOURCE_KEY, reinforcing that each row uniquely ties a credit case to a specific source record.

Key Information Stored

The documented physical schema for ETRM 12.2.2 records 11 columns. The most significant include:

  • CASE_FOLDER_ID — the Credit Management case folder identifier; the business anchor linking D&B data to a specific credit review.
  • SOURCE_TABLE_NAME — name of the table where the imported D&B report data is physically stored.
  • SOURCE_KEY — the key value used to locate the corresponding record within the named source table.
  • SOURCE_KEY_TYPE — classification of the source key, indicating the nature of the identifier used.
  • SOURCE_KEY_COLUMN_NAME — the column in the source table that holds the key.
  • SOURCE_KEY_COLUMN_TYPE_NAME — the datatype of that source key column, supporting correct interpretation and joins.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard audit columns capturing who last modified the row, when, and through which login.
  • CREATION_DATE, CREATED_BY — standard audit columns recording initial row creation.

The composite primary key (CASE_FOLDER_ID, SOURCE_TABLE_NAME, SOURCE_KEY) is the surrogate/structural identifier. The business-key candidates emerge naturally from these same three columns, since together they uniquely identify the placement of a given D&B source record against a case folder; CASE_FOLDER_ID alone is not unique, as a single case may reference multiple source tables and records.

Common Use Cases and Queries

Typical use cases center on locating and validating D&B data associated with a credit review. A common pattern resolves the source table and key for a given case:

  • Retrieving all source references for a credit case: SELECT SOURCE_TABLE_NAME, SOURCE_KEY, SOURCE_KEY_COLUMN_NAME FROM AR_CMGT_CF_DNB_DTLS WHERE CASE_FOLDER_ID = :case_id;
  • Auditing imports over time: filter on CREATION_DATE and CREATED_BY to determine when and by whom D&B report locations were registered.
  • Data-lineage and troubleshooting queries that inspect SOURCE_KEY_TYPE and SOURCE_KEY_COLUMN_TYPE_NAME to confirm correct join types when retrieving the actual report content.
  • Reporting on which credit case folders have external D&B content attached versus those relying solely on internal data.

Related Objects

The table is anchored to the Oracle Credit Management case folder construct and the external D&B staging structures it references. Significant related objects include:

  • Case folder tables (Credit Management) — joined via CASE_FOLDER_ID to resolve the credit review owning the D&B data.
  • D&B source tables — referenced dynamically through SOURCE_TABLE_NAME, SOURCE_KEY, and SOURCE_KEY_COLUMN_NAME; these hold the imported report payloads.
  • AR_CMGT family tables and Credit Management concurrent programs that populate this registry during D&B import.
  • Oracle Receivables Credit Management views exposing case and D&B content through the standard application layer.

Because the object is classified as standalone, it carries no documented foreign keys; relationships are resolved at runtime via the source table and key metadata rather than enforced constraints.