Material Ledger Cutover: SAP ECC to S/4HANA — Part 2: Greenfield New Implementation

A greenfield S/4HANA implementation starts with an empty system. No existing SAP ERP system is converted in-place. Configuration is built from scratch, master data is extracted from legacy ECC and loaded via structured migration tools, and historical transactional data is not carried forward. The ECC system remains live as a legacy archive post go-live.

This whitepaper covers every dimension of Material Ledger cutover in that context: what must be configured before the first data load, how the ten-step load sequence is enforced, what breaks if it is violated, and how to reconcile opening balances without the brownfield FINS_MIG_STATUS safety net.

The central tooling reference is SAP Note 2239701, which delivers the SAP Rapid Data Migration (RDM) package for S/4HANA On-Premise — 52 predefined migration objects, ATL job files, IDoc mapping templates, lookup files, and WebI reconciliation reports, all running on SAP Data Services 4.3. SAP Note 2345739 remains relevant for ML Customizing prerequisites applicable regardless of migration approach; the sections specific to FINS_MIG_STATUS M10/M11/M20/M21 execution do not apply in greenfield.

Five facts govern everything that follows. First, FINS_MIG_STATUS M10, M11, M20, and M21 do not run in greenfield — opening balances are created exclusively via RDM inventory balance jobs and FI open item loads. Second, ML Customizing — currency types, price determination, split valuation configuration, COGS Split — must be frozen before the first data load; retroactive changes require full reloads. Third, standard cost estimates must be released before inventory is loaded for any standard-price material; violating this sequence values opening stock at zero. Fourth, secondary cost elements do not exist in S/4HANA; every ECC secondary CE must be mapped to a primary G/L account before CO master data is loaded. Fifth, COGS Split must be active before the first goods issue; documents posted before activation have no cost component breakdown and cannot be retroactively split.

The document is structured as a complete execution reference: architecture, configuration, load sequence, field-level loading rules, reconciliation framework, risk register, six-phase playbook, and post-migration governance. Part 1 of this series covers brownfield system conversion; Part 3 covers bluefield and Selective Data Transition.

A greenfield S/4HANA implementation installs a new, empty S/4HANA system. The source ECC system continues running in parallel until go-live. Data migration occurs via structured ETL from ECC extracts into the new S/4HANA system. The data model in the target is S/4HANA-native from day one — Universal Journal (ACDOCA) stores all FI and ML postings, and there is no legacy table structure to migrate.

Three technical consequences follow directly from this:

No BSTAT = C carryforward records. In brownfield, M10 writes opening balance carryforward records to ACDOCA. In greenfield, opening balances are loaded as direct postings via movement type 561 (and variants) through Job_DM_InventoryBalance. ACDOCA receives standard goods movement documents, not migration-stamped carryforward records.

No CKMLHD/CKMLPR pre-population via M10. ML master data records in the new system are created when the material master is loaded and ML is activated for the valuation area. ML period records are populated when inventory is first posted.

All Customizing must be built from scratch. There is no Customizing migration wizard. Every OMXW currency type assignment, OMX1 price determination setting, OMWC split valuation configuration, and cost component structure must be manually configured and verified before the first data load begins.

This whitepaper covers Materials Management (MM) inventory valuation, the Material Ledger (ML) as mandated in S/4HANA from release 1511 onward, and Product Costing (CO-PC) — including standard costing, actual costing, COGS Split, mixed costing, and WIP. FI open items are in scope insofar as they interact with ML opening balances.

SAP Note 2239701 is the primary tooling reference for greenfield — it delivers the RDM package on SAP Data Services 4.3 with 52 predefined migration objects, ATL job files, IDoc mapping templates, and WebI reconciliation reports.

SAP Note 2345739 remains relevant in greenfield for ML Customizing prerequisites — specifically those governing OMXW currency type configuration, valuation area assignment, and ML type assignment. Notes specific to FINS_MIG_STATUS M10/M11 execution, NZDT/DOC conversion, and M10 memory management do not apply.

SAP Note 2239701 delivers the SAP Rapid Data Migration package for S/4HANA On-Premise, built on SAP Data Services 4.3. The package is downloaded from SAP Software Download Center as RDMS4HOP08_0-80001221.ZIP.

