Scenario 8 — Inter-Company STO (PakSteel Karachi → PakSteel Dubai, PSPK → PSAE)
The MM/SD flow below is confirmed live on S/4HANA 2023 (system DEV / client 250): the NB purchase order is recognised as a cross-company STO, VL10B finds it and creates the NLCC outbound delivery (our delivery 80000000), and it picks — end to end. The exact codes we used are in Prerequisites and the "Your live codes" box below.
The whole goods movement is POSTED — both sides. After the FI-basis fixes in Prerequisites ⑤, both goods movements posted live: goods issue at Karachi (mvt 643, material doc 4900423473, stock left PK01) and goods receipt at Dubai (mvt 101, material doc 5000047741, stock arrived at AE01/FNGD). 500 TO of rebar physically moved across the two company codes, with all FI documents posted. The heart of the inter-company STO is done end to end.
The intercompany billing is now PRICED and POSTED too. The seller's invoice (VF01, type IV) determines correctly from the delivery (payer = customer 1100000170) and now carries a real value: billing 90000002 = 75,000,000 PKR (500 TO × 150,000), and it posted to accounting as FI document 3800000000 in PSPK (Dr PakSteel Dubai receivable / Cr Sales revenue 800000). Getting the billing to price and post took a chain of 7 SD-pricing and FI gaps — all documented in Prerequisites ⑥ and rewritten step 8.4. So the whole selling side (Karachi) is complete end to end.
The receiving side (steps 8.6→8.7) is now POSTED too — the whole scenario is complete end to end, both company codes. In PSAE (Dubai): MIRO booked the vendor invoice (5100021698 → FI doc 3600000000: Dr GR/IR / Cr vendor 2100000770), and F-53 paid it (4900000000: Dr vendor / Cr bank 113100). Getting there needed the PSAE-side setup in Prerequisites ⑦ (intercompany vendor as invoicing party + a 0% tax code for country AE). Snag? Troubleshooting Center.
⚠️ One value note for learners: the STO PO was priced at a placeholder 1,000 AED/TO, so the receiving-side documents post at 500,000 AED — this does not equal the selling-side intercompany billing (75,000,000 PKR ≈ 1,000,000 AED). In a real setup you align the STO PO price to the intercompany price (PI01/PR00) so both sides match to the cent. The mechanics are identical either way.
📊 Business Case — When & Why You Use This
An inter-company STO moves material between two plants that belong to different company codes (different legal entities). Because a sale effectively occurs between two legal entities, this is the heaviest standard flow in MM: it pulls in SD (outbound delivery + intercompany billing) and FI (cross-company AR/AP clearing — AR = Accounts Receivable, money owed TO you; AP = Accounts Payable, money you owe), not just MM. Doc Type NB is used, and the goods movement is followed by a real invoice.
🕐 When to use it
One legal entity ships goods to a sister entity — e.g. PakSteel Pakistan (PSPK) sells 500 TO of TMT rebars to PakSteel UAE (PSAE), a separate Dubai LLC in AED. A real sale across legal entities is taking place.
❓ Why it matters
Crossing legal entities means the law and the books require a real transfer of value: a receivable in the seller, a payable in the buyer, intercompany revenue/COGS, and currency conversion (PKR ↔ AED). You can't do this with a simple transfer posting.
👤 Who triggers it
The receiving CC's purchaser raises the NB STO. As the MM consultant you set up the receiving side; an SD consultant handles delivery + intercompany billing; an FI consultant owns the cross-CC clearing (OBYA). OBYA = the FI setting that says, when one company posts against a sister company, which clearing accounts link their books. Your FI consultant owns it; this MM scenario posts without you touching it.
🔁 The key distinction
Different company codes = a real sale. Versus the intra-company STO (Scenario 7) where one company code just shuffles its own stock with zero P&L impact, this flow creates AR, AP, revenue, and COGS across two legal entities.
- 📖 Complete Setup Guide Step 16 (SD Setup for Inter-Co STO) first — 10 sub-steps (16A-16J)
- 🪂 Alternative: Skip this scenario and do Scenario 7 (Intra-Company STO) instead — same MM mechanics, no SD needed
- 👥 Or: Ask your SD consultant to do the setup for you
💰 Financial Impact — The Easy-Money Example
PSPK ships 500 TO of TMT rebars to PSAE for a total of PKR 75,000,000 ≈ AED 1,000,000 at a 75:1 rate. Unlike Scenario 7, money genuinely moves between two legal entities — here is the money story across both sets of books:
The big idea: because the two plants sit in different company codes, the transfer is a genuine intercompany sale: PSPK books a receivable + revenue + COGS, PSAE books inventory + a payable, and the two are squared off later by inter-company netting (F.13 / treasury). Two sides clear in two places: F-53 (step 8.7) clears Dubai's payable — Dubai actually pays. Karachi's matching receivable is cleared later by F.13, an automatic run that offsets "A owes B / B owes A" balances between sister companies so cash needn't move both ways. You don't run F.13 here. This is the opposite of the intra-company STO (Scenario 7), where the same company code just moves its own stock between plants with no P&L impact at all. Crossing the legal-entity boundary is precisely what turns "no accounting" into a full AR/AP + revenue flow with currency conversion.
🇵🇰 The Business Story
🎯 What you'll learn — what makes inter-company STO the most complex flow
- Two CCs involved (PSPK + PSAE) → real AR (sender) + AP (receiver)
- Currency conversion (PKR ↔ AED)
- SD module used — outbound delivery + intercompany billing
- Vendor master in receiving CC = supplying CC's "customer" linkage
- Customer master in supplying CC = receiving CC's "vendor" linkage
- Customs/import implications (Pakistan export, UAE import)
📋 Prerequisites — the hidden gates that make or break this scenario
When our NB PO would not turn into an STO (no "Shipping" tab, it asked for a price & tax like a normal PO, and VL10B found nothing), the cause was never one thing — it was a chain of small setup items across MM, SD and FI that had never been done for the two new company codes. Below is the exact chain we fixed live, grouped ①–⑤. Do these once, in order, and the flow works.
① Make the vendor "stand for" the Karachi plant (the #1 make-or-break)
The goal: make Dubai's purchase order see its "supplier" not as an outside firm, but as our own Karachi plant PK01. Only then does SAP treat the order as an internal stock transfer between our two plants — an STO (Stock Transport Order = moving goods from one of our plants to another) — instead of a normal outside purchase.
Why SAP needs this: a purchase order always buys "from a vendor". But a plant is not a vendor. So to pull stock out of a plant, we first build a vendor master (a supplier record) that points at that plant. SAP reads that pointer and realises: "this vendor is really plant PK01 — so this is an internal move: switch on the Shipping tab and let a delivery be created."
Everyday picture: it's like saving your own warehouse in your phone contacts as if it were a shop. You "order" from that contact, but the system knows it is really your warehouse — so it ships internally instead of buying from outside.
If you skip it: the PO looks normal but silently stays an ordinary purchase — no Shipping tab, it asks for a price and tax, and VL10B finds nothing to deliver. Nothing errors; it just never becomes an STO. That is exactly why this is the #1 trap.
Do these four in order. Every code below is the real value from your live system — type / select exactly these:
| Do this | Exact T-code · where | Exact value (your code) | What it is · why · what breaks without it |
|---|---|---|---|
| 1. Let the vendor's account group even hold a plant | OMSG → account group ZF01 → tick both flags | Plant level relevant + Vendor sub-range relevant | What it is: an "account group" is the template that decides which fields a vendor record shows. Why: out of the box the plant field is hidden on a vendor — these two flags un-hide it. Without it: there is literally no field to type PK01 into later. |
| 2. Flag this vendor itself as plant / VSR relevant | BP 2100000770 → role Supplier → General Data → "Vendor: General Data" tab | tick Plant relevant + VSR relevant → Save | What it is: "VSR" = Vendor Sub-Range (a way to split one vendor by plant or product line). Why: step 1 only allows plant data for the whole group; each vendor must also opt in. Gotcha: these flags sit on General Data, NOT Purchasing Data — the #1 place people look and miss. |
| 3. Extend the vendor to the cross-company purchasing org | BP → Purchasing → Switch Organization → enter the org → set order currency | Purch org GLBL · currency AED | What it is: a "purchasing org" is the buying unit a PO is created under. Why it must be GLBL: the Dubai-local org AELO only reaches plant AE01, so it can't see the Karachi supplying plant. GLBL ("Global procurement") is linked to BOTH PK01 and AE01 (verify in OX17). Without it: the PO can't even name PK01 as its supplier. |
4. Attach supplying plant PK01 to the vendor | BP → Purchasing (org GLBL) → Vendor Subranges tab → Separate Plant → OK → Save | Plant PK01 | What it is: the actual pointer "this vendor = plant PK01". Why: it is the exact link SAP reads to put the supplying plant on the STO. Order matters: PK01 must already be assigned to org GLBL (step 3) or this field rejects it — that is the whole reason GLBL comes first. |
✅ How you'll know it worked: create the NB PO for PK01 → AE01 and a Shipping tab appears on the item line, and VL10B can find that PO. If not, one of the four above is still missing.
② Give the receiving plant a "customer" identity so goods can be shipped to it
The goal: create a customer record that stands for the Dubai plant AE01, living inside Karachi's sales area — so Karachi's shipping team has a real "ship-to" account to deliver against.
Why SAP needs it: making a delivery is an SD (Sales & Distribution) job, and SD only ever ships to a customer. A plant is not a customer. So — exactly like ① turned the supplying plant into a "vendor" — here we turn the receiving plant into a "customer". Same trick, opposite direction.
Everyday picture: your Dubai branch has no shop account in Karachi's system. You open one for it, so Karachi can address the shipment to a real account instead of to thin air.
If you skip it: the outbound delivery has no ship-to and cannot be created — VL10B finds the STO but errors the moment you try to turn it into a delivery.
| Do this | Exact T-code · where | Exact value (your code) | What it is · why · what breaks without it |
|---|---|---|---|
| 1. Create the customer + its sales views | BP role FLCU01 → Sales & Distribution | Customer 1100000170 "PakSteel Dubai" · sales area PKSO / 10 / 60 | What it is: a customer master with the SD views filled in. A sales area = Sales Org (who sells — PKSO) + Distribution Channel (the sales route — 10) + Division (the product family — 60). It's the SD (sales-side) address a delivery and invoice are created under — the sales-side twin of a purchasing org. Why the SAME sales area PK01 uses: the ship-to must live in the supplying plant's sales area, or Karachi's delivery can't find it. Without it: the delivery has no ship-to → cannot be created. |
| 2. Set its shipping condition | Customer → S&D → Shipping tab | Shipping cond. = 01 · delivering plant PK01 | What it is: a code for "how the goods leave" (e.g. standard road freight). Why: it is one of the three inputs the shipping-point search in ④ needs. Without it: blank here = "cannot determine shipping point" later. |
✅ How you'll know it worked: in ④ the shipping point resolves, and VL10B can turn the STO into an NLCC delivery addressed to customer 1100000170.
Each STO config was read directly from its underlying table (not the SM30 view, which filters by "Work Area" and can hide your rows) and confirmed present on our IDES:
- ✅ T001W (shipping data): AE01 → customer
1100000170+ sales areaPKSO/10/60; PK01 → sales areaPKSO/10/60. - ✅ T161V (delivery type):
NB · PK01 → NLCC · checking rule B. - ✅ T161W (document type):
PK01 · AE01 → NB. - ✅ TVSTZ (shipping-point rule, Prereq ④):
ship cond 01 · loading grp Z001 · PK01 → SPK1. - ✅ FI & pricing (Prereqs ⑤–⑦: field status, pricing, recon accounts): confirmed because the whole chain posted live — STO → delivery → GI → GR → intercompany invoice → payment all went through, which is impossible if any of these were missing.
So on your system these are already in place — all required, all present. Rebuilding on a fresh system? This list is exactly what must exist; check each with SE16 on the table shown (not SM30, which can look empty because of the Work-Area filter).
③ Switch on the STO "rulebook" — three config rows that route the transfer
The goal: tell SAP three things so an NB order from PK01 → AE01 knows how to behave — which sales data each plant uses, which delivery type to create, and which PO document type applies to this exact plant pair.
Why SAP needs it: a cross-company STO is stitched together from MM + SD. These three rows are the stitches that connect "purchase order" to "outbound delivery". Without them SAP has all the pieces but no instructions for joining them.
Everyday picture: like telling a courier three things before a pickup — which branch is sending, which shipping service to use, and which order form applies. Miss one and the parcel can't be booked.
If you skip it: the PO won't turn into a delivery ("no delivery type found"), or VL10B simply finds nothing to ship.
Where you do all three: the SPRO folder SPRO → SAP Reference IMG → Materials Management → Purchasing → Purchase Order → Set Up Stock Transport Order — or jump straight to each using the short-code in the "Where" column below (verified live: SM30 views V_001W_IV and V_161V). ⚠️ You maintain these in SPRO / SM30, not in SE16 — SE16 (tables T001W/T161V/T161W) is only for checking the values afterwards.
| Do this (in order) | Where — SPRO activity & how the screen behaves | Exact entry (the fields you fill) | What it does · why it matters |
|---|---|---|---|
| 1. Define Shipping Data for Plants | Fastest route: SM30 → view V_001W_IV ("Stock Transport Order").SPRO tree: Set Up STO → Define Shipping Data for Plants. Either way it opens a list of all plants → click your plant → hit Details (🔍) → a detail screen (plain fields, not tabs). Do it once per plant. Saved to table T001W. |
On receiving plant AE01: field "Customer no. - Plant" = 1100000170, then Sales Org PKSO · Distr. Channel 10 · Division 60.On supplying plant PK01: Sales Org PKSO · DC 10 · Div 60. |
Gives each plant an SD (sales-side) identity. AE01 gets a "customer" face (1100000170) so a delivery can be addressed to it; PK01 gets a sales area so it can issue the delivery. Without it: SAP has no SD data for the plants and can't build the cross-company delivery at all. |
| 2. Assign Delivery Type & Checking Rule | Fastest route: SM30 → view V_161V ("Stock Transfer Data") → Maintain. SPRO tree: Set Up STO → Assign Delivery Type and Checking Rule. Either way it's a grid → New Entries → type one row → Save. Saved to table T161V. |
One row: Supplying plant PK01 · PO type NB → Delivery Type NLCC · Checking Rule B.✅ Verified live: this row is present in table T161V (NB · PK01 → NLCC · B) and it is required — it's what gives the STO its cross-company delivery type. ⚠️ Why SM30 can look "empty": when you open V_161V it first asks for a Work Area and defaults to showing only the standard plants (1000–4000); type supplying plant PK01 in that popup (or read the raw table via SE16 → T161V) to see your row. |
Tells an NB order from PK01 to spawn an NLCC (cross-company replenishment) delivery; checking rule B is the stock availability check it uses. Why it's the proof: when an NLCC delivery shows up in VL10B (step ⑤), you know this row is right. |
| 3. Assign Document Type | SPRO → Set Up STO → Assign Document Type, One-Step Procedure, Underdelivery Tolerance. Opens a grid → New Entries → type one row → Save. (No standalone SM30 view for this one — do it in SPRO; to check the values open SE16 → table T161W. On our IDES the row PK01 → AE01 → NB is present, so this one is used.) |
One row: Supplying plant PK01 · Receiving plant AE01 → Doc type NB. |
Says "for this exact supplying → receiving plant pair, the STO order type is NB", so ME21N proposes the right type automatically instead of you having to know it. |
✅ How you'll know it worked: in ME21N the NB STO (PK01 → AE01) saves without a "no delivery type / no shipping data" error, and in step ⑤ VL10B turns it into an NLCC delivery to customer 1100000170. Quick check in SE16: T161W shows the PK01/AE01 → NB row; T161V shows the PK01 + NB → NLCC row.
④ Let the supplying plant find a "loading dock" (shipping point) — the quietest blocker
The goal: make sure PK01 can work out which shipping point (loading dock) should pack and send the goods. SAP finds it from a small formula: shipping condition + loading group + delivering plant → shipping point.
Why SAP needs it: every delivery is handled by a shipping point — the physical desk/dock that packs and issues the goods. If the formula has no matching row, SAP literally does not know which dock to use, so it refuses to create the delivery.
Everyday picture: "how it ships" (shipping condition) + "what kind of goods" (loading group) + "from which plant" together point to exactly one loading bay. Miss the rule and the system can't pick a bay.
If you skip it: even with ①–③ perfect, the PO errors "Not possible to determine shipping point" and no delivery is ever created.
| Check / do this | Exact T-code · where | Exact value (your code) | What it is · why |
|---|---|---|---|
| 1. Supplying plant has a shipping point | SPRO → Enterprise Structure → Assignment → Logistics Execution → Assign Shipping Point to Plant → find PK01 → tick the shipping point → Save. (Saved to TVSWZ; open SE16 only to check, never to type into.) | PK01 → shipping point SPK1 | What it is: the dock itself. Why: it must exist and be linked to PK01 before the formula can point to it. |
| 2. Material has a loading group at PK01 | MM02 → Sales: General/Plant (or SE16 MARC) | FERT-REBAR-01 · loading group Z001 | What it is: the "kind of goods" input to the formula. Why: blank loading group = no match = no shipping point. |
| 3. Add the determination rule | OVL2 (or SM30 view V_TVSTZ) → New Entries | Ship. cond 01 + loading grp Z001 + plant PK01 → shipping point SPK1 | What it is: the formula row itself — the exact line SAP reads to resolve SPK1. This is the one people forget. |
✅ How you'll know it worked: the NB PO saves without the "cannot determine shipping point" error, and VL10B creates the delivery from shipping point SPK1.
⑤ FI-basis for the new company codes — so the goods movements can POST
The delivery is created after ①–④, but the goods issue (mvt 643, in PSPK) and goods receipt (mvt 101, in PSAE) each create an accounting document. A freshly-created company code usually isn't ready for that yet. We hit these three in PSPK — expect to repeat them for PSAE on the GR side.
| Error you'll see | Fix — exact T-code · where | Exact value |
|---|---|---|
M7 093 "Field selection for mvmt type 643 / account 893010 differs for Business Area" | OB14 (or OBC4) → variant PSPK → field-status group of the account (ours G030, "Change in stock") → group Additional account assignmentsA field-status group is a rulebook that says, for one G/L account, which fields are required / optional / hidden when you post to it (the field-status variant is the whole set of these groups for a company code). | Business Area → Opt. entry (find the account's FSG via SE16 SKB1; the variant via T001) |
NR 751 "Interval 47 / PSPK / 2026 does not exist for object RF_BELEG" | FBN1 → company code PSPK → Change Intervals → Insert Line | NR 47 · year 2026 · from 4700000000 · to 4799999999 (follow the company code's own NN→NNxx pattern) |
GLT2 076 "No item category assigned to account 893010/INT" | SPRO → FA → G/L Accounting → Business Transactions → Document Splitting → Classify G/L Accounts for Document Splitting → chart INTDocument splitting = an S/4HANA feature that breaks each finance document into balanced pieces (by profit centre, segment, etc.). To do that it must know whether each G/L account is an expense, revenue, receivable, etc. — that's the "item category" being classified here. | Add account 893010 → item category 20000 (Expense) (stock-change P&L account) |
⑥ Make the intercompany billing carry value AND post (the SD-pricing + FI chain)
After the goods move (①–⑤), the seller must bill the buyer (step 8.4, VF01, type IV). On a brand-new sales org this is where most people get stuck: the invoice is created but its Net Value is 0, and even once priced it refuses to post to accounting. That is not one bug — it is a chain of seven SD-pricing and FI settings that were never done for the new company code PSPK / sales org PKSO. We fixed every one live; here they are in the exact order the errors appear, in plain steps.
Pricing = 0? In VF01/VF03 open the item → Conditions tab → Analysis button. It shows every condition and says why it found (or didn't find) a price. Won't post to accounting? Save the billing, then run VFX3 (Release Billing Documents to Accounting) → select it → Release to Accounting → Notes/log shows the exact FI error. Fix, then release again — repeat until it posts.
| # | Symptom / error you see | Why it happens (plain words) | Fix — exact T-code · where · value |
|---|---|---|---|
| 1 | Billing saves but Net Value = 0; the pricing Analysis shows no pricing procedure at all | SAP couldn't pick a pricing procedure for sales org PKSO — because the determination table has no row for it. No procedure → no price conditions → zero. | OVKK → New Entries → Sales Org PKSO · Dist.Ch 10 · Division 60 · DocPP I (from billing type IV) · CustPP 1 (from the customer) → procedure ICAA01. DocPP = Document Pricing Procedure (from the billing type); CustPP = Customer Pricing Procedure (from the customer). SAP combines the two to pick which pricing procedure runs. (Find IV's DocPP in SE16 TVFK-KALVG; the customer's CustPP in KNVV-KALKS.) |
| 2 | V1 801 "Mandatory condition PR00 is missing" | The intercompany procedure needs a price. No price record exists for the material in this sales org. | VK11 → condition PR00 → key "Material with release status" → Sales Org PKSO · Dist.Ch 10 · Material FERT-REBAR-01 → 150,000 PKR per 1 TO (= 75,000,000 for 500 TO). |
| 3 | KM 745 "Conditions of category b are not permitted in company code PSPK" | The standard IDES procedure ICAA01 carries a group-valuation condition (KW00) that only works if multi-valuation/transfer pricing is switched on — PSPK doesn't have it. | Don't hack the shared ICAA01. In V/08 use Copy As to make your own ZPKINT ("PakSteel Intercompany"), open its Control data and delete the KW00 line (Group valuation). Then in OVKK change PKSO's row from ICAA01 → ZPKINT. A custom company code should get its OWN pricing procedure — never edit the standard one. |
| 4 | Billing saves "(error in account determination)" — no accounting document | SD found the price, but doesn't know which revenue G/L account to post it to for this sales org. | VKOA → table 005 "Acct Key" → New Entries → Appl V · CndType KOFI · Chart INT · Sales Org PKSO · Acct Key ERL → G/L account 800000 (the standard "Sales revenues"; find what other charts use via SE16 C001). |
| 5 | F5 "G/L account 800000 is not defined in company code PSPK" | Account 800000 exists at chart-INT level but was never extended to the new company code PSPK. | FS00 → account 800000, company code PSPK → With Template → copy from 800000 / company code 0001 (settings: field status G029, tax cat +, currency auto-set to PKR) → Save. |
| 6 | NR "Interval 38 / PSPK / 2026 does not exist for object RF_BELEG" | The billing's FI document type uses number-range interval 38, which PSPK doesn't have for 2026 (this is a different interval than the 47 you added in ⑤ for the goods movement). | FBN1 → company code PSPK → Change Intervals → Insert Line → NR 38 · year 2026 · from 3800000000 · to 3899999999. |
| 7 | GLT2 "There is no item category assigned to account 800000/INT" | Document splitting doesn't know what kind of line the revenue account is. | GSP_LZ2 → chart INT → New Entries → account 800000 → item category 30000 (Revenue). (A revenue account → 30000, NOT 20000/Expense like the stock accounts in ⑤. Save through the "customizing check" warning → confirm the transport request.) |
Fix #1–#3 and VF01 prices to 75,000,000 PKR. Fix #4–#7 (each surfaced by re-running VFX3) and the billing posts: FI document 3800000000 in PSPK — Dr PakSteel Dubai receivable / Cr Sales revenue 800000. Learning: a new sales org needs its pricing-procedure determination + a price + a company-code-safe procedure, and a new company code needs its revenue account created, number-ranged, and split-classified — the SD twin of the ⑤ goods-movement chain.
⑦ The receiving side — book & pay the invoice in PSAE (Dubai)
Now the buyer (PSAE) records the incoming intercompany invoice (MIRO, step 8.6) and pays it (F-53, step 8.7). Because PSAE is a second brand-new company code, it needs its own small setup — the mirror of what PSPK needed. Here's the exact chain we hit and fixed live.
| # | Symptom / error you see | Why it happens (plain words) | Fix — exact T-code · where · value |
|---|---|---|---|
| 1 | MIRO: "PO supplier is not an invoicing party" and "Vendor 2100000770 is not defined in company code PSPK" | MIRO opened in the wrong company code (PSPK). The invoice must be booked by the buyer, PSAE — and the vendor that represents PakSteel Karachi (the "intercompany vendor") lives in PSAE, not PSPK. | Start MIRO and set Company Code = PSAE in the entry popup. The PO's supplier 2100000770 (recon account 160000 in PSAE — reconciliation account = the G/L account that mirrors a vendor/customer subledger into the general ledger) then works as the invoicing party automatically. |
| 2 | Simulate: FF 713 "Tax code I0, country/region AE does not exist in procedure TAXPKN" | The STO PO carried a Pakistan tax code (I0). PSAE's country is AE (assigned to procedure TAXPKN), but no tax code was ever defined for AE — so even the 0% code fails. | FTXP → Country AE → Tax Code I0 → on the rates screen set the Input tax line to 0 → Save. (Creates the missing 0% tax record for Dubai.) |
| 3 | MIRO: "Specify payment period baseline date" | The payment due-date calc needs a baseline date, which didn't default. | MIRO header → Payment tab → Bline Date = invoice date. Tick the item OK, set the header Amount to match (Balance 0.00), then Simulate → Post. |
| 4 | F-53: "An entry is required in Value date field for account 113100" | Postings to a bank G/L account need a value date. | F-53 header → set Value date = payment date on the bank line, then Process Open Items. |
MIRO posted invoice 5100021698 (FI doc 3600000000: Dr GR/IR 500,000 AED / Cr vendor PakSteel Karachi 500,000 AED), and F-53 posted payment 4900000000 (Dr vendor / Cr bank 113100 500,000 AED). PakSteel Dubai has now recorded and paid its payable to PakSteel Karachi. Combined with the seller's booked receivable (step 8.4), the intercompany trade is fully settled on both sets of books. Learning: the buyer's side is a smaller repeat of the seller's — run it in the buyer's company code, give that company code its intercompany vendor + a valid tax code, and the standard MIRO → F-53 does the rest.
FERT-REBAR-01 (FERT, finished) — create steps. First time? the why behind every field.
Goods Receipt · Reference Purchase Order (or the inbound delivery) → mvt 101. The issue side is the SD delivery PGI in VL02N (mvt 643/645), not MIGO. Full guide: MIGO Selection Bar.
- Org structure is built — both company codes
PSPKandPSAEand their plants (Setup Guide). - SD is configured — Sales Org, Distribution Channel, Division, Shipping Point and intercompany billing — Setup Step 16.
- The posting-period and number-range gates are open (this scenario posts goods movements) — Stock-Readiness Checklist.
- PSAE / AE01 have their gates opened up-front — run the 🚀 New Company Code Fast-Track ONCE (mass G/L copy, OMS2, Plant Parameters, periods, number ranges, tolerances) and you skip every error family we met while live-testing Scenarios 5–7.
- Customer master (in PSPK) + vendor master (in PSAE) link the two entities, with plant links via OMGN — BP Guide. (OMGN is the classic all-in-one name for this STO plant setup; on S/4HANA the plant↔vendor/customer links are the ones you build in Prerequisites ①–③ — same result.)
- The material
FERT-REBAR-01exists in both plants — Material Guide.
🔧 Step-by-Step — Transaction Flow (high-level)
| Step | T-code | What it does | Why this step exists |
|---|---|---|---|
| 8.1 | ME21N (NB) | Dubai orders 500 TO from Karachi — cross-company STO | a promise between two legal firms needs a document |
| 8.2 | VL10B | Karachi's warehouse gets its shipping paper | the warehouse needs an order to pick and send |
| 8.3 | VL02N | PGI — stock leaves Karachi's books (643/645) | goods that left must leave the seller's books |
| 8.4 | VF01 (IV) | Karachi bills Dubai — receivable + intercompany revenue | a sale between legal entities needs a real invoice |
| 8.5 | MIGO | Dubai receives — stock ↑ at AE01, GR/IR IOU | goods must be counted in before paying |
| 8.6 | MIRO | Dubai records the bill — real payable to Karachi | the bill must match order and receipt |
| 8.7 | F-53 | Dubai pays — bank ↓, payable cleared | a purchase isn't finished until the vendor is paid |
Every step on this page already uses your real IDES codes. Here they are in one place, so you can glance back without scrolling:
| Item | Your code |
|---|---|
| Supplying plant (Karachi) | PK01 (Karachi Factory) |
| Company codes | PSPK (Karachi, PKR) · PSAE (Dubai, AED) |
| Receiving plant | AE01 (Dubai DC) |
| Vendor representing PK01 (the "supplier") | 2100000770 (PakSteel Karachi) — defined in PSAE, recon 160000 |
| Internal customer (ship-to for AE01) | 1100000170 (PakSteel Dubai) |
| Purchasing org | GLBL — the cross-company org that covers BOTH plants (the Dubai-local AELO is Dubai-only and will NOT work) |
| Sales area (for customer + shipping data) | PKSO / 10 / 60 |
| Delivery type | NLCC (Replen. Cross-Company) · shipping point SPK1 |
| Supplying storage loc (where stock sits at PK01) | FNGD (Finished Goods) — enter it on the delivery's Picking tab |
| Pricing procedure for the IV billing | ZPKINT "PakSteel Intercompany" — our copy of ICAA01 with the group-valuation condition removed (see Prereq ⑥). OVKK points PKSO/10/60 + DocPP I + CustPP 1 → ZPKINT. |
| Price condition + rate | PR00 = 150,000 PKR / TO (× 500 = 75,000,000) · revenue account key ERL → G/L 800000 "Sales revenues" |
| Material transferred | FERT-REBAR-01 · 500 TO |
| Your live documents | STO PO 4500032782 → delivery 80000000 → GI mat.doc 4900423473 · GR mat.doc 5000047741 · intercompany billing 90000002 (75,000,000 PKR) → FI doc 3800000000 · MIRO 5100021698 (FI 3600000000) · payment 4900000000 |
| Values in PKR (₨75,000,000) | AED on the Dubai side (material price ≈ 4,600/TO) |
8.1 — Receiving plant creates STO · ME21N doc type NB
⚡ This step will: turn the transfer plan into a binding cross-company order — Dubai (AE01) starts showing the 500 TO as On-Order (a promise, not stock), and because two legal entities are involved this order must end in a real invoice. 📄 paper: purchase order (STO, type NB) · 📦 stock: no change · 💰 money: no posting
PSAE creates a PO with PSPK's plant PK01 as "supplier" (Vendor = vendor master of PSPK linked via OMGN). The buyer is Dubai — so everything here is filled from PSAE's side.
The ME21N screen has 3 zones — know them and every field finds itself: ① the Header (top: doc type, vendor — with header tabs like Org Data, holding purch org / group / company code, below it), ② the Item overview grid (one ROW per material — code, quantity, plant, storage location), ③ the Item detail tabs (bottom: Material Data · Quantities · Delivery · Conditions · Texts — always 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 |
|---|---|---|---|
| Header · Doc Type | NB | Which pad of order forms is this? Like picking the right pre-printed form for the job | Crossing two company codes = a real purchase between two separate legal firms, so the standard buying pad NB is used — the flow must end in a real invoice. Impact: pick UB (Scenario 7, for moves inside ONE company code) and SAP expects no invoice, so the cross-company bill to Dubai would have nothing to hang on |
| Header · Vendor | vendor 2100000770 (represents PSPK / PakSteel Karachi) | Who is the seller? | The seller is your own sister company, entered like any supplier through the vendor master that stands for PSPK (the plant↔vendor link from OMGN, see Prerequisites). Impact: to Dubai's books PakSteel Karachi is simply "a vendor"; without this vendor master the STO cannot name who it buys from |
| Header → Org Data tab · Purch Org | GLBL (cross-company) | Which buying desk is purchasing? | Live gotcha: use the cross-company purchasing org GLBL — it is assigned to BOTH the Karachi supplying plant PK01 and the Dubai receiving plant AE01. The Dubai-local org AELO only reaches AE01, so the vendor can't carry PK01 there and the PO never becomes an STO. Impact: wrong org here = the #1 reason the NB PO silently stays an ordinary purchase order (see Prerequisites ①). |
| Header → Org Data tab · Company Code | PSAE | Which legal entity is buying? | The receiving company. Impact: drives which books carry the cost/payable. |
| Header → Org Data tab · Purch Group | 001 | Which buyer/team is responsible? | Any valid purchasing group. Impact: only misfiles who follows up; no accounting effect. |
| Item grid · Material | FERT-REBAR-01 | What is Dubai buying? | The finished rebar being transferred. Impact: the material must also exist in the receiving plant AE01 — each plant reads its own copy of the material record; if AE01 has no copy, the line cannot be entered |
| Item grid · Qty | 500 TO | How much? | 500 tonnes is the agreed transfer quantity (₨75,000,000 of goods). Impact: the quantity drives the delivery, the goods issue and the billing value downstream — key it wrong and every later document is wrong |
| Item grid · Plant | AE01 (receiving) | Where should the goods LAND? | The Dubai plant that will receive the stock. Impact: the wrong plant sends the rebar to the wrong site's stock |
| Item grid · SLoc | EXPT | Which exact store room inside that plant? | The storage location within AE01. Impact: a wrong store room only misplaces the stock inside the right plant — easy to move later, but it can hide the goods from the team expecting them |
Save.
8.2 — Supplying plant creates outbound delivery · VL10B or VL10G
⚡ This step will: create the shipping paper on Karachi's side — PK01's warehouse now has a document telling it to pick and send the 500 TO; the goods themselves have not moved yet. 📄 paper: outbound delivery · 📦 stock: no change · 💰 money: no posting
SD takes over — PSPK's shipping point creates outbound delivery referencing the STO. An outbound delivery = the shipping side's own document: "these goods are to be sent out." The STO said what to ship; the delivery organizes the actual sending.
VL10B is a "worklist" screen — 2 zones: ① the selection area at the top (shipping point + a date range, with tabs like Purchase Orders for the STO number), and ② the results list below, where the due STOs appear and you turn them into deliveries.
| Where on screen · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Selection · Shipping Point | PK01's shipping point SPK1 | Which loading dock packs and sends? | A delivery is always created for a shipping point — the desk that processes outbound goods. Impact: wrong/blank shipping point and the worklist finds nothing, or uses the wrong dock. |
| Selection · Deliv. Creation Date (to) | a date on/after the STO delivery date | Show orders due for shipping up to WHEN? | VL10B lists only STOs whose delivery is due by this date. Impact: too-early a date and your STO isn't "due yet", so it never appears. |
| Purchase Orders tab · Purchase Order | the STO number from 8.1 | Which order do I want to ship? | Narrows the worklist straight to your STO. Impact: leave it blank and you scroll a long list of everyone's due orders. |
| Toolbar · Execute (F8) | click | Run the worklist | Shows your STO line as "due for delivery". |
| Results list · select the line → click Dialog (or Background) | tick the row → Dialog | Create the delivery now | Dialog opens the delivery so you can review; Background creates it silently. Impact: nothing ticked = nothing created. |
| Result | outbound delivery # (ours was 80000000), type NLCC | — | The shipping paper — type NLCC proves the cross-company config worked. Impact: an error "no item category" / "no shipping point" means the material's Sales views or the shipping-point assignment is missing. |
8.3 — Post Goods Issue from delivery · VL02N
⚡ This step will: push the goods OUT of Karachi — the PGI click makes the stock leave PSPK's books, and the seller's first money document posts. 📄 paper: material + accounting document · 📦 stock: ↓ at PK01 · 💰 money: Dr COGS / Cr Inventory (at PSPK)
VL02N = change the delivery, then post the goods issue. The delivery already carries the material, quantity and plant from 8.2 — you're just confirming the goods left.
| Where on screen · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Initial screen · Outbound Delivery | the delivery # from 8.2 → Enter | Which delivery are you shipping? | Opens your delivery for change. Impact: wrong number = wrong goods shipped. |
| Picking tab · Storage Location | FNGD (Finished Goods, at PK01) | From which store room do the goods leave? | Live gotcha: our delivery item came through with a blank storage location, and PGI failed with "storage location not defined for item 000010". Type the SLoc where the stock actually sits (we posted 561 stock into FNGD). Impact: blank = PGI cannot find the stock to issue. |
| Picking tab · Picked Qty | 500 TO | How much is picked and ready to leave? | The delivery is picking-relevant, so PGI is blocked until picked qty = delivery qty. Enter 500, then Save. Impact: pick less and PGI won't post the full amount. |
| Header · Actual GI Date | today's date | On what date did the goods physically leave? | Becomes the posting date of the material + accounting documents. Impact: a date in a closed period is rejected. |
| Toolbar · Post Goods Issue | click | Have the goods left the building? | The hand-over click — stock leaves PSPK now and mvt 643 posts automatically (the cross-company GI; you don't type it). Impact: until you click this, nothing has actually moved. |
Accounting at supplying CC PSPK:
| Cost of Goods Sold (500000) | Dr | — |
| Inventory FERT (302000) | Cr | — |
This GI creates an accounting document in the new company code PSPK, so we hit three FI errors in turn — each a one-time fix (see Prerequisites ⑤): M7 093 field-status (Business Area → Optional, OB14); NR 751 missing FI number range (interval 47/2026, FBN1); GLT2 076 document-splitting classification (classify account 893010 as Expense via GSP_LZ2). After those, PGI posted — material document 4900423473. A company code set up with the Fast-Track sees none of these.
8.4 — Intercompany Billing · VF01 (priced + posted live)
⚡ This step will: write the real bill from Karachi to its sister company — a receivable and intercompany revenue appear in PSPK's books; no goods move here. 📄 paper: intercompany billing doc (type IV) + accounting document · 📦 stock: no change · 💰 money: Dr Customer / Cr Sales Revenue (at PSPK)
This is the step where the whole SD-pricing + FI chain (⑥) pays off. If you skip it, VF01 creates a billing with Net Value 0 and later refuses to post to accounting. Set up ⑥ (pricing procedure ZPKINT, price PR00, revenue account, number range, splitting), THEN run this step.
| Where on screen · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Initial screen · Document | the outbound delivery # from 8.2 (ours 80000000) → Enter | What am I billing? | The invoice is built from the delivery — you bill what actually shipped, not what was ordered. Impact: billing the STO or a wrong document gives the wrong basis. |
| Item · Billing Type | IV (proposed automatically) | Which KIND of invoice is this? | IV = intercompany billing — books real revenue in PSPK even though the buyer is a sister company. It's proposed by the copy-control rule NLCC → IV. Impact: a customer type like F2 posts to the wrong flow. |
| Header · Billing Date | today's date | What is the invoice date? | Drives the FI posting date and the PKR↔AED exchange rate used. Impact: a closed-period date is rejected. |
| Item → Conditions · Net Value | confirm it shows 75,000,000 PKR (price PR00 = 150,000 × 500 TO) | At what price does Karachi bill Dubai? | The intercompany transfer price, from the PR00 record you made in ⑥. Impact: if it's 0, the pricing procedure or price is missing — open Conditions → Analysis to see which, then fix in ⑥. |
| Toolbar · Save | → billing doc 90000002 | Commit the invoice | Creates the billing. Note: on a new company code the accounting document may NOT post immediately ("error in account determination" / "no journal entry generated") — that's normal here; you release it next. |
| Release to accounting · VFX3 | enter Sales Org PKSO + the billing doc → Execute → select it → Release to Accounting | Push the invoice into Finance | Each time it fails, the Notes/log names the exact FI gap (⑥ #4–#7). Fix, release again. When it posts you get the FI document and posting status turns to "C" (green). |
Accounting at supplying CC PSPK (our live FI document 3800000000):
Customer — PakSteel Dubai (1100000170) | Dr 75,000,000 PKR | the receivable (AR) |
Sales Revenue (800000) | Cr 75,000,000 PKR | intercompany revenue |
On our IDES this billing first priced to 0 (no pricing procedure for PKSO), then — once priced to 75M — refused to post through four more FI gaps in a row (revenue account not assigned → not in company code → number range 38 missing → not classified for splitting). We fixed each one, re-ran VFX3, and it finally posted as FI document 3800000000. Every gap + fix is in Prerequisites ⑥. That completes the selling side end to end. A company code prepared with the Fast-Track plus its SD pricing set up in advance sees none of this.
8.5 — Receiving plant: GR · MIGO
⚡ This step will: bring the goods IN at Dubai — AE01's shelf fills with real valuated stock, and the buyer's first money document posts (in AED). 📄 paper: material + accounting document · 📦 stock: ↑ at AE01 · 💰 money: Dr Inventory / Cr GR/IR (at PSAE)
PSAE (Dubai) receives the rebar at plant AE01 — a normal PO goods receipt, because to Dubai this really was a purchase from another company.
Do: MIGO → set the two top-left dropdowns → load the STO → 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 · Partner · 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 — receiving, issuing, transferring? | Stock is arriving from Karachi → Goods Receipt. Impact: the wrong action shows the wrong screen and the wrong movement types. |
| Header (top) · Dropdown 2 (Reference) | Purchase Order + the STO number from 8.1 → Enter (or the inbound delivery, if one was created) | Against WHICH document is this receipt? | The STO brings the material, the 500 TO and the price with it — you type almost nothing. Impact: no reference = a manual "other" receipt with none of the STO's data and no matching later. |
| Header (top-right) · Movement Type | 101 (auto) | Which KIND of movement is this? | 101 = goods receipt for a PO — proposed automatically. Leave it. |
| Item overview grid · Qty in UnE column | 500 TO (proposed) | How much actually arrived at Dubai? | Reduce it if the truck brought less. Impact: confirming more than arrived puts stock on Dubai's books that is not really there and breaks the invoice match in 8.6. |
| Header → General tab · Delivery Note | a reference (we used the outbound delivery 80000000) | What is the shipping paper number? | Live gotcha: our config made this field required — Post failed with "Enter Delivery Note" until filled. Impact: blank = cannot post. |
| Item detail → Where tab · Storage Location | FNGD (AE01 has EXPT/FNGD/VPK1) | Where should the stock be put? | We received finished rebar into FNGD (Finished Goods) at AE01. The field on the Where tab accepts the code directly. Impact: blank = post fails "storage location not defined". |
| Item overview grid · ☑ Item OK column | ✅ tick | Do you confirm THIS line? | Impact: forget the tick and Post fails with "no items selected" — the #1 MIGO beginner error. |
| Toolbar (top) · Check → Post | lights green → Post → note the material document number | Any problems before it becomes real? | Check simulates first; Post writes the material + accounting documents. |
What changes at this exact moment: 500 TO of FERT-REBAR-01 now sit in AE01's valuated stock (real inventory on Dubai's books). The posting below fires — GR/IR (Goods Receipt / Invoice Receipt clearing) is a holding account: filled when goods arrive, emptied when the invoice is booked — a "received it but not yet billed" tray. Here it is the "we owe Karachi" tray, parked until the invoice in 8.6.
Accounting at receiving CC PSAE: (converted to AED)
| Inventory FERT (300000) | Dr 1,000,000 AED |
| GR/IR (191100) | Cr 1,000,000 AED |
(Teaching value shown = 1,000,000 AED, the aligned intercompany price; your live documents post at 500,000 AED because the STO used a placeholder rate — see the value note in the banner at the top.)
This GR posts in the receiving company code PSAE — a brand-new company code — so it surfaced two one-time gaps: (1) G/L account 281500 (needed by the cross-company GR) didn't exist in PSAE → created it in FS00 (copied from company code 0001, since it existed in no other CC); (2) that account then needed a document-splitting classification → GSP_LZ2 → 281500 → 20000 (Expense) (it's a P&L account — check with SE16 SKA1, XBILK blank). After both, the GR posted: 500 TO into AE01/FNGD. Lesson: a new receiving company code needs its G/L accounts created + classified for splitting before it can receive stock — one-time Fast-Track work.
In an intra-company STO (Scenario 7, doc type UB, one company code) stock just slides between two plants — movement 351 one-step, or 641→101 two-step — with no invoice and no money. Here the transfer crosses TWO company codes, so this 101 books real valuated inventory + a GR/IR liability, and an invoice (8.6) must follow. The seller already shipped the stock out at 8.3 (mvt 643/645 → COGS); this 101 brings the same goods in on Dubai's side.
Verify: MMBE → FERT-REBAR-01 shows +500 TO at AE01/EXPT · ME23N → the STO → Purchase Order History tab shows the GR line · MB51 lists the 101 movement.
8.6 — Receiving plant: Invoice · MIRO
⚡ This step will: record the sister company's bill in Dubai — the GR/IR IOU from 8.5 clears and a real debt to the PSPK vendor appears. 📄 paper: invoice document · 📦 stock: no change · 💰 money: Dr GR/IR / Cr Vendor (at PSAE)
PSAE books the vendor invoice against the STO — the paper bill it matches is PSPK's intercompany billing document (type IV) from 8.4.
The #1 gotcha: MIRO defaults to the last company code you used (PSPK for us). If you leave it, you get "PO supplier is not an invoicing party" and "Vendor 2100000770 is not defined in company code PSPK." The invoice belongs to the buyer, PSAE — set Company Code = PSAE in the MIRO entry popup, and the vendor 2100000770 (defined in PSAE, recon 160000) works as the invoicing party. PSAE also needs a 0% tax code for country AE (Prereq ⑦ #2) or the simulate fails. Do ⑦ first, then this step posts.
Do: MIRO → set Company Code PSAE → invoice date + Reference (the seller's billing 90000002) → PO Reference tab → the STO number → Enter → tick item OK, set header Amount to match → Payment tab: Bline date → check Balance 0.00 → Simulate → Post:
| Field | Fill | What it asks (plain words) | Why — and the impact if wrong |
|---|---|---|---|
| Header · Basic Data tab · Invoice Date | the date on PSPK's billing document | When did the seller write this bill? | Drives the payment/due date. Impact: a wrong date shifts when Dubai's payable falls due. |
| Header · Basic Data tab · Reference | PSPK's intercompany billing doc number (from 8.4) | What number does the SELLER call this bill? | The audit trail between the two sister companies' books. Impact: without it, matching PSAE's payable to PSPK's receivable later is painful. |
| Allocation area · PO reference tab · Purchase Order | the STO number → Enter | Which purchase is being billed? | Loads the line: 1,000,000 AED expected from the 8.5 GR (teaching value; your live document posts at 500,000 AED — see the value note in the top banner). Impact: no reference = no three-way match protection (the invoice must agree with the PO and the goods receipt on both quantity and price). |
| Header · Basic Data tab · Amount | 1,000,000 AED | What is the TOTAL on the seller's bill? | SAP compares it with what the STO + 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 the STO and the GR? | Zero = the three-way match agrees → Post. Impact: a red balance means qty or price differs — check before forcing it. |
What changes at this exact moment: the GR/IR tray from 8.5 is emptied and a real payable to the PSPK vendor is created on Dubai's books. Now PSPK carries the receivable (its AR, booked in 8.4) and PSAE carries the payable (its AP) — the two sister firms owe / are owed.
Accounting at receiving CC PSAE (our live FI doc 3600000000, at the STO PO price 500,000 AED — see the value note in the top banner):
| GR/IR clearing (191100) at PSAE | Dr 500,000 AED |
Vendor — PakSteel Karachi (2100000770, recon 160000) | Cr 500,000 AED |
Booked in company code PSAE against STO PO 4500032782. The intercompany vendor 2100000770 resolved as the invoicing party once MIRO ran in PSAE, and the AE 0% tax code from Prereq ⑦ let it simulate to Balance 0.00. GR/IR cleared, payable to Karachi created.
An intra-company STO (Scenario 7, doc type UB) has no delivery billing and no MIRO — stock just moves and no money changes hands. Here the move is a real sale between two legal firms, so PSAE must record a real invoice, mirroring PSPK's intercompany billing (type IV, 8.4).
Final settlement: Periodic inter-company netting via F.13 or treasury — AR in PSPK matched against AP in PSAE.
Verify: FBL1N → the PSPK vendor shows an open payable in PSAE · ME23N → the STO → Purchase Order History shows the invoice line · the STO now reads fully delivered + invoiced.
8.7 — Pay the vendor · F-53 (PSAE pays PSPK)
⚡ This step will: pay the debt — the PSPK vendor's account in PSAE clears and Dubai's bank shrinks by AED 1,000,000. 📄 paper: payment document · 📦 stock: no change · 💰 money: Dr Vendor / Cr Bank (at PSAE)
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 | PSAE | WHOSE books release the cash? | PSAE (Dubai) carries the payable to PSPK, so Dubai's books pay — in AED. Impact: the wrong company code pays from the wrong legal entity. |
| Bank data · G/L Account + Amount | 113100 · 1,000,000 AED | From WHICH cash account, and HOW MUCH leaves? | 113100 = Bank Main Account (same INT chart as Scenario 1), here PSAE's AED bank; AED 1,000,000 is the full payable from 8.6. Impact: a wrong account or amount leaves a balance that will not post. |
| Open Item Selection · Account (vendor) | the PSPK supplier vendor 2100000770 | WHOSE unpaid bills are we clearing? | In PSAE's books PakSteel Karachi is simply a vendor; this is the open payable booked in 8.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: AED 1,000,000 leaves Dubai's bank and the PSPK supplier's account in PSAE goes to zero; the invoice's open item flips to CLEARED:
Vendor payable — PakSteel Karachi (2100000770) at PSAE | Dr 500,000 AED | the payable is cleared |
Bank (113100) at PSAE | Cr 500,000 AED | AED cash leaves Dubai's bank |
In company code PSAE: F-53 → bank 113100, amount 500,000 AED, Value date required (Prereq ⑦ #4) → Process Open Items → the MIRO invoice (FI doc 3600000000) selected, Not assigned 0.00 → Post. Vendor 2100000770's payable in PSAE is now cleared — the intercompany trade is fully settled on both sides.
This is the intercompany twist. The payable lives in PSAE (Dubai, AED), booked against the PSPK supplier vendor in 8.6 — so PSAE pays, from its own AED bank, in its own books. On the vendor the step is the same F-53 as Scenario 1: Vendor Dr / Bank Cr. PSPK's matching receivable (its AR from 8.4) is squared separately by the periodic inter-company netting (F.13) noted in 8.6 — you do not clear both sides here.
Verify: FBL1N → the PSPK supplier vendor in PSAE → no open payable left (cleared). Full F-53 walkthrough with every field: Scenario 1.
🐞 Errors we hit live — and how to fix them
An inter-company STO touches MM, SD and FI, so a fresh pair of company codes throws a lot of messages. Here are the exact messages we hit, roughly in the order they appear, with what each means, why it happens, and the fix — linked to the Prerequisite that clears it. Learning to read these messages is half of becoming an SAP consultant.
| Where it appears | The message SAP shows | What it means & why it happens | How to fix it |
|---|---|---|---|
| PO — 8.1 (ME21N NB) | no "Shipping" tab; the PO asks for price/tax like a normal order; VL10B finds nothing | Not a red error — a symptom. SAP treats an NB PO as a cross-company STO only if the vendor carries a supplying plant. Without that link it stays an ordinary purchase. | Make the vendor "stand for" the supplying plant — Prerequisite ①. |
| PO — 8.1 | "Not possible to determine shipping point" | SAP can't work out which loading dock ships the goods — the formula (shipping condition + loading group + plant → shipping point) has no matching rule. | Add the shipping-point rule — Prerequisite ④. |
| PGI — 8.3 (VL02N, mvt 643) | "M7 093 — Field selection for movement type 643 / account 893010 differs for Business Area" | The goods-issue posting and its stock-change account disagree on whether Business Area is required — a field-status mismatch on a new company code. | Make Business Area optional on the account's field-status group — Prerequisite ⑤ (OB14). |
| PGI — 8.3 | "NR 751 — Interval 47 / PSPK / 2026 does not exist for object RF_BELEG" | The FI document can't get a number — the number-range interval (47) for this company code + year doesn't exist yet. | Create the interval — Prerequisite ⑤ (FBN1). |
| PGI — 8.3 | "GLT2 076 — No item category assigned to account 893010/INT" | Document splitting doesn't know what kind of line the stock-change account is, so it can't split the FI document. | Classify the account for document splitting — Prerequisite ⑤ (GSP_LZ2). |
| Billing — 8.4 (VF01 IV) | Net Value = 0; pricing Analysis shows "no pricing procedure" | SAP couldn't pick a pricing procedure for the new sales org, so no price conditions ran → the invoice is worth nothing. | Add the pricing-procedure determination — Prerequisite ⑥ (OVKK). |
| Billing — 8.4 | "V1 801 — Mandatory condition PR00 is missing" | The procedure needs a base price, but no PR00 price record exists for the material in this sales org. | Create the PR00 price — Prerequisite ⑥ (VK11). |
| Billing — 8.4 | "KM 745 — Conditions of category b are not permitted in company code PSPK" | The standard IDES procedure ICAA01 carries a group-valuation condition (KW00) that PSPK isn't switched on for. | Use your own procedure ZPKINT (copy of ICAA01 with KW00 removed) — Prerequisite ⑥. |
| Billing → FI — 8.4 (VFX3) | "error in account determination", then "G/L account 800000 is not defined in company code PSPK" | SD found the price but doesn't know which revenue account to post to — and that account isn't extended to PSPK. | Assign the revenue account (VKOA) and create 800000 in PSPK (FS00) — Prerequisite ⑥. |
| Billing → FI — 8.4 | "NR — Interval 38 / PSPK / 2026 does not exist" · "GLT2 — no item category assigned to 800000/INT" | The billing's FI document needs number-range 38, and the revenue account needs split-classification — both missing on the new company code. | FBN1 interval 38 + GSP_LZ2 classify 800000 as Revenue — Prerequisite ⑥. |
| GR — 8.5 (MIGO 101) | G/L account (281500) does not exist / not classified in PSAE | The receiving company code PSAE is also new, so an account the cross-company GR needs isn't set up or split-classified there. | Create 281500 in PSAE (FS00, from 0001) + classify it (GSP_LZ2) — see the 8.5 live note / Prerequisite ⑦. |
| MIRO — 8.6 | "PO supplier is not an invoicing party" · "Vendor 2100000770 is not defined in company code PSPK" | MIRO opened in the wrong company code. The invoice belongs to the buyer (PSAE), and the intercompany vendor lives in PSAE, not PSPK. | Run MIRO with Company Code = PSAE — Prerequisite ⑦. |
| MIRO — 8.6 | "FF 713 — Tax code I0, country/region AE does not exist in procedure TAXPKN" | PSAE's country is AE, but no tax code (not even a 0% one) was ever defined for AE. | Create tax code I0 for country AE at 0% — Prerequisite ⑦ (FTXP). |
| MIRO — 8.6 | "Specify payment period baseline date" | The payment due-date calc needs a baseline date that didn't default. | Set the Baseline (Bline) date on the Payment tab — Prerequisite ⑦. |
| Payment — 8.7 (F-53) | "An entry is required in Value date field for account 113100" | Postings to a bank G/L account need a value date. | Set the Value date on the bank line — Prerequisite ⑦. |
✅ Verification — Confirm Scenario 8 Worked
Our live document numbers are shown so you can see exactly what "done" looks like.
- Stock moved: MMBE → FERT-REBAR-01 → 500 TO left PK01/FNGD (PSPK), arrived AE01/FNGD (PSAE) · MB51 shows the 643 issue (mat.doc
4900423473) and 101 receipt (mat.doc5000047741). - Goods issue posted: VL03N → delivery
80000000shows Goods Issue complete. - Billing priced + posted: VF03 → intercompany billing
90000002, type IV, Net Value 75,000,000 PKR → its accounting document is3800000000(FB03): Dr customer 1100000170 / Cr revenue 800000. - Seller's receivable: FBL5N → customer
1100000170(PakSteel Dubai) shows the open 75,000,000 PKR receivable in PSPK. - STO status: ME23N → STO
4500032782→ Purchase Order History shows the delivery, GI, GR and (after 8.6) the invoice. - Receiving side — posted: MIR4 → invoice
5100021698(FI doc3600000000) in PSAE · FB03 → payment4900000000· FBL1N → vendor2100000770in PSAE shows the payable created by MIRO and cleared by F-53 (no open item left).
🎓 Interview-Ready Answers
Q: How does an inter-company STO differ from an intra-company STO?
Intra-company (Doc Type UB) moves stock between two plants in the same company code — no invoice, no AR/AP, no P&L. Inter-company (Doc Type NB) moves stock between plants in different company codes, so it's a real sale: SD posts an outbound delivery and an intercompany billing document (type IV), the seller books a receivable + revenue, and the buyer books inventory + a payable, often across currencies.
Q: Which modules are involved and who owns each part?
It's an MM ↔ SD ↔ FI flow. MM (you) sets up the receiving side — the NB STO and the vendor/customer links via OMGN. SD handles the outbound delivery (VL10B), PGI (VL02N), and intercompany billing (VF01, type IV). FI owns the cross-company clearing configured in OBYA and the periodic netting (F.13).
Q: Why are customer and vendor master records needed for a stock transfer?
Because the transfer crosses legal entities, SAP treats it like a customer-vendor transaction. The supplying CC needs the receiving CC represented as a customer (BP role FLCU01) so SD can bill it; the receiving CC needs the supplying CC represented as a vendor (BP role FLVN01) so MM can raise the NB PO and post the invoice. The plant-to-customer and plant-to-vendor links are made in OMGN.
Q: How is the AR in the seller eventually matched against the AP in the buyer?
Through periodic inter-company netting / clearing — typically F.13 (automatic clearing) or a treasury settlement run — which offsets the receivable booked in PSPK against the payable booked in PSAE. The cross-company posting relationships are pre-configured in OBYA.