🔧 Troubleshooting Command Center

Where: MIGO, MIRO, or any posting whose date falls outside the open Materials Management (MM) period.

Cause (plain words): MM only lets you post into the current open month (and, if allowed, the one before). MM keeps its own period clock, separate from Finance (FI). If the clock is still on an old month, today's posting is refused. Door analogy: MM keeps exactly one door open at a time.

Fix:

1. MMRV — check which MM period is currently open.
2. MMPV — roll forward, one month at a time in sequence (you cannot jump). Enter company code + year, and in the Period field type the NEW month you want to OPEN (entering 07 means “make July the open month”; it closes the old month automatically and leaves it postable as the previous period).
3. Choose the radio “Check and close period” (the safe default). The three options: Check period only = a rehearsal that changes nothing; Check and close period = verify then turn the page (use this); Close period only = skips the safety checks (avoid).
4. Also confirm OB52 has the FI period open for that date — a closed FI period blocks the accounting document even when MM is open.

First posting ever in a company code? The MM clock must first be initialized once with OMSY.

Prevent it: Stock Readiness — Posting periods (OMSY · MMRV · MMPV · OB52)

Where: MIGO, when receiving stock for a material type that is switched off in this plant.

Cause (plain words): every material type (ROH, HALB, FERT…) has Quantity updating and Value updating switches per valuation area (plant). If they are off, that type cannot hold stock there — like a warehouse licensed for raw iron but not for semi-finished billets.

Fix: OMS2 → the material type (e.g. HALB) → Quantity/value updating → the valuation area (plant) → tick Qty + Value → Save (Customizing request). Turning Value updating on for a material that never had it can then trigger C+470 — repair the Material Ledger link next.

Prevent it: Stock Readiness — Gate 2 (OMS2 quantity/value updating)

Where: MIGO, the first valuated movement for a material after value updating was switched on.

Cause (plain words): in S/4HANA the Material Ledger is mandatory — every valuated material needs an ML record (its “price card”). Switching on value updating for a material that never had one leaves it disconnected, so SAP cannot value the stock and blocks the movement.

Fix (ladder — live-tested on S/4HANA 2023, try in order):

1. Confirm the Material Ledger is active for the plant: OMX1.
2. The screen route: MM02 (not MM03 — display is always grey) → Accounting 1 → Price Determ. If open and empty: type 2 → Save (re-saving the view issues the missing ML record). If grey in MM02: check OMX1 → the valuation area's "Price Determination Binding" checkbox — untick, then retry MM02.
3. The repair report — note the two spellings (⭐ live-confirmed on our S/4HANA 2023): SE38 → FML_REPAIR_ML_MASTERDATA (the S/4HANA name, with the leading F — this one existed and repaired our material in both plants; the ECC-era spelling ML_REPAIR_ML_MASTERDATA did NOT exist). Run with Material + Plant (valuation area); afterwards MM03 → Accounting 1 shows ML Act. ✓ and Price Determ. filled from OMX1's default. Also try SE38 F4 with *ML_MASTERDATA*. If Price Determ. arrives as 3 and you need 2 → CKMM.
4. The Help Desk (standard in S/4HANA since 1610): transaction FCMLHELP (older twin: CKMHELP) → repair MLHELP_REPAIR_TABLES rebuilds CKMLHD/CKMLPR/CKMLPP/CKMLCR. Repairs are locked to test mode: unlock (SANDBOX ONLY — officially reserved for SAP Support) via SU3 → Parameters → DONTPANIC = today's date, then =42 in the command field on the report's selection screen. Never on a real system — there, open an SAP incident (component CO-PC-ACT).
5. The practice-system escape (guaranteed): once all gates are open (OMS2, G/L accounts), a NEW material created today gets its ML record automatically at creation. Create a replacement via MM01 copy-from, swap it on the open document (ME22N), and continue — repair the broken material later, or never.
6. A whole valuation area that never started ML: FCML4H_STARTUP (older systems: CKMSTART).

After a successful repair, expect one more "G/L account … does not exist" (M7 055) — and possibly for a different account than any demanded before: while the material was broken, account determination fell back to a generic OBYC row; the healed material uses its true valuation-class row. Open the newly named drawer in FS00 (With Template) and the posting goes through.

Prevent it: Stock Readiness — Gate 4 (Material Ledger connection) — and always open the OMS2 gates BEFORE creating materials of a new type in a plant.

Where: MIGO / MIRO — the value posting cannot find which G/L account to hit.

Cause (plain words): automatic account determination (OBYC) has no G/L mapped for this combination of transaction key (BSX inventory, WRX GR/IR, GBB offsetting, PRD price difference, FR1–FR4 freight/duty…) + valuation grouping code + valuation class. SAP knows the movement but not the account to post to.

Fix:

1. Read the error — it names the exact key and valuation class.
2. OBYC → double-click that transaction key → enter your chart of accounts → fill the G/L account for the valuation class shown → Save → re-post.
3. If the valuation grouping code in the key looks blank/wrong, check it is active (OMWM) and assigned to the valuation area (OMWD).

A common special case is a consumption PO whose GBB / VBR row is missing (“GBB VBR not found” at GR) — add the consumption G/L (e.g. 410000) to GBB modifier VBR.

Prevent it: Stock Readiness — OBYC account determination · Accounting 101

Where: any posting or PO line that points at a G/L account (also seen as M7 055 at MIGO and F5506 on MIRO tax lines).

Cause (plain words): two things to check.

• Count the zeros first. Accounts in the INT chart are 6 digits (410000, 470000, 191100, 300000). A 5-digit number in the error (e.g. 41000) is almost always a missing-zero typo — fix the number and the red lights turn green.
• If the number is right, the account has two parts: the chart segment (number, name, type — shared by every company using the chart, so its name shows) and the company-code segment (currency, tax, field status — per company). The company-code segment was never created for this company code. Catalog vs playlist: the song exists in the catalog but was never added to this company's playlist.

