Interview Prep & Capstone Project

Purchase requisition (ME51N, an internal request) → purchase order (ME21N, a commitment to the vendor, no FI posting) → goods receipt (MIGO 101: Inventory Dr / GR-IR Cr) → invoice (MIRO, 3-way match: GR-IR Dr / Vendor Cr) → payment (F-53: Vendor Dr / Bank Cr). The GR/IR clearing account links the GR and the invoice and clears across the two.

It checks that the PO, the goods receipt, and the invoice agree on quantity and price. If any one of them mismatches, the invoice is blocked for payment; a buyer then releases it in MRBR after the issue is resolved.

A purchase requisition is an internal request to buy — it carries no financial commitment and is not sent to the vendor. A purchase order is the formal commitment sent to the vendor; it can be created manually or by converting a PR.

The GR posts a material document plus an accounting document: Inventory Dr / GR-IR Cr (movement type 101). It also updates the PO history so the buyer can see what has been received against the order.

It is a setting on the PO that says the invoice can only be posted for quantities already received. It enforces the goods-receipt step before invoicing and keeps the GR/IR account clean line-by-line.

Both are outline agreements. A contract is a longer-term commitment on value or quantity that you release against with individual POs (release orders). A scheduling agreement holds delivery dates and quantities directly in delivery schedule lines, so no separate PO is needed.

Client (the top, shared by all) → company code (the legal/FI entity that produces its own balance sheet) → plant (a manufacturing or operations site) → storage location (where stock physically sits inside a plant). Purchasing org and purchasing group sit alongside to handle buying.

A plant is an operational unit where you produce, procure, or store materials — a factory, warehouse, or distribution centre. It is the central org unit in MM and, in S/4HANA, normally the valuation area too.

A purchasing organisation is an org unit responsible for procurement and for negotiating terms with vendors; it is assigned to company codes and plants. A purchasing group is a buyer or a team of buyers — it is just a key on documents, with no org assignment.

A purchasing org is assigned to one or more plants, and can be assigned to a company code (plant-specific) or kept cross-company-code (a central purchasing org buying for several entities). This assignment decides which plants a purch org may buy for.

A storage location is a sub-division of a plant where stock is physically kept; stock is managed in quantity at storage-location level. The plant is the larger operational and valuation unit; one plant has many storage locations.

Material master (MM01), vendor/business partner master (XK01 / BP), purchasing info record (ME11, the material-vendor link with price), and the source list (ME01, which vendors may supply a material at a plant).

Because different departments own different data — Basic Data is client-wide, while Purchasing, MRP, Accounting and Storage views are maintained per plant or org level. The views let each area maintain its own fields without overwriting others.

It stores the relationship between one material and one vendor — agreed price, conditions, and lead time. When you create a PO for that material-vendor pair, the price defaults in from the info record.

The material type (e.g. ROH raw material, FERT finished good, HALB semi-finished, HAWA trading good) controls which views and fields are available, the default procurement type, and the account determination via its link to the valuation class.

The source list (ME01) lists the allowed sources of supply for a material at a plant, and can fix or block a vendor for a period. It becomes mandatory when the plant or material is flagged for source-list requirement, so POs can only be raised against an approved source.

A one-time vendor is a single master record used for vendors you deal with rarely, where the actual name and address are entered on each document. A normal vendor has its own dedicated master record reused across all its transactions.

OBYC is automatic account determination. It maps each goods movement — by transaction key, valuation class and chart of accounts — to the correct G/L account so postings happen automatically. Key keys: BSX (inventory), WRX (GR/IR clearing), GBB (offsetting entries, e.g. VBR for consumption), PRD (price differences).

V is moving average price — the material's value is recalculated at each goods receipt, so the price moves with what you actually pay. S is standard price — a fixed value; any difference between PO/invoice and standard posts to a price-difference account (PRD).

The valuation class is a key on the Accounting view of the material that groups materials with the same account determination. OBYC uses the valuation class (with the transaction key and chart of accounts) to find the right inventory and offset G/L accounts.

It is the bridge between goods receipt and invoice. The GR credits it (WRX) and the invoice debits it; when both are posted for the same quantity it nets to zero. A non-zero balance means a GR without an invoice or vice versa, which is why it is reconciled regularly.

GBB — the offsetting entry for goods movements without a PO reference — with the account modifier deciding the case. VBR is consumption to a cost centre or order; BSA is initial stock entry; others cover scrapping and stock differences.

Movement type 201 — goods issue to a cost center. It posts Consumption (an expense) Dr / Inventory Cr, charging the value to the receiving cost center. (251 issues to a sales order, 261 to a production order.)

101 is goods receipt against a PO or production order (Inventory Dr / GR-IR Cr). Its reversal is 102. The general rule is that a reversal movement type is the original plus one.

A plain stock transfer (e.g. 301/311) moves stock between plants or storage locations in one step with no purchasing document. A stock transport order (STO) uses a PO-type document to plan and track the movement, and can involve delivery, billing and two-step receipt.

Unrestricted-use (available to consume or sell), quality inspection (blocked pending QC), and blocked stock (not usable). Movement types and the GR setup decide which stock type a receipt lands in.

