Scenario 22 — Output Determination (Print/Email PO Form)
📊 Business Case
Output determination is SAP's framework for automatically routing a document — here a purchase order — to the vendor via the right medium (print, email, fax, or EDI) the moment it's created or changed. Instead of a buyer manually printing and emailing every PO, condition records tell the system "for this purch org + vendor + doc type, send by email immediately." Here PakSteel automates dispatching the PO so vendors get it instantly with a full audit trail.
🕐 When to use it
Whenever documents must reliably reach a partner — POs to vendors, order confirmations, reminders. Any time manual printing/emailing is slow, inconsistent, or risks a missed order.
❓ Why it matters
It makes dispatch automatic, consistent and auditable. The system records what was sent, when and how, so nothing is forgotten and every transmission is traceable for compliance.
👤 Who triggers it
An MM consultant configures output types and condition records (NACE, MN04); the PO then proposes the output automatically, and ME9F (often a background job) dispatches it.
🔁 The key distinction
This is config, not a posting — no money moves. Its value is speed and audit: faster vendor turnaround, no missed orders, and a complete record of every PO sent.
💰 Financial Impact — The Easy-Money Example
Output determination is configuration, so the payoff is processing time saved and orders never missed, not a posting. Picture a buyer creating 40 POs a day: manually printing, attaching and emailing each costs minutes and invites mistakes; automated output sends them all in seconds.
No direct posting here — output determination doesn't touch FI. But by guaranteeing the PO actually reaches the vendor (and logging it), it removes the delays and disputes that do cost money: late deliveries, duplicate orders, and "we never received the PO" arguments at invoice time.
🇵🇰 The Business Story
When a PO is created/changed, PakSteel needs to:
- Print a hardcopy for vendor (signed + stamped, Pakistani business norm)
- Email PDF to vendor's procurement contact
- Send fax (some legacy vendors still use this)
- For internal: post to a shared printer at procurement desk
Output Determination = SAP's framework for routing PO docs to printers/email/fax/EDI.
🎯 What you'll learn
- Output Types (NACE): NEU (New PO print), MAHN (reminder), etc. Each = an output trigger
- Access Sequence: where SAP looks for output condition records
- Condition Records (MN04): per Purch Org + Vendor + Doc Type → "use medium 1 (printer)" or "5 (email)"
- Procedure: ordered list of output types applicable to doc
- Smart Form / Adobe Form: the actual PDF layout (developed in SE71 / SFP)
- A vendor with a valid email address on its master record (see BP Create Guide).
- At least one purchase order to send — the PO this scenario will dispatch (create one in ME21N, see PO Master Reference).
- Customizing access on a sandbox (NACE / MN04) — nothing is posted to FI here.
🔧 Step-by-Step
| Step | T-code | What it does | Why this step exists |
|---|---|---|---|
| 22.1 | NACE | Define the output trigger (NEU) — program, layout, allowed channels | SAP can only send what it knows exists |
| 22.2 | MN04 | Store the rule: this vendor's NB POs auto-email on save | a trigger needs a rule saying who, how, when |
| 22.3 | ME9F | Send the waiting message — PDF leaves, status turns green | an unsent PO is an order the vendor never saw |
⚙️ Config Steps
22.1 — Output Type Setup · NACE Application EF (Purchasing)
⚡ This step will: create the trigger itself — after this, SAP knows an output called NEU (or your Z copy) exists for POs: which program builds it, which layout it draws, and which channels it may use. Nothing is sent to anyone yet. 📄 paper: — (customizing entry only) · 📦 stock: no change · 💰 money: no posting
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| NACE · Application | EF | Outputs for WHICH document family? NACE is the single front door for all output config; each application letter is one family. | EF is the purchasing family — where PO output lives. Impact: pick another application (e.g. V1 sales) and you would be editing the wrong module's outputs entirely |
| Output type | NEU | On WHAT event should a message go out? An output type is one trigger — like one alarm on your phone. NEU fires for a new or changed PO. | NEU is the standard "new PO" trigger, so reviewing it shows the media it already offers (Medium 1 = Print, 5 = Email/EDI). Impact: configure the wrong output type and the PO never gets an output proposed |
| Copy to Z (optional) | Z_NEU | Do you need custom sending logic? If so, make a Z copy and change the copy, not the SAP original. | SAP's own output types can be reset by an upgrade and are shared system-wide, so a Z copy protects your changes and isolates them. Impact: edit NEU directly and an upgrade may wipe your logic, or your change may disturb every other document using NEU |
🛠️ From scratch — creating an output type with New Entries (no NEU copy)
Starting from NEU is quicker (its processing-program wiring is already in place). Building your own Z_NEU from scratch, here is every field you must set and why:
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| General data | |||
| Access sequence | 0001 (DocType/PurchOrg/Vendor) | The search path SAP follows to find a matching output record — the order of "address books" it checks. | This path lets a rule be aimed by document type, purchasing org and vendor together. Impact: no access sequence and the output type can never find a condition record, so it works only if added by hand |
| Access to conditions (tick) | ✓ | May stored records (MN04) decide when this output fires, automatically? | Ticked, the system searches your condition records and proposes the output by itself. Impact: unticked and someone must add the output manually on every single PO — the automation is dead |
| Default values | |||
| Dispatch time | 3 (immediate) or 1 (job) | WHEN does the message go out? 3 = the instant the PO is saved; 1 = waits for the periodic dispatch job (22.3). | 3 gets the PO to the vendor at once. Impact: choose 1 when you expected instant sending and vendors wait until the next job run — orders look "sent" but sit in the out-tray |
| Transmission medium | 1 print / 5 email | Through WHICH channel does it leave — paper, email or EDI? | Medium 5 emails the PDF; medium 1 prints it. Impact: set print when the vendor expects email and the PO physically prints at your office instead of reaching them |
| Partner functions | |||
| Partner function (with its medium) | VN | WHO receives this output? VN = the vendor partner role. | The vendor must be a permitted recipient for the chosen medium. Impact: a missing VN row is the classic "no output found" error — everything else is right but SAP has no one to send to |
| Processing routines | |||
| Program | SAPFM06P | Which ABAP program actually builds and issues the document? | SAPFM06P is SAP's standard print program for purchasing documents, so it already knows how to read a PO. Impact: a wrong or blank program and processing the output dumps with a runtime error — nothing is produced |
| FORM routine | ENTRY_NEU | Which entry point inside that program handles this specific output? | ENTRY_NEU is the routine matched to the new-PO output. Impact: name the wrong routine and the program is called but cannot process this output type |
| Form (layout) | MEDRUCK | Which printed LAYOUT is drawn — the actual look of the PO on paper/PDF? | MEDRUCK is the standard PO layout; swap in your own Smart Form/Adobe form for a branded document. Impact: no form assigned and the message has no layout to render, so it fails to output |
| Add to the procedure | |||
| Output determination procedure | add Z_NEU (NACE → Procedures) | Is this output type listed in the PO's "recipe" of possible outputs at all? | Only output types inside the procedure are ever considered for a PO. Impact: leave Z_NEU out of the procedure and it never triggers, no matter how perfectly it is configured |
22.2 — Maintain Condition Records · MN04
⚡ This step will: write the rule that arms the trigger — from now on, every NB purchase order from PKLO to vendor MUGHAL21 automatically proposes an email (medium 5) the moment it is saved. Still nothing is sent until such a PO exists. 📄 paper: condition record (a stored rule, not a business document) · 📦 stock: no change · 💰 money: no posting
Same notebook-page idea as pricing records (Scenario 21): the condition record stores for whom the output fires and how. SAP then finds it by itself on every matching PO.
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| MN04 · Output Type | NEU | Which trigger are you writing a rule for? Here, the "new PO" message. | The record must sit under the output type that fires on a new PO. Impact: write it under a different output type and the new PO never matches it |
| Key combination | Doc Type + Purch Org + Vendor | How PRECISELY do you aim the rule? The key is the address SAP searches with — like finding a contact by name in your phone. | This trio aims the rule at one type of PO, from one buying org, to one vendor. Impact: too broad a combination and the output fires for vendors you never meant to email |
| The condition record (the values you type) | |||
| PO Document type | NB | Which PO type does this rule apply to? | Aims the rule at standard POs. Impact: put ZIMP here and standard NB orders to this vendor would not auto-send |
| Purchasing organisation | PKLO | Which buying organisation's POs are covered? | Restricts sending to POs raised by PakSteel's purchasing org. Impact: a wrong org and matching POs are missed while others send unexpectedly |
| Vendor | MUGHAL21 | Which supplier should receive the output? | Names the exact vendor this record emails. Impact: a wrong vendor code sends this vendor's POs nowhere and may email the wrong supplier |
| Medium | 5 (Email) | Through which channel does it go — 1 = print, 5 = email/external send? | Medium 5 emails the PO PDF straight to the vendor. Impact: set 1 (print) and the PO prints in your office instead of reaching the vendor's inbox |
| Communication (email) | vendor's email address | Where exactly is it sent — the actual email address used for medium 5? | Without the address SAP has a channel but no destination. Impact: a missing or wrong email and the send fails or reaches the wrong mailbox |
| Dispatch time | 3 (immediate) | WHEN is it sent — 3 = the instant the PO is saved, 1 = with the later batch job? | Time 3 gets the order out the moment it is saved, with no buyer action. Impact: time 1 makes the vendor wait for the next ME9F job run (22.3) |
| Save | — | Stores the rule so it applies to all future matching POs. | Until saved the rule does nothing. Impact: unsaved, matching POs still require manual output |
22.3 — Process Output · ME9F
⚡ This step will: actually send the PO — the waiting (yellow) message is processed, the PO PDF leaves for the vendor's inbox, the status turns green, and SAP logs what was sent, when and how. 📄 paper: — (message turns green + transmission log, no new document) · 📦 stock: no change · 💰 money: no posting
Do: ME9F → fill the selection screen below → Execute (F8) → tick the PO's message line → click Output Message → the PO is transmitted. Real systems run this very transaction as a background job (e.g. hourly).
| Field / Action | Fill | What it asks (plain words) | Why — and the impact if wrong |
|---|---|---|---|
| Selection screen · Document Number | your PO number (or leave a range) | WHICH PO(s) are you dispatching? Leave open to process every pending PO, or type one number to send just yours. | Narrowing to your PO keeps the test clean. Impact: too wide a range re-sends output for other buyers' POs too. |
| Selection screen · Purchasing Group / Application | optional filters (purchasing application EF) | Extra sieves — a buyer group, or the purchasing output family EF. | Handy to isolate one team's POs. Impact: a wrong filter excludes your PO from the list, so nothing sends. |
| Selection screen · Processing status | "not yet processed" (new output) | Do you want messages still WAITING to go out, or ones already sent (to repeat)? | "Not yet processed" picks the yellow, time-1 messages sitting in the out-tray. Impact: pick "already processed / repeat" and you re-send things already delivered, double-mailing the vendor. |
| Toolbar · Execute (F8) | the results list of pending messages appears | Show me everything matching. | The list is your out-tray. Impact: an empty list = the condition record (22.2) never proposed the output, or it already went out at time 3. |
| Results list · tick line → Output Message button | tick your PO's row → click Output Message | Actually SEND the ticked messages now. | "Output Message" processes and transmits (medium 5 = emails the PDF). "Display message" only previews; "Trial printout" tests paper without marking it sent. Impact: click Display and you see it but the vendor still gets nothing. |
Saving the PO only wrote the message and parked it. ME9F is the postman who actually delivers it. The instant you click Output Message, the message status flips from yellow (not processed) to green (successfully processed), and the PO PDF is emailed to MUGHAL21's address (medium 5). No FI posting happens — output determination never touches money; what changes is the transmission record: SAP now logs what was sent, when, and how.
The difference to notice: messages set to dispatch time 3 went out on their own the second the PO was saved — for those you never need ME9F. ME9F exists to push the time-1 messages that were deliberately left in the out-tray for a batch run. Verify: ME23N → your PO → Messages → the NEU line shows green (sent); yellow = still waiting, red = error.
✅ Verification
| # | T-code | Check |
|---|---|---|
| 1 | NACE | Application EF shows output type NEU with media 1 (Print) and 5 (Email) defined |
| 2 | MN04 | Condition record NB · PKLO · MUGHAL21 → medium 5, time 3 exists |
| 3 | ME21N | Create a PO for that vendor → Messages shows NEU proposed automatically (medium 5) |
| 4 | ME9F | Run output processing → PO message status turns green (successfully processed/sent) |
🎓 Interview-Ready Answers
Q: What is output determination and which objects make it up?
It's the condition-technique framework that decides how a document is issued. Components: output type (e.g. NEU = new PO), access sequence (where to search for records), condition records (the actual "send this combination by this medium"), the output procedure (ordered list of output types for the document), and the form/program (Smart Form or Adobe form that renders the layout). For purchasing it lives under application EF.
Q: What do the medium and timing settings on a condition record mean?
The medium is the channel: 1 = Print output, 2 = Fax, 5 = External send (email/EDI), 6 = EDI, etc. The dispatch time controls when it goes: 1 = with periodic job (e.g. RSNAST00 / ME9F batch), 3 = send immediately (when the document is saved), 4 = on explicit request. PakSteel uses medium 5, time 3 to email the PO the instant it is saved.
Q: How do you process and re-send PO output, and where do you check status?
ME9F processes purchase-order messages (usually scheduled as a background job). You can check and reprocess an individual PO's output under Messages in ME22N/ME23N — green means sent, yellow means not yet processed, red means error. ME9F lets you reissue or repeat output if needed.