Results for “cm_acer_msg”

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

Overview

CM_ACER_MSG is a Process Manufacturing Financials (GMF) table that serves as the Actual Cost Process Error Message repository within Oracle E-Business Suite 12.1.1 and 12.2.2. It captures inconsistencies and validation failures detected during the Actual Cost Process (ACP), the batch routine that calculates actual costs for process manufacturing inventory and production transactions. The table is owned by the GMF schema and currently holds a VALID status, indicating it is an active, supported object within the ETRM-documented data model.

From a Data Vault modeling perspective, the metadata's heuristic classification identifies CM_ACER_MSG as satellite-leaning. This classification reflects its role as a detail table whose rows describe attributes and messages associated with a parent process execution, rather than serving as a standalone hub or an associative link between two independent business entities. The foreign key to CM_ACPR_CTL reinforces this reading: each message row qualifies, but does not define, the parent cost process run.

Key Information Stored

The table contains 13 documented columns. The most significant are:

• ACPROC_ID — Identifier of the parent Actual Cost Process run; part of the composite primary key and the sole foreign key to CM_ACPR_CTL.
• LINE_NO — Sequence number distinguishing individual error messages within a given process run; the second component of the composite primary key.
• MESSAGE_COMMENT — The descriptive error text recording the specific inconsistency detected.
• DELETE_MARK — Oracle Applications standard logical-deletion flag.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard WHO audit columns capturing row provenance and change history.
• LAST_UPDATE_LOGIN — Login context of the most recent update.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent program context identifying the request and executable that generated the message row.

The composite primary key CM_ACER_MSG_PK (ACPROC_ID, LINE_NO) is also the only documented unique index, and thus the sole business-key candidate. There is no separate surrogate key column; the combination of process run and line number is the natural row identifier.

Common Use Cases and Queries

The primary use case is post-run diagnostics: an OPM user reviews messages after executing the Actual Cost Process to determine whether cost rollups completed cleanly and to identify the specific transactions, items, or cost elements that failed validation. Supporting scenarios include reconciliation reporting, trend analysis of recurring failure causes, and audit evidence for cost-cycle accuracy.

A representative query pattern retrieves all messages for a given process run:

• SELECT acproc_id, line_no, message_comment FROM gmf.cm_acer_msg WHERE acproc_id = :p_acproc_id ORDER BY line_no;
• Joining to the control table to enrich the run context: SELECT m.acproc_id, m.line_no, m.message_comment FROM gmf.cm_acer_msg m, gmf.cm_acpr_ctl c WHERE m.acproc_id = c.acproc_id AND c.acproc_id = :p_acproc_id;
• Filtering out logically deleted rows with WHERE delete_mark = 0 for active reporting.

Because message text is stored as free-form comments, pattern matching against MESSAGE_COMMENT with LIKE or regular expressions is a common technique for categorizing failure types across large historical populations of process runs.

Related Objects

The most significant related object is CM_ACPR_CTL, the Actual Cost Process control table and the sole documented foreign-key target. The relationship is:

• CM_ACPR_CTL — joined via CM_ACER_MSG.ACPROC_ID = CM_ACPR_CTL.ACPROC_ID; supplies the parent process run's status, timing, and parameters.

Beyond the documented FK, CM_ACER_MSG is functionally coupled to the Actual Cost Process concurrent program and the OPM cost management reporting layer, which consume its rows to present exception listings to users. Because the ETRM metadata exposes only one declared foreign key, the FK-derived relationship set is intentionally narrow; the table is best understood as a dependent detail store subordinate to the process control table rather than a participant in broad multi-table relationships.