The S/4HANA Migration Cockpit (transaction LTMC) provides an alternative migration path for certain objects using file-based migration templates. It is appropriate for simpler objects — cost center groups, profit center groups — where the RDM IDoc approach is heavier than necessary. For ML-critical objects — material master, inventory balances, production orders — RDM with Data Services 4.3 is the primary tool.

SAP Note 2287723 (referenced in Note 2239701) confirms that LSMW is deprecated in S/4HANA On-Premise. All legacy LSMW scripts must be replaced by RDM Data Services jobs or Migration Cockpit templates. No exceptions.

Cost estimate must be released via CK11N or CK40N before the inventory balance job runs. The release populates MBEW-STPRS via a standard ML price change document. If Job_DM_InventoryBalance runs before the cost estimate is released, S/4HANA has no standard price to value the opening stock against — the system either rejects the posting or values at zero. Retrospective correction requires reversing all inventory postings, releasing the cost estimate, and reloading — not feasible after go-live.

VERPR must be loaded explicitly in the material master IDoc. It is not derived from any calculation in greenfield. The source value is the closing MAP from ECC MBEW-VERPR at the period used as the cutover reference period. Reconcile the loaded MAP against the ECC extract to confirm agreement per plant/material.

Load sequence is strictly enforced:

1. Header material master record (valuation category BWTTY set, no individual valuation type)
2. Individual valuation type records (one MBEW record per valuation type, each with its own VPRSV, STPRS/VERPR, BKLAS)
3. Inventory balance per valuation type (separate 561 posting per type via Job_DM_InventoryBalance)

If the header record is not loaded first, valuation type records are rejected. If inventory is loaded before valuation type records exist, stock is posted without a valid ML valuation header.

Procurement alternative configuration (transaction CK91N) must be complete before running CK11N/CK40N. The cost estimate for a mixed-costing material requires all procurement alternatives to have valid cost estimates and weighting factors defined. In greenfield, this configuration is built from scratch — carry over the ECC procurement alternative structure or rationalize it during design.

Greenfield is the only opportunity to consolidate ECC legacy valuation classes without a migration-in-flight risk. Common rationalization patterns: consolidate multiple raw material classes into a single class per G/L account assignment; eliminate obsolete classes no longer aligned to the chart of accounts; align valuation classes to the new S/4HANA cost component structure for accurate COGS Split. Document the full mapping: ECC BKLAS → S/4HANA BKLAS → S/4HANA G/L account. This mapping drives the account determination table (OBYC).

For split valuation materials, valuation type records must be created in the material master even if the opening stock quantity is zero. The ML requires the CKMLHD/CKMLPR structure to exist for the valuation type before any future goods movement can post against it. Load the material master record for each zero-stock valuation type; do not load an inventory balance record.

Transaction OMXW assigns ML types to valuation areas and defines which currency types are active. This must be complete and frozen before the first material master or inventory load.

All currency types that will be used in production must be configured before the first data load. Currency types cannot be added to ML documents retrospectively — adding a currency type after inventory has been posted requires a full reload of all affected materials.

This setting applies per valuation area (plant). The decision is non-reversible after inventory is loaded. Document and freeze the decision per plant before go-live.

Configure valuation categories and valuation types within each category. Rationalize ECC categories: eliminate unused categories, consolidate overlapping types. Configuration must be complete before any split valuation material master records are loaded.

Greenfield is the right time to redesign the cost component structure from scratch (transaction OKTZ). Design principles:

• Align each cost component to a distinct G/L account for COGS Split mapping
• Separate at minimum: raw material, packaging, labor (direct), machine (direct), overhead (variable), overhead (fixed), subcontracting, freight
• Define auxiliary cost components for margin analysis detail without overcomplicating primary cost components
• Map each cost component to a COGS Split G/L account — required for margin analysis in CO-PA

The cost component structure is the foundation for COGS Split. If it is under-designed, COGS Split data in margin analysis is too coarse to be useful.

COGS Split must be activated before the first goods issue in the new system. Activation is done in CO-PA Customizing. The mapping from cost component to COGS G/L account must be complete. This is a Day 1 non-negotiable: documents posted before COGS Split activation have no cost component breakdown and cannot be retroactively split.

S/4HANA eliminates secondary cost elements. All ECC secondary CEs must be mapped to primary G/L accounts before CO master data is loaded.

This mapping must be completed and validated in the chart of accounts before Job_DM_CostCenter_IDOC and Job_DM_ActivityType_IDOC run. Any CO cycle that references a secondary CE that does not exist in S/4HANA will fail activation.

