Scenario 19 — Custom Material Type (Halal-Certified Materials)
📊 Business Case
A material type (ROH, HALB, FERT…) is the master switch that controls how a material behaves: which fields appear, which valuation classes — and therefore which G/L accounts — are allowed, what number range it draws from, and whether it is stockable and valuated. When the standard types don't fit a special category of material, you build your own. Here PakSteel's food-grade subsidiary needs to segregate Halal-certified materials, so we create ZHAL with its own number range, field control, and account determination.
🕐 When to use it
When standard ROH/HALB/FERT can't capture a distinct material category your business must track separately — e.g. Halal-certified, hazardous, or regulated goods needing their own numbering and accounting.
❓ Why it matters
The material type drives account determination (allowed valuation classes → OBYC G/Ls), field selection, and the number range. Get it right once and every material of that type behaves consistently and posts to the correct accounts.
👤 Who triggers it
An MM consultant configures it in customizing (OMS2); the master-data team then creates materials against it via MM01. Finance signs off on the valuation-class → G/L mapping.
🔁 The key distinction
A custom material type is config, not a posting. It changes how materials are numbered, controlled and valued — its payoff is correct accounts, clean reporting, and compliance, not a one-off journal entry.
💰 Financial Impact — The Easy-Money Example
This scenario is configuration, so the "money" is about accuracy and control, not a single posting. The payoff shows up every time a Halal material is created or consumed: it lands in the right valuation class, hits the right G/L, and is instantly reportable for audit.
HAL0000001 is forced onto valuation class 3050, so its inventory + consumption hit a dedicated Halal G/L via OBYC.Where a real posting appears: the config has no journal entry itself, but the downstream postings do. Because valuation class 3050 is wired into OBYC (BSX for inventory, GBB/VBR for consumption), a goods receipt for HAL0000001 debits the Halal Inventory G/L, and a goods issue debits the Halal Consumption G/L — automatically, every time.
🇵🇰 The Business Story
🎯 What you'll learn
- Field selection — which fields are mandatory/optional/hidden for this material type
- Valuation classes allowed — which OBYC G/L accounts get hit
- Number range — separate numbering pool (e.g., HAL-xxxxxxx vs MAT-xxxxxxx)
- Stock-keeping — is it stockable? Valuated?
- Quantity / Value updating per plant or globally
- Authorization group — who can create
This scenario configures the custom type ZHAL (OMS2) and creates ZHAL-CHEM-01 (MM01). Condensed steps & fields: Create the Z material.
- A working org structure — company code, plant and valuation area already built (see Setup Hub).
- Customizing access on a sandbox (SPRO / OMS2) — nothing is posted, so no vendor or master data is needed first.
- The will to customize: this scenario builds the material type
ZHALitself, from scratch.
🔧 Step-by-Step
| Step | T-code | What it does | Why this step exists |
|---|---|---|---|
| 19.1 | OMS2 | Copy ROH to new type ZHAL and set its rules | a special material needs its own rulebook |
| 19.2 | OMSK | Allow only valuation class 3050 for ZHAL | Halal money must hit only Halal accounts |
| 19.3 | SNRO | Build number pool HAL0000001–HAL9999999 and link it to ZHAL | a Halal material should be recognisable by its code |
| 19.4 | MM01 | Create the first Halal material — auto number, only 3050 offered | config is only proven by a real material |
⚙️ Config Steps
19.1 — Copy standard ROH to ZHAL · OMS2
⚡ This step will: create the rulebook itself — a brand-new material type ZHAL now exists in customizing, ready to control every future Halal material. Nothing is bought, moved or posted. 📄 paper: — (config only) · 📦 stock: no change · 💰 money: no posting
Do: OMS2 → select ROH → Copy As → new type ZHAL → adjust the fields below → Save.
Why start from ROH? It is already a raw-material type, so most of its settings are the ones any raw material needs — a sensible baseline that saves re-deciding each field. You only change what makes Halal special (its own number range, valuation class and authorization group). A Z-name is your own object, never overwritten by SAP upgrades.
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Description | Halal-Certified Raw Material | What is this material type called? Like the label on a filing drawer — it is the text staff read when they pick a type from the list. | A clear name makes staff choose the right type. Impact: a vague name gets the wrong type picked, so a Halal material could be created under normal-material rules and lose its segregation |
| External Purchase Orders | + (allowed) | May a material of this type be BOUGHT from an outside vendor (external procurement)? | Halal raw materials are bought in, so external buying must be permitted. Impact: if this were set to "not allowed", no purchase order could ever be raised for a ZHAL material — purchasing is blocked at the source |
| Internal Purchase Orders | + (allowed) | May it instead be obtained in-house / internally rather than bought out? | Leaving both routes open gives full flexibility for how the material is supplied. Impact: forbidding it stops in-house/internal supply of the material, cornering you into external buying only |
| Field selection group | 41 | Which bundle of screen rules do the material screens follow? A bundle decides which boxes are must-fill, optional, or hidden — like choosing a form template. | A raw material needs its purchasing, accounting and MRP boxes available and the key ones mandatory; this bundle exposes exactly those. Impact: a bundle missing key fields lets materials save with gaps (e.g. no valuation data), which later blocks postings |
| Authorization group | Z_HALAL | WHO is allowed to create or change materials of this type? A lock on the drawer — only staff whose role holds this key can open it. | Halal is a compliance category, so creation must be limited to trained, authorised staff. Impact: leave it blank and anyone can create or edit Halal materials, defeating the controlled segregation the type exists to enforce |
| Number range group | ZH | From which numbering pool do new ZHAL materials draw their code? Here you only write the pool's NAME onto the type. | It points the type at the dedicated ZH pool (built in 19.3) so every Halal material gets a recognisable HAL… code. Impact: name a pool that does not exist yet and material creation fails until the pool is created and linked |
19.2 — Assign Valuation Classes · OMSK
⚡ This step will: lock ZHAL onto one money label — after saving, valuation class 3050 is the ONLY choice MM01 will ever offer, so every future posting for a Halal material can reach only the Halal G/L accounts. 📄 paper: — (config only) · 📦 stock: no change · 💰 money: no posting (it pre-wires future postings)
Jargon first — valuation class: a label on the material that tells finance which G/L account its money lands in. OBYC reads this label. So controlling the label = controlling the accounts.
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| OMSK · Material Type | ZHAL | Which material type are you setting the allowed valuation classes for? (A valuation class is the label that tells finance which G/L account the material's money lands in.) | You are restricting ZHAL specifically. Impact: point at the wrong type and ZHAL keeps its default open list, so users can still choose a non-Halal class |
| Allowed valuation class | 3050 (Halal Raw Materials) | Which valuation-class label(s) may a material of this type wear? Whatever you list here is all that MM01 will ever offer. | Allowing exactly ONE class removes any chance of a wrong pick — every ZHAL material is forced onto 3050, which leads only to the Halal accounts. Impact: allow several classes and a clerk can post Halal stock to a non-Halal account, breaking the whole reason for the type |
| Save | — | Commits the restriction so it takes effect for new materials. | The rule is inactive until saved. Impact: unsaved, MM01 still offers the old open list of classes |
| OBYC · Account wiring | wire valuation class 3050 to G/Ls | Which REAL G/L accounts does the label 3050 stand for? OBYC is the map from class to account — BSX = inventory account, GBB/VBR = consumption. | A label is only useful if it points at accounts. Impact: skip this and 3050 maps to nothing, so a goods receipt for a Halal material has no account to post to and errors out |
19.3 — Define Number Range · SNRO Object MATERIALNR
⚡ This step will: build the ticket roll — a numbering pool HAL0000001–HAL9999999 now exists and is linked to ZHAL, so every new Halal material automatically gets a recognisable HAL… code. 📄 paper: — (config only) · 📦 stock: no change · 💰 money: no posting
Number range = a ticket roll. Every new material tears off the next number. ZHAL gets its own roll, so a Halal material is recognizable from its code alone.
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| SNRO · Object | MATERIALNR | Numbers for WHAT? SNRO holds every numbering pool in the system; you open the one for material numbers. | Material codes are issued by the MATERIALNR object. Impact: open the wrong object and you would edit some other document's numbering, not materials |
| Interval key | ZH | A short code that names this new ticket roll so the material type can point at it later. | ZHAL will reference "ZH" in 19.1. Impact: use a name ZHAL is not linked to and new Halal materials draw from the wrong roll (or none) |
| From number | HAL0000001 | The FIRST ticket in the roll — the lowest code that can be handed out. | The HAL… prefix is the visible identity: anyone seeing a HAL code knows it is Halal stock before opening a screen. Impact: a range that overlaps another roll causes number clashes and creation errors |
| To number | HAL9999999 | The LAST ticket — the highest code, i.e. how many the roll can ever issue. | Nearly 10 million codes is ample headroom. Impact: too small a range and the roll runs out, halting new Halal material creation until it is extended |
| External (tick / no tick) | no tick (internal) | Who types the number — SAP or the person? Internal (no tick) = SAP counts up and hands out the next code itself; external (tick) = the user types a code inside the range. | Internal numbering lets the test (19.4) leave the material field blank and have SAP assign HAL0000001. Impact: tick external by mistake and MM01 demands a hand-typed number, so blank-and-save fails |
| Link it · OMS2 | ZHAL → Number Range Group ZH · Save | Which material type actually uses this roll? Back in OMS2 you stamp the roll's name onto ZHAL. | The pool exists but stays unused until the type points at it. Impact: no link, no automatic numbers — MM01 cannot assign a code and creation stops |
🔄 Test
19.4 — Create material with ZHAL · MM01
⚡ This step will: create the first real Halal material — after Save, master record HAL0000001 exists in the database, permanently carrying the ZHAL rulebook (own number, own valuation class, own authorization). It is master data, not a transaction — no ledger entry yet. 📄 paper: material master record (no posting document) · 📦 stock: no change · 💰 money: no posting
MM01 walks through four screens: ① the Initial screen (Material number, Industry sector, Material type), ② the Select View(s) popup (tick which views to fill), ③ the Organizational Levels popup (plant, storage location…), ④ the data views themselves (Basic Data, Purchasing, Accounting 1…). The proof this scenario worked shows up on the Initial screen (the auto number) and the Accounting 1 view (only class 3050 is offered).
| Where on screen · Field | Fill | What it asks (plain words) | Why — and the impact if wrong |
|---|---|---|---|
| Initial screen · Material | leave blank (auto-assigned) | What code will this material get? | Blank = "give me the next ticket from the roll". Impact: typing a code yourself is the external-numbering way — not our internal-range setup. |
| Initial screen · Industry sector | M | Which broad industry screen layout applies? | Sets which industry-specific fields appear. Impact: a different sector shows a different field layout — keep M consistent so every material's screens look the same. |
| Initial screen · Material Type | ZHAL | Which rule book governs this material? | The master switch — it brings everything you configured: field template, number pool, allowed valuation class. Impact: the wrong type and none of your ZHAL rules apply. |
| Status bar (after Save) · Number assigned | system gives HAL0000001 | Did the ZH number roll from 19.3 actually link? | Proof the internal range works. Impact: a number from the wrong range means the SNRO assignment was missed. |
| Accounting 1 view · Valuation Class | ONLY 3050 allowed (others blocked) ✓ | Which G/L-account group may this material use? | Proof the OMSK restriction bites — a wrong label is impossible at creation, the whole point of the scenario. Impact: if other classes are selectable, the OMSK account-category reference was not restricted. |
| All data views · fill remaining + Save | — | Anything left before the material becomes real? | Saved with its full Halal identity: own number, own label, own G/L accounts. Impact: a missing required view blocks the save until completed. |
What changes at this exact moment: pressing Save does not post any accounting entry — it creates a material master record. The instant it saves:
- A brand-new material
HAL0000001now exists in the database, torn from theZHnumber roll built in 19.3. - It is stamped material type
ZHAL, so it permanently carries the ZHAL rulebook — the field template, authorization groupZ_HALAL, and only valuation class3050. - Because
3050is wired in OBYC (19.2), the FIRST time this material has a goods receipt it will post to the Halal inventory G/L — but no money moves now; this step only sets up the identity.
The difference from a posting step: MM01 is master-data creation, not a transaction — nothing hits the ledger here. The payoff is that every future posting for this material is now forced onto the right Halal accounts. Verify: MM03 → the new number → Accounting 1 view shows valuation class 3050.
✅ Verification
| # | T-code | Check |
|---|---|---|
| 1 | OMS2 | ZHAL exists with description, number range group ZH, authorization group Z_HALAL |
| 2 | SNRO | Object MATERIALNR shows interval ZH = HAL0000001–HAL9999999 |
| 3 | MM01 | Creating a ZHAL material auto-assigns HAL0000001 and offers only valuation class 3050 |
| 4 | MM03 | Display the new material → Accounting view shows valuation class 3050 |
🎓 Interview-Ready Answers
Q: What does a material type control in SAP MM?
The material type drives the allowed views/field selection (mandatory/optional/hidden fields), the number range (internal or external), whether the material is quantity- and value-updated (stockable/valuated), the permitted valuation classes (and hence OBYC G/L account determination), the default price control, and the authorization group for who may create it.
Q: How does a custom material type ensure postings hit the right G/L?
Via the valuation class. In OMSK you restrict the material type (ZHAL) to one valuation class (3050). That valuation class is mapped in OBYC — BSX for the inventory account, GBB/VBR for consumption — so every GR/GI for a ZHAL material posts to the dedicated Halal accounts automatically.
Q: Why create a new material type instead of just using a new valuation class on ROH?
A separate valuation class alone gives account separation but not field control, a dedicated number range, authorization, or guaranteed segregation. A custom type enforces all of these together — users can't accidentally pick the wrong valuation class, the number range visibly identifies the material (HAL…), and creation is restricted by authorization group — which matters for regulatory/compliance categories like Halal.