Setup Step 1 — Create & Configure Company Code

MANDATORY Layer 1 · FI Foundation · owned by FI ⏱️ ~2-3 hours OX02 OBY6 FBN1
← Previous
Setup Guide Hub
Next →
Step 2: Test the CC (F-02)

🎯 Why this setting exists

The Company Code (CC) is the legal entity — it owns the balance sheet and P&L, holds the bank accounts, and files the tax returns. It is the foundation of the entire system: every MM document (purchase order, goods receipt, invoice) eventually posts into a company code's books through the plant → CC link. If the CC is missing even one of its settings, FI postings fail and MM stops cold — your MIGO and MIRO are the transactions that break. This is the first thing you build, and almost everything else depends on it. In S/4HANA it is not one click but ~16 sub-steps, three of which (Universal Journal, Document Splitting, G/L extension) did not exist in ECC.

💡 Easy example

Think of the company code as one registered company on paper. PSPK is "PakSteel Industries (Pvt) Ltd" — the SECP-registered company that owns the bank accounts, files its NTN and sales-tax (STRN) returns with the FBR, and produces one balance sheet at year-end.

The factories and warehouses (plants) are inside this company — they are where work happens, but they are not the legal entity. PakSteel can have a Karachi factory, a Lahore factory and a Dubai DC, yet all of their money rolls up into the company's single set of books. One company, many sites. (The UAE arm, PSAE — "PakSteel Trading FZ-LLC" in AED — is a second company code, built once PSPK works.)

🔗 How this connects to everything else

The company code sits at the very bottom of the build. Nothing in MM is useful until a CC exists for its stock to be valued against — and once it exists, it is the silent backstop behind every posting you will ever make. Here is the web of what it needs, what it unlocks, and how it reaches into the other modules.

⬆️ Depends on (must exist first)

  • Nothing built by you — this is the first step of the whole guide.
  • It only needs two pre-delivered objects that already exist in IDES: the Chart of Accounts INT (the master list of G/L numbers) and a Fiscal Year Variant (K4, Jan–Dec). Both ship with the system, so there is no prerequisite step.

⬇️ Enables (what this unlocks)

🧩 Who owns it & why MM cares

FI Basis FI and Basis configure the company code — it is FI's foundation, not MM's. But every PO, goods receipt and invoice posts into it, so an MM consultant must understand its moving parts: the posting periods (OB52 / OMSY), the tolerances, the Material Ledger and the number ranges. When any of those is missing, it is MIGO / MIRO that throws the error — so MM must be able to read it and point FI at the right sub-step.

🔮 Links to other modules (now & later)

  • FI The company code is the books — every financial document lives here.
  • CO Controlling needs the CC plus a controlling area (Step 19) before cost postings work.
  • ML The Material Ledger (S/4 valuation engine) reads the CC's ledger currencies — sub-step 1O must match 1H.
  • SD Sales documents post revenue into the same CC; a delivering plant rolls up to it.
  • PP Production order settlement and WIP land in this CC's books too.

🔧 Configuration — fields & steps

OX02 OBBP OB52 OBC4 OBY6 FBN1 OBA4 FINSC_LEDGER FS00 OMSY EC01

This step is 16 sub-steps (1A–1P), not one click. SAP does not auto-create most of these — you build them one by one, each before the thing that references it. Three sub-steps (1H, 1I, 1J) are S/4HANA-specific — they did not exist in ECC but are mandatory in the Universal Journal architecture. Skip them and F-02, MIGO and MIRO all fail.

⚡ S/4HANA vs ECC — what changed
If you are following an ECC-era tutorial you will hit walls after 1G. S/4HANA added these requirements not present in ECC:

📋 The 16 sub-steps at a glance (1A–1P)

Each is a collapsible block below. The most important are open by default; click any summary to expand.

#T-codeWhat it doesTimeFlavor
1AOX02Create the CC shell (name, country, currency, address)5 minUniversal
1BOBBP / SM30Create Posting Period Variant (the label only)3 minUniversal
1COB52Open the actual posting periods (current + future)5 minUniversal
1DOBC4Create Field Status Variant (copy from 0001)5 minUniversal
1EOBY6Assign all 4 variants to the CC (Global Parameters)5 minUniversal
1FFBN1Create the FI Document Number Ranges (Year 9999 = evergreen)15 minUniversal
1GOBA4Configure FI Tolerance Groups (posting limits)5 minUniversal
1H ⚡FINSC_LEDGERAssign CC to Leading Ledger 0L + Accounting Principle10 minS/4 only
1I ⚡SPRO pathClassify G/L Accounts for Document Splitting10 minS/4 only
1JFS00Extend G/L accounts from chart to YOUR CC10 minUniversal
1K ⚡OMSYMM Period Initialization — without it MM01/MIGO fail with "CC not maintained"3 minUniversal (MM-side)
1LVarious10-point verification — includes F-02 smoke test + MM period check10 minUniversal
1M 🚀EC01BONUS: fast-copy for the 2nd+ CC (PSAE) — skip 1A-1K10 minUniversal
1N ⚠️OMR6/OMC0/SPROTolerance Keys (PE/PP/VP/BD…) — "how much variance is acceptable"; PO/GR/Invoice fail without them15 minUniversal
1O ⚡OMX3→OMX1→CKMSTARTMaterial Ledger startup — open the plant's "value diary"; ALL goods movements blocked without it15 minS/4 only
1P 🏁OMRG·OMC0·FS00·FBN1First-GR Readiness (4 Gates) — T169P row, VP tolerance, OBYC G/Ls in CC, FI doc intervals15 minUniversal

💡 Why this order: dependencies are built BEFORE they are referenced. 1B/1D create variants → 1E references them. 1H needs the CC + ledger to exist. 1I classifies G/Ls before they are used. 1J extends G/Ls before F-02 needs them. For the 2nd company onwards → jump to 1M (EC01 copy) instead of redoing 1A-1J.

🗺️ MASTER CONFIGURATION MAP — what each config is FOR, which module OWNS it, and how everything LINKS
🧒 How to read this map: Think of the company code as a new house. Layer 1 = the foundation + electrical wiring (FI — the money system). Layer 2 = the smart connections between rooms (MM↔FI integration — where goods movements become accounting). Layer 3 = the rooms and furniture (org units + master data you work with daily). Each layer needs the one below it. Whenever a transaction fails, find its config here and check the "Must exist BEFORE" column — the missing prerequisite is almost always the cause.

🧱 Layer 1 — FI Foundation (Module: FI · "the company's books")

ConfigNeeded byPurpose in plain wordsMust exist BEFOREFeeds into
OX02 Company Code (1A)EVERYTHINGThe legal entity — owns the balance sheet, files taxesNothing — this is firstPlants (OX10), Purch Orgs, all postings
OBBP+OB52 Periods (1B/1C)Every posting's DATE check"Which months is the cash register open?"CC (1A)F-02, MIGO, MIRO all validate posting date against this
OBC4 Field Status (1D)Every FI line itemWhich fields are required/optional when posting to each account type—FS00 accounts reference its groups (G001, G006…)
OBY6 Global Params (1E)Every FI postingWires CC to its rule set: Chart INT + Fiscal Year + Periods + Field Status1A–1DEverything FI validates against these 4 assignments
FBN1 Doc Number Ranges (1F + 1P Gate 4)EVERY FI document"Ticket rolls" — each doc type (WE/RE/KZ/SA) numbers its documents from its own rollCCMIGO→WE, MIRO→RE, F-53→KZ
FINSC_LEDGER (1H) ⚡S/4First FI posting everRegisters the CC in the Universal Journal (ACDOCA) + declares IFRS/local GAAPCC + OBY6ALL postings; also ML currency setup reads it
Doc Splitting classify (1I) ⚡S/4Posting balance checksTags every G/L with a category so SAP can balance documents by segmentChart assigned (OBY6)Each FI document's splitting logic
FS00 G/L extension (1J + 1P Gate 3)Posting to EACH accountChart = song catalog; each CC must add the song to ITS playlist before playing itOBY6 (chart known)OBYC's target accounts MUST be extended or MIGO fails (M7055)
OBA4 FI Tolerance Groups (1G)Manual FI entriesPer-user posting limits ("clerks may post up to X")CCF-02 and all manual FI
OBB8 Payment Terms (Step 18F)Vendor master, MIRO, F-53"When is the invoice due + early-payment discount" (e.g., 0003 = 14d 2%/30d net)—Cash discount auto-calculated at payment

🔗 Layer 2 — MM↔FI Integration (Module: MM-IM/LIV + CO-ML · "goods movements become accounting")

