Scenario 17 — Split Valuation (Same Material, Different Prices by Origin)

TIER 6 · MASTER DATA ★★★★☆ ⏱️ ~2 hours OMWC → MM01 (val type) → MIGO
← Previous
Scenario 16: Batch Management
Next →
Scenario 18: QM Integration
⚠️ Not yet live-tested
This page is built from researched standard-SAP content and has not yet been executed end-to-end in our IDES. The T-codes, fields, and accounts follow SAP standard but may need small adjustments on your S/4HANA 2023 system — we'll confirm and correct them when you run this scenario live. Hit a snag? See the Troubleshooting Center.

📊 Business Case

Split Valuation lets one material code carry more than one inventory value at the same time — split along a dimension you choose, such as origin (imported vs local), procurement type (in-house vs external), or condition (new vs used). PakSteel buys identical steel scrap both locally and as imports at very different costs, but it is the same physical material. Split valuation keeps each origin valued separately so costing, COGS and margins stay accurate.

🕐 When to use it

The same material is sourced at materially different costs (local vs imported), or exists in states worth different amounts (new vs refurbished) — and you need each valued and reported separately.

❓ Why it matters

Accurate costing and margins. A single blended price hides that imported scrap costs 50% more than local. Separate valuations give true COGS per origin, so pricing and profitability decisions rest on real numbers.

👤 Who triggers it

The buyer picks the valuation type on every PO; the storekeeper carries it through GR/GI; costing and finance read the per-type values in MBEW for valuation and analysis.

🔁 The key distinction

Batch management (Scenario 16) tracks which physical lot; split valuation tracks how much each sub-stock is worth. One material, one stock figure, but several valuation rows in MBEW — one per valuation type plus a header average.

💰 Financial Impact — The Easy-Money Example

PakSteel receives 100 TO of local scrap @ ₨80,000 and 100 TO of imported scrap @ ₨120,000 — same material code SCRAP-STEEL-01. Split valuation holds two valuation sub-totals instead of one misleading blend:

🏠 LOCAL valuation type
₨8,000,000
100 TO @ ₨80,000 — its own MBEW row. COGS when this stock is issued = ₨80,000/TO.
+
🚢 IMPORT valuation type
₨12,000,000
100 TO @ ₨120,000 — a separate MBEW row. COGS when this stock is issued = ₨120,000/TO.
📊 Header (blended avg)
₨20,000,000
200 TO, avg ₨100,000/TO — for reporting only. The accurate cost is the per-type value, not this blend.

The big idea: a single moving average of ₨100,000/TO would over-cost local issues and under-cost imported ones — distorting every margin. With split valuation, each origin is costed at its true ₨80,000 / ₨120,000, so COGS and profitability are correct per source.

💡 Lesson: split valuation creates multiple valuation rows in MBEW under one material number. The header price is just a weighted average for reporting — the real costing happens at the valuation-type level, which is why every PO, GR and GI must name its valuation type.

🇵🇰 The Business Story

PakSteel buys steel scrap from local sources (PKR 80,000/TO) and imported (PKR 120,000/TO). SAME material code, but DIFFERENT valuation per origin. Need separate inventory value tracking. Split valuation lets one material code hold multiple valuations.

🎯 What you'll learn

📦 Material needed — create first (just-in-time)

SCRAP-STEEL-01 (ROH — same steps as RM-IRON-01, different code) — create steps · how to create a ROH.

📦 MIGO top bar
MIGOAction Goods Receipt · Reference Purchase Order → mvt 101 → pick the valuation type on the line (which valuation bucket the stock lands in). Full guide: MIGO Selection Bar.

🔧 Step-by-Step

⚙️ Config

17.1 — Activate Split Valuation Category · OMWC
  1. OMWC · Activate Split Valuation globally
  2. Define Valuation Category H (Origin) — usually delivered standard
  3. Define Valuation Types under H: LOCAL, IMPORT
  4. Assign Cat H to Valuation Areas (plants PK01/PK02/PK03)
  5. Save
17.2 — Extend Material with Valuation Types · MM01
  1. MM01 · Material SCRAP-STEEL-01 · Material Type ROH
  2. Accounting view → Valuation Category: H
  3. Now create per valuation type:
    • Valuation Type: LOCAL · Moving Price: 80,000 PKR/TO
    • Valuation Type: IMPORT · Moving Price: 120,000 PKR/TO
  4. Header level: an "average" price for reporting

🔄 Test

17.3 — PO + GR with valuation type
  1. ME21N · Material SCRAP-STEEL-01 · enter Valuation Type field = LOCAL · Price 80,000
  2. GR mvt 101 · system posts to LOCAL bucket of MBEW
  3. Stock now: LOCAL 100 TO @ 80K, IMPORT 0 TO
  4. Repeat with valuation type IMPORT

✅ Verification

🎓 Interview-Ready Answers

Q: What is the difference between a valuation category and a valuation type?

The valuation category is the dimension you split on — e.g. H for origin. The valuation types are the individual buckets within that category — e.g. LOCAL and IMPORT. You set the category on the material's Accounting view, then extend the material with one accounting record per valuation type.

Q: How does split valuation show up in the database?

In table MBEW (material valuation). A split-valuated material has one row per valuation type (each with its own quantity and value/price) plus a header row that holds the weighted-average price across all types. A non-split material has a single MBEW row.

Q: Why must every PO, GR and GI specify a valuation type?

Because the stock and value are tracked separately per type. SAP must know which bucket (LOCAL vs IMPORT) to debit on receipt and which to credit at issue — otherwise it can't post to the right MBEW row or apply the correct cost. The header average is reporting only and can't receive postings.

Q: Split valuation vs batch management — when do you use which?

Batch management answers "which physical lot is this?" for traceability/expiry. Split valuation answers "what is this sub-stock worth?" for costing. They are independent and can be combined — e.g. batch-tracked steel that is also valued separately by local vs imported origin.

← Previous
Scenario 16: Batch Management
Next →
Scenario 18: QM Integration