All assessment and distribution cycles must reference primary G/L accounts as the cost element. Rebuild all cycles using primary G/L accounts. Validate cycle configurations in the new system before the first period-end close — not at go-live.

ECC transfer pricing using markup approaches must be reconfigured under the S/4HANA Transfer Pricing framework. The S/4HANA TP framework uses the multiple valuation approach within the Universal Journal — currency type 31 carries the transfer price. Configure TP rules in Customizing before the first intercompany inventory movement. The ECC markup approach does not translate directly — a design session is required during Phase 1.

All CO area settings must be frozen before any CO master data is loaded via RDM.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    subgraph SRC["ECC Source Extraction Layer"]
        S1["Valuation Data Extract"]
        S2["ML Period Records"]
        S3["PO History"]
        S4["Costing Run Data"]
        S5["CO Line Items"]
        S6["BOM / Routing"]
        S7["CO Master Data"]
        S8["FI Open Items"]
    end

    subgraph ETL["SAP Data Services 4.3 ETL Layer"]
        E1["ATL Job Files"]
        E2["IDoc Mapping Templates"]
        E3["Lookup Files"]
        E4["Migration Services Tool"]
        E5["SAP Information Steward"]
        E6["WebI Reconciliation Reports"]
    end

    subgraph CFG["Greenfield Configuration Gate"]
        C1["Currency Types"]
        C2["Price Determination"]
        C3["Split Valuation Config"]
        C4["COGS Split Activation"]
        C5["Cost Component Structure"]
        C6["Secondary CE to G/L Mapping"]
        C7["CO Area Settings"]
    end

    subgraph SEQ["Strict Load Sequence"]
        L1["Step 1: CO Master Data"]
        L2["Step 2: Material Master"]
        L3["Step 3: BOM and Routing"]
        L4["Step 4: Activity Prices"]
        L5["Step 5: Cost Estimates"]
        L6["Step 6: Business Partners"]
        L7["Step 7: Open POs and Info Records"]
        L8["Step 8: Inventory Balances"]
        L9["Step 9: Open Production Orders"]
        L10["Step 10: FI Open Items"]
        L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7 --> L8 --> L9 --> L10
    end

    subgraph TGT["S/4HANA Target Layer"]
        T1["Opening Balances — Currency Types"]
        T2["ML Documents"]
        T3["ML Header / Period Records"]
        T4["Material Valuation"]
        T5["CO Documents"]
    end

    subgraph VAL["Greenfield Validation Layer"]
        V1["Stock vs ECC Extract"]
        V2["ACDOCA Currency Type Check"]
        V3["Split Valuation KZVKZ Check"]
        V4["Cost Estimate Consistency"]
        V5["GR/IR Balance Reconciliation"]
        V6["WebI Reconciliation Reports"]
    end

    subgraph GOL["Go-Live Gate"]
        G1["All Validations Green"]
        G2["MM/FI Periods Aligned"]
        G3["COGS Split Active"]
        G4["Goods Movements Released"]
    end

    SRC --> ETL
    ETL --> CFG
    CFG --> SEQ
    SEQ --> TGT
    TGT --> VAL
    VAL --> GOL

    S1:::source
    S2:::source
    S3:::source
    S4:::source
    S5:::source
    S6:::source
    S7:::source
    S8:::source
    E1:::integration
    E2:::integration
    E3:::integration
    E4:::integration
    E5:::integration
    E6:::reporting
    C1:::integration
    C2:::integration
    C3:::integration
    C4:::integration
    C5:::integration
    C6:::integration
    C7:::integration
    L1:::integration
    L2:::integration
    L3:::integration
    L4:::integration
    L5:::integration
    L6:::integration
    L7:::integration
    L8:::integration
    L9:::integration
    L10:::integration
    T1:::target
    T2:::target
    T3:::target
    T4:::target
    T5:::target
    V1:::reporting
    V2:::reporting
    V3:::reporting
    V4:::reporting
    V5:::reporting
    V6:::reporting
    G1:::target
    G2:::target
    G3:::target
    G4:::target

SAP Note 2239701 lists 52 supported migration objects. The following table maps each to its ML/costing relevance in greenfield.