ConfigNeeded byPurpose in plain wordsMust exist BEFOREFeeds into
OMSY MM Periods (1K)MM01, MIGOStarts MM's own month-clock for the CC (separate from FI's OB52!)CC + fiscal year variantMaterial master create + every goods movement date check
OMS2 Qty/Value updateMaterial creation"Does this material TYPE carry value in this plant?" — if no, SAP demands manual account assignment (ME062)Plants existWhether Accounting view is possible/needed per material
OMWM/OMWD Valuation Grouping (Step 6)OBYC lookupGroups plants under one code (0001) so ONE set of account rules serves many plantsPlantsOBYC reads VGC to find the right rule row
OBYC Acct Determination (Step 7)MIGO, MIRO auto-postingThe translator: "GR of raw material (class 3000) → Dr 300000, Cr 191100" — no human picks accountsVGC + valuation classes + FS00-extended G/LsEVERY automatic FI line from goods movements
OMX3→OMX1→CKMSTART ML (1O) ⚡S/4FIRST goods movementOpens the plant's "value diary" — S/4 refuses any stock posting until productivePlants + FINSC_LEDGER currenciesAll stock valuation; ACDOCA material values
OMRG T169P (1P Gate 1)MIGO + MIROOne settings row per CC for invoice-check behavior — even GR reads itCCDuplicate-invoice + amount checks
Tolerances: SPRO-PE / OMR6-PP / OMC0-VP (1N + 1P Gate 2)ME21N / MIRO / MIGO"How much price/qty variance is acceptable before SAP blocks?" — no rules = NOTHING postsCCPO save, invoice post, GR post checks

🏠 Layer 3 — Org Units & Master Data (Module: MM · "rooms and furniture you use daily")

ConfigNeeded byPurpose in plain wordsMust exist BEFOREFeeds into
OX10+OX18 Plant→CC (Steps 3-4)All MM activityThe factory/warehouse + "whose books does it post to"CCMaterials, stock, MRP, MIGO derive CC from plant
OX09 Storage Locations (Step 5)MIGOWHERE inside the plant the stock physically sits (RAWM, FG01…)PlantStock per bin area; MMBE views
OX08+OX01+OX17+OMKI Purch Org (Steps 8-12)PR/POWHO buys (OX08), for which company (OX01), for which plants (OX17 M:M), and which is each plant's DEFAULT (OMKI 1:1)CC + plantsVendor purchasing views (LFM1), info records, every PO header
BP config: BUCF/BUC2/CVI/XKN1/OBAS (Step 18)Vendor creationNumbering + the bridge that auto-creates classic vendor records (LFA1/LFB1/LFM1) when you save a BPAccount groupsEvery vendor → used in source lists, info records, POs
Material Master (MM01)Whole P2PWHAT you buy/stock/value — views per area (Basic/Plant/Purchasing/Accounting)Org units + OMS2 + valuation class (OMSK)PR/PO/MIGO/MIRO all read it; Accounting view drives OBYC
ME11 Info RecordPO pricing"Vendor X sells material Y at price P" — auto-fills PO priceMaterial + vendorPO net price; updated back by each PO (Info Update flag)
ME01 Source List (Scenario 14)Source determinationThe APPROVED-vendors list per material+plant; Fixed flag = auto-pickMaterial + vendor (+info rec)PR/MRP auto vendor selection
🎯 The one-line summary of ALL of this:
MIGO Post button → reads Material's valuation class (Layer 3) → via plant's VGC finds OBYC rule (Layer 2) → posts to G/L accounts that must exist in the CC, into an open period, numbered from a FBN1 ticket roll, recorded in the Universal Journal + Material Ledger (Layer 1). One click — seven configs fire. When ANY link is missing, you get one of the 9 Gauntlet errors in the Issues section below.
1A. Create the CC shell — OX02 (direct create, not EC01 copy)

What this does: Creates the bare CC record in table T001 with its identity — code, name, country, currency, language, address. Nothing else yet; no variants linked.

Why direct create (and NOT EC01 / Copy CC): EC01 ("Copy Company Code") brings dependent customizing from the source CC. Convenient — but in learning you do not know what got copied silently, so when something fails later you cannot pinpoint why. Direct create via OX02 = you explicitly own every assignment. Recommended for learning. Real projects often use EC01 for speed.

Action sequence:

  1. Run OX02
  2. Two options appear — click "Edit Company Code Data" (NOT "Copy, delete, check")
  3. Click "New Entries" (or Ctrl+F4)
  4. Fill the 6 identity fields below
  5. Click the "Address" button (icon at top) → fill the address screen → Enter to confirm
  6. Back on the main row, save (Ctrl+S) → save as Local Object ($TMP) for learning, or to a Transport Request for real projects
  7. Repeat for CC PSAE (UAE entity, AED currency)

Identity fields:

Section · FieldFillWhat the field asks (plain words)Why we choose this — and the impact if wrong
Company code identity — Edit Company Code Data (OX02)
Company Code*PSPK (PK) · PSAE (UAE)What short code names this legal company? Like the registration number on a company's file — it stamps every document to this entity.A 4-character ID printed on every FI document for the life of the company; PSPK = PakSteel Pakistan, PSAE = PakSteel UAE keep the two entities' books clearly apart. Impact: it cannot be changed after the first posting, so a wrong or throwaway code is permanent.
Company Name*PakSteel Industries (Pvt) Ltd · PakSteel Trading FZ-LLCThe full legal name of the company, exactly as registered with the authorities.Appears on tax and statutory documents, so it must match the SECP (Pakistan) / DED (UAE) registered name. Impact: a mismatch makes printed invoices and tax returns legally wrong.
City*Karachi · DubaiThe company's registered city.Feeds tax determination and prints on output documents. Impact: a wrong city can drive the wrong tax result and misstate the address on legal paperwork.
Country*PK · AEWhich country's laws does this company file under? This one choice switches on a whole country's rulebook.Drives every country-specific behaviour — tax codes, statutory reports, language defaults. Impact: it cannot practically be changed later, and a wrong country is a legal/audit disaster (wrong tax and reporting for the whole entity).
Currency*PKR · AEDWhich currency are this company's books kept in? Like deciding the money the accounts are counted in.This is the statutory (local) books currency — pick the country's own currency, not the parent's reporting currency. Impact: once documents are posted, changing it is a multi-month conversion project, so a wrong currency is very costly to undo.
Language*EN (both)The default language for screens and printed output.EN is the working language here; Urdu/Arabic wording is added later on the material/customer master where needed. Impact: only the default text language — postings still work, but outputs default to the wrong language if set wrong.

Address fields (click Address button):

Section · FieldFillWhat the field asks (plain words)Why we choose this — and the impact if wrong
Address screen (PSPK example)
Street + House No.Plot 12-A, Industrial Area, KorangiThe street and building line of the company's address — what a courier reads to find the door.Prints on PO and invoice outputs so documents carry a real address. Impact: a blank or wrong street only makes printed documents look incomplete; it does not block posting.
Postal Code74900The postal (ZIP) code of the address.SAP treats it as part of a valid, complete address. Impact: missing it can trigger an "address incomplete" warning and weakens address-based output.
Region*SD (Sindh)Which province/state the company sits in? Country-dependent — Pakistan needs it because tax is set per province.Drives provincial sales tax (SRB Sindh, PRA Punjab, KPRA, BRA). Impact: the wrong region charges the wrong province's sales tax on documents — a real tax error.
Time ZonePKST (UTC+5)The local time zone of the company.Stamps the time on documents; matters when comparing entries across countries (PSPK vs PSAE). Impact: a wrong zone skews document timestamps in multi-country reporting.
Tax Number 1 (NTN)1234567-8 (field STCD1)The company's main government tax ID — in Pakistan the FBR National Tax Number (NTN).Prints on tax invoices as proof of registration. Impact: a wrong or missing NTN makes the tax invoice invalid for the buyer to claim input tax.
Tax Number 2 (STRN)03-99-9999-001-46 (field STCD2)The second tax ID — Pakistan's Sales Tax Registration Number (STRN).Required on business-to-business (B2B) tax invoices. Impact: without it a B2B sales-tax invoice is not compliant.

Common errors at 1A (full fixes in the Issues section): "Company code already exists" → pick another code or delete via OX02 · "Currency XXX not defined" → OY03 (PKR/AED usually pre-delivered) · "Country XX not maintained" → table T005, rare in IDES · "Choose Transport Request" → click Local Object ($TMP) for learning.

Verify 1A: Run SE16N → table T001 → BUKRS = PSPK → one row with BUTXT, LAND1, WAERS populated. KTOPL/PERIV/FSTVA are still empty — they get filled in 1E.

1B. Create Posting Period Variant — OBBP or SM30 view V_T010O

What this does: Creates just the name of the variant (e.g., "PSPK"). Think of it as an empty folder — the actual period rules get added in 1C via OB52.

Why it's a separate object: Multiple CCs can share one Posting Period Variant. If PSPK and PSAE follow the same close calendar, they can share one. SAP stores it independently from the CC so it's reusable.

Action sequence (primary — OBBP):

  1. Run OBBP
  2. Click "New Entries"
  3. Posting Period Variant: PSPK
  4. Name: PakSteel PK Periods
  5. Save
  6. Repeat for PSAE / "PakSteel UAE Periods"

If OBBP shows no "New Entries" button (restricted view in S/4HANA):

  1. Run SM30
  2. Table/View name: V_T010O
  3. Click Maintain → New Entries → same fields as above
  4. Save

💡 SM30 universal fallback: Whenever a T-code restricts editing in S/4, SM30 on the underlying view name almost always works. Useful views: V_T010O (period variant), V_T001B (period rules), V_T004V (field status), V_001S (plants).

1C. Open the actual posting periods — OB52

What this does: Now that variant PSPK exists (from 1B), tells SAP "for variant PSPK, periods 1-12 of years 2025-2030 are OPEN for posting." Without this, every posting fails with "period not open."

Why so many years: Closing periods is a real business decision (month-end close). For learning, open broadly so nothing blocks you. Real projects open only current + previous month.

