Scenario 12 — Third-Party Drop-Ship (Vendor Ships Direct to Customer)

TIER 4 · SPECIAL PROCUREMENT ★★★★☆ ⏱️ ~2.5 hours VA01 (item TAS) → ME21N auto → MIRO → VF01 → F-53

✅ The whole sell-side + procurement trigger + pricing are PROVEN LIVE — the buy-side settlement tail is the documented remainder

On the real system (PakSteel IDES) we built and ran the front half of this scenario end-to-end, live: the trading material TP-REBAR-01 (type HAWA, carrying the one switch that makes third-party work — item category group BANS); the customer 1200000410 "Karachi Builders Ltd"; the sell price (VK11 / PR00 / ₨60,000 per TO); all the SD config (sales office via OVXM, pricing determination via OVKK, procedure ZPKINT); and the VA01 sales order 2 itself — whose TAS line auto-created the purchase requisition 1000001210 to the vendor. The remaining tail — convert PR→PO (ME21N/ME57), statistical GR (MIGO), vendor invoice (MIRO), customer billing (VF01), payment (F-53) — is written out step-by-step from the verified S/4HANA flow, ready for you to post. The money story: buy 200 TO of rebar at ≈₨50,000/TO from the vendor, bill it to the customer at ₨60,000/TO — your profit is the margin (~₨2,000,000).

Part of the cycle	What it is	Status
Traded material	MM01 — type `HAWA`, item category group `BANS`	`TP-REBAR-01` "Rebar - Third-Party (Drop-Ship)" — created live ✅
Drop-ship vendor	reused standing supplier (no third-party setup needed)	`MUGHAL21` — already live (from Sc 9/10/11) ✅
Customer (sold-to)	BP — roles `FLCU00`+`FLCU01`, sales area `PKSO/10/60`, recon `160000`, cust. pricing proc. `01`	`1200000410` "Karachi Builders Ltd" — created live ✅
Sell price	VK11 — `PR00`, key Customer/Material	₨60,000 / TO — created live ✅
SD config	sales office (OVXM) + pricing determination (OVKK) → procedure `ZPKINT`	sales office `1000` + OVKK `PKSO/10/60/A/01→ZPKINT` — done live ✅
Sales order (VA01)	type `OR`, item cat `TAS` auto, net ₨12,000,000	order `2` — created live ✅ (an incomplete first attempt saved as order 1; the good one is 2)
Auto purchase requisition	born from schedule line CS — item cat `S`, acct assgt `X`	`1000001210` item 00010 (plant PK01, vendor MUGHAL21) — auto-created live ✅
PR→PO → MIGO → MIRO → VF01 → F-53	the buy-side settlement + customer-billing tail	documented from the verified flow — run it live

Honesty note: everything above marked ✅ is confirmed on the live system. For the remaining tail (PO/GR/MIRO/VF01/F-53) we do not show document numbers, because you'll generate those yourself when you post it — we never invent SAP document numbers. The Prerequisites box lists everything that must be in place first; the Errors box shows the exact messages we hit live and how we cleared them.

Supplier note: we reuse our standing vendor MUGHAL21 (Mughal Steel Industries Ltd) so this scenario ties to Scenario 9, Scenario 10 and Scenario 11. A supplier needs no third-party-specific setup — which is exactly why we can reuse it.

📊 Business Case — When & Why You Use This

Third-party drop-ship is where you sell something you never physically handle. A customer order triggers a purchase order to your vendor, and the vendor ships the goods straight to your customer's site. You sit in the middle of the transaction — earning the margin between vendor cost and customer price — without the goods ever entering your warehouse or your inventory. This is a tight MM ↔ SD ↔ FI integration scenario.

🕐 When to use it

When you take a customer order for material you don't stock and don't want to stock — bulky, made-to-order, or supplier-direct items where it's cheaper and faster for the vendor to deliver to the customer for you.

❓ Why it matters

You capture the trading margin with zero inventory cost or warehousing. The sales order auto-creates the purchase requisition, so SD and MM stay linked end-to-end and the goods never touch your books.

👤 Who triggers it

Sales raises the order with item category TAS; the system auto-creates the PR; purchasing converts it to a PO to the vendor; AP verifies the vendor invoice; billing invoices the customer.

🔁 The key distinction

You never hold the goods. The PO carries account assignment X (sales order), so stock never enters your inventory — any GR is purely statistical. COGS and revenue are recognized without inventory ever sitting on your balance sheet.

💰 Financial Impact — The Easy-Money Example

PakSteel sells 200 TO of rebar to a builder. It holds no stock — Mughal Steel Industries Ltd (MUGHAL21) ships straight to the builder. Here's how the money flows through PakSteel's books without a single ton of inventory landing:

📄 Vendor invoice (MIRO)

COGS ↑

Mughal's invoice posts to a Third-party COGS G/L → Vendor Cr. This is your cost of the deal.

→

🧾 Customer billing (VF01)

Revenue ↑

Customer Dr / Revenue Cr — you bill the builder from the sales order.

→

📊 Result

Margin = Rev − COGS

Profit booked with no inventory ever on the balance sheet — pure trading margin.

The big idea: in a normal sale you'd capitalize inventory, then release it to COGS at delivery. Here the goods skip your warehouse entirely — COGS comes straight from the vendor invoice (MIRO) and revenue from customer billing (VF01). The margin lands in your P&L while inventory never appears on your balance sheet.