Material Master (Job_DM_Material_IDOC) Carries valuation class (BKLAS), price control (VPRSV), ML indicator (MLAST), and split valuation category (BWTTY). The IDoc interface is MATMAS. Price control S materials must not have STPRS populated via this IDoc — STPRS is set by the cost estimate release only.

Inventory Balances (Job_DM_InventoryBalance) Posts opening stock via movement type 561. For split valuation materials, a separate 561 posting per valuation type is required. The job does not calculate prices — it accepts quantity and value from the source file. For S-price materials, the value must equal quantity × STPRS / PEINH. If the cost estimate has not been released, S/4HANA has no standard price and the posting fails or posts at zero.

Cost Centers (Job_DM_CostCenter_IDOC) and Activity Types (Job_DM_ActivityType_IDOC) Must be loaded before any cost estimate is run. CK11N references work center → activity type → cost center to pull planned activity prices from COSS/COSP. If cost centers or activity types are missing, the cost estimate throws a missing master data error.

BOM (Job_DM_BOM_IDOC) and Routing (Job_DM_Routing_IDOC) Define the cost structure for multilevel cost rollup in CK11N/CK40N. The cost estimate explodes the BOM and pulls activity prices from routing operations. If BOM or routing is incomplete at cost estimate execution, the rollup produces partial costs — finished goods are undercosted and opening inventory is loaded at a price that does not reflect actual production cost structure.

Production Orders (Job_DM_ProductionOrder_IDOC) Open production orders carry WIP balances. In greenfield, WIP is loaded as the open order balance at cutover. The order must reference valid cost centers, activity types, materials, and BOMs already loaded. Post-load, run KKAO to confirm WIP balance agrees with the loaded order value.

Purchase Orders (Job_DM_PurchaseOrder_IDOC) Open POs carry EKBE (GR/IR history) and EKBZ (delivery cost history). The PO must reference a valid vendor (business partner) already loaded. GR/IR open items in FI are reconciled against open PO quantities at cutover.

Internal Orders and WBS Internal orders (Job_DM_InternalOrder_IDOC) and WBS elements (Job_DM_WBS_IDOC) are ML cost objects when they carry open balances at cutover. Load before FI open items — FI postings reference the cost object.

SAP Note 2239701 states explicitly: “There are risks when using INFREC to migrate data. If you would like to distribute info records through SAP systems, you can use the Idoc type INFREC. This is meant for info record distribution via ALE, however, not for data transfer.”

Consequence for ML: Purchase info records carry delivery cost condition records that feed EKBZ. If EKBZ is populated via INFREC IDoc incorrectly, delivery costs are miscalculated in actual costing — specifically in multilevel actual costing where delivery costs are included in the periodic unit price (PUP) calculation.

Correct approach: Use ME_INFORECORD_MAINTAIN API as referenced in Notes 2472030 and 2417298. Do not develop custom Data Services flows against INFREC IDoc.

Job_DM_CustomerMaster_IDOC and Job_DM_Vendor_IDOC are the correct RDM objects for customer and vendor migration. Additional BP roles beyond Customer and Vendor require custom development per the Extension Guide (RDM_S4H_OP_2023_DM_Extension_Guide_EN_XX.docx).

RFC_CVI_EI_INBOUND_MAIN is explicitly obsolete per Note 2239701. Do not use it. Any project team using this RFC risks creating incomplete BP records that block PO and inventory loads.

Business partners must be complete — all roles assigned — before Job_DM_PurchaseOrder_IDOC and Job_DM_InventoryBalance run.

SAP Note 2239701 states: “We do not provide any support for custom SAP Data Services code based on any API that is used with the rapid data migration solution.” If a project team develops custom DS flows for objects not covered by the 52 prebuilt objects, the full validation burden falls on the project. Custom flows must be tested exhaustively in multiple mock cutover iterations before production execution.

SAP Note 2239701 explicitly lists “Secondary Cost Element” as object #1 and notes it is not supported in S/4HANA. This is the single most significant CO master data impact in greenfield. Every ECC secondary CE must be analyzed, mapped to a primary G/L account, and the downstream CO cycles, activity types, and cost component structures must be updated before any CO master data load begins.

SAP Note 2239701 confirms: “If you own either a runtime (REAB) or full use SAP HANA license, this includes a limited use license of SAP Data Services software restricted to loading data into SAP HANA (called Data Integrator license). This fills the minimum requirement for the SAP Rapid Data Migration to SAP S/4HANA content which includes full ETL.” No separate DS license purchase is required for migration ETL execution.