Action sequence:

  1. Run OB52
  2. Click "New Entries"
  3. Add 6 rows (one per Account Type) — see table below
  4. Save

The 6 rows to add for variant PSPK:

VarAFrom AcctTo AcctFrom PerYearTo PerYear
PSPK+blankblank12025122030
PSPKA0ZZZZZZZZZZ12025122030
PSPKD0ZZZZZZZZZZ12025122030
PSPKK0ZZZZZZZZZZ12025122030
PSPKM0ZZZZZZZZZZ12025122030
PSPKS0ZZZZZZZZZZ12025122030

Field meanings:

Section · FieldFillWhat the field asks (plain words)Why we choose this — and the impact if wrong
OB52 — one row per account type
VariantPSPKWhich posting-period calendar does this rule belong to? Like writing which shop's opening-hours sheet you are filling in.Must be the same variant name OBY6 points the company code at in 1E. Impact: a mismatch means the CC's postings check a different (or empty) calendar and fail with "posting period not open".
A (Account Type)+, then A D K M SWhich kind of account does this open-period row cover? Like separate open/closed signs on different counters.+ = all accounts; A = Assets, D = Customers, K = Vendors, M = Materials, S = G/L. Splitting by type lets you close, say, vendor postings before G/L at month-end. Impact: a missing type row leaves that account type blocked even when others are open.
From Accountblank when A=+, else 0The first account number in the range this row opens.When A = + (wildcard) it MUST be blank — the wildcard already means "all accounts" and a range would contradict it; for a specific type use 0 as the low end. Impact: typing a number while A=+ triggers "Do not enter an account for a masked account type" and the save fails.
To Accountblank when A=+, else ZZZZZZZZZZThe last account number in the range this row opens.Same rule — blank for the + wildcard row, ZZZZZZZZZZ (the highest value) for a specific type so the whole range is covered. Impact: a too-small "to" value silently leaves higher-numbered accounts closed.
From Period 1 + Year1 / 2025The earliest month (and its year) that is open for posting.Period 1 = January under the K4 calendar-year fiscal variant; 2025 is an early start so nothing before today is blocked. Impact: set it too late and older documents cannot be posted ("period not open").
To Period 1 + Year12 / 2030The latest month (and its year) that is open for posting.12 = December; year 2030 leaves plenty of buffer so you never hit a closed future period while learning. Impact: too small a "to" period or year blocks postings dated after it.
From Period 2blank (skip)The first special period (13–16) open for year-end adjustments.Special periods are extra "month 13–16" buckets used only for year-end closing entries; leave blank for learning. Impact: none for normal postings — only matters if finance posts year-end adjustments.
To Period 2blank (skip)The last special period (13–16) open for year-end adjustments.Same — leave blank now. Impact: none unless special-period year-end postings are used.

Common error: "Do not enter an account for a masked account type" → you typed numbers in From/To Account when A = +. Clear those fields.

Verify 1C: SE16N → table T001B → variant PSPK → 6 rows visible. Repeat for variant PSAE (6 more rows).

1D. Create Field Status Variant — OBC4 (copy from 0001)

What this does: Field Status Variant (FSV) = the master rulebook saying "for this type of G/L, field X is mandatory, field Y is optional, field Z is hidden." Every FI posting checks against this.

Why COPY from 0001 (not create blank): SAP-delivered variant 0001 contains 80+ field status groups (G001 bank, G003 material consumption, G007 inventory, G030 reconciliation, etc.). Building these from scratch = days of work, easy to break. Copy gives you the full SAP-blessed template ready to use.

Action sequence:

  1. Run OBC4
  2. Select existing variant 0001
  3. Click "Copy As..." (F6) — small copy icon in toolbar
  4. Change variant key to PSPK, name to PakSteel PK FSV
  5. Press Enter → popup asks "Copy all dependent entries?" → click Copy all (copies all 80+ groups in one go)
  6. Save
  7. Repeat: copy 0001 → PSAE, name "PakSteel UAE FSV"

If variant 0001 not in your client (rare in IDES): ask Basis to copy from client 000 via SCC1, OR copy any other variant present (they all have the same field status groups).

Verify 1D: OBC4 → double-click variant PSPK → 80+ field status groups visible.

1E. Link all variants to CC — OBY6 (Global Parameters)

What this does: ONE screen that shows ALL the CC's financial assignments. Connects PSPK to: Chart of Accounts, Fiscal Year Variant, Posting Period Variant (from 1B/1C), Field Status Variant (from 1D), and a few smaller settings.

Why one screen, not 5: You could use OB62 (chart), OB37 (FY), OBBP_ASSIGN (period variant), OBC5 (field status) separately. OBY6 collapses them into one view — easier to verify, faster to set up.

Action sequence:

  1. Run OBY6
  2. Select CC PSPK → click 🖉 Details (or double-click the row)
  3. Fill the fields below
  4. Save
  5. Repeat for PSAE
Section · FieldFillWhat the field asks (plain words)Why we choose this — and the impact if wrong
OBY6 — Global Parameters (PSPK)
Chart of AccountsINTWhich master list of G/L account numbers does this company use? Like choosing which numbered filing system the books follow.INT is SAP's international chart and works for Pakistan; it supplies every G/L number the CC can post to. Impact: without a chart no G/L posting is possible at all — the CC cannot record a single accounting line.
Country Chart of AcctsblankAn optional second, country-specific chart for local statutory reporting.Only needed when local GAAP requires its own account numbers alongside INT; not needed for learning. Impact: none here — leaving it blank simply means you report on the one INT chart.
Credit Control AreablankWhich area manages customer credit limits for this company?Used only if you block or monitor customer credit (a sales-side feature). Impact: none for our purchasing focus — blank just means no credit checks run.
Fiscal Year VariantK4What shape is the company's financial year? Like choosing whether the year runs Jan–Dec or some other 12 months.K4 = January–December calendar year, standard for Pakistani private companies (government bodies use Jul–Jun = V3). Impact: it is hard to change after postings, and a wrong shape misaligns every period and report with the real accounting year.
Posting Period VariantPSPKWhich set of open/closed month rules governs this company's postings?Names the period calendar (PSPK) whose open months gate every posting date. Impact: this link is what makes SAP check each posting's date against your open months; blank or wrong = date checks fail or use the wrong calendar, and postings are rejected.
Field Status VariantPSPKWhich rulebook decides, per account type, whether each field is required, optional or hidden when posting?Links the CC to the field-status rules (variant PSPK) that validate every FI line — e.g. forcing a cost object on an expense line. Impact: without this link SAP errors "no field status variant assigned" and no FI document can be entered.
VAT Registration Numberblank for PKThe EU-style VAT registration number of the company.An EU concept; Pakistan identifies tax registration through NTN/STRN on the address tab (set in 1A), not here. Impact: none for Pakistan — correctly left blank.
Document Entry Screen Variant2Which posting-screen layout do clerks see? Like choosing which version of the entry form to show.Variant 2 is the standard layout that keeps cost-accounting fields visible, which you need for CO-relevant postings. Impact: a layout hiding those fields would make clerks miss cost-object entry on relevant lines.
Maximum Exchange Rate Deviation10 %How far off the official daily rate may a manual exchange rate be before SAP warns?10% flags a posting whose rate is more than 10% away from the OB08 daily rate — a typo guard. Impact: set too high and fat-finger rate errors slip through; too low and normal fluctuations nag constantly.
Workflow VariantblankWhich approval-workflow rules apply to this company's documents?Only needed if you route documents for electronic approval; not used in learning. Impact: none here — blank means no approval workflow is triggered.

Common errors at 1E: "Chart of Accounts INT not defined" → OB13 (delivered in IDES) · "Fiscal Year Variant K4 not defined" → OB29 (SAP standard) · "Posting Period Variant PSPK not defined" → you skipped 1B · "Field Status Variant PSPK not defined" → you skipped 1D.

Verify 1E: Re-open OBY6 → PSPK → all fields show your values. Or SE16N → T001 → fields KTOPL, PERIV, XPERV, FSTVA all populated for PSPK.

1F. Create FI Document Number Ranges — FBN1 (manual, most reliable)

What this does: Every FI document (vendor invoice, payment, GR posting, GI, journal) needs a unique number. Number ranges = the "pools" SAP draws from. Without these, FI postings fail with "Document number not in range XX defined for CC YYYY."

Why this is the #1 missed step: Number ranges are NOT auto-created with a new CC. OX02 only writes to T001; ranges in table NRIV stay empty. SAP delivers them for CC 0001 — your new CC starts empty.

Why OBH1 (copy from 0001) often does nothing in S/4HANA: Modern S/4 restricts cross-CC copy of number ranges for transport safety. The transaction "succeeds" silently without copying. Manual FBN1 is more reliable.

Action sequence (manual):

  1. Run FBN1
  2. Company Code: PSPK
  3. Click "Change Intervals" (NOT "Maintain Groups")
  4. For each range below, click "Insert Interval" (Shift+F1) → enter values → Enter
  5. Save (truck icon) → dismiss "Transport Number Range Intervals" info popup with ✓
  6. Repeat all ranges for CC PSAE

The 8 ranges to create (use Year 9999 for evergreen — no future maintenance):

