ERPClimb logoERPClimb
SAP transaction codeObjectCM01ModulePP_M2D

CM01 — Capacity Planning Evaluation

CM01 is used to evaluate work-center capacity load against available capacity over time. It is most useful when production planners need to identify overloads, underloads or bottlenecks before rescheduling orders. Start from the exact business object, organizational scope and status, then prove the result through document flow, logs or master data before applying a corrective action.

This ERPClimb practitioner page covers CM01 — Capacity Planning Evaluation. It focuses on the transaction's real operational role, the parameters that matter, the evidence needed to diagnose problems, S/4HANA context, and the mistakes that cause most support rework.

Published 19 Sept 2026· 613 words

Diese Seite ist noch nicht auf Deutsch verfügbar.

Purpose

evaluate work-center capacity load against available capacity over time. CM01 is most useful when treated as part of an end-to-end process rather than a shortcut. The object status you see here is usually influenced by upstream master data, configuration, planning or document history, so capture those inputs before changing anything.

When it is used

CM01 is typically used when production planners need to identify overloads, underloads or bottlenecks before rescheduling orders. It is also valuable during project testing because it exposes a repeatable state that can be compared before and after configuration or master-data changes. In production, narrow the population first and distinguish display/analysis from actions that post, approve, replicate or change status.

How to use it in practice

  • Select the work center and planning horizon.
  • Review available capacity and requirements in the same unit/time basis.
  • Drill into orders creating peaks.
  • Check calendars, shifts and formulas before changing orders.
  • Use a leveling transaction/process when rescheduling is approved.

Key data objects

These are the most useful anchors when working in CM01. Capture them in screenshots, test evidence and incident handovers so another consultant can reproduce the same result and identify whether the issue is data, configuration, status or integration.

  • plant/work center — verify the exact value, validity/date context and relationship to the affected process.
  • capacity category — verify the exact value, validity/date context and relationship to the affected process.
  • period — verify the exact value, validity/date context and relationship to the affected process.
  • capacity requirements — verify the exact value, validity/date context and relationship to the affected process.
  • available capacity/load percentage — verify the exact value, validity/date context and relationship to the affected process.

How to prove it in the data

Build an evidence chain rather than relying on one message: identify the source requirement or master record, show the transaction status or worklist entry, then show the resulting document, posting, warehouse object, planning element or replication log. Use the same date and organizational scope throughout. That makes the diagnosis repeatable and separates a true fix from a coincidental retry.

ECC vs S/4HANA

Classic capacity evaluation remains available on S/4HANA, though PP/DS and Fiori planning tools may provide more advanced scheduling. Where a Fiori app or cloud service becomes the strategic user experience, the SAP GUI transaction can still remain valuable for support, migration and deep technical analysis, but it should not be used to justify a legacy design for new work.

Common pitfalls and how to diagnose them

  • Reading an overload without checking available-capacity master data. Return to the exact object status and chronology before applying a workaround.
  • Comparing hours and units that use different formulas. Return to the exact object status and chronology before applying a workaround.
  • Moving orders without considering material availability and downstream operations. Return to the exact object status and chronology before applying a workaround.

Whose problem this is

Primary ownership is the PP M2D team, with adjacent functional, Basis, Security or integration teams joining when the evidence crosses system boundaries. Escalate with the object/document number, organization, date/time, expected result, actual status and checks already completed.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tcodes/cm01ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.