Scenario 20 — Custom PO Document Type (Imports vs Local)

TIER 7 · CUSTOMIZATION ★★★★★ ⏱️ ~2 hours OMEC → OMEB → SNRO (object EBELN)
← Previous
Scenario 19: Custom Material Type
Next →
Scenario 21: Pricing Procedure
⚠️ 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

A purchasing document type (NB Standard PO, FO Framework Order…) controls how a PO is numbered, which item categories are allowed, which fields are mandatory, and which release strategy and output forms apply. When one business process needs to behave differently from another — say imports vs local purchasing — you split them into separate document types. Here PakSteel creates ZIMP (imports) and ZLOC (local), each with its own number range and field control for cleaner control and reporting.

🕐 When to use it

When two PO streams need distinct numbering, mandatory fields, approvals, or print forms — classically import vs local, or capex vs opex — so each can be governed and reported on separately.

❓ Why it matters

The document type is the hook for number ranges, allowed item categories, field selection, release strategy, and output. One config decision shapes governance and reporting across thousands of POs.

👤 Who triggers it

An MM consultant defines the doc types in customizing (OMEC); buyers then pick ZIMP or ZLOC when creating a PO in ME21N.

🔁 The key distinction

This is config, not a posting. It doesn't move money — it routes each PO into the right number range, field rules, and approval path, which pays off as control and clean reporting.

💰 Financial Impact — The Easy-Money Example

Splitting PO streams by document type is configuration, so the value is control and reporting accuracy, not a posting. Imagine the CFO asking "how much have we committed on imports this quarter?" — with separate doc types the answer is one filtered report; without them it's a manual, error-prone hunt.

🧾 One generic NB type
Imports buried
Local and import POs share one number range and field set. Reporting on imports means manually tagging and filtering — slow, error-prone.
⚙️ ZIMP / ZLOC split
9xxxxxxxxx vs 1xxxxxxxxx
Imports auto-number in the 9-series, locals in the 1-series. Import POs force Incoterms/LC fields and route to CFO approval.
📊 Result
One-click reporting
Import commitment, on-time, and compliance reports filter by document type instantly — and missing import fields are caught at PO creation.

Where a posting is touched: the doc type itself posts nothing, but it gates the documents that do. By forcing import-only mandatory fields (Incoterms, LC number, country of origin) and a CFO release strategy, ZIMP ensures the eventual GR/IR and invoice postings carry correct, complete data — preventing mis-posted landed cost and downstream corrections.

💡 Lesson: a document type is governance configured up front. Separating streams gives you distinct numbering, enforced fields, and tailored approvals — turning "where are our imports?" from a spreadsheet exercise into a single filter, while preventing incomplete POs from ever being saved.

🇵🇰 The Business Story

PakSteel wants separate document types for Local POs (ZLOC) and Import POs (ZIMP). Reasons:

🎯 What you'll learn

🔧 Step-by-Step

⚙️ Config Steps

20.1 — Define Document Type · OMEC (or SPRO path)
  1. SPRO → MM → Purchasing → Purchase Order → Define Document Types
  2. Copy NB → ZIMP (Import PO) · Description: PakSteel Import PO
  3. Number Range Internal: ZI (define in next step)
  4. Update group: leave standard
  5. Field selection key: ZIMP (create separately if custom fields needed)
  6. Allowed item categories: blank only (no subcon for imports)
  7. Save

Repeat: copy NB → ZLOC.

20.2 — Number Range · SNRO Object EBELN
  1. SNRO · Object EBELN · Number Ranges
  2. Add interval ZI: From 9000000000 to 9999999999 (imports)
  3. Add interval ZL: From 1000000000 to 1999999999 (locals)
  4. Link in OMEC: ZIMP → ZI, ZLOC → ZL
20.3 — Field Selection · OMEB (for custom mandatory fields)

Define field selection key ZIMP with INCOTERMS, Country of Origin, LC Number, etc. as Required input.

🔄 Test

20.4 — Create PO with ZIMP · ME21N
  1. ME21N · Doc Type = ZIMP
  2. Notice: Number from ZI range (e.g., 9000000001)
  3. If field selection set, Incoterms/Port required to save

✅ Verification

#T-codeCheck
1OMECZIMP and ZLOC exist, each linked to its number range (ZI / ZL) and field selection key
2SNROObject EBELN shows interval ZI (9-series) and ZL (1-series)
3ME21NDoc type ZIMP draws a 9xxxxxxxxx number; Incoterms/Port are required to save
4ME2NPOs can be filtered by document type — imports separated from locals for reporting

🎓 Interview-Ready Answers

Q: What does a purchasing document type control?

It controls the number range (internal/external), the allowed item categories (blank, K consignment, L subcontracting, S third-party…), the field selection key (which fields are required/optional/hidden), the linked release strategy, the output/print determination, and which document types are allowed for which transaction (PR, RFQ, PO, contract).

Q: Why use separate document types for imports vs local instead of one NB type?

Separate types give each stream its own number range (instant reporting separation), mandatory fields (imports force Incoterms, LC number, country of origin), release strategy (imports always route to CFO), and output forms (imports need customs paperwork). One generic type can't enforce different rules per stream.

Q: How is the field selection per document type achieved?

Each document type points to a field selection key. In OMEB you maintain that key, setting individual fields (e.g. Incoterms, country of origin, LC number) as Required / Optional / Display / Hidden. SAP merges the document-type field selection with other influencing keys (transaction, item category, account assignment) to decide the final field status on the screen.

← Previous
Scenario 19: Custom Material Type
Next →
Scenario 21: Pricing Procedure