No.YearFrom NumberTo NumberDoc Types using thisPurpose
01999919000000001999999999KR, KGVendor invoice / credit memo (MIRO)
15999915000000001599999999KZVendor payment (F110, F-53)
17999917000000001792000999ABClearing documents
19999951000000005199999999RE, RNLogistics invoice verification
39999939000000003999999999SA (in some IDES)G/L doc — used in many IDES for F-02 SA type
49999950000000005099999999WEGoods Receipt (MIGO mvt 101)
50999949000000004999999999WA, WI, WLGoods Issue / inventory movements
519999100000000199999999SA, SKG/L document (general journal)

⚠️ Why range 39 is included: Many IDES installations map doc type SA (G/L journal) to range 39 instead of 51 via OBA7. To be safe, create BOTH. To verify which range your SA actually uses: OBA7 → SA → check "Number range" field.

⚡ IMPORTANT — Year column behavior: The Year column is YEAR-SPECIFIC, not "valid through." If you enter 2030, the range is ONLY valid for fiscal year 2030 — postings in 2026 fail with "number range XX missing for year 2026". Best practice: use Year 9999 — SAP treats this as "valid for ALL fiscal years" (evergreen).

Field meanings: No. = range key (must match doc type's OBA7 mapping) · Year = use 9999 evergreen · From/To Number = 10-digit pool boundaries · Current Number = leave 0 · Ext (External Flag) = leave UNCHECKED for MM (SAP auto-assigns).

Popups you'll see: "Define Selection Options" (OBH1) → click = · "Variant Attributes" (OBH1) → F3 to back out, do NOT save · "Transport Number Range Intervals" (info) → dismiss with ✓ (ranges deliberately do NOT transport, to protect production's current-number counter).

Verify 1F: FBN1 → CC PSPK → Change Intervals → all 8 ranges visible with Year 9999. Or SE16N → table NRIV → SUBOBJECT = PSPK → 8 rows.

1G. Configure FI Tolerance Groups — OBA4

What this does: Sets posting authority limits per user. SAP needs to know "how much can this user post in a single document, and what payment differences are acceptable?" The blank group is the default catch-all for any user not assigned to a specific group.

Why mandatory: Without ANY tolerance group, users either get blocked entirely OR can post unlimited amounts (audit nightmare).

Action sequence:

  1. Run OBA4
  2. Click "New Entries"
  3. Fill all fields below
  4. Save → Repeat for PSAE (currency AED)
Section · FieldFillWhat the field asks (plain words)Why we choose this — and the impact if wrong
Who and where these limits apply
Group(BLANK)Which set of users do these limits apply to? Blank means the default "catch-all" group.A blank group automatically covers every user not put in a specific named group, so one row governs everyone during learning. Impact: with no tolerance group at all, users are either blocked from posting or (worse) can post unlimited amounts — an audit risk.
Company CodePSPKWhich company code do these limits belong to?Ties the limits to PSPK only, so PSAE keeps its own. Impact: a wrong CC leaves PSPK postings with no limits and may leave PSAE uncovered.
CurrencyPKR (auto)Which currency are the money limits below expressed in?Defaults from the CC (PKR for PSPK); every amount limit below is read in this currency. Impact: if it were wrong, a "9999.99" limit would mean a different real value than intended.
Upper limits for posting procedures
Amount per document9999999999.99The biggest total a single FI document may reach. Like a ceiling on one whole receipt.~10 billion PKR is effectively unlimited, so nothing blocks you while practising (real projects tier this per role). Impact: set it low and a large but valid posting is rejected as "amount exceeds limits".
Amount per open item account item9999999999.99The biggest amount allowed on one single line within a document.Kept effectively unlimited for practice. Impact: too low and a legitimate large line is blocked even when the document total would be fine.
Cash discount per line item10.00 %The most cash discount a user may grant on one line.10% is a generous practice cap on early-payment discounts. Impact: too low blocks normal discounts; too high lets a clerk give away margin by mistake.
Permitted payment differences — Revenue (when receiving money)
Amount9999.99The biggest rupee over/under-payment auto-accepted when a customer pays. Like ignoring small change on a bill.e.g. ₨50,005 received against a ₨50,000 invoice = the ₨5 difference is cleared automatically instead of left hanging. Impact: too low and tiny differences pile up as open items to chase; too high and real short-payments get written off silently.
Percent10.00 %The same tolerance, but as a percent of the amount.SAP accepts the smaller of the amount and percent limits, so 10% guards small invoices. Impact: too high a percent could auto-write-off a big shortfall.
Cash discount adjustment99.99How much the cash-discount figure may be adjusted in this (revenue) direction.Left generous for practice. Impact: too tight blocks normal discount rounding on incoming payments.
Permitted payment differences — Expense (when paying money)
Amount9999.99The biggest rupee difference auto-accepted when you pay a vendor slightly off the invoice.e.g. ₨49,995 paid against a ₨50,000 invoice = the ₨5 difference is cleared automatically. Impact: too low leaves tiny residuals as open items; too high hides real underpayments.
Percent10.00 %The same paying-side tolerance as a percent.Caps the auto-accepted gap on small invoices. Impact: too high could silently absorb a large underpayment.
Cash discount adjustment99.99How much the cash-discount figure may be adjusted on the paying side.Generous for practice. Impact: too tight blocks normal discount rounding on outgoing payments.

How users get assigned to a tolerance group: SU01 → user → Parameters tab → parameter TGR. If blank, user falls into the blank default group automatically.

💡 Real-world tiering: Junior buyer = 1M PKR/doc · Manager = 10M · Director = 100M · CFO = unlimited. Each tier = its own group, assigned per user via SU01.

Verify 1G: SE16N → table T043T → CC PSPK → one row with all your values.

1H. ⚡ S/4HANA ONLY: Assign CC to Leading Ledger + Accounting Principle — FINSC_LEDGER
⚡ S/4HANA-SPECIFIC — Not needed in ECC. This is the #1 trap when migrating from ECC habits to S/4HANA. F-02 + MIGO + MIRO all fail with the cryptic error "Correct the Customizing settings for ledgers for the universal journal" until this is done.

What this does: S/4HANA uses the Universal Journal (table ACDOCA) — a single unified ledger replacing the separate FI + CO + ML tables from ECC. Every Company Code must be: (1) assigned to a Ledger (default Leading Ledger = 0L), and (2) linked to an Accounting Principle (IFRS, Local GAAP, etc.).

Why mandatory: ACDOCA stores every posted line with a ledger + accounting principle reference. Without these for your CC, the Universal Journal engine rejects all postings.

Action sequence:

  1. Run FINSC_LEDGER (or SPRO → FI → FA Global Settings → Ledgers → Ledger → Define Settings for Ledgers and Currency Types)
  2. On the Ledger overview, click row 0L (Leading Ledger) to highlight it
  3. In the LEFT tree, double-click "Company Code Settings for the Ledger"
  4. Check if PSPK is already in the list (0001, 1000, 2000 etc. usually are)
  5. If PSPK is NOT listed → New Entries, add row with values below
  6. If PSPK IS listed but Accounting Principle is BLANK → click the cell → type 60 → Enter
  7. Save (Ctrl+S) → Local Object / TR
  8. Repeat for PSAE (or use EC01 copy method — see 1M)