For greenfield projects, the approach to Note 2345739 is:

1. Identify the S/4HANA target release and SP level from the tables in Note 2345739
2. Implement all notes marked X for the target SP level — the note states: “by implementing all of the mentioned notes, you can prevent large amount of issues from occurring”
3. Filter out notes whose description explicitly references FINS_MIG_STATUS, M10, M11, M20, M21, or NZDT — safe to skip in greenfield
4. Retain all notes referencing ML Customizing, actual costing, CKMLCT, CKMLHD, or CKMLPR — these apply in greenfield

The load sequence runs strictly top to bottom: the Configuration Gate, then Steps 1–10 in order, then the Validation Layer, then the Go-Live Gate.

1. Load material master via Job_DM_Material_IDOC with VPRSV = S and STPRS = 0
2. Load BOM and routing referencing this material
3. Ensure activity prices are loaded (KP26)
4. Execute CK11N or CK40N to create and release the cost estimate
5. System writes STPRS to MBEW via ML price change document
6. Only then execute Job_DM_InventoryBalance for this material

Never load STPRS directly in the material master IDoc for S-price materials. The cost estimate release creates the ML price document chain in CKMLHD/CKMLPR. Without this chain, ACDOCA has no basis for the standard price, and variance calculation in actual costing is broken from the first goods movement.

1. Load material master via Job_DM_Material_IDOC with VPRSV = V and VERPR set to the ECC closing MAP at the reference period
2. Reconcile loaded VERPR against ECC MBEW-VERPR extract — tolerance should be zero (exact match)
3. Execute Job_DM_InventoryBalance — the 561 posting uses the loaded VERPR as the price basis
4. Post-load, verify MBEW-VERPR in S/4HANA matches the source extract

MAP is not recalculated by the system during the 561 posting — it uses the price already in MBEW-VERPR. If VERPR was loaded incorrectly, every subsequent goods movement uses the wrong price until a physical inventory adjustment corrects it.

G/L account numbers are illustrative. Actual accounts must align to the S/4HANA chart of accounts design.

Each special stock type requires its own 561 variant posting in Job_DM_InventoryBalance. The source file must include the correct SOBKZ value and the associated account assignment object.

Job_DM_InventoryBalance is the RDM Data Services job that posts opening stock in the new S/4HANA system.

What it does: Reads quantity and value from the source file, generates an IDoc with movement type 561, and posts a goods receipt to unrestricted stock (or special stock per SOBKZ). The posting creates an ACDOCA line item with all ML currency fields populated based on the configured currency types (10/30/31/32).

What it does NOT do: It does not calculate prices. It does not create cost estimates. It does not validate that the loaded value matches the standard price. It does not post split valuation types automatically — each valuation type requires a separate source record.

In brownfield, FINS_MIG_STATUS M20 performs the formal reconciliation. In greenfield, M20 does not run. The reconciliation framework must be built by the project team.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    ECC["ECC Extract"]:::source
    S4["S/4HANA Post-Load"]:::target

    Q1{"Quantity Match?"}:::integration
    Q2{"Value Match?"}:::integration
    Q3{"KZVKZ Check"}:::integration
    Q4{"Cost Estimate Status?"}:::integration
    Q5{"ACDOCA Currency Types?"}:::integration
    Q6{"GR/IR Balance?"}:::integration
    Q7{"ML Period Records?"}:::integration

    PASS["All Checks Pass — Sign Off"]:::target
    FAIL1["Quantity Mismatch"]:::reporting
    FAIL2["Value Mismatch"]:::reporting
    FAIL3["KZVKZ Missing"]:::reporting
    FAIL4["Cost Estimate Missing"]:::reporting
    FAIL5["Currency Type Gap"]:::reporting
    FAIL6["GR/IR Mismatch"]:::reporting
    FAIL7["ML Record Missing"]:::reporting

    ECC --> Q1
    S4 --> Q1
    Q1 -->|"Pass"| Q2
    Q1 -->|"Fail"| FAIL1
    FAIL1 -->|"Corrected"| Q1
    Q2 -->|"Pass"| Q3
    Q2 -->|"Fail"| FAIL2
    FAIL2 -->|"Corrected"| Q2
    Q3 -->|"Pass"| Q4
    Q3 -->|"Fail"| FAIL3
    FAIL3 -->|"Corrected"| Q3
    Q4 -->|"Pass"| Q5
    Q4 -->|"Fail"| FAIL4
    FAIL4 -->|"Corrected"| Q4
    Q5 -->|"Pass"| Q6
    Q5 -->|"Fail"| FAIL5
    FAIL5 -->|"Corrected"| Q5
    Q6 -->|"Pass"| Q7
    Q6 -->|"Fail"| FAIL6
    FAIL6 -->|"Corrected"| Q6
    Q7 -->|"Pass"| PASS
    Q7 -->|"Fail"| FAIL7
    FAIL7 -->|"Corrected"| Q7