💡 Key lesson: Third-party drop-ship recognizes revenue and COGS without inventory ever sitting on your books. The PO's account assignment X routes the cost straight to the sales order, so any goods receipt is statistical only. One more twist: because the item category is TAS (billing relevance F), you can only bill the customer after the vendor's invoice (MIRO) is posted — the cost is known before the sale is booked.

🇵🇰 The Business Story

PakSteel sells 200 TO of rebar to a builder customer, but doesn't have stock. Instead, they arrange for vendor Mughal Steel Industries Ltd (MUGHAL21) to ship directly to the builder's site. PakSteel never touches the goods — they just earn the margin between vendor cost and customer price. It's the same standing vendor we use in Scenarios 9, 10 and 11, so the whole story ties together.

🎯 What you'll learn

Item category group BANS on the material — the single switch that turns a normal order line into third-party
Trigger: SD Sales Order with item category TAS (Third-party), auto-determined from BANS
Schedule line category CS — the piece that auto-creates the purchase requisition from the sales order
PO has item category S + account assignment X (sales order) — stock never enters our books
Vendor ships directly to customer; PakSteel just verifies the invoice (MIRO) + bills the customer (VF01)
MIGO is statistical (no real stock movement); the PO's GR flag may be off, skipping it entirely
Order-related billing type F2 — you bill from the sales order (there is no delivery), and only after MIRO (billing relevance F)

📋 Prerequisites — what must be in the system (and why)

These are the master-data records and SD/MM settings the third-party cycle needs, all anchored to the verified standard flow. On our system we created the trading material TP-REBAR-01 live (with the key BANS switch) and we reuse vendor MUGHAL21; the customer and the SD config below are what you must have in sales area PKSO/10/60 to run the cycle cleanly — miss any and you'll meet the messages in the Errors box. The two third-party-specific switches are ② the material's BANS group and ③④ the TAS/CS determination; the rest are ordinary SD selling settings.

① Master data — the records the steps use

Record	Live value	What it is · why the scenario needs it
Traded material	`TP-REBAR-01` (type `HAWA`, plant `PK01`, sales area `PKSO/10/60`, base unit `TO`, item category group `BANS`, acct-assignment group `Z2`, no Accounting view)	The rebar you sell but never stock — created live. Needed because the VA01 line reads its BANS group to become TAS, and its account-assignment group Z2 drives revenue account determination. No Accounting view: the cost routes via the sales-order account assignment, not stock valuation.
Drop-ship vendor	`MUGHAL21` — extended to purch org `PKLO` + company code `PSPK`	Who ships to the customer and whom you pay. Needed because the auto-PO and MIRO must land on a real vendor account (AP). Reused from Sc 9/10/11 — a supplier needs no third-party-specific setup, which is why we reuse it.
Customer (sold-to)	`1200000410` "Karachi Builders Ltd" — BP roles `FLCU00`+`FLCU01`, company code `PSPK`, recon acct `160000`, sales area `PKSO/10/60`, customer pricing procedure `01`, acct-assignment group `Z2`	Who orders and receives the goods — created live. Needed because VA01 must find a sold-to that belongs to your sales area, or it can't place the order. See Prerequisite ⑤ for how it was built (and the sales-office snag we hit).

🔀 Prerequisite ② — the item category group BANS on the material

🎯 In plain words: this is the one switch that turns an ordinary trading material into a "the vendor ships this for me" material. Without it, a sales order would try to sell it from your own stock.

What to set: in MM01 (or MM02), on the Sales: Sales Org 2 view, set Item Category Group = BANS ("Third-party item"). Our material TP-REBAR-01 (type HAWA) already carries it. Also set acct-assignment group Z2 and tax classification 1 for the tax conditions ZT1/ZT2/ZT3/ZT4 on the Sales views.
Why SAP needs it: when you type the material into a sales order, SAP reads this group to decide the item category. BANS is what makes the line land on TAS (third-party) instead of TAN (sell from stock).
What breaks without it: the default group NORM makes the order line TAN — SAP expects to ship from your warehouse, and no purchase requisition to the vendor is ever created, so the drop-ship never starts.
✅ How you'll know it worked: MM03 → Sales: Sales Org 2 → Item Category Group shows BANS; and in VA01 the line's ItCa column auto-fills TAS with no typing.

🧩 Prerequisite ③ — item category determination (VOV4): OR + BANS → TAS

🎯 In plain words: the rule table that reads "order type + the material's item-category group" and picks the right item category. This is where OR + BANS is told to become TAS.