Section · FieldFillWhat the field asks (plain words)Why we choose this — and the impact if wrong
Company Code Settings for Leading Ledger 0L
Company CodePSPKWhich company code are you registering in the Universal Journal ledger?Adds PSPK to leading ledger 0L so its postings are accepted by the S/4HANA journal (table ACDOCA). Impact: if PSPK is not listed here, every F-02 / MIGO / MIRO fails with "correct the Customizing settings for ledgers for the universal journal".
Fiscal Year VariantK4What financial-year shape does the ledger use for this CC?Must be the same K4 the CC already uses in OBY6, so the ledger and the CC agree on when each period starts and ends. Impact: a different variant here makes the ledger and the CC disagree on periods, and postings are rejected as inconsistent.
Posting Period VariantPSPKWhich open/closed-month calendar does the ledger use for this CC?Must match the PSPK variant from OBY6 so the ledger checks dates against the same open months. Impact: a mismatch causes "posting period variant empty/inconsistent" errors and blocks postings.
Accounting Principle60 (typically IFRS in IDES)Which accounting rulebook does this company report under — IFRS, local GAAP, etc.? Like declaring which accounting standard the books obey.S/4HANA stores every journal line against an accounting principle; 60 is usually IFRS in IDES (use F4 to see your system's options). Impact: this is the critical field — missing or wrong and the journal engine rejects all postings ("customizing is inconsistent: postings not possible").
1st FI Currency10Which currency type is the ledger's first (main) currency? 10 = company-code currency.10 means the ledger records values in the CC's own currency (PKR for PSPK), and it must line up with the Material Ledger currencies in 1O. Impact: a currency-type mismatch with the ML causes error FML_CUST033 when you start the Material Ledger.
2nd FI Currency(blank or 30)An optional second currency the ledger also records in — 30 = group currency.Only needed for multi-currency group reporting; leave blank for a simple learning setup. Impact: none if blank; if you add it, it must also match the Material Ledger's currency types.

Common errors at 1H: "Accounting principle 60 not defined" → F4 in cell, pick from your IDES (may be 01, IFRS, LGAAP) · "Posting period variant empty" → 1B not done · "Consistency check warnings about other CCs" → pre-existing IDES issues, dismiss with ✓ · "Customizing is inconsistent: Postings of journal entries not possible" → Acctg Principle missing/wrong.

Verify 1H: Run SE16N → table FINSC_LD_CMP → BUKRS = PSPK → one row with RLDNR = 0L and ACCOUNT_PRINCIPLE filled.

1I. ⚡ S/4HANA ONLY: Classify G/L Accounts for Document Splitting — SPRO path
⚡ S/4HANA-SPECIFIC — Required if Document Splitting is active (default in most S/4 implementations). F-02 fails with "There is no item category assigned to account XXXXXX/INT" until classified.

What this does: Document Splitting splits every FI doc by characteristics (Profit Center, Segment, Business Area) for fine-grained reporting. To work, every G/L account must be classified into an Item Category (Cash, Vendor, Customer, Material, Asset, Expense, Revenue, etc.). The splitter uses the category to decide HOW to allocate the line.

Why mandatory: Without classification, the splitter doesn't know what kind of account a G/L is → rejects the posting.

Important — this is CHART-LEVEL config: Once you classify a G/L for chart INT, it applies to ALL CCs using INT. You do this ONCE for the chart, not per CC. PSAE benefits automatically.

Action sequence:

  1. Run SPRO → click SAP Reference IMG
  2. Navigate: Financial Accounting → General Ledger Accounting → Business Transactions → Document Splitting → Classify G/L Accounts for Document Splitting
  3. Click 🕓 execute icon
  4. Chart of Accounts: INT → Enter
  5. Click New Entries → add classifications (ranges save time):
Account fromAccount toCategoryCovers
10000012999904000 Cash AccountPetty cash, bank accounts
14000014999902000 CustomerAR reconciliation accounts
16000016999903000 VendorAP reconciliation accounts
19100019999901000 Balance SheetGR/IR clearing & other clearing
30000039999906000 MaterialRaw materials, trading goods, inventory
79000079200006000 MaterialUnfinished + finished goods
40000049999920000 ExpenseConsumption, expenses (when created)
80000089999930000 RevenueSales revenue (when created)

Save (Ctrl+S) → Local Object / TR. If category codes differ: press F4 in the Category field — different IDES/S4 versions use different numbering. Pick by NAME ("Cash Account", "Vendor", "Material").

Common errors at 1I: "View V_FAGL_SPLITGL not in directly" → use the SPRO IMG path (view name varies by release) · "Category 04000 not defined" → F4, pick valid code · Document Splitting node missing → expand "Business Transactions" first, or try Financial Accounting → FA Global Settings → Document → Document Splitting.

Verify 1I: SE16N → table T8G17A → KTOPL = INT → your classifications visible. Better: try F-02 (Step 2) — if it posts, classifications work.

1J. Extend G/L Accounts from Chart to Your CC — FS00

What this does: G/L accounts exist at TWO levels:

TableLevelContents
SKA1Chart of Accounts (e.g., INT)The "template" definitions for all CCs using this chart
SKB1Company Code (e.g., PSPK)The CC-level instance that's actually usable for posting

When you create a new CC via OX02, its SKB1 is EMPTY. You must extend chart-level G/Ls down to your CC before any FI posting can use them. FS00 is the T-code.

How many G/Ls to extend now: minimum for the F-02 smoke test (Step 2) = just 2 (bank/cash); for the full MM journey = ~15-20 (cash, vendor recon, customer recon, GR/IR, inventory, consumption, revenue).

Action sequence (per G/L):

  1. Run FS00
  2. G/L Account: 100000 · Company Code: PSPK
  3. Click "Create with Template" icon (paper-with-pencil at top)
  4. Reference popup: G/L Account 100000 (same) · Company Code 0001 (or 1000, 2000 if 0001 lacks it)
  5. Press Enter → all tabs auto-populate from source
  6. Quick review: Type/Description (name, account group) · Control Data (Account currency PKR or blank, Line Item Display ✓, Sort Key 001) · Create/bank/interest (Field Status Group = G005 Bank or G001 General)
  7. Save (Ctrl+S) → success: "Account 100000 was created in PSPK"

Minimum 2 G/Ls for F-02 (do these now):

G/L #INT chart nameUse in F-02
100000Petty cashLine 1 debit (PstKy 40)
113100Bank 1 (domestic)Line 2 credit (PstKy 50)

Full set for all MM scenarios (extend as you reach each scenario):

G/L #Name (INT chart)Needed for
100000Petty cashF-02, expense advances
113100Bank 1 (domestic)F-02, F-53 payments
113200Bank 2Multi-bank scenarios
140000AR domestic (Customer recon)Inter-co STO (Sc 8), 3rd-party (Sc 12)
160000AP domestic (Vendor recon)ALL P2P scenarios (MIRO → vendor balance)
191100GR/IR clearing ext procCRITICAL — every GR + IV
300000Raw material 1Stock procurement (Sc 1)
300010Raw material 2Alternative raw mat
303000Operating suppliesSpare parts, MRO
304000Spare partsReturn scenarios (Sc 2)
310000Trading goodsConsignment (Sc 10)
790000Unfinished productsWIP, subcontracting (Sc 9)
792000Finished goodsSTO (Sc 7,8), production
177000Withholding tax payableWHT scenario (Sc 24)
176000Salaries payablePayroll-related
2000BuildingsAsset procurement (Sc 6)
11000Machinery & equipmentAsset procurement (Sc 6)

Bulk method (15+ G/Ls): FS15 (Send G/L Master via ALE) or copy all SKB1 entries from a source CC.

Common errors at 1J: "Account XXXXXX does not exist in chart INT" → not in SKA1; SE16N → SKA1 → KTOPL=INT to see what exists · "Account XXXXXX does not exist in source CC 0001" → try a different source CC (SE16N → SKB1 → SAKNR=XXXXXX shows which CCs have it) · "Field Status Group G005 not defined in variant PSPK" → re-copy FSV from 0001 via OBC4.

Verify 1J: SE16N → table SKB1 → BUKRS=PSPK → rows visible for extended G/Ls.

1K. ⚡ MM Period Initialization — OMSY (per CC, required for ANY material creation)
⚡ CRITICAL — Easy to miss — Without OMSY, MM01 or MIGO error with: "The company code PSPK does not exist or has not been fully maintained". This is misleading — the CC exists in FI (your F-02 works!), but MM has its OWN per-CC period tracking, separate from OBY6/OB52. OMSY initializes it.

What this does: OMSY sets the CURRENT period for Materials Management (per CC, per year). This is separate from FI posting periods (OB52) — MM tracks its own "current month" for material valuation, stock movements, period closing.

Why it's separate from OB52: MM has its own monthly closure cycle (MMPV) and needs its own period state per CC. Without OMSY, MM doesn't know "what month is open" → blocks ALL material activity.

Action sequence:

  1. Run OMSY (or SPRO → MM → Logistics General → Material Master → Basic Settings → Maintain Company Codes for Materials Management)
  2. Find your CC. PSPK is likely NOT initialized yet (no Year/Period set)
  3. Click the PSPK row → enter values directly OR click New Entries if PSPK not listed
  4. Fill the fields below
Section · FieldFillWhat the field asks (plain words)Why we choose this — and the impact if wrong
OMSY — MM period initialization (per CC)
Company CodePSPKWhich company code are you switching the MM month-clock on for?MM keeps its own current-period clock per CC, separate from FI's OB52. Impact: if PSPK has no OMSY row, MM01 and MIGO fail with "company code PSPK not fully maintained" even though FI works.
Yearcurrent year (e.g. 2026)Which fiscal year is MM's clock starting in?Sets the MM current year to today's fiscal year. Impact: a wrong year leaves MM out of step with the calendar, so goods movements dated in the real month are blocked.
Pe (Period)current month (e.g. 6 for June)Which period (month) is MM's clock starting on? Like setting today's month on the stock system's calendar.Must be the current calendar month so goods movements dated today are allowed. Impact: a wrong period gives "period not allowed" on every material posting.
FYr (1st)blank (or 0)The fiscal year of the previous MM period.Leave it blank at initial setup; SAP fills and advances it automatically at each MMPV period close. Impact: none now — hand-typing it risks a value that disagrees with what MMPV would set.
M. (previous period)blank (or 0)The period (month) number of that previous MM period.Same — SAP maintains it automatically after the first MMPV run. Impact: none at setup.
FYr (2nd)blank (or 0)A further previous-period fiscal-year counter SAP keeps for its period history.Also filled automatically by period close; leave blank now. Impact: none at setup.
LM (last month)blank (or 0)A further previous-period ("last month") counter SAP keeps.Also maintained automatically by MMPV; leave blank now. Impact: none at setup.
ABp (Allow Backposting)✅ CHECKEDMay postings be made into the previous period? Like allowing a late entry to be dated to last month.Ticking it lets you, e.g., post a May invoice in June while May is still being closed. Impact: unticked, any document dated in the previous period is rejected.
DBp (Disallow Backposting)❌ UNCHECKEDThe opposite switch — forbid posting into the previous period?It is mutually exclusive with ABp, so leave it off when ABp is on. Impact: tick both and the save fails with "this combination of entries does not make sense".

Repeat for PSAE — same year + period (and same ABp/DBp settings). Save (Ctrl+S) → Local Object / TR.

Common errors at 1K: "This combination of entries does not make sense" → both ABp and DBp checked; uncheck DBp · "Period 6 not allowed" → must match current calendar month + valid year · "Entry already exists" → OMSY run before, check Display mode · "Cannot save with no posting period variant" → OBY6 (1E) didn't assign PPV.

💡 Monthly task going forward (FYI): OMSY is initial setup. Each month, run MMPV (Close Period for Materials) to advance the MM period (6→7, 7→8…). For learning you can skip MMPV — just set OMSY with the current period. Relationship: OMSY = initial setup (once) · MMPV = advance monthly · MMRV = display current period.

Verify 1K: Run MMRV → enter CC PSPK → shows current + previous period. Or SE16N → table MARV → BUKRS=PSPK → row exists with PERYR and PERIO set.

1L. ✅ Verify CC is FULLY FUNCTIONAL — 10-point check

Run these 10 checks IN ORDER. If all pass, the CC is ready for plant creation (Step 3). If any fails, the table tells you which sub-step to revisit.

#T-code / TableWhat to checkPass criteriaIf fails → revisit
1OBY6All 4 variants assignedChart of Accounts, FY Variant, Posting Period Variant, Field Status Variant all filled for PSPK1E (and 1B/1D if variants missing)
2OB52Current period openToday's date falls within an open period row for variant PSPK1C
3OBC4Field Status Variant PSPK exists80+ field status groups visible inside PSPK1D
4FBN1Number ranges exist for current FYRanges (01, 15, 17, 19, 39, 49, 50, 51) visible with Year covering current FY (use 9999 for evergreen)1F
5OBA4Tolerance group existsOne row for CC PSPK with all values populated1G
6 ⚡FINSC_LEDGER / SE16N FINSC_LD_CMPCC assigned to ledger 0LPSPK row with Acctg Principle = 60 (or IFRS)1H
7 ⚡SE16N T8G17AG/L doc splitting classificationsRows for chart INT covering ranges 100000-129999 (cash), 160000-169999 (vendor), etc.1I
8SE16N SKB1G/L accounts extended to PSPKAt least 100000 + 113100 visible for BUKRS = PSPK1J
9 ⚡MMRV / SE16N MARVMM period initializedPSPK row shows current Year + Period (e.g., 2026/6) — required for material creation1K
10F-02Test post a G/L journal1000 PKR doc saves with a number → CC fully worksStep 2 covers this in detail

Quick database-level sanity check: SE16N → table T001 → BUKRS = PSPK. The row should show: BUKRS=PSPK · BUTXT=PakSteel Industries · LAND1=PK · WAERS=PKR · KTOPL=INT · PERIV=K4 · XPERV=PSPK · FSTVA=PSPK.

If all 10 checks pass → the CC is FULLY FUNCTIONAL for both FI AND MM. Move to Step 2 (F-02 smoke test) or directly to Step 3 (Plants).

1M. 🚀 BONUS: Create the 2nd+ CC via EC01 Copy — skip 1A-1K for PSAE

Why use EC01: You just spent ~2 hours configuring PSPK through 11 sub-steps. Doing it all again for PSAE is painful. EC01 is SAP's official "Copy Company Code" transaction — it brings ~80% of customizing in one click. You then change only the country-specific essentials (currency, country, address, tax IDs).

🎯 OX02 direct (1A) vs EC01 copy (1M) — when to use which
MethodUse whenTimeProsCons
OX02 direct (1A)First CC, fresh system~2 hrsExplicit control over every assignment11+ sub-steps to do
EC01 copy (1M)2nd, 3rd, Nth CC after first works~10-15 minInherits all variants, ranges, tolerances, classificationsMust change country/currency/address; FINSC_LEDGER still manual

📋 What EC01 COPIES automatically

ObjectAuto-copied?Notes
CC master data (T001 row)✅ YesCreates target CC with source's settings — change identity fields after
Global parameters (OBY6 assignments)✅ YesChart, FYV, Posting Period Variant, FSV — all linked
Address tab✅ Yes (then edit)Copies PSPK's Pakistan address — overwrite with Dubai details
Number ranges (FBN1)✅ If checkbox selectedEC01 popup asks — check this option
Tolerance Groups (OBA4)✅ YesInherits same tolerances
FI Document Types (OBA7)✅ YesStandard types — same as source
Tax codes (FTXP)✅ If checkbox selected⚠️ But UAE tax codes differ from Pakistan — edit after
G/L Account extensions (SKB1)✅ If checkbox selectedHighly recommended — copies all extended G/Ls to target CC
Customizing tables (account assignments)✅ YesOBYC, FI account determination inherited
Document Splitting classifications✅ Already doneChart-level (1I) — works for any CC using INT
FINSC_LEDGER assignment❌ NO — Manual!You MUST add the target CC in FINSC_LEDGER → 0L Company Code Settings after copy. Critical S/4HANA step.
Posting Period Variant (the variant itself)⚠️ Reuses source's (PSPK)Keep sharing OR create new via OBBP then reassign in OBY6
Field Status Variant (the variant)⚠️ Reuses source's (PSPK)Usually OK to share unless different field rules needed

⚠️ What you MUST CHANGE after EC01 copy

FieldFrom PSPK (Pakistan)To PSAE (UAE)Why
Company Code keyPSPKPSAEDifferent legal entity
Company NamePakSteel Industries (Pvt) LtdPakSteel Trading FZ-LLCUAE entity name
CountryPKAEDifferent jurisdiction → different tax/legal rules
CurrencyPKRAEDLocal statutory currency for UAE — once posted, can't easily change
CityKarachiDubaiRegistered city
Region / EmirateSD (Sindh)DU (Dubai) or other Emirate codeFor UAE VAT determination
Postal Code74900UAE postal (e.g., 12345)Address validity
Time ZonePKST (UTC+5)GULFST (UTC+4)UAE is 1 hour behind Pakistan
Tax Number 1 (STCD1)NTN (FBR Pakistan)TRN (UAE Tax Reg #)Different fiscal regime
Tax Number 2 (STCD2)STRN (Pakistan Sales Tax)(blank — or UAE VAT #)Pakistan STRN doesn't apply to UAE
LanguageENEN (keep) or AR (Arabic)For Arabic outputs

🔄 EC01 Action Sequence (5-10 min)

  1. Run EC01
  2. Copy button → Source Company Code PSPK, Target Company Code PSAE
  3. Press Enter → confirmation popup with copy options. Tick ✅: Copy G/L master records · Copy number ranges · Copy tax codes · Copy account assignments. Leave unticked ☐: Copy customer master · Copy vendor master (usually empty)
  4. Execute → wait 1-2 minutes → success message lists what was copied
  5. Save (Ctrl+S) → Local Object / TR

🛠️ Post-Copy Adjustments (5-10 min)

  1. Change identity fields via OX02: select PSAE → Edit Company Code Data → Currency AED, Country AE, City Dubai, Name PakSteel Trading FZ-LLC → Address button → update street, postal, region (Emirate), tax numbers (TRN instead of NTN/STRN) → Save
  2. ⚡ Run FINSC_LEDGER for PSAE (does NOT auto-copy): Ledger 0L → Company Code Settings → New Entries → CC PSAE, FYV K4, PPV PSAE (or PSPK if sharing), Acctg Principle 60, 1st FI Currency 10 → Save
  3. Decide on Posting Period Variant: keep PSAE on PSPK's variant (simple), or create a new PSAE variant via OBBP → OB52 → reassign in OBY6 (independent)
  4. Update tax numbers: UAE uses TRN for VAT → STCD1 = UAE VAT registration; STCD2 blank

⚠️ Note: Even with EC01, the S/4HANA-specific FINSC_LEDGER step (1H) must be done manually for each new CC. Doc-splitting classifications (1I) are chart-level so apply automatically.

1N. ⚠️ CRITICAL: Tolerance Keys for a new CC — OMR6 + SPRO + OMC0
🧩 Module ownerMM — split across 3 areas: Purchasing (PE/SE keys), Logistics Invoice Verification (PP/BD/DQ/VP via OMR6), Inventory Management (B1/B2/VP via OMC0)
⚙️ Needed by processP2P — ME21N (PO save checks PE) · MIGO (GR checks VP/B1/B2) · MIRO (invoice checks PP/BD/DQ). Each transaction checks ITS OWN keys
🎯 Purpose (plain)"How much price/quantity difference is acceptable before SAP complains?" — rules are per company code; a new CC has NO rules, and for SAP no rules = nothing posts
📋 Pre-config requiredOnly the CC itself (1A). But to actually CHECK price variance, the material needs an Accounting view with a price to compare against
🔗 Links to / feedsPE compares PO price ↔ material master price (MBEW) · PP/DQ power the MIRO 3-way match vs PO+GR · resulting messages can be softened E→W via OMRM

Why this is critical: tolerance keys control price/quantity variance checks. A NEW CC has no keys, so the first PO/MIGO/MIRO fails with errors like M8 215 "Maintain tolerance limits for tolerance key PE (CoCode PSPK)" at PO save, or M8 462 "Tolerance key PP not maintained" at MIRO. This step PREVENTS them.

📋 All MM Tolerance Keys — what each controls

KeyNamePurposeUsed InRecommended (Learning)
PEPrice Variance PurchasingPO net price vs material moving avg priceME21N (PO)20% / 50,000 PKR both ways
SEStochastic ErrorsRandom sample invoice checkingME21N + MIRODo Not Check (skip)
PPPrice Variance InvoiceInvoice price vs PO priceMIRO10% / 10,000 PKR
BDForm Small DifferencesAuto-clear tiny rounding diffsMIRO1% / 100 PKR
BR% OPUn variance (IR before GR)Order price unit variance before GRMIRO5%
BW% OPUn variance (GR before IR)Order price unit variance after GRMIRO5%
DQQuantity VarianceInvoice qty vs GR qtyMIRO10% / 100 PKR
DWQty Variance when GR qty = 0Invoice without GR yetMIRODo Not Check
KWVariance from condition valueInvoice condition price checkMIRO10%
LAAmount of blanket POValidation for FO doc type (limit)ME21N20% / 100,000 PKR
LDBlanket PO time limit exceededDate validation for FO docsME21N30 days
PSPrice variance: estimated priceEstimated price checkMIRO15%
STDate variance (value × days)Late delivery × value checkMIGO + MIRODo Not Check
VPMoving average price varianceMaterial valuation alertMIRO10%
ANAmount for item without order refDirect FI invoice limitFB6050,000 PKR
APAmount for item with order refPO-based invoice limitMIRO1,000,000 PKR

🛠️ Configuration Path — Three T-codes for different tolerances

T-CodeWhat it configuresUsed For Keys
OMR6Logistics Invoice Verification tolerancesAN, AP, BD, BR, BW, DQ, DW, KW, LA, LD, PP, PS, ST, VP (Invoice context)
SPRO IMG: MM → Purchasing → Purchase Order → Set Tolerance Limits for Price VariancePO Price Variance specificallyPE, SE (PO context)
OMC0Goods Movement tolerancesB1, B2, VP (GR context)
⚠️ Common gotcha
PE is NOT visible in OMR6's F4 dropdown (only 14 keys shown). PE must be configured via the SPRO IMG path "Set Tolerance Limits for Price Variance" — NOT OMR6.

1N.1 — Configure PE (PO Price Variance) via SPRO

  1. /oSPRO → SAP Reference IMG
  2. Navigate: Materials Management → Purchasing → Purchase Order → Set Tolerance Limits for Price Variance
  3. Click the 🕒 Activity icon → New Entries → fill: Tolerance Key PE · Company Code PSPK · Amounts in PKR · Lower Limit Absolute (Check Limit ✓, Value 50000) · Lower Limit Percentage (Check Limit ✓, % 20) · Upper Limit Absolute (✓, 50000) · Upper Limit Percentage (✓, 20)
  4. Save → Local Object → repeat for SE if needed

1N.2 — Configure PP, BD, DQ, VP, AN, AP (Invoice Verification) via OMR6

  1. /oOMR6 → for each key, New Entries:
Tol KeyCCLower Abs/%Upper Abs/%
PPPSPK10,000 / 10%10,000 / 10%
BDPSPK100 / 1%100 / 1%
DQPSPK100 / 10%100 / 10%
VPPSPK10%10%
ANPSPKDo Not Check50,000 PKR
APPSPKDo Not Check1,000,000 PKR

1N.3 — Configure GR Tolerances (B1, B2, VP) via OMC0

  1. /oOMC0 → New Entries → add B1, B2, VP for CC PSPK with relaxed limits

🪂 ALTERNATIVE — OMRM Workaround (change Error to Warning)

If you can't configure tolerances properly (F4 issues, "Enter values for non-key fields" errors), use OMRM to change message severity from Error to Warning so PO/MIRO save with a warning instead of blocking.

  1. /oOMRM (Configure System Messages — MM)
  2. Change Area at top (M8, 06, ME…)
  3. New Entries → MsgNo 215 (PE) · User Name blank · Online W · BatchI W · Standard W → Save

Severity reference: M8 215 (PE), M8 462 (PP), M8 463 (BD), 06 207 (tolerance variant) — all default E, change to W only in a training environment. For production, never bypass via OMRM — configure proper tolerances.

🇵🇰 Pakistani industry recommended tolerances

IndustryPE %PP %Reasoning
Steel mills (volatile commodity)25%15%Iron ore prices fluctuate daily
Cement (stable)10%5%Tightly controlled pricing
Pharma (DRAP-regulated)5%3%Government price ceilings
Textile (export)20%10%Forex impact on cotton
For Learning IDES20%10%Generous + realistic

📚 Verified against saponlinetutorials — Tolerance Limits · SAP Community — PE Tolerance F4 · SAP Help — Tolerance Limits for Invoice Postings.

1O. ⚠️ S/4HANA MANDATORY: Material Ledger Production Startup — OMX3 → OMX1 → CKMSTART
🧩 Module ownerCO-PC / Material Ledger (Controlling — Product Cost) — but it BLOCKS MM goods movements, so MM consultants must know it. True cross-module config
⚙️ Needed by processThe FIRST (and every) goods movement per plant: MIGO, MB1C, STO, physical inventory — anything that touches stock value
🎯 Purpose (plain)Opens the plant's "value diary" so stock values can be written into the Universal Journal in multiple currencies. Optional in ECC — MANDATORY in S/4HANA
📋 Pre-config requiredPlant exists + assigned to CC (OX10/OX18) · FINSC_LEDGER (1H) — the ML Type's currency types must match the CC's ledger currencies (mismatch = FML_CUST033)
🔗 Links to / feedsACDOCA material values · the "ML Act." flag you see in MM03 Accounting 1 view · with Price Det. 3 also month-end Actual Costing (CKMLCP) — we use Det. 2 (simple)
🧒 In plain words: S/4HANA keeps a special "value diary" (the Material Ledger) for every plant — it records what your stock is worth, in multiple currencies. Until you officially open this diary for a plant, SAP REFUSES every goods movement with error:

❌ FML_CUST097 — "ML is not productive for any valuation area of company code PSPK"

Why does S/4HANA force this? In old ECC, Material Ledger was optional. In S/4HANA it is mandatory because stock values now live inside the Universal Journal (ACDOCA) in multiple currencies — and the Material Ledger is the engine that feeds it. No engine = no postings.

🛠️ The fix is 3 layers, IN THIS ORDER (each unlocks the next)

Layer 1 — Assign an ML "Type" to your plants — OMX3

Plain words: the ML Type is the diary's format (which currencies it tracks). Without a type assigned, the activation checkbox in OMX1 is GREYED OUT.

  1. OMX3 (Assign Material Ledger Types to Valuation Area)
  2. Rows PK01 / PK02 / PK03 / AE01 → Mat. Ledger Type = Y001 (the type all working IDES plants use — proven compatible)
  3. Save → Local Object

Layer 2 — Activate ML — OMX1

  1. OMX1 → your plant rows now show the ML Type → checkbox is editable
  2. Tick ML Act. ✓ for each plant
  3. Price Deter. = 2 (Transaction-Based — the simple mode, works like classic moving average. Mode 3 = Actual Costing needs month-end CKMLCP — skip for learning)
  4. Save → warning "live data must be converted" → confirm

Layer 3 — The "opening ceremony" — CKMSTART

Plain words: activation is just a flag. CKMSTART actually converts the data and flips the productive switch. Run it twice: test first, then real.

  1. CKMSTART → Plant PK01 (use multi-select ➡️ to add all plants at once)
  2. Exchange Rate Type: blank · Background Processing: ☐ UNTICK (online is instant for new plants) · Test Run: ✓
  3. Execute → log must show "Plant can be set as productive" + 0 errors
  4. F3 back → UNTICK Test Run → Execute again
  5. Log now says "Plant is now productive" ✅ — done forever (irreversible, but it's mandatory anyway)

🚨 Gotchas hit live

ProblemReal causeFix
ML Act. checkbox greyed out in OMX1No ML Type assigned yetOMX3 first (Layer 1) — then OMX1 unlocks
"Valuation area PK01 unable to be locked"Your OWN other session (MIGO with PO loaded, MM03…) holds a lockClose all other SAP windows → SM12 → delete YOUR stale locks → rerun
Log says "No data found in valuation area"Plant is brand new — nothing to convertNormal! Not an error
"Processing was ended without job scheduling"Background job never scheduledUntick Background Processing — run online

📚 Verified: SAP Community — CKMSTART preparation steps · saponlinetutorials — Activate ML for Valuation Areas

1P. 🏁 First Goods Movement Readiness — the 4 gates every NEW CC must pass (OMRG · OMC0 · FS00 · FBN1)
🧩 Module ownerMixed — Gate 1 MM-LIV (T169P) · Gate 2 MM-IM (OMC0) · Gate 3 FI-GL (FS00) · Gate 4 FI document numbering (FBN1)
⚙️ Needed by processThe FIRST MIGO in a new CC — and silently by every MIGO/MIRO afterwards
🎯 Purpose (plain)The last 4 per-company rows/rules SAP checks before it can physically WRITE your goods receipt and its FI document
📋 Pre-config requiredEverything above: CC foundation (1A-1J) · OMSY (1K) · tolerances (1N) · ML productive (1O) · OBYC rules (Step 7) — because OBYC DECIDES which accounts Gate 3 must extend
🔗 Links to / feedsGate 3 G/Ls = exactly OBYC's BSX/WRX targets · Gate 4 intervals match OBA7 doc-type→range mapping · MIRO later reuses Gate 1 rules + interval 51 · F-53 uses interval 15
🧒 In plain words: Your FIRST MIGO in a new company code walks through a security checkpoint with 4 gates. SAP checks them one at a time — fix one, the next appears. Here they are in the exact order SAP checks, so you can fix all 4 in 10 minutes BEFORE your first GR.

🚪 Gate 1 — Invoice Verification: the TWIN tables T169P + T169V — OMRG + OMR2

❌ M7 001 — "Check table 169P: entry PSPK does not exist" (hits at MIGO)
❌ M8 100 — "Table T169V: entry PSPK does not exist" (hits later at MIRO!)

Plain words: two tiny one-row-per-company "rulebook" tables for invoice verification. T169P = checking rules (duplicate invoices, amount checks) — even a goods receipt reads it. T169V = default values (which tax code MIRO pre-fills). New CC = no rows = blocked. Fix BOTH at once — they fail at different transactions, days apart, and confuse everyone.

  1. T169P: OMRG (or SM30 → view V_169P_S) → New Entries → CoCd PSPK (+ PSAE) — leave Threshold/Percentage blank → Save
  2. T169V: OMR2 (Maintain Default Values for Tax Codes) → New Entries → CoCd PSPK (+ PSAE) · Default tax code I0 → Save. Bonus: MIRO now pre-fills the tax code

🚪 Gate 2 — Stock-posting tolerances — OMC0

❌ M8 215 — "Maintain tolerance limits for tolerance key VP (CoCode PSPK)"

Plain words: VP = "how much may this goods receipt move my material's average price before SAP complains?" A new CC has NO rules — and for SAP, no rules means 'nothing goes'. ⚠️ Read the small print: for stock postings it's OMC0 (Inventory Management), NOT OMR6 (invoices). Same M8215 number, different config place!

  1. OMC0 → New Entries → 3 rows for the CC:
KeyWhat it checksLearning values
VPMoving average price swing at GRCheck Limit · 50%
B1Order price qty variance (error)Check Limit · 50% / 100000
B2Order price qty variance (warning)Check Limit · 30% / 50000

Remember the radio-button rule from 1N: every section with a typed value needs its "Check Limit" radio selected — else "Enter values in work area" error.

🚪 Gate 3 — G/L accounts must exist IN the company code — FS00

❌ M7 055 — "G/L account 300000 does not exist in company code PSPK"

Plain words: the chart of accounts (INT) is a song catalog — the song exists, but each company code must add it to its own playlist. OBYC points your GR to 300000 (inventory) and 191100 (GR/IR) — BOTH must be extended to the CC, because one GR posts to both at once.

  1. FS00 → G/L 300000 · CC PSPK → With Template button (don't press Enter first — "does not exist" on Enter is normal, it's why you're here!)
  2. Template: 300000 / CC 0001 (or 1000) → Enter
  3. Repeat for 191100

⚠️ The 2 checkbox gotchas that bite later:

Section · FieldFillWhat the field asks (plain words)Why we choose this — and the impact if wrong
FS00 G/L master — the checkboxes that bite later
Posting without tax allowed (Control Data)✓ tickMay documents post to this account without a tax code? Like allowing a receipt slip that carries no VAT line.Several stock movements carry NO tax code — 561 initial stock, 201 goods issue to a cost center, 309 transfers, 701/702 count differences — and they post to these inventory/clearing G/Ls. Impact: unticked, all of them fail with "tax code missing", blocking normal stock postings.
Post automatically only (Create/bank/interest)✓ tickShould only the system be allowed to post here, never a person by hand?Stock and GR/IR accounts must move only through automatic OBYC postings, so a clerk cannot type a manual FB50 entry into them. Impact: leave it off and a manual posting can knock the G/L balance out of step with the true stock value.
Open Item Management (on 191100)✓ tick (on)Should each posting here stay "open" until an offsetting one clears it? Like an invoice sitting on a to-be-paid spike until it is settled.191100 is the GR/IR clearing account — every goods-receipt line must later be cleared by its matching invoice line, and open-item management is what makes that line-by-line matching possible. Impact: without it the GR/IR account can never be reconciled, so you cannot tell which receipts are still awaiting an invoice.

Pre-extend checklist for a new CC (2 min each): 300000 Inventory RM · 191100 GR/IR · 160000 AP recon · PRD price-difference account (e.g., 231000) · bank/cash (113100/100000) for payments.

🚪 Gate 4 — FI document number ranges — FBN1

❌ NR751 — "Interval 45/Subobject PSPK To Year 2026 does not exist for object RF_BELEG"

Plain words: every FI document takes a numbered ticket from a ticket roll. Each document type pulls from a specific roll (our WE goods-receipt doc → roll 45). New CC = missing rolls = no ticket = no document. This error is actually GOOD news — it means everything else works and SAP reached the very last step: numbering your document.

  1. FBN1 → CC PSPK → Change Intervals → note what exists
  2. Insert the missing rolls (pattern NN → NN00000000–NN99999999):
NoYearFrom – ToFeeds doc type
4599994500000000 – 4599999999WE — Goods Receipt (our blocker — standard systems often use 50!)
3699993600000000 – 3699999999RE — MIRO invoice in our IDES (error F5150 named it)
5099995000000000 – 5099999999WE/WA standard mapping
5199995100000000 – 5199999999RE — MIRO invoice (standard mapping)
1999991900000000 – 1999999999KR — vendor invoice
1599991500000000 – 1599999999KZ — vendor payment (F-53)
2099992000000000 – 2099999999ZP — payment program

⚠️ Three FBN1 gotchas:

  • Year 2026 vs 9999: year-specific intervals DIE on 1-Jan of next year (NR751 returns for everything!). Use 9999 on test systems. Real companies maintain new-year intervals as a year-end task.
  • "Copy intervals from CC" only works into an EMPTY company code. If even one interval exists, copy refuses → insert the missing rows manually.
  • Your system's doc-type→range mapping may be NON-STANDARD. Our IDES maps MIRO's RE doc to range 36 (standard is 51!). Proactive check: OBA7 → double-click each doc type you'll use (WE, RE, KR, KZ, ZP, SA) → note its "Number range" → ensure each exists in FBN1.

📚 Verified: SAP Community — T169P fix · T169P per-CC requirement · Tolerance limits

🚨 Issues & fixes (from a live IDES)

A brand-new company code in S/4HANA must pass a gauntlet of checks before its first complete P2P posting succeeds. SAP shows them one at a time — fix one, the next appears. These were all hit live on the IDES. The table below is the 9-Gate Gauntlet in the exact order SAP raises them; fix all of them up front and your first GR posts clean. Each error links to the Troubleshooting Center.

#Error you'll seePlain meaningFix (T-code)Sub-step
1Ledger 0L not set up for CCThe CC isn't registered in the S/4 accounting ledgerFINSC_LEDGER1H
2"Company code not fully maintained" at MM01MM's own period clock never started for this CCOMSY1K
3ME062 "Account assignment mandatory"Material has no value-tracking setup (Accounting view / OMS2)MM01 Accounting 1 + OMS2Material step
4M8 215 for PE at PO saveNo "acceptable price difference" rule for POsSPRO → PO → Price Variance1N
5FML_CUST097 "ML not productive"The plant's value diary was never openedOMX3→OMX1→CKMSTART1O
6M7001 "table 169P entry missing" (MIGO) + M8100 "T169V missing" (MIRO)The TWIN invoice-verification rulebooks have no row for this CCOMRG + OMR21P Gate 1
7M8 215 for VP at MIGONo "acceptable price swing" rule for stock postingsOMC0 VP/B1/B21P Gate 2
8M7055 "G/L 300000 does not exist in CC"Account in catalog but not on this CC's playlistFS00 With Template ×21P Gate 3
9NR751 "Interval 45 does not exist"No ticket roll to number the FI documentFBN1 insert intervals1P Gate 4
10F5150 interval 36 + M8100 T169V + F5506 G/L (MIRO) · F5100 T043G (F-53)The same 4 gate types REPEAT for invoice + payment: another ticket roll, the T169V twin, the input-tax account, and vendor-side tolerances (OBA3 — sibling of 1G's OBA4: OBA4=USER tolerances T043T, OBA3=VENDOR tolerances T043G)FBN1 · OMR2 · FS00 · OBA31P + 1G
✅ After gate 9: "Material document posted" (GR works) — and after gate 10's repeats, MIRO and F-53 post too = the complete P2P cycle. Dr 300000 Inventory / Cr 191100 GR/IR at GR → GR/IR cleared against vendor at invoice → vendor cleared against bank (−2% cash discount!) at payment. Every config piece fires automatically. That's MM-FI integration working end-to-end.

Other errors worth knowing (per sub-step)

ErrorRoot causeFixSub-step
"Posting period MM YYYY is not open"OB52 missing a row covering today's dateOB52 — add current period1C
"Document number not in range XX defined for CC PSPK"FBN1 range missing / year-specific entry expiredFBN1 — create range with Year 99991F
"No field status variant assigned to CC PSPK"OBY6 missing FSV fieldOBY6 — fill Field Status Variant = PSPK1E
"There is no item category assigned to account XXXXXX/INT"G/L not classified for Document SplittingSPRO Classify G/L1I
"This combination of entries does not make sense" (OMSY)Both ABp and DBp checkedOMSY — uncheck DBp, keep ABp1K
ML Act. checkbox greyed out in OMX1No ML Type assigned in OMX3 yetOMX3 first, then OMX11O

✅ Verification

The full 10-point functional check lives in sub-step 1L. The fastest confirmation that everything works together is the F-02 smoke test in Step 2. Quick database-level checks:

← Previous
Setup Guide Hub
Next →
Step 2: Test the CC (F-02)