Scenario 20 — Custom PO Document Type (Imports vs Local)
📊 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.
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.
🇵🇰 The Business Story
PakSteel wants separate document types for Local POs (ZLOC) and Import POs (ZIMP). Reasons:
- Different number ranges (Z-local 1xxxx, Z-import 9xxxx) for reporting
- Import POs need additional fields (incoterms, port, BL #) mandatory
- Different release strategies (import POs always need CFO approval)
- Custom output forms (import has customs paperwork)
🎯 What you'll learn
- Number range — separate pool per doc type
- Allowed item categories (blank, K, L, S, etc.)
- Field selection — mandatory/optional fields per doc type
- Print/Output settings — different SmartForms per doc type
- Release Strategy linkage — different approval per type
- Authorization — who can create which doc type
- A working org structure — company code, plant and purchasing organization already built (see Setup Hub).
- Customizing access on a sandbox (SPRO / OMEC) — nothing is posted, so no vendor or master data is needed first.
- The will to customize: this scenario builds the document types
ZIMPandZLOCthemselves, from scratch.
🔧 Step-by-Step
| Step | T-code | What it does | Why this step exists |
|---|---|---|---|
| 20.1 | OMEC | Create two new PO rule books: ZIMP (imports) and ZLOC (local) | imports and local buys need different rules |
| 20.2 | SNRO | Build separate number rolls: 9-series imports, 1-series local | a PO number should reveal its stream at a glance |
| 20.3 | OMEB | Make import fields (Incoterms, port, LC) required | compliance fields must enforce themselves, not rely on memory |
| 20.4 | ME21N | Create a test import PO using ZIMP | config only counts once a real PO proves it works |
⚙️ Config Steps
20.1 — Define Document Type · OMEC (or SPRO path)
⚡ This step will: create two new PO rule books — ZIMP for imports and ZLOC for local buys — that buyers can pick in ME21N; pure configuration, nothing is bought yet. 📄 paper: — (config entry, not a document) · 📦 stock: no change · 💰 money: no posting
Do: SPRO → MM → Purchasing → Purchase Order → Define Document Types → select NB → Copy → ZIMP → adjust the fields below → Save.
Why start from NB? NB is the standard PO type, so its ~15 control settings are the ones an ordinary PO needs — a sensible baseline that saves re-deciding each one. You only change what makes imports special (number range, field selection, allowed item categories).
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Type · Description | ZIMP · PakSteel Import PO | What is this new "flavour" of PO called? A document type is one style of PO with its own rules; the description is the human label. | A Z name is your own object, safe from SAP upgrades, and a clear description stops buyers picking the wrong style. Impact: reuse an SAP name and an upgrade may overwrite it; a vague description gets imports raised as ordinary POs |
| Number range (internal) | ZI | From which ticket roll do these POs draw their numbers, with SAP assigning each one automatically? | A dedicated import roll (built in 20.2) makes every import PO number instantly recognisable and keeps import and local numbering from clashing. Impact: point at a shared or missing roll and imports lose their at-a-glance identity, or numbering fails |
| Update group | standard | How should this PO type feed reporting statistics (the Logistics Information System)? | The standard group already updates the usual purchasing statistics correctly. Impact: a wrong group can skew or omit this type from LIS reports — a quiet reporting gap, not an error |
| Field selection key | ZIMP | Which screen-rule template do these PO screens follow — deciding which boxes are must-fill, optional, or hidden? | A dedicated key (maintained in 20.3) is the lever that forces Incoterms, port and LC number on every import PO. Impact: leave the generic key and import papers stay optional, so buyers can save imports missing compliance fields |
| Allowed item categories | blank only | Which KINDS of line may this PO carry? The item category is the line's kind — blank = normal purchase, K consignment, L subcontracting, S third-party. | An import buys finished goods outright, so only the blank (standard) kind makes sense. Impact: allow L and a buyer could accidentally raise a subcontracting import line, which needs components and a wholly different process |
| Save · then build ZLOC | create ZLOC the same way | Repeat the whole definition for the local-purchase type. | Local POs need their own number stream and rules too, so a second type (its own roll ZL) keeps local and import purchasing cleanly separated. Impact: skip it and local POs fall back to generic NB, losing the reporting split |
🛠️ From scratch — creating a document type with New Entries (no NB copy)
Starting from NB is quicker (its ~15 control settings give you a ready baseline). If you must build it from scratch, here is every field and the reason each value is right:
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Type / Description | ZIMP · PakSteel Import PO | The code and human label for this new PO style. | A Z name is your own object, so an SAP upgrade never overwrites it; the label tells buyers what it is for. Impact: an SAP-namespace name risks being changed by a support pack under you |
| Item interval | 10 | How far apart are the PO line numbers? Steps of 10 give 10, 20, 30… | Gaps let you insert a line later (e.g. 15) without renumbering the rest. Impact: an interval of 1 leaves no room, so inserting a line forces a messy renumber |
| Number range (internal) | ZI | Which number block do these POs draw from when SAP assigns the number automatically? (Defined in SNRO, object EBELN.) | An internal roll means buyers never invent numbers and imports get their own clearly-separated series. Impact: no valid internal roll and the PO cannot be saved — SAP has no number to give it |
| Number range (external) | blank | A second block for numbers the USER types by hand, if manual numbering is allowed. | Imports are auto-numbered, so no manual block is needed — left blank. Impact: fill it and buyers could hand-key PO numbers, risking duplicates and breaking the clean import series |
| Field selection key | ZIMP | Which screen-rule template drives which PO fields are mandatory, optional or hidden? | A dedicated key is exactly how you force Incoterms and country of origin on imports. Impact: reference a generic key and those import fields stay optional, so incomplete import POs can be saved |
| Update group | standard (0000) | How this type feeds the Logistics Information System (reporting statistics). | The standard group already captures the normal purchasing statistics. Impact: a wrong group quietly distorts or omits this type from LIS reports |
| Dialog: Allowed item categories | blank (standard) only | Which line kinds may appear on the PO? Set in the left-side sub-dialog (blank / K / L / S / D). | An import buys goods outright, so only the blank kind is allowed. Impact: allow L/K/S and a buyer can raise the wrong kind of line (e.g. subcontracting) on an import by mistake |
| Dialog: Link purchase requisition | allow NB PRs → ZIMP | Which purchase-requisition types are permitted to turn INTO this PO type? | Buyers usually start from an existing NB requisition, so that link must be open. Impact: without it, an NB requisition cannot be adopted into a ZIMP PO and buyers must re-key everything |
20.2 — Number Range · SNRO Object EBELN
⚡ This step will: build the two "ticket rolls" the new types tear their numbers from — 9-series for import POs, 1-series for local POs — so every future PO number instantly says which stream it belongs to. 📄 paper: — (config entry, not a document) · 📦 stock: no change · 💰 money: no posting
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| SNRO · Object | EBELN | Numbers for WHAT? EBELN is the numbering object for purchasing documents — every PO number is torn off one of its rolls. | PO numbers must come from EBELN. Impact: edit a different object and you change some other document's numbering, not POs |
| Interval ZI — import POs (9-series) | |||
| Interval key | ZI | The short code naming the import roll, so the ZIMP document type can point at it. | ZIMP references ZI in 20.1. Impact: a mismatched key and import POs draw from the wrong roll, or none |
| From number | 9000000000 | The first import PO number. | Starting at 9 makes every import PO number visibly SAY "import" in any list — reporting separation for free, no extra field. Impact: a range overlapping the local one destroys that at-a-glance split and can clash |
| To number | 9999999999 | The last import PO number the roll can issue. | A billion numbers is ample. Impact: too small and the roll runs dry, blocking new import POs until extended |
| Interval ZL — local POs (1-series) | |||
| Interval key | ZL | The short code naming the local roll, for the ZLOC document type. | ZLOC references ZL. Impact: a mismatched key and local POs draw from the wrong roll |
| From number | 1000000000 | The first local PO number. | The 1-series keeps local numbers in a completely different band from imports, so the two can never collide. Impact: overlap the 9-series and the clean separation is lost |
| To number | 1999999999 | The last local PO number the roll can issue. | Ample headroom for local buying. Impact: too small and local PO creation stops once exhausted |
| Link in OMEC | ZIMP → ZI · ZLOC → ZL | Which document type tears from which roll? Back in OMEC each type is pointed at its own interval. | The rolls exist, but a type with no roll assigned cannot number its POs. Impact: forget the link and saving a PO of that type fails with a number-range error |
20.3 — Field Selection · OMEB (for custom mandatory fields)
⚡ This step will: make the import fields (Incoterms, port, LC number) impossible to skip — after this, an import PO missing them can no longer be saved. 📄 paper: — (config entry, not a document) · 📦 stock: no change · 💰 money: no posting
Do: OMEB → field selection key ZIMP → set INCOTERMS, Country of Origin, LC Number, etc. to Required input.
What this step IS: the form template itself. Each field has four possible states — Required (starred box: cannot save without it), Optional, Display (visible but locked), Hidden. Setting the import papers' fields to Required means a buyer cannot save an import PO with a missing Incoterm — the rule enforces itself; no reminder emails needed. The template applies because the ZIMP document type points at this key (20.1).
🔄 Test
20.4 — Create PO with ZIMP · ME21N
⚡ This step will: create the first real import PO — a binding promise to the vendor carrying a 9-series number and the forced import fields, proving the whole ZIMP config works. 📄 paper: purchase order · 📦 stock: no change (quantity shows as On-Order — a promise, not stock) · 💰 money: no posting
Recap the ME21N screen (Scenario 6): ① the Header (top — Document type and Supplier, with header tabs like Org Data and Delivery/Invoice below), ② the Item overview grid, ③ the Item detail tabs. This test only touches the Header — the very first field (document type) and the import fields the ZIMP template forces.
| Step · Where on screen | Do / see | What it asks (plain words) | Why — and the impact if wrong |
|---|---|---|---|
| 1 · Header (top) · Doc Type | Doc Type = ZIMP | Which rule book governs this PO? (the very first choice on the screen) | ZIMP is the import rule book — number roll, form template and allowed lines all follow from it. Impact: pick NB (standard) here and the PO gets local numbering and none of the import controls. |
| 2 · Header · PO number | it comes from the ZI range (e.g. 9000000001) | Did the number roll actually link to ZIMP? | A 9-series number = import, visible in every future report. Impact: if it comes from the standard range instead, the SNRO/OMEC number assignment (20.2) was missed. |
| 3 · Header → Delivery/Invoice tab · Incoterms / Port | Incoterms / Port are required | Does the field template actually enforce the import fields? | SAP refuses to save until the import boxes are filled — the compliance rule enforces itself. Impact: if it saves without them, the OMEB field selection (20.3) is not set to "required". |
What changes at this exact moment: pressing Save writes a purchasing document (the PO) into the database — a formal commitment to buy, not yet an FI journal entry. The instant it saves:
- The PO is born with a number torn from the
ZIroll — a9…number that visibly says "import" in every future report. - It is stamped document type
ZIMP, so it permanently carries the import rulebook — the ZIMP field template made Incoterms/Port required, so a PO missing them could never have reached Save. - No money has moved: a PO is an obligation. The real postings come later — GR/IR at goods receipt, the payable at MIRO.
The difference from a posting step: saving a PO commits an order, it does not touch the general ledger. Its payoff is control — correct numbering and enforced import fields — locked in before any value flows. Verify: ME23N → your PO → the header shows type ZIMP and a 9-series number.
✅ Verification
| # | T-code | Check |
|---|---|---|
| 1 | OMEC | ZIMP and ZLOC exist, each linked to its number range (ZI / ZL) and field selection key |
| 2 | SNRO | Object EBELN shows interval ZI (9-series) and ZL (1-series) |
| 3 | ME21N | Doc type ZIMP draws a 9xxxxxxxxx number; Incoterms/Port are required to save |
| 4 | ME2N | POs 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.