Fix: FS00 → the account + company code → button “With Template” → reference a working account already in that company code (e.g. 470000, or 300000/191100/154000/276000 for their sibling errors) → it copies correct currency, tax and field-status settings → Save → retry. GR/IR accounts (191100) keep Open Item Management + a sort key; inventory/expense accounts usually get “Post automatically only”.

Prevent it: FI vs CO — the errors table · Scenario 5

Where: a PO or posting that charges a cost center (account assignment K) or another CO object.

Cause (plain words): cost centers live in Controlling (CO), which only accepts G/L accounts that also have a doorway into CO — a cost element. The account exists in FI but has no doorway yet, so the cost cannot flow into the pocket.

Fix: FS00 → the account → tab Type/Description: G/L Account Type = P (Primary Costs or Revenue) → tab Control Data: Cost Element category = 1 (primary costs) → Save. Analogy: the G/L account is the page in the company book; the cost element is its twin copy in the department book — the twin needs its own label before money can be written there.

Prevent it: FI vs CO in Easy Words · Setup Step 19 (controlling area & cost centers)

Where: entering an expense account on a PO line or invoice.

Cause (plain words): some accounts are reserved for automatic postings only (they carry the “Post automatically only” flag) — humans may not write on them by hand. 400000-type consumption accounts are usually set this way so that only account determination feeds them.

Fix: use a direct-postable expense G/L instead — e.g. 470000 — on the PO/invoice line. If you truly need to post to that account manually, remove the “Post automatically only” flag in FS00, but the normal answer is to pick the right direct-postable account.

Prevent it: FI vs CO — the errors table · Scenario 4

Where: assigning or repairing a controlling area (OKKP, OX19), or any posting afterwards.

Cause (plain words): the controlling area was set up (or linked to the company code) after FI documents were already posted. S/4HANA guards against this retroactive inconsistency, and a chain of follow-on messages appears until every gap is filled. Greenfield rule: build the CO area before any postings.

Fix (each message, in order):

Prevent it: Setup Step 19 (controlling area setup) · FI vs CO in Easy Words

Where: any FI posting when Document Splitting is active.

Cause (plain words): Document Splitting must be able to put a profit center on every line so each profit center's books balance on their own. One line has none and none can be derived.

Fix: enter a Profit Center on the line (F4 to pick one) — or fix the splitting derivation / set a default profit center in configuration so it fills automatically.

Prevent it: Accounting 101

Where: OADB, when you save or assign a chart of depreciation you just copied — a wall of red lines appears.

Cause (plain words): in S/4HANA every active depreciation area must say which ledger group and accounting principle it posts to (the Universal Journal rule — one shared table, so every area needs a target). A copied reference chart carries about 11 areas; a simple single-ledger company needs only one. Analogy: a rule book copied from a big multi-country company — you throw away the pages you don't use and address the one you keep.

Fix:

1. OADB → open the new chart of depreciation.
2. Delete every area except 01 Book Depreciation. If a delete refuses, delete the dependent / derived areas first (they lean on a parent area), then the parent.
3. Double-click area 01 → Accounting Principle = the entry tied to ledger group 0L (press F4 to pick it).
4. Target Ledger Group = 0L → Save.

Prevent it: Scenario 6 — §6.0 Activating FI-AA

Where: activating Asset Accounting for a fresh company code (and later on postings) — SAP blocks until a non-taxable tax code pair is set.

Cause (plain words): asset postings carry no tax, but SAP still wants a tax code on every posting that touches tax-relevant accounts. So it needs a pair of 0% codes that officially mean “nothing to declare”. Analogy: even an empty parcel at customs needs the “nothing to declare” sticker — the sticker must exist before the parcel can pass.

Fix: OBCL → your company-code row → Input = the system's 0% input code (I0 or V0, press F4 to see which exists) · Output = A0 → Save.

Prevent it: Scenario 6 — §6.0 Activating FI-AA

Where: AS01, choosing an asset class right after a new chart of depreciation was created.

Cause (plain words): an asset class has two parts — a client-wide part (created in OAOA) and a per-chart-of-depreciation “annex” (which areas are active, and the default depreciation key + life). A brand-new chart has no annex yet, or the area is stamped inactive — so the class exists but cannot be used here.

Fix:

1. OAYZ → Chart of Depreciation = the one assigned to your company code.
2. Open the class → Depreciation Areas → area 01 detail.
3. Un-tick “Area Deact.” (Area deactivated) so area 01 is live for this class.
4. Set Screen Layout 1000 → optionally a DepKey (straight-line) + Useful Life → Save.

Prevent it: Scenario 6 — §6.0 Activating FI-AA

Where: AS01 — it refuses to create the first asset in a company code that has just been switched on for FI-AA.

Cause (plain words): FI-AA keeps a note saying which fiscal year is already closed for assets. A fresh company code's note is empty, and SAP will not open a new asset book without it. Analogy: a new ledger book must state on page 1 where the old book ended — even if there was no old book, page 1 must say so.

Fix:

1. FAA_CMP_LDT → your company code → set the legacy data transfer date = the last day of the PREVIOUS fiscal year, with a completed / no-transfer status → Save.
2. If it still complains: OAAQ → set last closed fiscal year = the previous year.

Prevent it: Scenario 6 — §6.0 Activating FI-AA

Where: the first asset-related posting (GR or invoice) in a company code whose Asset Accounting was just activated.

Cause (plain words): every fiscal year's book must start with a "balance brought forward" line copied from last year's closing page. Setting the legacy-transfer date declared "last year is closed" — but nobody ever wrote the new year's opening line. Asset postings check for it and refuse until it exists. Even when all amounts are zero, the line itself must be written. Real companies run this every 1st of January — it is the G/L's version of the MMPV month roll.

Fix:

1. FAGLGVTR (G/L Balance Carryforward) → Ledger 0L · your company code · Carry Forward to Fiscal Year = the current year.
2. Follow-up FINS_BCF_EN010 "Create the retained earnings account NNNNN in company code …"? The carryforward moves every P&L account's year result into Equity's "profits kept so far" pocket (the retained earnings account) — and that account's company-code part doesn't exist yet. FS00 → the named account · your company code → With Template (same account + a company code that has it) → Save → re-run.
3. Run once with Test Run ✓ to preview, then again with Test Run unticked — it writes a period-0 opening entry in the Universal Journal.
4. Warning "More than 80% of available dialog processes will be used"? Just information: the program works in parallel and will occupy most of the server's "cashier counters" (work processes). On a test system with one user → ✓ and continue. On production it runs as a night-time background job for exactly this reason.
5. Re-post the goods receipt / invoice.

Prevent it: Scenario 6 — §6.0 Activating FI-AA (run the carryforward right after setting the legacy-transfer date)

Where: creating an asset PO (ME21N with account assignment A) or receiving it (MIGO) — the value cannot find its balance-sheet home.

Cause (plain words): an asset PO capitalizes the cost onto a fixed asset (Asset Accounting, FI-AA) instead of stock or expense. For that to work, three things must already be in place — and one of them is missing:

• Asset class not set up. The asset class (e.g. 2000 Plant & Machinery) is the “drawer” that carries the link to the acquisition G/L account. If the class does not exist, SAP has nowhere to file the asset.
• Account determination missing (AO90). The asset class finds its acquisition account (e.g. Plant & Machinery 140000) through FI-AA account determination in AO90. If AO90 is incomplete, the G/L on the PO stays empty and the goods receipt fails with “account determination not possible for account assignment A”.
• No asset master to point at. The PO’s Account Assignment tab must name a real asset master; if none was created with AS01, there is nothing to receive the value.

Fix: confirm the asset class and its AO90 account determination exist — this is FI-AA (Asset Accounting) setup, normally the FI consultant’s job, so ask “is asset class 2000 ready?” before you start. Create the asset master with AS01, then put account assignment A + that asset number on the PO line so the G/L (e.g. 140000) fills automatically. A separate “asset capitalization date not set” message is fixed in AS02 (fill the Capitalized On date).

Special case — AO90 “Balance Sheet Accounts” screen completely EMPTY (Bal.Sh.Acct APC blank): the money wiring for that asset group was never written — the machines have no balance-sheet page at all. Fix: AO90 → set the chart of depreciation → the class's account determination (the key comes from OAOA) → Balance Sheet Accounts → Bal.Sh.Acct APC = a machinery balance-sheet account from the chart (press F4, e.g. 11000 Machinery & equipment in chart INT) → if prompted, create it in the company code (FS00 With Template) and set Recon. acct for acct type = A → Save. The Depreciation folder (accumulated depreciation + expense accounts) must be filled before the first depreciation run, but it does not block the PO or the goods receipt.

Also appears as: “Account 'KTANSW : Bal.Sh.Acct APC' could not be found for area 01” at MIRO/MIGO — KTANSW is the technical name of that very AO90 field. If you are sure you filled it: a Save interrupted by a follow-up error is NOT a save. Re-enter AO90, retype the account, Save, and finish EVERY follow-up (create the account in the company code, set Recon type A) until the status bar says “Data was saved” — then leave and re-enter to confirm the value survived. Side note: the yellow warning “asset … does not manage quantity” on the same log is harmless (the asset card simply has no unit of measure).

Prevent it: Scenario 6 — §6.0 Activating FI-AA · Setup Guide

Where: saving an asset PO (ME21N) or its goods receipt (MIGO) in S/4HANA.

Cause (plain words): in S/4HANA an integrated asset acquisition posts as two linked halves — a vendor/operational document and an asset/valuation document — that meet in a pass-through account which always nets to zero. That account is a doorway between the vendor world and the asset world. The doorway must (1) exist per chart of accounts, (2) be a reconciliation account of type A (assets), and (3) belong to nothing else.

Fix (live-verified order):

1. Pick a FRESH G/L number. A number already used inside asset account determination (e.g. the classic 199990) can never be the doorway — it is already taken.
2. FS00 → create it (balance-sheet account; a template from an existing clearing account is fine) → tab Control Data → Recon. acct for acct type = A · Open Item Management OFF → tab Create/bank/interest → “Post automatically only” OFF. An account gets one lock: reconciliation or post-automatically-only, never both.
3. IMG → Financial Accounting → Asset Accounting → Integration with G/L → Technical Clearing Account for Integrated Asset Acquisition → Define → enter chart of accounts + the account → Save.
4. Re-save the PO.

Follow-up messages while creating the doorway (all part of this same fix):

• “Acct NNNNNN must be reconciliation acct for acct type A” → set Recon. acct for acct type = A in FS00 (step 2).
• “Account NNNNNN is already used in automatic account determination (T095…)” → that number is taken; go back to step 1 and pick a fresh number.
• “‘Post auto. only’ and ‘Recon.acct for acct type’ cancel each other out” → the account has both locks; switch “Post automatically only” OFF and keep only Recon. type A.
• “Account NNNNNN has been set as not relevant for tax” (at MIRO) → the account's Tax Category is empty ("tax never touches me"), but the invoice line carries a tax code (even a 0% one counts). FS00 → Control Data → Tax Category = * (or - only input tax) + tick “Posting without tax allowed” → Save → re-post the invoice.

Prevent it: Scenario 6 — §6.0 Activating FI-AA

Where: FS00 → Control Data, trying to make an account a reconciliation account — but the field is simply not on the screen.

Cause (plain words): the field's visibility is controlled by the account group's field status (OBD4). Some groups (e.g. MAT) suppress that field — and a hidden field can't be filled.

Fix: OBD4 → chart of accounts → the account's group → double-click → “Account control” → Reconciliation account: change Suppress → Optional → Save → the field now appears on FS00's Control Data tab. Optional is harmless — it forces nothing on other accounts in the group; it only lets the field show.

