Results for “num_char_flag”

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

Overview

The AR_CMGT_SCORE_DTLS table is a Receivables (AR) module data object within the Oracle E-Business Suite, owned by the AR schema. It stores detail-level information for a credit scoring model used by Oracle Credit Management. Where the parent scoring model definition establishes which data points drive a credit decision, AR_CMGT_SCORE_DTLS materializes the scoring bands: for each data point, it defines one or more value ranges and the score credited when a customer's actual value falls inside that range. This makes the table the mechanism by which quantitative or categorical inputs are converted into a numeric score that aggregates into a customer's overall credit score.

Under the heuristic Data Vault classification supplied in the metadata, this object is modeled as standalone — no foreign-key relationships were mined from its structure. In Data Vault terms, that suggests treating it as a standalone satellite-like construct (or possibly a hub if SCORE_MODEL_ID/DATA_POINT_ID are treated as business keys), rather than as a link between independent hubs. This is a modeling suggestion, not a documented constraint; Oracle EBS itself enforces integrity through the composite primary key rather than declared foreign keys.

Key Information Stored

The table is documented with 12 columns in ETRM 12.2.2. The most significant are:

• SCORE_MODEL_ID — identifies the credit scoring model to which the range definition belongs. Together with DATA_POINT_ID and RANGE_SEQUENCE_NUM it forms the composite primary key AR_CMGT_SCORE_DTLS_PK, and the same three columns form the unique business-key index AR_CMGT_SCORE_DTLS_U1.
• DATA_POINT_ID — identifies the specific scoring data point (for example, a financial ratio, aging bucket, or external bureau attribute) whose ranges are being defined.
• RANGE_SEQUENCE_NUM — the ordinal position of the band within the data point, allowing multiple non-overlapping bands per data point and giving deterministic ordering for evaluation.
• RANGE_FROM and RANGE_TO — the lower and upper bounds of the band against which an actual value is compared, typically left-closed and right-open in evaluation logic.
• SCORES — the score awarded when the evaluated value falls within the band defined by RANGE_FROM/RANGE_TO.
• NUM_CHAR_FLAG — indicates whether the data point is evaluated as numeric or character, governing how the range bounds are interpreted.

The remaining columns are the standard Oracle EBS WHO columns — LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, CREATION_DATE, and CREATED_BY — providing audit lineage. There is no single surrogate sequence key: the primary key is the natural composite of the three identifying columns, and AR_CMGT_SCORE_DTLS_U1 is a unique index rather than a separate surrogate, so the PK and business-key candidates coincide.

Common Use Cases and Queries

Typical uses include reviewing the banding logic of a scoring model, auditing which bands award what scores, and reporting score distributions for model tuning. A representative query lists all bands for a given model and data point in evaluation order:

• SELECT score_model_id, data_point_id, range_sequence_num, range_from, range_to, scores, num_char_flag FROM ar.ar_cmgt_score_dtls WHERE score_model_id = :model_id AND data_point_id = :dp_id ORDER BY range_sequence_num;
• A join to the parent model header returns the model name alongside each band for reporting: SELECT s.score_model_id, s.data_point_id, s.range_sequence_num, s.range_from, s.range_to, s.scores FROM ar.ar_cmgt_score_dtls s WHERE s.score_model_id = :model_id ORDER BY s.data_point_id, s.range_sequence_num;
• Validation queries check for overlapping or missing bands per data point before a model goes live, comparing adjacent RANGE_FROM/RANGE_TO values across RANGE_SEQUENCE_NUM.
• Model-diff reporting compares the band sets between the production and test copies of a model by joining on the composite key columns and filtering on LAST_UPDATE_DATE.

Because ranges drive customer scoring, care is required in any direct DML: band edits should be made through Oracle Credit Management setup rather than by direct SQL, so that dependent scoring logic remains consistent.

Related Objects

The most significant related objects, based on the documented relationship data and Credit Management usage, are:

• AR_CMGT_SCORE_MODELS / scoring model header — joined on SCORE_MODEL_ID, providing model name, status, and validity dates.
• Data point definitions (AR_CMGT_DATA_POINTS and related) — joined on DATA_POINT_ID, describing the attribute being scored.
• AR_CMGT_SCORE_DTLS_PK / AR_CMGT_SCORE_DTLS_U1 — the composite primary key and unique business-key index on (SCORE_MODEL_ID, DATA_POINT_ID, RANGE_SEQUENCE_NUM).
• Credit Management scoring APIs — the credit scoring engine that reads these bands to compute a customer's score.
• AR_CMGT_CUSTOMER_SCORES / score result tables — hold computed scores that trace back to the band and model defined here.
• AR_CMGT_MODEL_RULES and case/matrix objects — the higher-level rule orchestration that consumes model output.

No declared foreign keys are documented, so joins to these objects are application-enforced through the shared SCORE_MODEL_ID and DATA_POINT_ID values rather than by database constraints.