Scenario 9 — Subcontracting (Send Components, Receive Finished Goods)
We executed this whole scenario live on the real system, start to finish. A few one-time settings had to be in place first (tolerance key SE, the finished-good price, and three G/L accounts on the receipt side). See the Prerequisites box for the exact codes and how to set them, and the Errors box for the messages you'll see if one is missing.
- ✅ Master data: finished material
FERT-REBAR-GALV-01(copy ofFERT-REBAR-01, valuated), BOM (CS01), subcontracting info record 5300079962 (ME11, ₨500/TO). - ✅ Config fixed: tolerance key
SEforPSPK(via OLME → Set Tolerance Limits for Price Variance — not OMR6; see gap ①), and the finished-good standard price aligned to 3,500,500 PKR/TO via MR21 (doc 3000468320) so the goods receipt balances. - ✅ Subcontract PO 4500032783 created (ME21, vendor MUGHAL21, item cat
L, 50 TO @ ₨500, componentFERT-REBAR-0150 TO) · components sent (mvt 541, 50 TO to MUGHAL21's special stock) via ME2O. - ✅ Goods receipt — material doc 5000047742 (MIGO: mvt 101 received 50 TO
FERT-REBAR-GALV-01into SLoc FNGD + auto mvt 543 consumed 50 TOFERT-REBAR-01from the vendor's special stock). Needed three G/L accounts created in PSPK first (415000, 417000, 192300) plus OKB9 default cost centers — see gap ③. - ✅ Service invoice — logistics invoice 5100021699 (MIRO, ₨25,000 = 50 TO × ₨500, tax I0), FI document 3600000007 posted to vendor MUGHAL21.
- ✅ Payment — outgoing payment 4900000004 (F-53): bank G/L 113100 paid ₨24,500 and took the ₨500 (2%) early-payment cash discount, fully clearing the ₨25,000 invoice. Vendor balance is now zero.
📊 Business Case — When & Why You Use This
Subcontracting is the procurement flow where you send your own components to an external vendor, the vendor performs a process (machining, galvanizing, assembly), and you receive back a finished product — paying only for the service, not the materials. The components stay your property the whole time (special stock "O", stock provided to vendor). It is driven by a BOM and a special PO item category L.
🕐 When to use it
You lack an in-house capability — e.g. PakSteel has no galvanizing line, so it sends steel billets to Mughal Steel Industries Ltd to galvanize and return finished galvanized rebars. Outsource a process step while keeping ownership of the raw material.
❓ Why it matters
It lets you outsource production steps without selling the inputs. SAP tracks your material at the vendor's site, knows which components feed the output via the BOM, and charges only the vendor's service fee to the finished-good cost.
👤 Who triggers it
The buyer raises the subcontract PO (item category L); the storekeeper issues components to the vendor (541); on return the goods receipt (101) and component consumption (543) post together; AP pays the service invoice.
🔁 The key distinction
You buy a service, not goods. The vendor's bill is the service fee only (PKR 500/TO), not the billet value. Your components never leave your balance sheet until they're consumed (543) into the finished product you receive.
- ✅ You need: Just CS01 (Create BOM) — covered in this scenario step 9.1. No work centers or routings needed.
- 📖 Reference: Setup Guide Step 17B covers BOM creation in detail if you want to read more
- ⏩ Why subcon doesn't need full PP: The "production" is done by the SUBCONTRACTOR (external vendor), not your plant. So no PP order, no work center, just BOM mapping for components.
💰 Financial Impact — The Easy-Money Example
PakSteel sends 50 TO of steel billets (say ₨2,000,000 of components) to the subcontractor, who galvanizes them and returns 50 TO of galvanized rebars, charging a service fee of PKR 500/TO = ₨25,000. Here is the money story — notice the finished good is worth components plus service:
The big idea: subcontracting splits the finished-good cost into two pieces — the component consumption (your billets, moved via 541 then consumed via 543) plus the service fee you pay the vendor (the PO net price, invoiced via MIRO). The finished-good receipt (101) capitalises both into the new material's inventory value: galvanized rebar inventory = billet value + ₨25,000 service. Sending the components (541) itself has no P&L impact — they remain your asset until the 543 consumption at receipt.
🇵🇰 The Business Story
🎯 What you'll learn — what makes subcontracting unique
- Item Category L (Subcontracting) on PO
- BOM-driven — system knows what components to send based on the BOM (CS01)
- Special Stock O — "stock provided to vendor" (your stock, at vendor's location)
- Three movements: 541 send components, 543 consume at receipt, 101 receive finished product
- Vendor PO line shows BOTH the finished product AND its components
- Subcontractor's bill = service charge only (not material value)
Every step below uses the real codes you built on the PakSteel IDES — follow them exactly. Full details and how each was created are in the Live prerequisites box.
- Component you send =
FERT-REBAR-01("TMT Rebar 12mm") — already in stock atPK01/FNGD. - Finished product you receive =
FERT-REBAR-GALV-01— created with MM01 Copy fromFERT-REBAR-01. - Subcontractor =
MUGHAL21("Mughal Steel Industries Ltd") · purch orgPKLO· plantPK01· SLocFNGD. - Order qty 50 TO · service fee ₨500/TO → ₨25,000 total.
- Org structure + MM-FI integration are built — Setup Guide.
- The posting-period and number-range gates are open (this scenario posts goods movements) — Stock-Readiness Checklist.
- The component and finished-product materials exist (
FERT-REBAR-01,FERT-REBAR-GALV-01) — Material Guide. - A BOM lists the finished product's components — created in step 9.1 (CS01); more detail in Setup Step 17B.
- The subcontractor vendor (Business Partner) exists — BP Guide.
🧰 Prerequisites — settings & master data this scenario needs (verified live)
These are the real codes the steps below use — what already existed on the IDES and what we created — plus the one-time settings a fresh company code needs first. Substitute nothing: the walkthrough already uses these exact codes.
| Role in the scenario | Real code used | How we got it |
|---|---|---|
| Component you send (the "billet") | FERT-REBAR-01 — "TMT Rebar 12mm" | Already existed with 100 TO unrestricted stock at PK01 / SLoc FNGD (left over from Scenario 8). We reuse it as the input — realistic case: send plain rebar, get galvanized rebar back. |
| Finished product you receive | FERT-REBAR-GALV-01 | We created it in MM01 with Copy from FERT-REBAR-01 (industry M, type FERT, plant PK01, SLoc FNGD). ⚠️ Its description still reads "TMT Rebar 12mm" — rename to "Galvanized TMT Rebar 12mm" in MM02 → Basic Data 1 for clarity. |
| Subcontractor vendor | MUGHAL21 — "Mughal Steel Industries Ltd" (Karachi) | Already existed, extended to purch org PKLO and company code PSPK (recon acct 160000, PKR). Ideal galvanizing subcontractor. |
| Purchasing org / Plant / SLoc | PKLO / PK01 / FNGD | PK01 is served by two purch orgs — GLBL (used for the Scenario 8 STO) and PKLO (local). Use PKLO for this local subcontract PO. |
| BOM | FERT-REBAR-GALV-01 → 1 TO FERT-REBAR-01 | Created in CS01 (usage 1, item category L). One component, 1:1. No separate zinc line (kept simple). |
| Service fee / order qty | 500 PKR/TO · order 50 TO | 50 TO galvanized needs 50 TO plain rebar sent (we have 100 TO, leaving margin). Service invoice = 50 × 500 = ₨25,000. |
SE must exist for company code PSPK (or the PO won't save) — SET LIVE🎯 In plain words: a "tolerance key" is a rule that says how much price / cash-discount variance SAP will tolerate on a purchase. SAP refuses to create any purchase order for a company code until this rule exists — so a brand-new company code like PSPK trips on its very first PO. Purpose: guard against wild price entries. What breaks without it: you cannot save the PO at all. One-time config; you never touch it again.
The moment you enter the header of the subcontract PO (ME21 or ME21N) SAP checks the purchasing tolerances and stops with a hard error:
Maintain tolerance limits for tolerance key SE (CoCode PSPK) — message M8 215.
What SE is: tolerance key SE = "Max. cash discount deduction (purchasing)"; its partner PE = "Price variance: purchasing". These are purchasing tolerance keys — NOT the invoice-verification keys you see in OMR6. That's the trap: OMR6's key list (AN, AP, BD, PP, PS, VP…) does not contain SE/PE, so you can never add SE there.
The correct place (this is the exact 1-minute fix we used live):
- Open the Purchasing IMG: run OLME (or SPRO).
- Navigate: Purchasing → Purchase Order → Set Tolerance Limits for Price Variance and execute it (this opens maintenance view
VV_169G_PS— the purchasing variant, where the key list is justPEandSE). - Click New Entries. In the Tolerance Key field pick
SE(use the F4 list — only PE/SE appear here); Company Code =PSPK→ press Enter (the currency fills to PKR automatically). - Set a generous limit so it never blocks a demo — e.g. Upper limit → Percentage → Check limit → 99.9.
- Save (into a customizing transport). Re-run the PO — the error is gone.
Note on PE: on our system PE already existed for PSPK, so only SE was missing. If your PO later stops on PE, add it here the same way. (Earlier we wasted time trying OMR6 — that is the wrong transaction for SE; it only holds invoice-verification keys.)
🎯 In plain words: when the finished good comes back (step 9.5), SAP values it at its own standard price, but it consumes the component at the component's (much higher) value. If those two don't line up, the gap dumps into a "price-difference" account and the receipt looks wrong. Purpose: keep the new material valued correctly. What breaks without it: a big, confusing price-difference posting — or an account-determination error — at the goods receipt.
FERT-REBAR-01 (the component) carries a standard price of 3,500,000 PKR/TO. The new FERT-REBAR-GALV-01 was created with a default standard price of only 350,000 PKR/TO (price control S, valuation class 7920). At the goods receipt (step 9.5) SAP would value the finished good at its standard (350k) but consume the component at 3.5M — the huge gap would post to a price-difference account (PRD).
Fix we applied before the GR: set the finished good's standard price = component + service = 3,500,500 PKR/TO via MR21 (Price Change: company code PSPK, plant PK01, new price in the "New price" column → Save). Live price-change document 3000468320 posted. Now the 101/543 postings balance and the price difference is ~0.
If the GR errors instead of posting with an account-determination message, the PRD transaction key is not set for chart INT / valuation class 7920 in OBYC — either configure PRD or use the MR21 price alignment above so no difference arises.
PSPK — SET LIVE🎯 In plain words: a goods receipt must write an accounting document, and that needs the right G/L "buckets" (an expense account + a clearing account) to already exist in this company code, each wired to a cost center. A fresh company code is missing them, so the receipt can't post until you create and classify them. Purpose: give the receipt somewhere to book the money. What breaks without it: the GR fails with account-determination errors, one account at a time.
When the goods receipt (9.5) tried to post, SAP needed three G/L accounts that did not yet exist in company code PSPK: 415000 and 417000 (subcontracting / external-processing expense) and 192300 (a GR/IR-type clearing account). Each threw an account-determination error in turn.
Fixes we applied (all in FS00 unless noted):
- Created 415000, 417000, 192300 in PSPK using FS00 → "Create with reference" from company code
0001(copies the ready-made account settings so you don't fill every tab by hand). - 192300 "not consistent": an account that is type M (materials-management) may not have Open Item Management ticked when it is used in automatic MM postings. Fix: FS00 → company-code data → uncheck Open Item Management.
- 417000/415000 need a CO object: these are P&L (cost) accounts, so every posting needs a cost center. Fix: OKB9 → set a default cost center (
PKKHI-PROD) for both accounts in controlling area, so the GR finds one automatically.
One more live gotcha: a custom MIGO enhancement (BAdI ZCL_EXM_IM_MB_MIGO_BADI) dumped when the Delivery Note field held more than 10 characters. Keep the delivery-note text short (we used SCGR01).
🔧 Step-by-Step
| Step | T-code | What it does | Why this step exists |
|---|---|---|---|
| 9.1 | CS01 | Create the BOM — the recipe for the finished rebar | SAP must know which parts to send the vendor |
| 9.2 | ME11 | Store the vendor's price for the galvanizing work | every future PO finds the fee by itself |
| 9.3 | ME21N | Create the subcontract PO (item cat L) — components list appears | a promise needs a document |
| 9.4 | MB1B / ME2O | Send billets to the vendor (mvt 541) — still your stock | the vendor needs your parts to do the work |
| 9.5 | MIGO | Receive finished rebar (101); SAP consumes your billets (543) | goods coming back is the whole point |
| 9.6 | MIRO | Record the vendor's bill — the work fee only | you pay for the service, not the steel |
| 9.7 | F-53 | Pay the vendor; the debt goes to zero | a purchase isn't finished until the vendor is paid |
📦 Master Data Setup
9.1 — Create BOM · CS01 for the finished product
⚡ This step will: create the recipe card that tells SAP which parts make 1 TO of galvanized rebar — the subcontract PO reads it later to build your send-list. 📄 paper: BOM (master data) · 📦 stock: no change · 💰 money: no posting
Create a single-level BOM showing what components produce 1 TO of galvanized rebar. A BOM (bill of material) = a recipe card: "1 TO galvanized rebar ← 1 TO plain rebar." SAP reads this recipe in 9.3 to know which parts to send the vendor.
| Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Material | FERT-REBAR-GALV-01 (galvanized rebar — create as FERT first) | Whose recipe is this — which product does the ingredient list belong to? Like a cake recipe filed under "cake", not under "flour" | The recipe hangs on the OUTPUT (the finished product), not on the ingredients. Impact: file it under the wrong material and the subcontract PO in 9.3 finds no component list, so SAP never tells you which billets to send the vendor |
| Plant | PK01 | Where is this recipe valid? | BOMs are kept per plant, because another factory could make the same product a different way. Impact: build it under the wrong plant and PK01's subcontract PO sees no recipe at all |
| Usage | 1 (Production) | What is the recipe FOR? The same product can carry several recipe versions for different purposes | Usage 1 = the recipe used to actually produce the item (rather than a costing or engineering version). Impact: the subcontracting component list reads the production BOM; a different usage may hold different parts, so the wrong billets could be proposed |
| Component line 1 (the only one) | FERT-REBAR-01 ("TMT Rebar 12mm") — Qty 1 TO per 1 TO of output | The one ingredient, plus how much of it goes into ONE unit of output | SAP multiplies this per-unit quantity by the PO quantity later (order 50 TO → send 50 TO). Impact: set 2 TO here by mistake and every order would demand double the stock shipped out. Live note: our BOM has just this one component, 1:1 — no separate zinc line (kept simple). |
Save BOM.
9.2 — Maintain Subcontracting Info Record · ME11
⚡ This step will: store the vendor's price card for the galvanizing WORK (₨500/TO) so every future subcontract PO finds the fee by itself. 📄 paper: info record (master data) · 📦 stock: no change · 💰 money: no posting
An info record = the stored price card for one vendor + one material pair: "what does THIS vendor charge for THIS item?" Here it stores the galvanizing fee.
| Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Vendor | MUGHAL21 | Whose price is this? The subcontractor who will do the work | An info record stores a price for one vendor. Impact: the wrong vendor means the subcontract PO to MUGHAL21 finds no price and the buyer must type the fee by hand every time |
| Material | FERT-REBAR-GALV-01 | A price for WHAT item? | The material is the FINISHED product — you price the outcome, not the billets you send. Impact: price the billet instead and the PO for the finished rebar finds no processing price |
| Purch Org | PKLO | Valid for which buying desk? | Prices are held per purchasing organization, so different desks can negotiate their own rates. Impact: a mismatch with the PO's purch org means the price is not found at PO time |
| Plant | PK01 | Valid for which site? | The plant that will receive the galvanized rebar. Impact: a plant-specific price only applies to that plant; the wrong one leaves your PK01 PO without a price |
| Info Category | Subcontracting | Which KIND of deal is this price for? One vendor + material pair can hold a separate price card per kind of deal | This card is for the processing work, kept apart from any normal buying price, because a subcontract PO (item category L) only reads the subcontracting card. Impact: save it as "Standard" and the item-category-L PO finds no matching price |
| Net Price | 500 PKR/TO | What does the vendor charge PER unit — for the WORK only? | ₨500 per TO of galvanizing; NOT the material value, because the billets stay yours and are never sold to the vendor. Impact: include the billet value here and you would pay the vendor for steel he never bought — the fee should be only 50 TO × ₨500 = ₨25,000 |
Save.
🔄 Transaction Flow
9.3 — Create Subcontract PO · ME21N with Item Cat L
⚡ This step will: make a binding promise to the vendor — order 50 TO finished rebar, and SAP lists the billets you must send (your packing list for 9.4). 📄 paper: purchase order · 📦 stock: no change · 💰 money: no posting
Do: ME21N · Vendor MUGHAL21 → fill Line 1 → press Enter so the components explode → Save.
The ME21N screen has 3 zones: ① the Header (top: doc type, vendor — with header tabs like Org Data below it), ② the Item overview grid (one ROW per line — the small I item-category column, material, quantity, plant, net price), ③ the Item detail tabs (bottom, for the selected line — for an item-category-L line the component list appears in the item detail's Material Data area).
| Where on screen · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Header · Doc Type | NB | Which pad of order forms? | The normal buying pad works — there is no special document type for subcontracting, because the special behaviour is switched on by the item category, not the doc type. Impact: none from using NB here; hunting for a "subcontracting doc type" only wastes time |
| Header · Vendor | MUGHAL21 | Who does the work? | The subcontractor who will galvanize your billets. Impact: must match the info-record vendor from 9.2, or the ₨500/TO fee is not found and stock at the vendor is tracked against the wrong party |
| Item grid · Item Category (column I) | L (Subcontracting) | What KIND of line is this? Blank = buy goods · D = buy a service (Scenario 4) · L = "I send parts, the vendor works on them, I get a product back" | Letter L switches on the component list, special stock O (your stock at the vendor), and the paired 543 + 101 posting at goods receipt. Impact: leave it blank and SAP thinks you are simply buying finished rebar — no billets are sent, no component consumption, the whole subcontracting cycle collapses |
| Item grid · Material | FERT-REBAR-GALV-01 | What do you want to RECEIVE? | You order the finished product — never the billets; the billets enter the story through the BOM. Impact: order the billet by mistake and there is nothing to galvanize and nothing to receive back |
| Item grid · Qty | 50 TO | How many finished units? | 50 TO of galvanized rebar. Impact: this number drives the BOM explosion — 50 TO output tells SAP to send 50 TO of billets; a wrong figure sends the wrong amount of your stock out |
| Item grid · Plant | PK01 | Which site orders and receives? | The plant that holds the billets and takes the finished rebar back. Impact: must be the plant where the 9.1 BOM and the 9.2 price live, or neither is found |
| Item grid · press Enter | components auto-expand | What happens after you enter the line? SAP reads the 9.1 recipe and lists what you must send | It lists FERT-REBAR-01 × 50 TO — your packing list for step 9.4. Impact: if nothing expands, the BOM or item category L is wrong; sending stock without this list means guessing the quantity |
| Item grid · Net Price (line) | 500 PKR/TO (service fee) | What do you PAY per unit? | Only the work: 50 TO × ₨500 = ₨25,000. The billet value is not on this PO because the billets never leave your books. Impact: add the steel value here and you would over-pay the vendor and double-count the billet cost |
Save.
9.4 — Send components to subcontractor · mvt 541 (MB1B or MIGO)
⚡ This step will: move your billets from your own shelf to the vendor's site — still YOUR stock, now shown as special stock O ("stock provided to vendor"). 📄 paper: material document · 📦 stock: PK01/WIPS → stock at vendor (special stock O) · 💰 money: no posting (same owner, same value)
| Where on screen · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| T-code | MB1B (or ME2O for monitor-based dispatch) | Which screen sends the parts? | MB1B = the transfer-posting screen; ME2O = the subcontracting monitor, an alternative way to send and later your window on stock at the vendor. Impact: either works; ME2O also shows what is still lying at the vendor |
| Initial screen · Mvt Type | 541 | Which exact stock instruction? A movement type is a reason code for a stock move | 541 = "hand stock to the subcontractor — still MINE." Not a sale, not a consumption: the billets only change place, from your shelf to "at the vendor." Impact: use a normal issue (e.g. 201) and the billets would leave your books as an expense — you would lose sight of stock you still own |
| Initial screen · Vendor | MUGHAL21 | At WHOSE site will your stock sit? | Special stock O (stock provided to a vendor) is tracked per vendor, so SAP must know who is holding your billets. Impact: the wrong vendor books your billets as sitting at the wrong subcontractor, and the 543 consumption at GR cannot clear it |
| Item lines · Material | FERT-REBAR-01 | What leaves your shelf? | The steel billet the BOM said to send. Impact: send the wrong component and the vendor cannot galvanize; the finished-goods receipt in 9.5 will not clear your provided stock |
| Item lines · Qty | 50 TO | How much? | Exactly what the BOM expansion in 9.3 asked for (50 TO output → 50 TO billets). Impact: send too little and the vendor runs short mid-job; too much and billets pile up unused at the vendor's site |
| Initial screen · Plant | PK01 | From which site? | The plant that owns the billets. Impact: the wrong plant has no billet stock to send, so the posting fails or short-ships |
| Initial screen · SLoc | WIPS | From which store room inside that site? | The storage location the billets are drawn from. Impact: point at an empty store room and there is no stock to transfer |
Post.
FI effect: NONE (same valuation, just transfer to "stock at vendor"). Stock now visible in MMBE under "Special Stock O" — your billets, shown at the vendor's location.
Monitor: ME2O shows stock provided to vendor.
9.5 — Receive finished product · MIGO mvt 101 + auto 543
⚡ This step will: bring the finished rebar IN and, in the same post, use up your billets sitting at the vendor (you key only the 101 — SAP fires the 543 itself). 📄 paper: material + accounting document · 📦 stock: rebar ↑ at PK01, billets at vendor ↓ to zero · 💰 money: Dr Rebar Inventory / Cr GR/IR (fee) + Dr Consumption / Cr Stock at Vendor
Do: MIGO → set the two top-left dropdowns → load the subcontract PO → tick Item OK → Post:
The MIGO screen has 3 zones — know them and every row makes sense: ① the top bar (the two dropdowns — Action + Reference — and the movement-type box), ② the header tabs (General/Vendor: dates, delivery note), ③ the item area = the overview grid (one row per line) + the item-detail tabs below it (Material · Quantity · Where · Purchase Order Data · Account Assignment), with the component overview shown under an item-category-L line and ☑ Item OK at the very bottom.
| Field / Action | Fill | What it asks (plain words) | Why — and the impact if wrong |
|---|---|---|---|
| Header (top) · Dropdown 1 (Action) | Goods Receipt | What are you DOING — receiving, issuing, transferring? | The finished galvanized rebar is coming back from the vendor → Goods Receipt. Impact: the wrong action shows the wrong screen and movement types. |
| Header (top) · Dropdown 2 (Reference) | Purchase Order + the subcontract PO from 9.3 → Enter | Against WHICH document is this receipt? | The PO brings the finished item, the 50 TO, the ₨500/TO fee AND the component list. Impact: no reference = a manual receipt with none of that, and the billets at the vendor never clear. |
| Header (top-right) · Movement Type | 101 (auto) | Which KIND of movement is this? | 101 = goods receipt for a PO; the paired 543 rides along automatically. Leave it. |
| Item overview grid · Qty in UnE column (finished) | 50 TO of FERT-REBAR-GALV-01 | How much finished product arrived? | This drives how many billets get consumed (50 TO output → 50 TO billets). Impact: receive less and only that share of components is consumed at the vendor. |
| Item detail → Where tab · Storage Location | FNGD | Where should the finished rebar be put? | The finished-goods store at PK01. Impact: the wrong store room only misplaces the rebar inside the right plant. |
| Item detail · Component overview (auto sub-screen under the item) | shows FERT-REBAR-01 × 50 TO to be consumed from stock-at-vendor | Which of YOUR parts get used up? | SAP fills this from the 9.1 BOM — check it matches what you sent in 9.4. Impact: if the quantity looks wrong, the BOM or the sent quantity is off. |
| Item overview grid · ☑ Item OK column | ✅ tick | Do you confirm THIS line? | Impact: forget the tick and Post fails with "no items selected." |
| Toolbar (top) · Check → Post | lights green → Post → note the material document number | Any problems before it becomes real? | Check simulates first; Post writes BOTH movements (101 + 543) at once. |
What changes at this exact moment — two movements post together (you type only the 101; SAP fires the 543 itself):
| Mvt | What | Accounting |
|---|---|---|
| 101 | Receive 50 TO galvanized rebar | Inventory Galv Rebar Dr / GR/IR Cr (service fee value) |
| 543 | Consume components at subcontractor | Component Consumption Dr / Stock Provided to Vendor Cr |
Net FI: Galv rebar inventory increases by component value + service fee. Component value (billets) moves from "stock provided" to consumption.
In a normal PO receipt (Scenario 1) movement 101 alone just adds stock. Here, because the PO line is item category L, the single Post fires 101 and 543 together: the finished rebar comes in, and in the same breath SAP consumes the billets you sent in 9.4 out of special stock O (your stock at the vendor). Nobody keys the 543 — the item category wired it. That is how the billets' value flows into the finished-goods value without a separate issue step.
Verify: ME2O → stock provided to MUGHAL21 cleared · MMBE → FERT-REBAR-GALV-01 +50 TO at PK01/FNGD, and FERT-REBAR-01 special stock O reduced by 50 TO · ME23N → the subcontract PO → Purchase Order History shows both the 101 and 543 lines.
9.6 — Invoice for service fee · MIRO
⚡ This step will: record the vendor's bill for the WORK only — the ₨25,000 GR/IR IOU from 9.5 clears and a real debt to MUGHAL21 appears. 📄 paper: invoice document · 📦 stock: no change · 💰 money: Dr GR/IR / Cr Vendor
The vendor bills ONLY the processing work: 50 TO × ₨500 = ₨25,000. Not the billets — those never left your books.
Do: MIRO → fill the header → PO reference tab → the subcontract PO → Enter → check Balance is 0.00 → Post:
| Field | Fill | What it asks (plain words) | Why — and the impact if wrong |
|---|---|---|---|
| Header · Basic Data tab · Invoice Date | the date on MUGHAL21's bill | When did the vendor write this bill? | Drives the payment/due date. Impact: a wrong date shifts when the ₨25,000 falls due. |
| Header · Basic Data tab · Reference | the vendor's bill number | What number does the VENDOR call this bill? | The audit trail between your books and the subcontractor's. Impact: without it, later disputes are painful. |
| Allocation area · PO reference tab · Purchase Order | the subcontract PO from 9.3 → Enter | Which purchase is being billed? | Loads the fee line: only the ₨25,000 the 9.5 GR parked in GR/IR — the billet value is not here. Impact: no reference = no three-way match. |
| Header · Basic Data tab · Amount | 25,000 PKR | What is the TOTAL on the vendor's bill? | SAP compares it with the fee the PO + GR promised. Impact: a different amount shows as a Balance ≠ 0. |
| Header (top-right) · Balance indicator | must be 0.00 · green | Does the bill match PO and GR? | Zero = the three-way match agrees → Post. Impact: a red balance means the fee differs — check before forcing it. |
What changes at this exact moment: the ₨25,000 GR/IR tray that the 9.5 receipt parked is emptied, and a real payable to MUGHAL21 is created (paid later via F-53).
MIRO posting → GR/IR Dr 25,000 / Vendor Cr 25,000.
In a normal purchase (Scenario 1) MIRO pays for the whole material. In subcontracting the billets stayed yours the entire time — sent as special stock O, consumed by the auto-543 in 9.5 — so the vendor never bought or sold them. He bills labour only: 50 TO × ₨500. Adding the steel value here would pay him for stock he never owned.
Verify: FBL1N → MUGHAL21 shows a ₨25,000 open payable · ME23N → the subcontract PO → Purchase Order History shows the invoice line · vendor cleared after F-53.
9.7 — Pay the vendor · F-53
⚡ This step will: pay the debt — the vendor's account goes to zero and the bank shrinks by ₨25,000. 📄 paper: payment document · 📦 stock: no change · 💰 money: Dr Vendor / Cr Bank
Do: F-53 → fill the header (dates + company code) → Bank data (which cash account + how much) → Open Item Selection (the vendor) → Process Open Items → double-click the invoice so Not assigned = 0.00 → Post.
| Where on screen · Field | Fill | What it asks (plain words) | Why — and the impact if wrong |
|---|---|---|---|
| Header · Document Date / Posting Date | today (proposed) | When is the payment made / in which period does it post? | Same-day defaults are right. Impact: a wrong posting date can land in a closed period. |
| Header · Company Code | PSPK | WHOSE books release the cash? | PSPK owes MUGHAL21 and pays. Impact: the wrong company code pays from the wrong firm's bank. |
| Bank data · G/L Account + Amount | 113100 · 25,000 | From WHICH cash account, and HOW MUCH leaves? | 113100 = Bank Main Account, the same bank G/L as Scenario 1; ₨25,000 is the full service-fee payable from 9.6. Impact: a wrong account credits the wrong cash line; a wrong amount leaves a balance that will not post. |
| Open Item Selection · Account (vendor) | MUGHAL21 (Mughal Steel Industries Ltd) | WHOSE unpaid bills are we clearing? | The subcontractor that carries the fee payable MIRO booked in 9.6. Impact: the wrong vendor shows no matching open item. |
| Button · Process Open Items | click | Show this vendor's open (unpaid) invoices. | Opens the open-items list so you can pick the exact invoice. Impact: skip it and there is nothing selected to pay. |
| Open-items screen · the invoice line | double-click it → Not assigned = 0.00 | WHICH bill exactly are you paying? | Activating the line makes Assigned = Amount Entered, so Not assigned falls to 0. Impact: if it is not 0 the payment is unbalanced and will not post. |
| Toolbar · Post | save → payment doc number | Commit the payment? | Post writes the FI document and clears the invoice. Impact: nothing is real until you Post. |
What changes at this exact moment: the ₨25,000 leaves the bank and MUGHAL21's account goes to zero; the invoice's open item flips to CLEARED:
| Vendor payable (via MUGHAL21) | Dr 25,000 | the payable is cleared |
| Bank (113100) | Cr 25,000 | cash leaves the bank |
Remember the billets were never bought — they stayed your stock (special stock O) and were consumed by the auto-543 in 9.5. So the only payable that ever existed is the vendor's service fee: 50 TO × ₨500 = ₨25,000, booked to MUGHAL21 in 9.6. F-53 clears just that small labour bill — Vendor Dr / Bank Cr — the same as Scenario 1, only far smaller, because you paid for work, not materials.
Verify: FBL1N → MUGHAL21 → the invoice now shows as cleared, no open items left. Full F-53 walkthrough with every field: Scenario 1.
🐞 Errors we hit live — and how to fix them
These are the exact messages we met running subcontracting on a fresh company code — what each means, why it happens, and the fix, linked to the Prerequisite that clears it. Reading these is how you learn to debug SAP.
| Where it appears | The message SAP shows | What it means & why it happens | How to fix it |
|---|---|---|---|
| PO — 9.3 (ME21) | "M8 215 — Maintain tolerance limits for tolerance key SE (CoCode PSPK)" | SAP checks purchasing tolerances before it will save any PO, and key SE has no limit for this new company code. (The trap: SE is a purchasing key — it is NOT in OMR6, which holds only invoice-verification keys.) | Add key SE — Prerequisite ① (OLME → Set Tolerance Limits for Price Variance, view VV_169G_PS). |
| PO — 9.3 | "ME 092 — Material mainly procured internally" (and the net price keeps resetting to 0) | The finished good was created as in-house-produced, so entering the PO line re-proposes the item and wipes any price you type — an endless "Enter Net Price" loop. | Create the subcontracting info record first (ME11, ₨500/TO) so the price has a source that survives the re-proposal — step 9.2. |
| PO — 9.3 | The components don't auto-explode into the PO | Symptom, not a message: the BOM didn't explode for the subcontracting line, so SAP didn't list the parts to send. | Enter the component manually on the "Processing Components" screen (FERT-REBAR-01, 50 TO). |
| GR — 9.5 (MIGO 101+543) | "G/L account 415000 / 417000 / 192300 does not exist in company code PSPK" (one at a time) | The goods receipt posts subcontracting expense + a clearing account that were never set up in this new company code. | Create each account — Prerequisite ③ (FS00, "Create with reference" from company code 0001). |
| GR — 9.5 | Account 192300 "not consistent" | A materials-management (type M) account may not have Open Item Management ticked when it's used in automatic MM postings. | Untick Open Item Management on 192300 — Prerequisite ③ (FS00). |
| GR — 9.5 | Account 417000 / 415000 requires a CO account assignment (cost object) | These are P&L (cost) accounts, so every posting needs a cost center — and none defaults for them. | Set a default cost center — Prerequisite ③ (OKB9 → PKKHI-PROD). |
| GR — 9.5 | ABAP dump (CX_SY_OPEN_SQL_DATA_ERROR) in a MIGO enhancement | A custom BAdI overflowed a 10-character field because the Delivery Note text was too long. | Keep the Delivery Note ≤ 10 characters (we used SCGR01). |
| GR — 9.5 | A large price difference posts to a PRD (price-difference) account | Symptom: the finished good's standard price didn't match the (much higher) component value it consumes, so the gap posts as a variance. | Align the finished-good standard price = component + service — Prerequisite ② (MR21). |
✅ Verification — Confirm Scenario 9 Worked
- ME2O → stock at vendor cleared
- MMBE → FERT-REBAR-GALV-01 stock 50 TO at PK01/FNGD
- MMBE → FERT-REBAR-01 → reduced by 50 TO from WIPS
- Vendor cleared after F-53
🎓 Interview-Ready Answers
Q: What is special stock type "O" and why does subcontracting use it?
Special stock O is "stock provided to vendor" — your own material physically sitting at the subcontractor's site but still owned by you and still on your balance sheet. Subcontracting uses it because you send components (mvt 541) for the vendor to process; until they're consumed into the finished product (mvt 543), they remain your inventory, just tracked separately. You can monitor it any time with ME2O.
Q: Walk me through the three movement types in a subcontracting cycle.
541 sends components from your plant to the vendor's special stock (no P&L). 543 consumes those components when the finished product is received — it credits stock-provided-to-vendor and debits component consumption. 101 receives the finished product into your inventory at component value plus the service fee. The 543 and 101 post together at goods receipt.
Q: What does the subcontractor's invoice actually cover?
Only the service fee — the PO net price (e.g. PKR 500/TO), not the value of the components. You never sold the billets to the vendor, so they're not on the bill. At MIRO the service value clears GR/IR (Dr) against the Vendor (Cr). The component cost was already captured in your books via the 543 consumption.
Q: Why does subcontracting need a BOM but not the full PP module?
The BOM (created in CS01) tells SAP which components and quantities feed one unit of the finished product, so the subcontract PO (item category L) can auto-explode the components to send. But the actual production happens at the external vendor, not your plant — so you need no work centers, routings, or production orders. Just the BOM for component determination.
Built and verified live end-to-end. Config fixes applied along the way: gap ① (tolerance key SE via OLME → Set Tolerance Limits for Price Variance — not OMR6), gap ② (MR21 standard price), and gap ③ (G/L accounts 415000/417000/192300 + OKB9 cost centers). Live docs: PO 4500032783 · GR 5000047742 · MIRO 5100021699 · payment 4900000004.