Greenfield is the only opportunity to design the cost component structure without migration constraints. Design the cost component structure (OKTZ) as follows:

• Align each cost component to a distinct G/L account for COGS Split mapping
• Separate at minimum: raw material, packaging, labor (direct), machine (direct), overhead (variable), overhead (fixed), subcontracting, freight
• Define auxiliary cost components for margin analysis detail where the business requires more granularity than COGS Split G/L accounts
• Define at least the “cost of goods manufactured” view and the “cost of goods sold” view separately if transfer pricing is in scope

Three prerequisites (Activity Prices, BOM, Routing) must all be complete before the cost estimate is created; the remaining steps run strictly in sequence.

Actual costing activation is configured per plant via transaction CKMVFM. This decision is non-reversible after inventory has been posted.

COGS Split must be activated before the first goods issue in S/4HANA. Activation sequence:

1. Activate COGS Split in CO-PA Customizing
2. Map each cost component to a COGS G/L account
3. Validate the mapping covers 100% of cost components — any unmapped component posts to the default COGS account without breakdown
4. Activate for all relevant company codes and plants
5. Verify activation before go-live gate sign-off

If COGS Split is not active at go-live, the first period’s margin analysis has no cost component detail — this cannot be retroactively corrected.

Price determination = 3 must be set in the material master before the cost estimate is created. If price determination = 2 is set and the cost estimate is released, the material is valued at the single-source cost — switching to = 3 afterward requires re-running and re-releasing the cost estimate and reposting any inventory already loaded.

After Job_DM_ProductionOrder_IDOC loads open production orders:

1. Run KKAO (WIP calculation) for all loaded orders
2. Compare WIP balance per order to the ECC COEP extract at the reference period
3. Any discrepancy indicates a missing cost posting on the order — investigate via KOB1
4. WIP is carried in ACDOCA as a balance on the production order cost object — verify per order that the ACDOCA balance matches the loaded WIP value

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    P1["Phase 1: Assess and Design<br>10–14 Weeks"]:::source

    P2["Phase 2: Build and Configure<br>6–10 Weeks"]:::integration

    P3["Phase 3: Master Data Load Iterations<br>4–8 Weeks"]:::integration

    P4["Phase 4: Mock Cutovers<br>2–4 Weeks"]:::integration

    P5["Phase 5: Cutover Execution<br>Migration Window"]:::target

    P6["Phase 6: Hypercare<br>4 Weeks Post Go-Live"]:::reporting

    P1 --> P2
    P2 --> P3
    P3 --> P4
    P4 -->|"Mock Cutovers Pass"| P5
    P4 -->|"Issues Found"| P3
    P5 --> P6

First Run Prerequisites Specific to Greenfield:

• All opening inventory postings (561) must be in the same period as the first CKMLCP run — do not split inventory loads across two periods
• All open production order WIP loaded via Job_DM_ProductionOrder_IDOC must be in the first period
• Activity prices (KP26) must be loaded before CKMLCP — actual costing uses planned activity prices as the basis for single-level price calculation until actual prices are confirmed
• COGS Split must be active — first CKMLCP run generates COGS revaluation documents that split across cost component G/L accounts

First Run Monitoring Checklist:

Common causes of MB5L vs FS10N variance in greenfield post go-live:

CKM3N — Material Ledger Cockpit:

MLDOC_EXTRACT provides a structured extract of all ML documents for a plant/period. Use it for audit trail of all ML-relevant postings, BW/analytics feed for ML reporting, reconciliation input comparing ML document values to ACDOCA balances, and investigation of specific ML document categories (price change, revaluation, settlement). Run at the end of each period and store the output as an audit artifact.

The WebI reconciliation reports delivered by SAP Note 2239701 are not only for cutover — they should be integrated into the ongoing data quality monitoring framework.