Search Results optimize_flag




Overview
Explore in AI Chat

Overview

APPS.MSC_UNDO_DETAILS_V is a reporting and diagnostic view in the Oracle Advanced Supply Chain Planning (ASCP) module of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. It exposes the row-level detail of the undo log that ASCP maintains when a planner performs an undo of an earlier planning action or transaction. The underlying undo mechanism (MSC_UNDO_SUMMARY and MSC_UNDO_DETAILS) captures, for each undone operation, the identity of the changed column and both its previous and new values. Whereas the summary object records which planning transaction was reversed, this view resolves the raw internal identifiers and codes stored in the detail rows into human-readable text.

The view’s distinctive feature is its heavy reliance on the MSC_GET_NAME package to translate stored values into display names — organization codes, supplier names, project and task numbers, resource codes, department codes, and lookup meanings. Because ASCP frequently stores flags as single-character codes (for example Y/N), lookups such as SYS_YES_NO are decoded here, making the view particularly useful when auditing why a field changed during an undo.

Underlying Base Objects

The view is defined over the following documented objects:

  • MSC_UNDO_DETAILS (syonym to the base table) — supplies the core undo detail rows: undo_id, column_changed, column_type, old_value, and new_value.
  • MSC_UNDO_SUMMARY (synonym) — joined via the undo_id and supplies context such as plan_id, sr_instance_id, transaction_id, and table_changed.
  • MSC_GET_NAME (package) — a helper package invoked for nearly every meaningful column to convert IDs into descriptive text and to resolve lookup meanings.
  • FND_DATE (package) — used to convert stored canonical date values back into a formatted character representation via CANONICAL_TO_DATE and DATE_TO_CHARDT.

Key Columns

  • undo_id — Identifier linking each detail line to its parent undo summary record.
  • column_changed / column_changed_text — The technical column name that was modified and its descriptive label.
  • column_type — Drives conditional decoding (for example DATE columns are formatted through FND_DATE).
  • old_value / new_value — The pre- and post-undo values, each passed through MSC_GET_NAME for contextual translation based on column_changed.

Notable value translations include SOURCE_ORGANIZATION_ID → msc_get_name.org_code, supplier and supplier site lookups, project and task resolution, resource code resolution, and a branch for FIRM_FLAG that selects between SYS_YES_NO and RESOURCE_FIRM_TYPE depending on table_changed. Many constraint and scheduling flags (RESCHEDULE_FLAG, OPTIMIZE_FLAG, daily/weekly/period resource and material constraints, CURR_PLAN_CAPACITY_FLAG) are decoded through the SYS_YES_NO lookup.

Common Use Cases and Queries

Typical scenarios include investigating the effect of an undo action, auditing plan changes, and diagnosing unexpected field reversions. A representative query:

SELECT undo_id, column_changed_text, old_value, new_value
FROM   apps.msc_undo_details_v
WHERE  undo_id = :p_undo_id;

Filtering to boolean-style columns demonstrates the SYS_YES_NO decoding directly:

SELECT column_changed_text, old_value, new_value
FROM   apps.msc_undo_details_v
WHERE  column_changed = 'OPTIMIZE_FLAG';

Because it resolves internal IDs, the view is best suited to operational troubleshooting and audit reporting rather than high-volume bulk extraction.