Search Results csc_prof_check_results




Overview
Explore in AI Chat

Overview

The CSC_PROF_CHECK_RESULTS table is a core data repository within the Customer Care (CSC) module of Oracle E-Business Suite (EBS) versions 12.1.1 and 12.2.2. It serves as the system of record for storing the outcomes of profile checks executed against customer parties and accounts. Profile checks are automated business rules that assess customer attributes, such as creditworthiness or transaction history, to enforce service policies. This table is critical for maintaining a historical audit trail of these evaluations, enabling consistent application of business rules across customer interactions and supporting subsequent analysis and reporting on customer profiles.

Key Information Stored

The table's primary function is to store the result value of each executed profile check. Its central structure is defined by a primary key column, CHECK_RESULTS_ID, which uniquely identifies each result record. A fundamental foreign key, CHECK_ID, links each result to its specific business rule definition in the CSC_PROF_CHECKS_B table. While the provided metadata does not list all columns, typical data stored in such a table includes the identifier for the party or customer account that was evaluated, the actual result value (which could be a score, a flag, or a numeric limit), the date of the check, and potentially the context or transaction that triggered the evaluation. This design allows the system to query the latest or historical profile check results for any given customer entity efficiently.

Common Use Cases and Queries

The primary use case is the retrieval of a customer's current standing against active profile checks during order entry, service provisioning, or credit review processes. For instance, an order management workflow may query this table to determine if a customer's account passes relevant credit checks before submitting a new sales order. Common reporting scenarios involve analyzing the distribution of check results to identify trends or customers requiring review. A typical SQL pattern involves joining to CSC_PROF_CHECKS_B to get the check's name and business context.

SELECT cpcb.CHECK_NAME, cpcr.RESULT_VALUE, cpcr.EVALUATION_DATE
FROM CSC_PROF_CHECK_RESULTS cpcr,
     CSC_PROF_CHECKS_B cpcb
WHERE cpcr.CHECK_ID = cpcb.CHECK_ID
  AND cpcr.CUSTOMER_ID = :p_cust_account_id
  AND cpcr.EVALUATION_DATE = (
      SELECT MAX(EVALUATION_DATE)
      FROM CSC_PROF_CHECK_RESULTS cpcr2
      WHERE cpcr2.CHECK_ID = cpcr.CHECK_ID
        AND cpcr2.CUSTOMER_ID = cpcr.CUSTOMER_ID
  );

Related Objects

The table maintains defined relationships with other core CSC tables, primarily through foreign key constraints. Based on the provided metadata:

  • CSC_PROF_CHECKS_B: This is the primary related table. The column CSC_PROF_CHECK_RESULTS.CHECK_ID is a foreign key referencing CSC_PROF_CHECKS_B. This relationship is essential for retrieving the business rule (check) name, type, and active configuration details associated with each stored result.

While not listed in the provided excerpt, this table would also logically relate to the core Trading Community Architecture (TCA) tables, such as HZ_PARTIES or HZ_CUST_ACCOUNTS, via a PARTY_ID or CUST_ACCOUNT_ID column to fully identify the subject of the profile check.