What to set: VOV4 (SPRO → Sales & Distribution → Sales → Sales Documents → Sales Document Item → Assign Item Categories) → entry: sales doc type OR + item cat group BANS → default item category TAS.
Why SAP needs it: without this line, SAP can't map the material's BANS group to an item category, so it can't decide the line is third-party.
What breaks without it: in VA01 the item category comes up blank (the line can't be saved) or defaults to a stock category — the auto-TAS behaviour is lost.
✅ How you'll know it worked: entering TP-REBAR-01 in VA01 auto-proposes TAS in the ItCa column. Standard IDES already carries OR+BANS→TAS.

📝 Prerequisite ④ — the schedule line category CS (attached to TAS) — this is what creates the PR

🎯 In plain words: the little setting on the order line that actually says "create a purchase requisition." TAS uses schedule line category CS, and CS is the piece that spawns the PR to the vendor.

What to set: in the TAS configuration, schedule line category CS is assigned to item category TAS. CS carries a PR document type NB, item category 5 (third-party) and account assignment category X (sales order) — so the PR is born third-party.
Why SAP needs it: the requisition is created by the schedule line, not the item. CS is the third-party schedule line that carries the "make a PR to the vendor" instruction.
What breaks without it: TAS with the wrong schedule line makes no requisition — sales saves the order, but purchasing never gets a to-do, so nothing is ever bought and the vendor never ships.
✅ How you'll know it worked: after saving the VA01 order, the item's schedule line shows category CS and a purchase requisition number (visible in the schedule-line detail / the document flow).

👤 Prerequisite ⑤ — a customer that lives in sales area PKSO/10/60 (create via BP) — built live as 1200000410

🎯 In plain words: you need a "sold-to" that actually belongs to the same sales area you sell from. The general IDES customers sit on other sales orgs, so you must create (or extend) one into PKSO/10/60. We created ours live: 1200000410 "Karachi Builders Ltd".

What to set: BP → create an organization, role FLCU00 (FI Customer) + FLCU01 (Customer). Company code PSPK, reconciliation account 160000 (trade receivables). Sales-area data for PKSO / 10 / 60: customer pricing procedure 01 (drives which pricing procedure OVKK picks — see Prerequisite ⑩), account-assignment group Z2, the Shipping + Billing tabs, and order-related billing. Tip: also maintain payment terms + Incoterms on the Billing tab so every order inherits them (we hit soft "Enter Terms of Payment / Missing Incoterms" warnings in VA01 because ours were blank — see the Errors box). Name: "Karachi Builders Ltd."
Why SAP needs it: VA01 must find the sold-to in exactly the sales org / channel / division you enter. FI needs the recon account to post the receivable; SD needs the sales-area data to price and bill.
⚠️ The live snag — Sales Office required, but the sales area had none: the BP Sales tab made Sales Office a required field, but sales area PKSO/10/60 had no sales office assigned, so the BP would not save. Fix: transaction OVXM ("Assign sales office to sales area") — assign sales office 1000 (Export Sales Office) to PKSO/10/60. The sales offices 0001/1000/2000 already existed (table V_TVBUR); only the assignment to our sales area was missing.
What breaks without it: in VA01 you get "The sales area could not be determined" — because the customer you picked exists only on a different sales org, not PKSO/10/60.
✅ How you'll know it worked: BP shows the customer (1200000410) with company-code data (recon 160000) and sales-area data for PKSO/10/60 (sales office 1000, customer pricing procedure 01); VA01 accepts it as sold-to with no sales-area error.

📦 Prerequisite ⑥ — PO item category S + account assignment category X

🎯 In plain words: on the buying side, two little codes make the purchase "for this one customer order, delivered to the customer, never into my stock."

What to set: the third-party PO line carries item category S (Third-party) and account assignment category X (Sales order). These flow automatically from the TAS/CS setup into the auto-created PR and onto the PO — you just confirm them in ME21N.
Why SAP needs it: item category S tells the PO "vendor ships to the customer's address"; account assignment X tells FI "book the cost to the sales order, not to inventory."
What breaks without it: a blank account assignment makes SAP try to capitalize the rebar as your stock — but no goods ever reach your warehouse, so stock and accounting break.
✅ How you'll know it worked: ME23N on the PO shows column A = X (Sales order) and item category S; the Delivery Address tab shows the customer's site.

🧾 Prerequisite ⑦ — order-related billing / copy control (OR → F2)

🎯 In plain words: because there's no delivery in a drop-ship, the invoice to the customer must come from the sales order itself. A copy-control rule allows "order → billing F2."

What to set: item category TAS is set for order-related billing, and copy control (VTFA, order → billing) exists for OR → F2 (confirmed live: order type OR's order-related billing type is F2). TAS billing relevance = F ("relevant for order-related billing — status according to invoice quantity") — meaning the order can only be billed after the vendor invoice (MIRO) is posted.
Why SAP needs it: with no delivery document, VF01 has nothing to bill unless the order itself is billing-relevant and copy control routes OR → F2.
What breaks without it: VF01 finds no billing-relevant document — "the document is not relevant for billing" — and no customer invoice can be raised.
✅ How you'll know it worked: after MIRO, VF01 proposes an F2 invoice from the sales order number (not a delivery). Before MIRO, billing relevance F correctly holds it back.

💰 Prerequisite ⑧ — revenue account determination (VKOA)

🎯 In plain words: when you bill the customer, the revenue has to find a G/L account. VKOA is the table that picks it, using the account-assignment groups of the customer and the material.

What to set: VKOA → for the combination of the customer's account-assignment group + the material's account-assignment group (material AAG = Z2) + account key ERL → a revenue G/L account. The G/L must exist in company code PSPK (FS00).
Why SAP needs it: the credit side of the billing document is revenue; without a VKOA entry SAP doesn't know which revenue account to post to.
What breaks without it: VF01 fails with a revenue account determination error and no accounting document is created — the invoice sits incomplete.
✅ How you'll know it worked: the billing document's accounting entry shows Dr Customer / Cr Revenue with a real revenue G/L; VF02/VF03 shows the accounting document created.

🏷️ Prerequisite ⑨ — a sales price condition (VK11 / PR00) — created live at ₨60,000/TO

🎯 In plain words: the order needs to know what price to charge the customer. You store that in a condition record.

What to set: VK11 → condition type PR00 (the base price in procedure ZPKINT) → key Customer/Material (1200000410 / TP-REBAR-01) → we entered ₨60,000 per TO. Against a vendor cost of ≈₨50,000/TO on the PR, that leaves a margin of ~₨2,000,000 on 200 TO.
Why SAP needs it: pricing in the sales order is driven by condition records; with none, the line prices at zero.
What breaks without it: the VA01 line shows a zero net value; VF01 then bills nothing, so there's no revenue and no margin.
✅ How you'll know it worked: live, the VA01 item's net value came up as ₨12,000,000 (200 TO × ₨60,000); the same value flows to the F2 invoice.

🧮 Prerequisite ⑩ — pricing-procedure determination (OVKK) → ZPKINT (this is the one we had to add live)

🎯 In plain words: before SAP can even read your PR00 price, it must first decide which pricing procedure the order uses. OVKK is that decision table — it reads five keys and picks a procedure.

What to set: OVKK → new entry for sales area PKSO / 10 / 60 + document pricing procedure A (comes from order type OR) + customer pricing procedure 01 (from the customer master) → pricing procedure ZPKINT, with PR00 as the condition type. We added exactly this line live: PKSO / 10 / 60 / A / 01 → ZPKINT.
🧠 Teaching note — why the existing PKSO entry didn't help: the sales area already had an OVKK line for I / 1, but that was set up for the inter-company billing in Scenario 8. A normal sales order of type OR carries document pricing procedure A, and this customer's customer pricing procedure is 01 — so it needs its own matching OVKK line. Both the document key and the customer key must match, or no procedure is found.
Why SAP needs it: with no matching row, the order has no pricing procedure, so it can't run any condition (not even PR00) and the line can't be priced.
What breaks without it: VA01 throws "No pricing procedure could be determined" and the item won't price — this is the live error we hit (see the Errors box).
✅ How you'll know it worked: after adding the row, the VA01 item's Conditions tab shows procedure ZPKINT with PR00 = ₨60,000 and a net value of ₨12,000,000.

🔧 Step-by-Step

🧭 The route at a glance — read this first

Step	T-code	What it does	Why this step exists
12.1	VA01	Record the builder's order; TAS + schedule line CS auto-create a purchase requisition	a customer order starts the whole chain
12.2	ME21N (or ME57)	Convert the auto PR into a PO to MUGHAL21 (item cat S, acct assignment X)	a promise needs a document — delivery set to the customer's site
12.3	MIGO	Log that the vendor shipped — no stock, no money (optional)	proof of shipment for goods you never own
12.4	MIRO	Enter Mughal's bill; cost books straight to Third-party COGS	your cost of the deal must be recorded
12.5	VF01	Bill the builder straight from the sales order — only after MIRO (billing relevance F)	revenue is only earned once the customer is billed
12.6	F-53	Pay MUGHAL21; the payable clears, bank goes down	a purchase isn't finished until the vendor is paid

📇 Your live codes — quick reference

Material TP-REBAR-01 (type HAWA) · Vendor MUGHAL21 · Customer 1200000410 "Karachi Builders Ltd" · Sales order 2 · Auto PR 1000001210 · Plant PK01 · Sales area PKSO / 10 / 60 · Sales office 1000 · Purch org PKLO · Purch group RMT · Company code PSPK · Order type OR · SD item category TAS · Schedule line CS · PO item category S · Acct assignment X · Billing type F2 (order-related) · Qty 200 TO · Sell price ₨60,000/TO · Vendor cost ≈₨50,000/TO · Net value ₨12,000,000 · Margin ≈₨2,000,000 · Pricing procedure ZPKINT · Doc pricing proc. A · Customer pricing proc. 01 · Material AAG Z2 · Profit center PSPK-PC · Customer recon 160000 · Bank G/L 113100.

📦 MIGO top bar (step 12.3 — statistical GR, optional)

MIGO → Action Goods Receipt · Reference Purchase Order → mvt 101, purely statistical (no stock, no value — acct assignment X routes cost to the sales order). The PO's GR flag may be off, skipping this entirely. Use MIGO, never the obsolete MB1A/MB01.

🔄 Transaction Flow

12.1 — Sales Order · VA01 with item category TAS

⚡ This step will: record the builder's order — and the TAS line (via schedule line CS) makes SAP auto-create a purchase requisition, so purchasing already knows what to buy. 📄 paper: sales order + auto purchase requisition · 📦 stock: no change · 💰 money: no posting

Do: VA01 → fill the fields below → Save → note the SO number.

VA01 opens on a short initial screen (order type + the sales area — sales org · distribution channel · division); press Enter and the order screen has 3 zones: ① the Header (sold-to party, ship-to, the customer's PO number, dates), ② the Item overview grid (one ROW per line — material, order quantity, and the ItCa item-category column), ③ the Item detail tabs (for the line selected above).

Where on screen · Field	Fill	What the field asks (plain words)	Why we choose this — and the impact if wrong
Initial screen · Order Type	`OR`	What KIND of sales document is this?	OR = a normal sales order; the special third-party behaviour sits in the ITEM category below, not in the order type. Impact: none from using OR — hunting for a "third-party order type" is a wrong turn
Initial screen · Sales Org	`PKSO`	WHICH selling company/team sells this?	PakSteel's sales org — the selling-side mirror of the purchasing organization. Impact: the wrong sales org books the sale in the wrong selling unit, so pricing and revenue land in the wrong place
Initial screen · Distribution Channel	`10` (Export)	Through WHICH route to market is it sold?	SD documents need this to find the right prices and settings for that channel. Impact: a wrong channel can pull the wrong price list or block the material for sale
Initial screen · Division	`60` (Steel Products)	WHICH product line/group does it belong to?	Groups the sale under a product division for reporting and control. Impact: a wrong division misfiles the sale and can fail the material's sales-area checks
Header · Sold-To Party (Customer)	`1200000410` "Karachi Builders Ltd" (from Prerequisite ⑤)	WHO buys — and WHERE will the vendor deliver?	In third-party the goods go straight to this customer's site, so the customer master carries the real delivery address. Impact: a customer not in sales area PKSO/10/60 gives "The sales area could not be determined" — create/extend it first (Prerequisite ⑤)
Item overview grid · Material	`TP-REBAR-01`	WHAT did the builder order?	The traded rebar (type HAWA). Impact: the wrong material orders and bills the wrong product
Item overview grid · Order Qty	`200` TO	HOW MUCH?	200 tonnes ordered. Impact: this quantity flows into the auto-created purchase requisition, so a wrong figure makes you buy the wrong amount from the vendor
Item overview grid · Item Category (ItCa column)	`TAS` (auto — Third-party)	HOW is this line fulfilled? Normal = from your own stock · `TAS` = "we don't stock it — buy it for this order and let the vendor ship straight to the customer." Like a shopkeeper who phones the factory to deliver to your house	SAP fills TAS automatically because the material's item-category group is `BANS` (Prerequisite ②/③). TAS is the trigger for everything that follows. Impact: if it comes up TAN instead, the BANS group is missing and no requisition to the vendor is created

Behind the scenes (confirmed live): saving the TAS line makes its schedule line category CS create a PR (purchase requisition — an internal "please buy this" note, NB-style) automatically, already carrying item category S + account assignment X. Live, our order came out as SO 2, net value ₨12,000,000 (200 TO × ₨60,000), and it spawned PR 1000001210 item 00010 (plant PK01, desired vendor MUGHAL21). Sales typed one order; purchasing already has its to-do. (An earlier attempt saved incomplete as order 1 — the good, complete order is 2.)

⚠️ Two small entries VA01 asked us for live — don't skip them

① When the third-party PR is created inside the order, its item needs a valuation price — SAP stopped us with "Make an entry in mandatory field Val. Price". Enter the expected vendor cost (we used ₨50,000/TO) plus desired vendor MUGHAL21 and purch org PKLO on the PR item. ② The order also flagged soft warnings "Enter Terms of Payment" and "Missing data: Incoterms" (the customer master had none in its Billing view) — we set Incoterms EXW Karachi + payment terms 0001 on the order header. Better: maintain both on the customer's Billing tab so every order inherits them (Prerequisite ⑤).

12.2 — Convert PR to PO · ME21N (or ME57 to convert the auto PR)

⚡ This step will: turn the auto-created wish into a binding promise to MUGHAL21 — with the builder's site as the delivery address, so the vendor ships straight to your customer, never to you. 📄 paper: purchase order · 📦 stock: no change · 💰 money: no posting

Do: ME21N → pull in the auto-created PR (or use ME57 "Assign and Process Requisitions" to convert it) → check the fields below → Save.

The ME21N screen has 3 zones — plus the Document Overview panel on the left, which is how you pull in the auto-created PR: ① the Header (top: vendor, doc type, Org Data tab), ② the Item overview grid (one row per line — with the small A account-assignment-category and I item-category columns), ③ the Item detail tabs (bottom, for the selected line — including the Delivery Address tab).

Where on screen · Field	Fill	What the field asks (plain words)	Why we choose this — and the impact if wrong
Document overview · the PR	PR `1000001210` (auto-created in 12.1)	Buying against WHAT need?	Adopting the purchase requisition keeps the chain SO → PR → PO linked, so the PO "knows" which customer order it serves. Impact: create a loose PO instead and the link to the sales order is lost — costs and delivery no longer tie back to the customer's order
Item grid · column A (Account Assignment)	`X` (Sales Order)	WHERE does the cost go? Blank = the goods become your stock · `X` = the cost belongs to ONE sales order	`X` because you never own the rebar — it goes straight to the builder, so the cost must attach to the sales order, not to your inventory. It arrives pre-set from the CS schedule line. Impact: leave it blank and SAP tries to capitalize the rebar as your stock — but no goods ever reach your warehouse, so stock and accounting break
Item grid · column I (Item Category)	`S` (Third-party)	HOW does delivery happen?	`S` because the vendor ships to the CUSTOMER, not to you — so the delivery address on the PO is the builder's site. Impact: a normal (stock) category would tell MUGHAL21 to deliver to your plant and expect a real goods receipt into your stock, breaking the drop-ship
Header · Vendor	`MUGHAL21`	WHO actually ships the rebar?	Mughal Steel Industries Ltd sends the goods straight to the builder. Impact: the wrong vendor would dispatch the customer's order from the wrong supplier — or one who cannot drop-ship at all
Item detail · Delivery Address tab	the customer's site (defaults from the sales order)	WHERE does the vendor deliver?	Third-party delivers to the customer, so the address is the builder's, not your plant. Impact: the wrong address sends the rebar to your warehouse instead of the customer

Tip: the item category S and account assignment X are already carried by the auto-PR (from schedule line CS), so on a clean setup you mostly just confirm the vendor and Save.

12.3 — Statistical GR (optional) · MIGO

📄 paper: material document only (no accounting document) · 📦 stock: no change · 💰 money: no posting

"Statistical" = for information only. Asks: did the vendor really ship? It records the confirmation — no stock, no value, nothing enters your warehouse. Like ticking "delivered" on courier tracking for a parcel that never came to your house. If the PO's GR flag is off, skip this step entirely — that is allowed here because the goods are not yours. Use MIGO, never the obsolete MB1A.

Do: only if the GR indicator on the 12.2 PO is on — MIGO → set the two top-left dropdowns → load the PO → tick Item OK → Post:

The MIGO screen has 3 zones: ① the top bar (the Action + Reference dropdowns 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 ☑ 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?	You are recording that the vendor shipped → Goods Receipt. Impact: the wrong action shows the wrong screen and movement types.
Header (top) · Dropdown 2 (Reference)	Purchase Order + the third-party PO from 12.2 → Enter	Against WHICH document is this receipt?	The PO brings the item and the 200 TO. Impact: no reference = nothing to confirm against.
Header (top-right) · Movement Type	`101` (auto)	Which KIND of movement is this?	101 — but SAP posts it statistically (non-valuated), because the PO is account-assigned to the sales order (X) with item category S. Leave it.
Item overview grid · Qty in UnE column	`200` TO	How much did the vendor ship to the customer?	Records what MUGHAL21 confirms it sent. Impact: this only logs a confirmation — it moves no stock and no money either way.
Item detail → Where tab · Storage Location	field is ABSENT / greyed — correct!	Where should the stock be put?	Nowhere: the goods went straight to the builder and the receipt is statistical, so there is no storage location to fill. Impact: if a Storage Location field DID appear and take a value, your item category / account assignment is wrong — SAP would be trying to put stock on your shelf.
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?	Post writes a material document only — no accounting document, because nothing is valuated.

What changes at this exact moment: a material document is written that says "vendor confirmed shipment." That is all — no stock quantity on your books, no accounting document, no value. Your TP-REBAR-01 stock at your own plant stays exactly as it was (it never had any — this material has no Accounting view).

⚠️ A third-party GR is STATISTICAL — and optional (the lesson)

In a normal receipt (Scenario 1) movement 101 adds valuated stock and posts Inventory Dr / GR/IR Cr. Here 101 posts nothing financial and nothing to stock, because account assignment X + item category S mean the rebar is the customer's, never yours. And the whole step is optional: if the PO's GR flag is off, skip it — the vendor's invoice in 12.4 drives the flow on its own.

Verify: MMBE → TP-REBAR-01 shows no stock change at your plant · MB51 → the statistical 101 line appears with no value · ME23N → the PO → Purchase Order History shows the GR line but no FI document.

12.4 — Vendor invoice · MIRO

⚡ This step will: record MUGHAL21's bill: your cost of the deal books straight onto the sales order, and a real debt to the vendor appears — no inventory is touched. 📄 paper: invoice document · 📦 stock: no change · 💰 money: Dr Third-party COGS / Cr Vendor

Mughal Steel's bill for goods you never touched. Do this before VF01 — TAS billing relevance F means you can only bill the customer after the vendor invoice exists.

Do: MIRO → fill the header → PO reference tab → the third-party 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 Mughal's bill	When did the vendor write this bill?	Drives the payment/due date. Impact: a wrong date shifts when the payable falls due.
Header · Basic Data tab · Reference	Mughal's bill number	What number does the VENDOR call this bill?	The audit trail between your books and Mughal's. Impact: without it, later matching is painful.
Allocation area · PO reference tab · Purchase Order	the third-party PO from 12.2 → Enter	Which purchase is being billed?	Loads the ordered line (200 TO) so SAP can match. Impact: no reference = no match and the cost has nowhere to land.
Header · Basic Data tab · Amount	Mughal's total for the 200 TO	What is the TOTAL on the vendor's bill?	SAP compares it with what the PO promised. Impact: a different amount shows as a Balance ≠ 0.
Header (top-right) · Balance indicator	must be 0.00 · green	Does the bill match the PO?	Zero = the match agrees → Post. Impact: a red balance means price/qty differs — check before forcing it.

What changes at this exact moment: because account assignment X points the cost at the sales order, MIRO books your cost of the deal straight to Third-party COGS (on that sales order) and creates a real payable to Mughal — no inventory, no GR/IR-to-stock.

Third-party COGS (on the sales order)	Dr	what the deal cost YOU
Vendor MUGHAL21 (AP)	Cr	"we owe Mughal Steel" — a real payable

In plain words: COGS = cost of goods sold — what the deal cost YOU. Because of account assignment X there is no stock account to hit; the cost books straight against the sales order's result. Cr (credit) on the vendor = "we owe Mughal Steel."

⚠️ Cost goes to COGS, and the match is only two-way (the lesson)

In a normal buy (Scenario 1) MIRO clears GR/IR against the vendor and the value stays in inventory. Here there is no inventory — the cost books straight to Third-party COGS on the sales order. And because the only GR was statistical (12.3), there is no valuated receipt to match; the check is PO ↔ invoice (two-way match), not the usual PO ↔ GR ↔ invoice three-way.

Verify: FBL1N → MUGHAL21 shows the open payable · ME23N → the PO → Purchase Order History shows the invoice line · the Third-party COGS sits on the sales order's result.

12.5 — Customer Billing · VF01

⚡ This step will: bill the builder straight from the sales order: the builder now owes you money and your sales income is booked — the margin becomes visible. 📄 paper: billing + accounting document · 📦 stock: no change · 💰 money: Dr Customer / Cr Revenue

Now bill the builder. In a drop-ship there is no delivery, so you bill straight from the sales order (12.1). This only works after MIRO (12.4) — TAS billing relevance F holds the order back until the vendor invoice is posted.

Do: VF01 → enter the sales order number → the billing document is proposed → check it → Save:

Field / Action	Fill	What it asks (plain words)	Why — and the impact if wrong
Selection screen · Document	the sales order number from 12.1	WHICH document are you billing?	In third-party you bill the ORDER, because there is no delivery to bill from. Impact: try to enter a delivery number and there is none — the drop-ship never created one.
Billing overview · Billing Type	`F2` (proposed)	Which KIND of invoice document is this?	Here F2 is order-related (points at the SO), set automatically by the item category TAS (Prerequisite ⑦). Impact: if VF01 says "not relevant for billing," MIRO hasn't been posted yet (relevance F) or copy control OR→F2 is missing.
Item overview · Qty / Value	200 TO at the customer sales price	How much, and at what price to the builder?	Pulled from the sales-order pricing (PR00, Prerequisite ⑨). Impact: a zero value means no pricing condition was found.
Toolbar · Save	posts the billing document → note the number	Make the invoice real?	Save writes the accounting document below and sends the invoice to the customer. Impact: if revenue account determination (VKOA, Prerequisite ⑧) is missing, Save fails and no accounting document is created.

What changes at this exact moment: the builder now owes you and your sales income is booked.

Customer — Karachi Builders Ltd (via recon 160000)	Dr	the builder now owes you (a receivable)
Revenue (via VKOA / account key ERL)	Cr	your sales income is booked

In plain words: the builder now owes you (Dr on the customer), and your sales income is booked (Cr on Revenue). Margin = Revenue − Third-party COGS — the profit for arranging the deal, earned without ever holding a single ton of rebar.

⚠️ You bill from the ORDER, not a delivery — and only after MIRO (the lesson)

A normal sale is billed from the delivery (delivery-related F2). A drop-ship has no delivery — the vendor shipped straight to the customer — so VF01 bills from the sales order (order-related F2). And because TAS billing relevance is F, the order becomes billable only once the vendor invoice (MIRO, 12.4) sets the invoiced quantity. This is the selling-side mirror of account assignment X on the buying side: the whole deal hangs on that one sales order.

Verify: VF03 → the billing document · FBL5N → the builder shows an open receivable · VA03 → the sales order's document flow shows order → PR → PO → (statistical GR) → invoice → billing.

12.6 — Pay the vendor · F-53 (closes the money loop)

⚡ This step will: pay the debt: MUGHAL21's payable clears and the bank shrinks — the money-out side of the deal is closed. 📄 paper: payment document · 📦 stock: no change · 💰 money: Dr Vendor / Cr Bank 113100

Do: F-53 → fill the header → Bank data → Process Open Items → balance 0.00 → Post. Same manual outgoing payment as Scenario 1, Step 5 — it clears the payable MIRO created in 12.4. Tip: type /nF-53 in the command field — the hyphen trips some launchers.

Where on screen · Field	Fill	What it asks (plain words)	Why — and the impact if wrong
Header · Document / Posting Date	today	When did the payment happen / in which period does it post?	Same-day defaults are right. Impact: a date in a closed period is rejected.
Header · Company Code	`PSPK`	From WHOSE books does the cash leave?	PSPK is the company that owes Mughal Steel for the drop-ship. Impact: the wrong company code pays from the wrong books.
Header · Currency	`PKR`	In WHICH money do you pay?	The payable is held in PKR, so pay in PKR. Impact: a wrong currency mis-converts the amount.
Bank data · Account (G/L)	`113100`	From WHICH bank account does the money go out? A G/L account = one line in the books.	113100 is the Bank Main Account — the same one Scenario 1 paid from. Impact: a wrong G/L drains the wrong bank ledger.
Bank data · Amount	Mughal's invoice total (from 12.4)	HOW MUCH leaves the bank?	Matches the vendor payable posted in 12.4 for the 200 TO. Impact: pay less and part stays open; more and Mughal is over-paid.
Open item selection · Account (Vendor)	`MUGHAL21`	WHOSE bill are you paying?	Mughal Steel, the drop-ship vendor whose payable you are clearing. Impact: the wrong vendor shows no matching open item.
Process Open Items · select the invoice	Assigned = Mughal's total · Not Assigned 0.00 🟢	Which exact open item does this cash clear?	MUGHAL21 also carries older items (Sc 9/10/11), so isolate just this drop-ship invoice (see tip below). Impact: if "Not Assigned" ≠ 0, SAP will not let you Post.
Toolbar · Post	note the payment document number	Make the payment real?	Post writes the cash-out and clears the payable. Impact: until you Post, Mughal stays open on the books.

Isolating one item when the vendor has several: MUGHAL21 carries older open items from earlier scenarios. On the Process-Open-Items screen: Select all → Deactivate items (so Assigned = 0), then click Amount and enter this invoice's total — SAP activates just the matching drop-ship item and the balance goes to 0.00. (This "amount search" avoids the fiddly activate button — same trick as Scenario 11.)

What changes at this exact moment:

Vendor MUGHAL21 (AP)	Dr Mughal's total	the payable MIRO created in 12.4 is cleared
Bank Main Account (113100)	Cr Mughal's total	cash leaves the bank — the vendor is square

⚠️ Two money streams — you PAY the vendor, the CUSTOMER pays you (the lesson)

A drop-ship has cash moving both ways. This F-53 is the money-out stream: you pay Mughal Steel and clear its payable, exactly as in Scenario 1. The money-in stream is the mirror on the SD side — the builder settles the receivable that VF01 raised in 12.5, booked as an incoming payment (F-28, Bank Dr / Customer Cr). Your profit is the gap: cash in from the customer minus cash out to the vendor = the trading margin.

Verify: FBL1N → MUGHAL21 → this invoice + payment share one Clearing Document. FBL3N → G/L 113100 shows the cash-out. FBL5N → the builder's receivable stays open until the customer pays (F-28).

🐞 Errors we hit live — and how to fix them

Every row below is a message we actually hit live on PakSteel IDES while building the material, creating the customer, and running the sales order — with the exact fix we applied and the Prerequisite that clears it. The only thing still ahead is the buy-side tail (MIRO → VF01), which we have not posted live yet; the most likely snag there is revenue account determination in VKOA, covered in Prerequisite ⑧.

Where it appears	The message SAP shows	What it means & why it happens	How to fix it
Material — MM01 / VA01	item category `TAN` proposed (sell-from-stock), not `TAS`	The material's item-category group was left at the default NORM, so a normal order tries to sell from stock instead of triggering third-party — no PR is ever created.	Set item category group BANS on the material's Sales: Sales Org 2 view — Prerequisite ②.
Material — MM01 (Sales view, Acct assmt group)	"The account assignment group 01 does not exist"	We tried the generic value `01`; in this system the only valid material account-assignment groups are Z1 (Export) and Z2 (Local).	Use Z2 (Local Customer) — Prerequisite ② / ⑧.
Customer — BP save (Sales tab)	"Sales office" is a required field — fill in all required entry fields (the BP would not save)	The Sales tab made Sales Office mandatory, but sales area `PKSO/10/60` had no sales office assigned, so there was nothing to pick. (Sales offices `0001`/`1000`/`2000` existed in table V_TVBUR — just not linked to our sales area.)	OVXM ("Assign sales office to sales area") → assign sales office `1000` (Export Sales Office) to `PKSO/10/60` — Prerequisite ⑤.
Sales order — VA01	"No pricing procedure could be determined"	OVKK had no row for our sales area + document pricing procedure `A` (order type OR) + customer pricing procedure `01`. The existing PKSO line was `I / 1` — set up for the Scenario 8 inter-company billing, not a normal OR order — so nothing matched and the order couldn't price.	OVKK → new entry `PKSO / 10 / 60 / A / 01 → ZPKINT` (with PR00) — Prerequisite ⑩.
Sales order — VA01 (PR creation inside the order)	"Make an entry in mandatory field Val. Price"	The auto-created third-party PR needs a valuation price — the estimated vendor cost — before it can be saved, and the order carried none.	On the PR item enter the expected purchase price (₨50,000/TO) + desired vendor `MUGHAL21` + purch org `PKLO` — Prerequisite ⑤ / ⑥.
Sales order — VA01 (soft/incompletion warnings)	"Enter Terms of Payment" then "Missing data: Incoterms" (order incomplete)	The customer master had no payment terms or Incoterms in its Billing view, so the order came up incomplete.	Set on the order header (Incoterms EXW Karachi, payment terms 0001); better, maintain both on the customer's Billing tab so every order inherits them — Prerequisite ⑤.

✅ Verification — Confirm Scenario 12 Worked

VA03 → display the sales order → item shows category TAS, and the schedule line shows category CS with the linked purchase requisition / PO.
ME23N → the third-party PO shows account assignment X (Sales Order) and item category S; the Delivery Address tab is the customer's site.
MMBE → TP-REBAR-01 → no stock change at your plant (the goods never entered inventory; the material has no Accounting view).
VF03 / FBL5N → customer billing posted Revenue; MIRO posted Third-party COGS → margin = Revenue − COGS. FBL1N → MUGHAL21 cleared after F-53.

🎓 Interview-Ready Answers

Q: What is item category TAS and how does SAP decide to use it?

TAS is the third-party item category in the sales order. SAP determines it automatically (VOV4) from the sales doc type OR + the material's item-category group BANS. When the line becomes TAS, its schedule line category CS automatically creates a purchase requisition, which purchasing converts into a PO to the vendor. The vendor then ships directly to the customer — you never receive the goods into your own stock.

Q: Why does the third-party PO use account assignment X, and what does that mean for stock?

Account assignment X (sales order) with item category S tells SAP the procurement is for a specific sales order, not for your own inventory. The cost is assigned to the sales order rather than capitalized as stock — so the goods never enter your valuated inventory, and any goods receipt is purely statistical. That's also why the traded material can be created with no Accounting view.

Q: Where do revenue and COGS come from if you never hold the goods, and in what order?

COGS comes from the vendor invoice in MIRO (to a Third-party COGS result on the sales order, vendor credited). Revenue comes from customer billing in VF01 (customer debited, revenue credited via VKOA). Order matters: TAS billing relevance is F, so you must post MIRO first; only then can you bill the customer. The margin is Revenue − Third-party COGS, recognized without any inventory on the balance sheet.

Q: Is the goods receipt mandatory in third-party processing?

No. The GR indicator on the PO can be unchecked to skip GR entirely. If it's on, you can post a statistical goods receipt (via MIGO, not the obsolete MB1A) to record that the vendor confirmed shipment — but it has no stock or financial impact either way, so the vendor-invoice match is only two-way (PO ↔ invoice).

✅ Scenario 12 complete — Third-party drop-ship cycle

← Previous

Scenario 11: Pipeline Material

Scenario 13: Release Strategy