Search Results poa_cm_eval_scores




Overview

POA_CM_EVAL_SCORES is a transactional table in the PO (Purchasing) schema that stores the individual scoring records generated when buyers evaluate supplier responses against a structured set of evaluation criteria. It sits within the Oracle Procurement Contracts and sourcing evaluation framework, where a single evaluation event defined in AMW_EVALUATIONS_B is decomposed into one or more scored criteria, each persisted as a row in this table. The table therefore captures the quantitative and qualitative outcome of an evaluation rather than the definition of the evaluation itself.

The heuristic Data Vault classification mined from the foreign key structure is standalone. Because the only documented outbound relationship is a single FK to AMW_EVALUATIONS_B, no link-table pattern (a table resolving two or more hubs) is evidenced. From a modeling perspective, this object is best treated as a satellite of the evaluation hub: it carries descriptive and measurable attributes keyed to an evaluation parent, with no independent business identity of its own beyond its surrogate key.

Key Information Stored

The table is physically documented with 33 columns, of which the descriptive core is comparatively small. The most important columns are:

  • EVALUATION_SCORE_ID — the surrogate primary key, enforced by unique index POA_CM_EVAL_SCORES_U1. It provides the technical row identity.
  • EVALUATION_ID — the foreign key to AMW_EVALUATIONS_B, linking each score back to its parent evaluation event. Together with CRITERIA_CODE it forms the second unique index, POA_CM_EVAL_SCORES_U2, which is the true business-key candidate.
  • CRITERIA_CODE — identifies which evaluation criterion the row scores. The U2 constraint guarantees one score per criterion per evaluation.
  • SCORE — the recorded value or rating assigned to the criterion.
  • WEIGHT — the weighting applied to the criterion when aggregating scores into a total evaluation result.
  • MIN_SCORE and MAX_SCORE — the permitted bounds for the score, enabling validation and normalization.
  • COMMENTS — free-text justification or evaluator notes accompanying the score.

The remaining columns are standard EBS audit and extensibility attributes: WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN), concurrent program context (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE), and the fifteen descriptive flexfield columns ATTRIBUTE_CATEGORY through ATTRIBUTE15. There are no documented, seeded DFF definitions, so the ATTRIBUTE columns are available for customer extension.

Common Use Cases and Queries

The primary reporting scenario is reconstructing how a given evaluation was scored, criterion by criterion, and how the weighted total was derived. A typical query joins the score rows to their parent evaluation:

  • Detail extraction: SELECT s.criteria_code, s.score, s.weight, s.min_score, s.max_score, s.comments FROM po.poa_cm_eval_scores s WHERE s.evaluation_id = :p_evaluation_id ORDER BY s.criteria_code;
  • Weighted aggregation: sum of score * weight grouped by evaluation_id, used to reproduce or audit the total evaluation result.
  • Variance and exception reporting: rows where score < min_score or score > max_score, useful for detecting data-entry or interface errors.
  • Scorecard extracts for supplier performance reviews, exporting score, weight, and comments per criterion into BI Publisher or OBIEE layouts.
  • Change auditing via LAST_UPDATE_DATE and LAST_UPDATED_BY to identify scores revised after initial submission.

Because the table is standalone with a single parent, queries are simple and index-driven; filtering on EVALUATION_ID benefits from the U2 index, while direct lookups by EVALUATION_SCORE_ID use U1.

Related Objects

  • AMW_EVALUATIONS_B — the parent evaluation entity, joined on POA_CM_EVAL_SCORES.EVALUATION_ID = AMW_EVALUATIONS_B.EVALUATION_ID. This is the only documented foreign key and the most significant relationship.
  • AMW_EVALUATIONS_TL — the translation table for evaluation names and descriptions, joined through EVALUATION_ID for readable reporting.
  • POA_CM_EVAL_CRITERIA (or equivalent criteria definition objects) — supplies the master definition of CRITERIA_CODE, enabling descriptive labels to be attached to each scored row.
  • POA_CM_EVALUATION_HEADERS / evaluation result tables — consume the weighted output derived from these score rows.
  • AMW_* sourcing APIs and concurrent programs — populate POA_CM_EVAL_SCORES during score calculation, and are the supported path for inserting or updating evaluation scores rather than direct DML.

In Oracle EBS 12.1.1 and 12.2.2 the physical definition is identical in name, owner, and column count; only the surrounding AD/online patching file system differs, which does not affect this table's structure or query patterns.