Prevent it: Accounting 101 — reconciliation (two-part) account · Scenario 6 — §6.0

Where: ME21N, saving an asset PO (account assignment A).

Cause (plain words): every G/L wears a “dress code” — its Field Status Group — that says which fields a posting to it may carry. If the dress code forbids the Asset number field while account assignment A demands one, the two rules collide. (The check compares the G/L's field selection against the account-assignment category's, on field group “Asset number/subnumber”.)

Fix:

1. Find the correct “dress code”: FS00 → display the acquisition account from AO90 (e.g. 11000 Machinery) → tab Create/bank/interest → note its Field Status Group.
2. FS00 → the blocked account → set that same Field Status Group → Save.
3. Re-save the PO.

Prevent it: Scenario 6 — §6.0 Activating FI-AA

Where: M/03, creating a new pricing condition table.

Cause (plain words): a condition table creates a real database table (e.g. A901) whose number space is shared between SD pricing and MM purchasing and is cross-client. A number already taken by SD (or another client, or demo content) is blocked even though your purchasing list does not show it.

Fix: pick another free number (try 902, 905…), or list every taken number first: SE16N → table T681 → Usage A → Execute (this shows all pricing condition tables, SD + MM together) → choose any 501–999 number not in the list.

Prevent it: Scenario 21 — Pricing procedure

Where: M/07, trying to change an access sequence.

Cause (plain words): access sequences are cross-client objects (they belong to the whole system, not one client), and the client is set to block cross-client changes, so SAP opens in view-only mode. (Condition types in M/06 are client-specific — that is why only M/07 complains.)

Fix — climb the ladder, checking each lock:

1. Client lock: SCC4 → the client → the box “Cross-Client Object Changes” should say “Changes to repository and cross-client customizing allowed”. If it already does, change nothing.
2. User authorization: reproduce the popup, then run SU53 — it names the failed check S_TABU_CLI (maintain cross-client tables). On a sandbox, add profile SAP_ALL in SU01 → log off/on.
3. Blocked from SU01 too? User administration needs S_USER_GRP; a role such as ZSAP_ALL_EXCEPT_SU01 means this was blocked on purpose.
4. Don't stop — use the copy path: M/06 is client-specific, so copying a standard type (FRA1 → ZCUS) brings its access sequence along and needs no cross-client rights. On a real project, SU53 + a role request to Basis is the proper route.

Users are client-specific: the same name can hold SAP_ALL in one client but not another. Access sequences are cross-client, so building one in a client where you do have rights makes it exist everywhere.

Prevent it: Scenario 21 — Pricing procedure

Where: M/07, after saving an access sequence.

Cause (plain words): not really an error — the sequence was saved before the Fields level was finished, so the wiring that connects the table to the document “basket” does not exist yet.

Fix: select the access row (click the narrow grey box at the far left) → double-click Fields → if the status bar says “The field assignment has not yet been made”, press Enter → the Fields screen lists the key fields (e.g. EKORG + MATKL) → press Enter again to generate the assignments → Save. If the Source column is empty, F4 → pick the KOMK entry for header fields (EKORG) and the KOMP entry for item fields (MATKL).

Prevent it: Scenario 21 — 21.2 Access sequence

Where: M/07, opening the Fields level of an access.

Cause (plain words): an information message, not an error. It means “I am about to create the field wiring for the first time” — the link between the condition table's key fields and the document basket (KOMK header / KOMP item) has not been generated yet.

Fix: press Enter — the Fields screen lists the key fields → press Enter again to generate the assignments → Save. Two extra rows (KFRST Release Status, KBSTAT Processing Status) may appear automatically; SAP manages them, leave them untouched.

Prevent it: Scenario 21 — 21.2 Access sequence

Where: saving pricing customizing (condition table, access sequence) on a sandbox/IDES.

Cause (plain words): the object is being created as a Local Object (package $TMP) instead of being attached to a transport request. On a practice system that is normal and harmless.

Fix: on a sandbox, accept it — click Local Object / the green ✓ and continue; the Customizing-request popup that follows is also normal. On a real (transport-managed) system, assign the object to a proper package and Customizing request so it can move to QA/Production.

Prevent it: Scenario 21 — Pricing procedure

Where: ME21N/ME22N — the PO lines all computed, but the schema never published a final answer.

Cause (plain words): the Subtotal column code S marks one row as “this result IS the effective price”. With no row marked S, SAP reads the effective price as 0, compares 0 against the material master price, and warns. (It is only a warning — Enter passes it — but with effective price 0 every price comparison is meaningless, so fix it.)

Fix: M/08 → your procedure → Control data → find the Subtotal column → on the final subtotal row type S (“publish this as the effective price”) and on the gross-price row (PB00) type 9 (“this is the gross value”). Unsure of a code? Click the cell and press F4 for the list. Then ME22N → Conditions → Update to re-price. See also the Subtotal column explained and the double-count trap.

Prevent it: Scenario 21 — 21.4 Add to the pricing procedure

Where: M/08, a pricing procedure built from a blank page (not copied from RM0000).

Cause (plain words): a copied schema arrives with its Subtotal codes already set; a from-scratch schema is born with the column empty. Two codes matter: 9 on the gross-price row (PB00) = “this line is the gross value”, and S on the final subtotal row = “publish this row's result as the PO's effective price”. Missing S is exactly what produces message 06 207 (effective price 0).

Fix: M/08 → Control data → set 9 on the PB00 row and S on the final subtotal row (F4 shows each code with its description) → Save → re-price the PO. A small variance versus the master price after the fix is normal — it is your duty/freight; the point is that the price is no longer 0.

Prevent it: Scenario 21 — building a schema from scratch

Where: M/08 — the grand-total row of a pricing procedure.

Cause (plain words): the final row's From was set to 1, spanning across the middle net-subtotal. The middle subtotal row already contains the earlier steps, so a 1–89 range adds the goods twice — once as PB00 and again inside the subtotal.