It is the counting of actual stock to reconcile against the system. You create the count document in MI01, enter the counted quantity in MI04, and post the difference in MI07, which adjusts inventory and posts the gain/loss.

MIGO — a single, mode-driven screen that handles goods receipt, goods issue, transfer postings and more. You pick the action and reference (PO, order, material document) and it derives the movement type.

You send components to a vendor (item category L, issued with movement 541 to vendor stock), the vendor returns a finished good and consumes those components (543) at goods receipt, and you pay a service/processing fee for the work.

Intra-company (document type UB) moves stock between plants in the same company code, with no real receivable or payable. Inter-company is between two company codes, so it needs an SD delivery and an inter-company invoice that creates a genuine receivable/payable between the entities.

Stock that physically sits at your site but is still owned by the vendor until you withdraw it. There is no liability at goods receipt; the liability and the invoice are settled (via MRKO) only on the quantity you consume.

The vendor ships goods directly to your customer; the goods never enter your stock. A sales order triggers a PR/PO with item category S, and the statistical goods receipt and invoice are based on what the vendor delivers to the customer.

A material consumed continuously from a supply source — water, electricity, gas — without a normal purchase order. Consumption is withdrawn as needed and settled periodically with the vendor.

MIRO — logistics invoice verification. With a 3-way match it posts GR-IR Dr / Vendor Cr, clearing the GR/IR balance created at goods receipt and creating the open payable.

The invoice is posted but blocked for payment because of a price or quantity variance against the PO/GR. A buyer reviews and releases it in MRBR once the difference is explained or corrected.

A planned delivery cost (freight, duty) is entered on the PO up front and accrued at goods receipt, so the invoice can settle it against that accrual. An unplanned delivery cost is only known at invoice time and is added on the MIRO screen, distributed to the line items or a separate G/L.

It is the reverse of an invoice — used when the vendor over-charged or goods were returned. Posted in MIRO as a credit memo, it reduces the payable (Vendor Dr / GR-IR or expense Cr).

An invoice block is set automatically by the system when a tolerance (price, quantity, date) is breached at MIRO. A payment block is a flag (manual or system) that simply stops the payment run from paying that item until it is removed.

It is SAP's approval workflow for purchasing documents. Based on characteristics (e.g. value, plant, purchasing group), the document needs one or more release codes to be approved before it can be processed. PRs are released in ME54N, POs in ME29N.

Release without classification is simple, value-based approval for purchase requisitions only. Release with classification uses characteristics and a class, allowing multi-condition strategies, and is the method used for POs and other purchasing documents.

A calculation schema (pricing procedure) holds condition types in sequence — gross price (PB00/PBXX), discounts, surcharges, freight, taxes — and computes the net and effective price. Conditions default from the info record or are entered manually.

It is a single element of price — a gross price, a percentage discount, a freight charge, a tax. Condition types are arranged in the calculation schema to build up the final PO price.

From the purchasing info record for that material-vendor combination, or from a valid outline agreement. If neither exists, the buyer enters the price manually and can save it back to a new info record.

Vendors are now managed as Business Partners, the Material Ledger is mandatory, finance runs on the Universal Journal (table ACDOCA), the material number (MATNR) can be up to 40 characters, and the front end moves to the Fiori user experience.

Valuation is normally at plant level — the plant is the valuation area — so the same material can carry different prices at different plants. (Company-code-level valuation is technically possible but plant level is the standard.)

In S/4HANA a vendor (and customer) is created as a Business Partner with roles, rather than via the old separate vendor master transactions. One BP record can play both a supplier and a customer role, removing duplicate master data.

A single table that combines FI and CO line items, so there is one source of truth for finance. For MM it means every value posting from a goods movement lands in one journal with full detail and no reconciliation between ledgers.

Because inventory valuation now runs through the Material Ledger by default — it enables multiple currencies and actual costing for stock. You don't have to switch on actual costing, but the ledger itself is always active.

Stay calm and structured: read the exact error first, then check the usual causes — is the posting period open (OB52 / OMSY)? Is OBYC account determination set up? Is the G/L extended to the company code (FS00)? Is the number range maintained (FBN1)? Is the Material Ledger productive? Narrate that checklist to show method, not guesswork.

Ask clarifying questions and restate the business need in my own words to confirm it, then map it to a standard SAP process before considering anything custom. I document the requirement and the proposed solution so the business signs off before I configure.

I keep it in business terms — for example explaining the 3-way match as "we only pay for what we ordered and actually received." I tie the SAP behaviour to the outcome they care about, and use a screen walk-through rather than jargon.

Never directly in production — I build and unit-test in the development client, move it through transports to quality for testing and business sign-off, then to production. I document the change and confirm a fallback before transporting.

I first check whether standard SAP, configuration, or a small enhancement can meet the need, because custom code carries long-term cost. If custom is genuinely required, I write a clear functional spec and agree it with the business and the developer before any build.

I say what I do know plainly, flag the part I'm unsure of rather than bluffing, and explain how I'd find the answer (help, documentation, a quick test in the system). Honesty plus a method reads better than a confident guess.