Fix: set the final row's From = the step number of the net subtotal (e.g. 20), To = 89. Start AT the subtotal and add only what comes after it (freight, duty, tax). Restaurant-bill rule: grand total = “subtotal so far” + the new lines under it, never the subtotal plus all the original items again.

Prevent it: Scenario 21 — 21.4 Add to the pricing procedure

Where: M/08 or when re-pricing a PO that uses a delivery-cost condition (freight, customs duty…).

Cause (plain words): a condition with the Accruals flag on (set in M/06) MUST also have an Accruals (provision) key in the pricing procedure — the key that tells OBYC which provision/clearing G/L to credit when the cost is accrued at goods receipt. The row has the flag but its Accruals column is empty. Key insight: account keys do not live on the condition type — they live on the SCHEMA ROW, so even a standard type (like FRA1) is born with empty keys in a from-scratch schema.

Fix: M/08 → your procedure → Control data → the condition's row → fill both the AccKey (ActKy) and the Accruals columns. Choose by logic, not by copying: click the cell → F4 → pick the key whose description matches (e.g. FR3 “Customs duty” — put it in both columns; freight instead uses a pair: FRE cost + FR1 clearing). Save → re-price. If a later goods receipt then says “account missing” for that key, give the key a G/L behind it in OBYC.

Prevent it: Scenario 21 — 21.4 Add to the pricing procedure · Accounting 101 (keys vs accounts)

Where: ME21N → Conditions tab → Analysis button (the pricing X-ray that explains why each condition did or did not get a value).

Cause / meaning of each number (these are diagnoses, not errors):

If your custom condition even appears in Analysis, determination already worked — the correct schema was chosen and the condition is being processed.

Prevent it: Scenario 21 — schema determination & condition records

Where: ME21N (PO item) or MIRO (invoice) — a tax code is mandatory and none was entered.

Cause (plain words): SAP needs to know how much input tax is on the line, even when it is 0%. Without a tax code it cannot build the tax line.

Fix: on the PO item's Invoice tab (or MIRO's Basic Data tab) enter a Tax Code — e.g. V0 = input 0%, or your local input-tax code. If no tax codes exist in the system, create one in FTXP. F4 shows what is actually configured — that is how you find the real code when a familiar one (like V0) is absent.

Prevent it: Scenario 4 (service PO)

Where: MIRO, posting a vendor invoice. The Balance indicator (top-right) must be 0.00 green.

Cause (plain words): the PO supplies only the expected/debit side. You must type the vendor's total Amount in the header — until you do, debits and credits do not match and the balance shows red. The BD (“small difference”) tolerance error is usually a side-effect of that unbalanced amount.

Fix:

1. Enter the invoice Amount in the header (the vendor's total from the paper bill) → the balance goes to 0.00 green → Post.
2. If a genuine small rounding difference remains and BD still blocks you, maintain tolerance key BD for the company code in OMR6 (the same place as the PE/PP tolerances) with a small allowed difference.

Prevent it: Scenario 4 (service MIRO)

Where: MIGO (M7 001) and MIRO (M8 100) — the Logistics Invoice Verification (LIV) control tables have no row for this company code.

Cause (plain words): two twin tables need a company-code row: T169P holds the checking rules (duplicate-invoice / amount checks) and T169V holds the default values (such as the default tax code).

Fix:

• M7 001 / T169P: OMRG (or SM30 → V_169P_S) → New Entries → the company code (thresholds can stay blank) → Save.
• M8 100 / T169V: OMR2 → New Entries → company code + a default tax code (e.g. I0) → Save (MIRO then pre-fills the tax code).

Prevent it: Stock Readiness checklist

Where: MIRO — SAP asks for a Baseline Date every time you post.

Cause (plain words): the Baseline Date is “day zero” of the payment countdown — the date from which the payment terms start counting (Due Date = Baseline Date + net days). Each payment term has a switch “Default for baseline date”; when it is set to No default, SAP has to ask you every time.

Fix: OBB8 → double-click the payment term → section “Default for baseline date” → choose one: Posting date (simplest, good for practice), Document date (the vendor's invoice date — the common business deal “30 days from invoice”), or Entry date. Save. There is no “goods receipt date” option because one invoice can cover many receipts with different dates — such deals are handled by typing the date into the Baseline Date field by hand.

Prevent it: Setup Step 18F — Payment Terms (OBB8)

Where: F-53, clearing a vendor payable.

Cause (plain words): two different things describe your bank. The G/L account (e.g. 113100) is the bank's page in your books; the house bank is the real bank relationship (bank, branch, account number, bank key). The F4 list is empty because a fresh company code has no house bank defined yet (FI12 is empty). Manual clearing mostly needs only the books page.

Fix — climb the ladder:

1. Try leaving House Bank blank — fill only the Account (113100) + Amount. It is optional in most setups.
2. If SAP hard-stops, create one: FI12 (or FI12_HBANK on S/4) → company code → New Entries → House Bank HBL01, Country, Bank Key (SAP offers to create the bank — name it, save) → Bank Accounts folder → Account ID MAIN + account number + G/L 113100 → Save → back to F-53.
3. If S/4 only allows bank accounts via the Fiori “Manage Bank Accounts” app, use any plain cash G/L in the Account field instead — the lesson here is the clearing, not the bank plumbing.

Prevent it: Scenario 5 — pay the vendor (F-53)

Where: F-53, on the bank line.

Cause (plain words): the Value date is the day the money actually moves at the bank. It can differ from the posting date (a cheque posted today may clear at the bank two days later); banks use it for interest and cash position, so it is required on bank G/L lines.

Fix: in the Bank data area set Value date = today (or the real clearing date) → Enter. Also make sure Open Item Selection → Account = the vendor number before clicking Process Open Items.

Prevent it: Scenario 5 — pay the vendor (F-53)

Where: F-53 clearing a payment.

Cause (plain words): the vendor-side clearing tolerances are missing. Do not confuse the twins: OBA4 = user tolerances (table T043T, set in basic FI config) versus OBA3 = vendor tolerances (table T043G).

Fix: OBA3 → New Entries → company code + a blank tolerance group (= the default for all vendors) + small allowed Gain/Loss values → Save.

Prevent it: Scenario 5 (F-53)

Where: MIGO, trying to Post a goods receipt.

Cause (plain words): every line has an Item OK confirmation. If it is not ticked, SAP thinks no line is confirmed and refuses to post — the most common MIGO beginner error.

Fix: tick ☑ Item OK at the bottom of the item detail (or the “OK” checkbox column in the item grid) for each line → Post.

Prevent it: MIGO Guide

Where: ME21N save (key PE, price variance) or MIGO post (key VP, moving-average price swing). Same message number, two different config places — read the long text.

Cause (plain words): the price-variance rule for this company code has not been maintained. SAP will not let a price move without a tolerance rule telling it how much variance is acceptable.

Fix (choose by the key in the message):

• PE (PO save): it is not in OMR6's F4 list. Go to SPRO → MM → Purchasing → Purchase Order → Set Tolerance Limits for Price Variance → PE + company code → set the check limits and values.
• VP (goods receipt): OMC0 → maintain VP (and B1, B2) for the company code.
• Other keys: PP/BD/DQ → OMR6; VP/B1/B2 → OMC0; vendor-side → OBA3.

When maintaining a tolerance row, every section that has a value must also have its “Check Limit” radio selected; empty sections stay “Do Not Check” — otherwise you get “Enter values in work area for non-key fields”.

Prevent it: Stock Readiness checklist

Where: ME51N/ME21N, creating a requisition or PO line.

Cause (plain words): SAP cannot find a Valuation Class to derive the stock account, so it demands an account assignment instead. Usually the material has no Accounting view, or its material type has Value updating switched off for the plant.

Fix: MM01/MM02 → add the Accounting 1 view (valuation class, price control, price) → and/or check OMS2 quantity/value updating for the plant. If the item is genuinely non-stock, add the account assignment (e.g. K + cost center) on the line.

Prevent it: Stock Readiness — Gate 2 (OMS2)

Where: MIGO, receiving against a returns PO.

Cause (plain words): two possibilities. (1) You typed 161 by hand in the header movement field — leave it 101; the Returns flag on the PO item derives 161 automatically. (2) The item already shows 161 but movement 161 does not list MIGO in its Allowed Transactions (table T158B) in this system.

Fix:

• Cause 1: set the header movement back to 101; tick Returns on the PO item (ME22N → R column).
• Cause 2: OMJJ → movement 161 → Allowed Transactions → New Entries → MIGO (F4 to confirm the exact T-code your release validates against) → Save; add 162 (the reversal) too. Compare with movement 122's list, which already works.

Prevent it: MIGO Guide

Where: MIGO, posting a goods issue or transfer (e.g. the STO issue 351, an issue to production 261, a transfer 311).

Cause (plain words): you are taking more than the named shelf holds. SL = storage-location level: SAP checked that exact plant + storage location and its unrestricted stock is smaller than your quantity. Stock in another room, in transit, or in quality/blocked status does not count. Three usual reasons: ① the stock was never created (an earlier receipt failed and was never re-posted), ② the stock sits in a different storage location, ③ something else (a reservation or an earlier issue) already took it.

Fix: MMBE → the material → see where stock REALLY sits and in which status. Then either post the missing receipt, or point the issue's Where tab → From storage location at the room that actually has the stock, or move it there first (MIGO Transfer Posting, mvt 311). Retry.

Prevent it: check MMBE before any issue — goods issues only take from the exact shelf's unrestricted stock.

Where: MIGO — the first movement in a plant that needs a plant-level default, most often a receipt that must auto-create the material's storage-location data (a MARD row for a room the material never used).

Cause (plain words): table T159L holds a plant's default switches for Inventory Management (including the "create storage-location data automatically?" flags, OMB2/OMB3). A posting only opens this table when it needs one of the defaults — a plant can post for months without the row. Live proof on our system: PK01 posted 561 and 351 with NO row, because its material was born with storage data (SLoc typed in MM01's Org Levels); PK02's first receipt had to auto-create storage data → opened T159L → no row → stop.

Fix (two parts, both quick): ① SPRO → Materials Management → Inventory Management and Physical Inventory → Plant Parameters → New Entries → the plant → keep the defaults → Save (if a proven plant's row exists, Copy it; if not, defaults are fine). ② Better still, remove the need for auto-creation: give the material its storage data directly — MMSC → material + plant → add the storage location → Save (or MM01, view "Plant data/stor. 1"). Retry the movement.

Prevent it: when extending a material to a new plant, include the storage location in the Org Levels popup — storage data from birth means this table is never consulted. Stock-Readiness Checklist.

Where: MIGO, posting a goods movement.

Cause (plain words): the Delivery Note header field is configured as mandatory for goods movements in this system.

Fix: Header → General tab → type any delivery-note / challan reference text → continue.

Prevent it: MIGO Guide

Where: ME21N, when a PO number was typed into the number field.

Cause (plain words): ME21N is Create, and its number field is only for document types with external numbering. Standard type NB is internal (SAP assigns the number at save), so typing a number is rejected. Typing an existing PO number here is also a mistake — that is not how you open a PO.

Fix: to open an existing PO use ME23N (display) / ME22N (change) → “Other Purchase Order” button → enter the PO number. In ME21N, leave the number field empty.

Prevent it: PO Master Reference

Where: ME21N, trying to pull a purchase requisition into the PO.

Cause (plain words): a GUI quirk / wrong right-click target (PR header vs item).

Fix (most reliable): type the PR number directly into the item table's “Purchase Requisition” column → Enter. If the column is hidden, right-click the table header → Configure/Layout → show the column.

Prevent it: PO Master Reference

Where: ME21N/ME51N — a yellow warning, not an error (Enter passes it).

Cause (plain words): backward scheduling found that the delivery date is earlier than today + planned delivery time + goods-receipt processing time (+ purchasing processing time for a PR) — the order should already have been placed.

Fix: ignore it (it is yellow), or move the delivery date out, or shorten the lead times (info record ME12 / material master MRP 2 in MM02; purchasing processing time in plant parameters OPPQ).

Prevent it: PO Master Reference

Where: checking/saving an intra-company Stock Transport Order (ME21N, doc type UB) — a yellow warning, not an error.

Cause (plain words): the partner schema assigned to the STO document type expects certain partner roles on the document — DP = Delivering Plant. On a normal PO those roles are filled automatically from the vendor's Business Partner record. But an intra-company STO has no vendor at all — the supplier is a plant, and a plant has no BP partner roles — so partner determination finds nothing and politely warns.

Fix: for learning, ignore it — press Enter and save; the STO posts and moves stock perfectly without the partner role. Real-life options if a company wants silence: enter the role manually on the PO (Header → Partners tab), or in customizing un-tick Mandatory for DP/OA in the partner schema used by document type UB (SPRO → MM → Purchasing → Partner Determination).

Prevent it: Scenario 7 — intra-company STO (no vendor, no invoice — the same reason this warning exists)

Where: OMR6/OMC0, saving a tolerance row.

Cause (plain words): a value was typed while its “Check Limit” radio still says “Do Not Check” (or the reverse) — the row is internally inconsistent.

Fix: every section that has a value must have its “Check Limit” radio selected; sections you are not using stay fully on “Do Not Check” with no value.

Prevent it: see M8 215 tolerance keys

Where: ME21N (PO) or ME51N (PR) — you named a vendor for a material whose source-list requirement is switched on.

Cause (plain words): the material’s “Source list” flag (MARC-KORDB, set in MM02 → Purchasing view) means “this material may be bought only from vendors on the approved list”. The vendor on your document is not on that list for this plant, or its source-list row is not valid on the document date — so SAP rejects it. Like a fuel card that only works at three named petrol pumps: any other pump is declined.

Fix (pick one):

• Add the vendor to the list: ME01 → material + plant → new row with the vendor, its purchasing org, and a validity that covers the document date → Save.
• Or, if the material should not be restricted, untick the Source list flag in MM02 (Purchasing view).

Prevent it: Scenario 14 — 14A/14B (activate the source list & add the approved vendor)

Where: ME21N/ME51N, choosing a vendor that is on the source list but switched off.

Cause (plain words): the vendor’s source-list row has the Block box (Blk column · EORD-NOTKZ) ticked. A block is a temporary “closed” sign on an approved vendor — the approval stays on record, but SAP will not let anyone pick that vendor until the block is removed. This is how you freeze a supplier (for example after a quality failure) without deleting the approval.

Fix: ME01 → material + plant → the vendor’s row → untick the Blk column → Save, and the vendor can be used again. If the block should stay, pick a different approved vendor instead.

Prevent it: Scenario 14 — 14E (block / unblock a source)

Where: ME21N/ME51N with Source Determination ticked, or an MD03 MRP run — SAP tried to find the vendor itself and came up empty.

Cause (plain words): SAP looked in the source list for a row that is valid for this material, plant and the document’s delivery date, and found none. Usual reasons: there is no source-list row at all; the row’s Valid From / Valid To window does not cover the delivery date; or every matching row is blocked.

Fix: ME01 → material + plant → check a row exists and its Valid From/To covers the document’s delivery date (SAP’s “forever” end date is 31.12.9999) → widen the dates or add a row → Save → re-run. Also confirm the vendor is not blocked (06 405).

Prevent it: Scenario 14 — 14D (time-dependent validity)

Where: adding a vendor to the source list (ME01) or using it on a PR/PO — the vendor is known, but not for this buying team.

Cause (plain words): a vendor record has two layers: a general layer (name, address) and a purchasing-organization layer (the terms this specific buying desk uses). The vendor exists, but the purchasing-org layer (table LFM1) was never created for the purchasing org on your document — so that org may not buy from them yet.

Fix: open the vendor Business Partner (BP) → add / complete the Vendor (Purchasing) role for the purchasing org named on the source list → Save → retry.

Prevent it: BP Create Guide (extend the vendor to the purchasing org) · Scenario 14

Where: a PR/PO with Source Determination on, where you expected SAP to divide the quantity between vendors (say 60/40) but it did not.

Cause (plain words): a quota arrangement (MEQ1) only runs when several things line up. Common reasons it stays silent:

• Quota usage is off. The material’s “Quota arr. usage” field (MARC-USEQU, in MM02 → Purchasing view) is blank or set to a value that excludes your document type, so the quota machine never starts.
• The arrangement is not valid on the date. The MEQ1 header Validity Start/End does not cover the document date, so there is no active quota to apply.
• The split is already consumed. One vendor’s allocated quantity has been used up, so SAP biases new demand to the other vendor until the shares rebalance (the Quota Base Qty can also pre-load a starting balance that changes the maths).

Fix: MM02 → set Quota arr. usage = 4 (applies to PR + PO + scheduling agreements) → then MEQ1 → confirm the validity covers the date and the vendor rows carry the right allocated shares → check current usage in MEQ3 → re-run source determination.

Prevent it: Scenario 14 — 14F (quota arrangement, MEQ1 / MEQ3)

Where: an MD03 (single-material) or MD01 MRP run raises a purchase requisition for a shortage, but the requisition comes out with no vendor.

Cause (plain words): MRP reads only the source list’s MRP indicator column (EORD-AUTET). It ignores the Fix flag completely. If the row’s MRP indicator is blank, MRP treats the row as “not for automatic planning” and builds a requisition with no source attached — a buyer must add the vendor by hand later.

Fix: ME01 → material + plant → the vendor’s row → set the MRP indicator to 1 (MRP may use this source and create purchase requisitions) — or 2 when the source is a scheduling agreement and you want MRP to create delivery schedule lines → Save → re-run MD03. If several rows have the indicator set and a quota is active, MRP splits per the quota; otherwise it takes the first valid row.

Prevent it: Scenario 14 — 14H (MRP-driven PR, the MRP indicator)

Where: AC01, creating a service master.

Cause (plain words): the service category's number range is internal by default, so a typed key (like SVC-CONSULT-01) is rejected — internal means SAP assigns the number, you do not.

Fix (easiest): leave the Service Number blank and let SAP number it. To keep an alphanumeric key, define an external interval in ACNR (SPRO → MM → External Services Management → Service Master → Define Number Ranges) and assign it to the category.

Prevent it: Create the service master · Scenario 4

Where: MIGO/MIRO when the FI document is created.

Cause (plain words): the FI document type's number-range “ticket roll” is missing for the company code — and the document-type→range mapping may be non-standard. A range defined only for the current calendar year also “dies” in January.

Fix: FBN1 → insert the named interval, Year 9999 (= any year). Proactively check the mapping first: OBA7 → each document type (WE/RE/KZ/ZP/SA) → note its range number → confirm that interval exists in FBN1. “Company code intervals already exist, cannot be copied” means copy-all only works into an empty company code — insert the missing intervals manually (pattern NN → NN00000000–NN99999999).

Prevent it: Stock Readiness — Number ranges (OMBT · FBN1)

Where: creating a vendor Business Partner (BP).

Cause (plain words): the vendor account group uses external numbering, so you must type the number yourself, and it must fit the range's pattern. Common traps: (1) the classic vendor number range (object KREDITOR) does not exist yet; (2) a numeric value was typed into an alphabetic range (a “2” sorts before “A”).

Fix:

• Type a code that matches the range — for an A–Z range, start with a letter (e.g. MUGHAL21), not a digit.
• Range missing: XKN1 → insert the interval (e.g. 02, A–ZZZZZZZZZZ, mark External ✓).
• “Same Number” (BP = vendor number) requires the group's range to be external — check OBAS (group→range) + XKN1 (Ext flag), or skip Same-Number and type codes manually.

Prevent it: BP Create Guide · Setup Step 18

Where: creating the one-time config keys a produced material needs (MM01 · MRP 2 view wants a Schedule Margin Key). Many training lists say the T-code is OPPF — you type it and get "New Entries: Details of Added Entries" with Profile, Number of Hierarchy Levels, Read Order Report from Buffer, Multilevel Delay and green/yellow/red threshold rows.

Cause (plain words): the label is wrong, not your system. OPPF is really "Customizing for Order Report" — display settings for a planners' report (the traffic-light delay report opened from MD04). It has nothing to do with the Schedule Margin Key and nothing to do with creating a material. Even if no profile is ever created here, SAP quietly uses its own delivered standard profile — so this screen cannot block anything.

Fix: fill nothing — press Back (F3) and answer No if asked to save. The real home of the Schedule Margin Key has no direct T-code on S/4HANA (OMDC from older lists is not valid either — live-confirmed). Use the menu: SPRO → Production → Material Requirements Planning → Planning → Scheduling and Capacity Parameters → Define Floats (Scheduling Margin Key) — or OPPQ → your plant → the Floats button. Then New Entries → Plant PK01 · Margin key 000 · the four day-columns (Opening Period, Float After Production, Float Before Production, Release Period) all 0. Zero days = no scheduling buffer, which is fine for practice. Save → Customizing request → 000 is now accepted in MM01's MRP 2 view.

Prevent it: Create Production Materials — the three one-time config keys

Where: MIGO, the first ever movement in a valuation area whose Material Ledger was never started.

Cause (plain words): activating the Material Ledger is not enough — the “value diary” must also be started (made productive) for the valuation area.

Fix: OMX3 (assign an ML type, e.g. Y001) → OMX1 (ML Active ✓, Price Determination 2) → CKMSTART (test run, then real — “Plant is now productive”).

Two neighbours: if OMX1's ML Act. checkbox is greyed out, no ML type is assigned yet — do OMX3 first. If CKMSTART says “Valuation area … unable to be locked”, your own other session (a MIGO with the PO loaded, an MM03…) holds the lock — close other SAP windows, clear stale locks in SM12, and rerun.

Prevent it: Stock Readiness — Material Ledger

Where: MM01, creating a material for a company code/plant.

Cause (plain words): Materials Management's own period clock was never started for this company code. This is independent from Finance's period settings (OB52).

Fix: OMSY → the company code + current year/period + tick ABp (allow posting to previous period as needed). Leave DBp unticked — ticking both gives a “combination does not make sense” error.

Prevent it: Stock Readiness — Posting periods (OMSY)

Where: anywhere a record is held — very often by your own second session.

Cause (plain words): someone (usually you, in another open window) is holding the material, plant, or business partner, so SAP will not let a second change begin.

Fix: close your other SAP windows first → SM12 → filter by your user → delete only your own stale locks → retry. On a shared system, never delete another user's lock without asking.

Prevent it: Toolbox — SM12

Where: any transaction on a shared/IDES system.

Cause (plain words): saved breakpoints left by earlier debugging sessions keep triggering the debugger.

Fix: never spam F8 — F8 (Continue) runs the rest of the program, including SAVES. Exit cleanly with Alt+D → E (Exit debugger). To stop it recurring: in the debugger → Breakpoints tab → delete all → save.

Prevent it: Toolbox — the debugger

Where: saving a PO (ME21N) or a service entry sheet (ML81N).

Cause (plain words): output determination (printing/emailing the document) is not configured. The document data itself saves fine — this is only about the printout.

Fix: for learning, ignore it — click Yes/save anyway (then Accept the SES). The real fix is output configuration: NACE (application EF) + MN04 condition records.

Prevent it: Scenario 22 (output/message determination)