Top 120 SAP MM Interview
Questions & Answers (2026)

SAP MM stands for Materials Management — SAP's core module for managing all procurement and inventory processes within an organisation. It covers the complete Procure-to-Pay (P2P) cycle: material planning, purchase requisition, purchase order, goods receipt, invoice verification, and vendor payment.

SAP MM integrates tightly with: SAP FI/CO (financial posting at goods receipt and invoice), SAP SD (stock availability for sales orders), SAP PP (material requirements planning), and SAP WM/EWM (warehouse management). It is used across manufacturing, retail, healthcare, public sector, and all industries that procure goods and manage inventory. In SAP S/4HANA, MM is part of the Supply Chain suite with enhanced Fiori apps and real-time inventory analytics.

The Procure-to-Pay (P2P) cycle is the end-to-end procurement process in SAP MM: (1) Material Requirements Planning (MRP) — SAP identifies material shortages and generates planned orders or purchase requisitions automatically; (2) Purchase Requisition (PR) — internal request to procure a material or service (ME51N); (3) Request for Quotation (RFQ) — optional, sent to vendors for price comparison (ME41); (4) Purchase Order (PO) — legal procurement document issued to vendor (ME21N); (5) Goods Receipt (GR) — goods received from vendor, inventory updated (MIGO); (6) Invoice Verification (IV) — vendor invoice matched to PO and GR (MIRO); (7) Payment — vendor paid via F110 (automatic payment program). Each step creates linked SAP documents — the document flow is visible in ME23N → Environment → Document Overview.

SAP MM organisational structure (top to bottom): Client — the SAP system instance; Company Code — legal entity for financial reporting; Plant — a manufacturing facility, warehouse, or distribution centre. The central organisational unit in MM — materials, stocks, and procurement all happen at plant level; Storage Location — physical storage area within a plant (e.g. Raw Material Store, Finished Goods Store). Stock is managed at storage location level; Purchasing Organisation — responsible for procuring materials and negotiating contracts with vendors. Can be company-code-specific or cross-company; Purchasing Group — a buyer or group of buyers within the purchasing organisation.

Key assignment: Plant → Company Code (OX18), Purchasing Organisation → Company Code (OX01), Purchasing Organisation → Plant (OX17). Correct organisational structure setup is the first and most critical step in any MM implementation.

A Purchasing Organisation is an organisational unit responsible for all procurement activities — negotiating contracts, issuing purchase orders, and managing vendor relationships. It can be: Company-specific (one purchasing org per company code), Cross-company (one purchasing org for multiple company codes), or Plant-specific (one purchasing org per plant). Configured in OX08 and assigned to Company Codes in OX01.

A Purchasing Group is a smaller unit within the purchasing organisation — a buyer or team of buyers responsible for specific material groups or vendors. It is a 3-character key assigned on the purchase order and used for reporting and responsibility. Key difference: Purchasing Organisation = the legal/organisational entity; Purchasing Group = the individual buyer or team within it. Both appear on purchase orders and are used in vendor evaluation and reporting.

A Purchase Requisition (PR) is an internal document requesting the procurement of a material or service — it does not go to the vendor. It can be created manually (ME51N) or automatically by MRP. It requires approval before conversion to a PO. No legal obligation is created.

A Purchase Order (PO) is an external legal document sent to the vendor committing to purchase specific quantities at agreed prices and delivery dates. Created from a PR in ME21N (or via ME59N — automatic PO from PR). The PO creates a commitment in FI (shown in S_ALR_87013611 as commitment value). Key PO document types: NB (standard PO), FO (framework/blanket order), UB (stock transport order). A PO cannot be deleted if a GR or IR has been posted against it — it can only be closed (set delivery completed indicator).

SAP MM manages several stock types at plant/storage location level: Unrestricted-Use Stock — available for all purposes (production, sales, transfer). Valued in FI. Quality Inspection Stock — received but pending quality check. Not available for use. Can be moved to unrestricted or blocked after inspection. Blocked Stock — goods rejected or on hold. Not available. Not normally valued. Restricted-Use Stock — available with restrictions (e.g. near-expiry batch). In-Transit Stock — goods transferred between plants/storage locations, in transit. Consignment Stock — vendor-owned stock at your premises; ownership transfers only when consumed. Subcontracting Stock — components issued to vendor for processing, still your property. Project Stock — reserved for a specific WBS element. Sales Order Stock — reserved for a specific customer sales order (make-to-order). All stock types are visible in MMBE (stock overview).

Special procurement types are alternative sourcing methods beyond standard external procurement: Consignment — vendor delivers stock to your premises; you own it only when you withdraw it (ME21N item category K). Liability to vendor created via MRKO (consignment settlement); Subcontracting — you issue components to vendor; vendor assembles/processes and returns finished goods (ME21N item category L). Component list in PO item details; Stock Transfer / STO — move stock between plants within one company (ME21N document type UB) or between company codes (intercompany STO); Third-Party — you raise a PO but vendor delivers directly to your customer. Triggered from SD sales order (item category TAS); Pipeline — commodities (water, gas, electricity) drawn from a supply pipeline as needed; Returnable Transport Packaging (RTP) — packaging returned to vendor after use. Each special procurement type has unique account determination and document flow requirements.

Materials Requirements Planning (MRP) in SAP MM automatically calculates what materials are needed, in what quantities, and by when — based on demand (sales orders, production orders, planned independent requirements) minus available supply (current stock, open POs, open production orders).

MRP creates: Planned Orders (internal production recommendation) and Purchase Requisitions (external procurement recommendation). Key MRP parameters on material master: MRP Type (PD=MRP, VB=reorder point, ND=no planning), Lot Size (EX=exact, FX=fixed, HB=maximum stock level), Safety Stock, Reorder Point, Planned Delivery Time. MRP run: MD01 (plant-level), MD02 (single material), MD04 (stock/requirements list — key monitoring report). In S/4HANA, MRP Live (MRP_LIVE) runs in real-time using HANA's in-memory processing, replacing the traditional batch MRP run.

Vendor Evaluation (ME61/ME62/ME6B) is SAP MM's structured process for scoring and ranking vendors based on performance criteria. Five standard main criteria: Price (how competitive vs. other vendors), Quality (inspection results, defect rates), Delivery (on-time delivery vs. promised date), Service (responsiveness, complaint handling), External Service (for service vendors). Each criterion has a weight; the weighted average gives an overall score (0-100). Scores can be: Automatic (calculated from GR data, quality notifications, delivery dates) or Semi-automatic/Manual (entered by purchasing).

Vendor evaluation scores are used in: source determination (prefer high-scoring vendors), contract negotiations, and vendor development programmes. Configuration: OMG1 (define criteria and weighting). The evaluation result is stored on the vendor master and visible in ME63.

A Source List (ME01/ME03) defines the valid sources of supply for a material — which vendors or contracts are approved to supply a specific material at a specific plant during a defined period. It controls: which vendors can be used when creating purchase orders, MRP source determination (MRP can automatically assign a source when creating PRs), and fixed source enforcement (if 'Fixed' indicator is set, only that source can be used).

A source list record contains: vendor, purchasing organisation, plant, validity period, and fixed indicator. Source lists can be maintained manually or automatically from outline agreements. If source list requirement is activated on the material master (MRP2 view → Procurement tab), a PO cannot be created for that material without a valid source list entry. This is a key procurement control used in regulated industries.

SAP MM Purchase Order types (document types): NB (Standard PO) — most common. Used for one-time or regular procurement of goods/services from an external vendor; FO (Framework Order / Blanket PO) — open PO for repetitive procurement without specifying exact quantities/delivery dates upfront. Used for maintenance services, office supplies; UB (Stock Transport Order) — transfers stock between plants within the same company (no vendor involved); ZNB / Customer-specific types — client-defined document types for specific procurement scenarios.

PO item categories: Standard (blank) — normal stock/non-stock items; K (Consignment) — consignment procurement; L (Subcontracting) — send components to vendor; D (Service) — service procurement (service entry sheet required); B (Limit) — blanket/limit order for unknown quantities; U (Stock Transfer) — used with UB document type. The combination of PO document type and item category drives the entire procurement behaviour.

Account assignment in a PO determines where the cost of the procured item is charged. When a PO has an account assignment category, the goods are procured for direct consumption (not into stock) — no stock posting occurs at GR; instead, the cost goes directly to the assigned cost object.

Common account assignment categories: K (Cost Centre) — cost charged to a CO cost centre; P (Project/WBS Element) — cost charged to a project WBS element; A (Asset) — item capitalised as a fixed asset (triggers FI-AA posting); F (Production Order) — cost charged to a production/process order; N (Network) — charged to a project network activity; blank — item goes into stock (standard stock PO).

Account assignment is set at the PO item level. When account assignment category K is used, the system requires a cost centre and G/L account — the GL is typically determined automatically via valuation class or entered manually. This is frequently tested in both functional and technical FICO/MM interviews.

The 3-way match is the cornerstone of procurement financial control in SAP MM. It verifies three documents before authorising vendor payment: (1) Purchase Order (PO) — agreed price and quantity; (2) Goods Receipt (GR) — confirmed physical delivery (MIGO); (3) Vendor Invoice (IR) — supplier's billing document (MIRO).

SAP performs the match automatically during MIRO: Quantity check — invoice quantity must not exceed GR quantity (within tolerance); Price check — invoice price vs. PO price (within tolerance keys configured in OMR6: PP for price, KW for quantity). If both match within tolerance → invoice posts and is available for payment. If not → MIRO blocks the invoice (payment block). Blocked invoices reviewed in MRBR. FICO posts at GR: stock debit + GR/IR credit. At IR: GR/IR debit + vendor credit. Price differences post to account key PRD (configured in OBYC).

The Release Strategy is SAP MM's approval workflow for Purchase Requisitions and Purchase Orders — defining who must approve a document before it can be used/transmitted to the vendor.

Configuration (OMGSRV / SPRO → MM → Purchasing → PR/PO → Release Procedure): (1) Release Group — groups documents by type (e.g. all POs in group 01); (2) Release Class — a classification class with characteristics that determine which strategy applies (e.g. total value, purchasing org, material group); (3) Release Codes — individual approver levels (e.g. A=Buyer, B=Manager, C=Director); (4) Release Indicator — status after each release (blocked, released for ordering); (5) Release Prerequisite — which code must be approved before the next can act.

Runtime: PO is blocked until all required release codes approve. Approval via ME28 (mass release), ME29N (individual), or Fiori app 'Approve Purchase Orders'. Released POs can be transmitted to vendors via message output (email, EDI, print).

A Framework Order (FO) — also called a Blanket PO — is a long-term procurement agreement for repetitive goods or services where the exact delivery dates and quantities are not fixed upfront. A total value limit is set on the PO; individual goods receipts or service entries are posted against it throughout the validity period until the limit is reached.

Configuration: PO document type FO, item category B (Limit). Key fields: overall limit (total spend cap), expected value (for commitment reporting). No individual PO line quantities — just a total value. GRs post against the FO item; invoice verification references the FO. Common use cases: office supplies, maintenance services, IT support contracts, cleaning services.

Advantage: eliminates the need to create individual POs for every small purchase. The FO number is given to the vendor; they deliver as needed; GRs/invoices reference the FO until the limit is reached. At limit: a warning is issued; posting may be blocked depending on configuration.

Contracts and Scheduling Agreements are outline agreements — long-term procurement arrangements with vendors.

Contract (ME31K): a longer-term agreement specifying total quantity or value to be procured from a vendor during a period. Two types: Quantity Contract (MK) — total quantity agreed (e.g. 10,000 units over 12 months); Value Contract (WK) — total value agreed (e.g. CA$500K over 12 months). Releases (call-offs) are made against the contract via release orders (ME21N with ref to contract).

Scheduling Agreement (SA) (ME31L): a long-term agreement with delivery schedule lines specifying exact quantities and delivery dates. Used for just-in-time (JIT) procurement, especially in manufacturing. Delivery schedule lines are maintained in ME38 and transmitted to vendors electronically (EDI). SA eliminates individual POs — the schedule line IS the procurement instruction. Common in automotive and electronics manufacturing.

A Goods Receipt (GR) in SAP MM (MIGO, movement type 101) is the posting that records the physical receipt of goods from a vendor against a Purchase Order. It creates multiple linked documents simultaneously: Material Document — records the stock movement (quantity, material, plant, storage location, movement type). Visible in MB51 and MB03. Accounting Document — FI posting: debit stock account (BSX) + credit GR/IR clearing account (WRX) at PO price. Visible in FB03. PO History Update — GR quantity and value recorded in the PO item history (ME23N → PO History tab).

At GR, the following happen: inventory increases, FI commitment decreases (PO commitment is replaced by actual stock value), and the GR/IR account is credited (awaiting the matching vendor invoice in MIRO). In S/4HANA, all postings go to ACDOCA (Universal Journal) via a single accounting entry.

A Request for Quotation (RFQ) (ME41) is a formal document sent to one or more vendors inviting them to submit price and delivery proposals for a specific material or service. It is used for competitive bidding — especially for high-value or infrequent procurement. The RFQ is transmitted to vendors via email, EDI, or print output.

When vendors respond, their prices and conditions are entered as Quotations (ME47) in SAP. A Price Comparison (ME49) ranks all vendor quotations for the same RFQ side by side, highlighting the best price. The preferred vendor's quotation is then converted into a Purchase Order (ME21N with reference to quotation).

RFQ → Quotation → Price Comparison → PO is the standard competitive procurement process in SAP. For recurring procurement, Info Records and Contracts eliminate the need for repeated RFQs by locking in agreed prices for a period.

A Purchasing Info Record (PIR) (ME11/ME12/ME13) stores the procurement history and conditions for a specific material-vendor combination — essentially SAP's memory of past agreements. It contains: vendor, material, purchasing org, plant, price and conditions (net price, price unit, price date), delivery time (planned delivery time in days), minimum order quantity, tolerance for over/under delivery, and tax indicator.

Info Record types: Standard (regular stock purchase), Subcontracting (with component list), Consignment (consignment pricing), Pipeline. When a PO is created for a material-vendor combination with an existing PIR, SAP automatically defaults the price, delivery time, and conditions from the PIR. PIRs are updated automatically when a PO is ordered (if the 'Update Info Record' flag is set in the PO). This is a foundational MM data object frequently asked in interviews.

Both PRs and POs can have release strategies, but they serve different purposes and are configured separately:

PR Release Strategy: approves the internal request to buy before a PO is even created. Ensures the business need is authorised. Common thresholds: total value > CA$5,000 requires manager approval. Configuration: SPRO → MM → Purchasing → PR → Release Procedure. PR release class uses characteristics like total value, material group, plant, account assignment.

PO Release Strategy: approves the vendor-facing commitment before it is sent to the vendor. Ensures the commercial terms are authorised. Common thresholds: PO value > CA$50,000 requires Finance Director approval. Configuration: SPRO → MM → Purchasing → PO → Release Procedure. PO release class uses total net order value, vendor, purchasing org.

Key distinction: a PR can be released (approved internally) but still need the resulting PO to go through its own separate release before transmission to the vendor. Many organisations use both levels of control for high-value procurement.

Movement types in SAP MM are 3-digit codes that control what type of stock movement is being posted, which accounts are updated, and how the stock is classified. Key movement types: 101 — GR against PO (stock increases, GR/IR credited); 102 — reversal of GR against PO; 103 — GR to quality inspection stock; 105 — release from quality to unrestricted; 122 — return delivery to vendor; 201 — goods issue to cost centre (consumption); 261 — goods issue to production order (component withdrawal); 301 — plant-to-plant transfer (one step); 303/305 — plant-to-plant transfer (two step: removal/placement); 311/312 — storage location to storage location transfer; 501 — receipt without reference (initial stock entry); 551 — scrapping. Each movement type has a configured quantity string and account grouping in OMJJ (movement type customising). The movement type is the single most important field in any MIGO transaction.

MIGO (transaction MIGO — Material Document, Goods Movement) is the central goods movement transaction in SAP MM — used for virtually all stock movements. MIGO has four main action categories: Goods Receipt (GR) — receive goods against PO (101), production order (101), or without reference (501); Goods Issue (GI) — issue goods to cost centre (201), production order (261), or scrapping (551); Transfer Posting — move stock between storage locations (311), plants (301), or stock types (unrestricted ↔ QI ↔ blocked); Return Delivery — return goods to vendor (122) or to production (262).

Key MIGO features: multiple items in one posting, batch management, serial number assignment, automatic account determination via OBYC, mandatory/optional reference to purchase order or production order, storage location selection. After posting: MIGO generates a material document (visible in MB03) and an accounting document (visible in FB03). In S/4HANA, MIGO is supplemented by Fiori apps like 'Goods Movement' and 'Post Goods Receipt for Purchase Order'.

One-step stock transfer (movement type 301 — plant to plant, or 311 — storage location to storage location): stock is removed from the source and placed at the destination in a single posting. No in-transit stock exists. Simple and fast — used for transfers within the same company where physical distance is short or immediate.

Two-step stock transfer (movement types 303 + 305 for plant transfer, or 313 + 315): Step 1 — stock removed from source plant/storage location (303) and placed in in-transit stock; Step 2 — stock received at destination plant (305) and placed in unrestricted stock. In-transit stock is visible in MMBE (stock overview).

Two-step is used when: the transfer takes time (physical transport between distant locations), proof of receipt at destination is required before stock is 'available', or when different people/teams handle the removal and receipt. For intercompany transfers (STO across company codes), an SD billing step is also involved — creating an accounting document for the intercompany revenue/cost.

Physical Inventory is the process of counting physical stock and reconciling it with the system stock balance. SAP MM supports three methods: Periodic Inventory — count all stock at one point in time (typically year-end); Cycle Counting — count high-value or fast-moving items more frequently (A, B, C classification) without disrupting operations; Inventory Sampling — statistical approach, count a sample and extrapolate.

Process: (1) MI01 — create physical inventory document (blocks the storage location for booking); (2) MI04 — enter count results; (3) MI07 — post inventory differences. Inventory differences create material documents (movement type 701 for surplus, 702 for deficit) and accounting documents (stock account debit/credit + inventory adjustment account). After posting, the book inventory equals the physical count. In SAP S/4HANA, the Fiori app 'Count Physical Inventory' allows warehouse staff to enter counts on mobile devices in real time.

Batch management allows tracking of materials at a sub-stock level using a batch number — identifying specific lots, production runs, or shipments. Activated on the material master (Plant Data/Storage 1 view → Batch Management checkbox, or via Purchasing view). A batch is uniquely identified by: material + plant + batch number.

Batch classification: batches can carry characteristics (expiry date, country of origin, quality grade, chemical composition) using SAP's classification system. Shelf Life Expiration Date (SLED) management ensures FEFO (First Expired First Out) picking. Batch determination automatically selects the correct batch during goods issue using a search strategy based on characteristics.

Batch-relevant processes: GR (batch number assigned/created), QM inspection (batch-level results), goods issue (batch selected), delivery (batch in outbound delivery). Batch management is mandatory in: pharmaceuticals, food & beverage, chemicals, and any regulated industry requiring lot traceability. Configured in OMCO and material master.

Consignment is a procurement arrangement where the vendor delivers and stores goods at your premises, but you only become liable for payment when you consume or withdraw the stock — not when it is received. Until withdrawal, the stock belongs to the vendor.

Process: (1) ME21N — create consignment PO (item category K); (2) MIGO — GR against consignment PO. Stock is received into vendor consignment stock (visible in MMBE, segregated from own stock). No FI posting at GR (vendor not yet liable); (3) MB1A/MIGO — withdrawal from consignment stock (movement type 201 with special stock indicator K). At withdrawal: stock debit + vendor liability credit created in FI; (4) MRKO — consignment settlement: creates the vendor invoice for all withdrawals in the period. FI: debit GR/IR or consignment liability, credit vendor AP.

Advantage: reduces cash tied up in inventory, vendor bears holding cost. Common in manufacturing (fasteners, raw materials) and retail (display merchandise).

A Goods Issue (GI) records the outward movement of stock from a storage location — for production consumption, delivery to customers, cost centre consumption, or scrapping. Posted in MIGO or MB1A.

Key GI scenarios: To Production Order (261): components issued from warehouse to production floor. FI: debit WIP/production order, credit stock account. Inventory decreases; To Cost Centre (201): consumable items charged directly to a department (office supplies, maintenance materials). FI: debit cost centre expense account, credit stock account; To Customer / Delivery (601 via VL02N in SD): outbound delivery posted as GI in SD. FI: debit COGS, credit finished goods stock; Scrapping (551): damaged or obsolete stock written off. FI: debit scrapping expense account, credit stock account.

At every GI, the system updates: material document (quantity change), accounting document (FI posting via OBYC), cost object (CO posting if account assignment present), and plant stock balance in MMBE.

MMBE (Stock Overview) is the primary stock monitoring transaction in SAP MM — displaying all stock quantities for a material across all organisational levels (client → company code → plant → storage location) and all stock types.

MMBE shows: Unrestricted (available), Quality Inspection, Blocked, Restricted-Use, In-Transit, GR Blocked, Consignment Stock (vendor and customer), Special Stocks (project, sales order, subcontracting). From MMBE you can: double-click any stock type to see individual stock items and batches, navigate to material documents, and check storage bin assignments (in WM systems).

Related transactions: MB52 (warehouse stock — all materials at a plant/storage location), MB53 (plant stock), MB54 (consignment stock), MD04 (stock/requirements list — shows current stock plus all future supply and demand). In S/4HANA Fiori: 'Monitor Inventory' and 'Track Stock' apps replace MMBE with real-time graphical display.

GR/GI slips (output messages) are printed or electronic documents generated when a goods movement is posted — providing a paper trail that accompanies the physical goods. In SAP MM, output is controlled by the message determination framework (condition technique, similar to SD output).

Configuration: message condition records define which output type (WE01=GR slip, WA01=GI slip) is generated for which movement types, plants, and storage locations. Output can be: print (to a label printer or office printer at the warehouse), email (to the receiving department), EDI (advance shipping notice back to vendor). GR slips typically contain: material number and description, quantity received, PO reference, batch number, storage location, date and time, and a barcode for scanning.

In S/4HANA: Output Management replaces the classic NAST-based output framework. BRF+ (Business Rules Framework Plus) or Adobe Forms are used for GR/GI document generation. Warehouse teams can also use Fiori mobile apps that eliminate the need for printed slips entirely — digital proof of delivery replaces paper.

Inventory valuation determines the monetary value of stock on hand. SAP MM supports two primary valuation methods at the material master level (Accounting 1 view): Standard Price (S): a fixed price set for the entire period (typically updated quarterly or annually via CK11N/CK24 in product costing). All stock movements post at this price. Any difference between actual purchase price and standard price posts to a price difference account. Provides clear variance analysis. Moving Average Price (V): the price automatically recalculates after every GR based on the weighted average of existing stock value plus new receipt value. More accurate for materials with fluctuating prices (raw materials, trading goods).

Key rule: once a price control is set and a GR is posted, you cannot easily change between S and V. Standard price is recommended for finished and semi-finished products; moving average for raw materials. In S/4HANA, the Material Ledger is mandatory and can revalue stock to actual cost at period end regardless of the price control setting.

Logistics Invoice Verification (LIV) is the SAP MM process of verifying and posting vendor invoices that reference a Purchase Order and Goods Receipt. The primary transaction is MIRO. LIV performs the 3-way match automatically: PO (agreed price) vs. GR (received quantity) vs. Invoice (billed amount).

At MIRO posting: FI document is created — debit GR/IR account (clearing against the GR) + credit vendor AP account. If price differs from PO: price difference posts to account key PRD (configured in OBYC). If quantity differs and GR not yet done: invoice is parked or blocked. After MIRO, the vendor invoice is available for payment via F110 (automatic payment program).

LIV also handles: subsequent debits/credits (MIRO with transaction type 'Subsequent Debit' or 'Credit Memo') for price adjustments after the original invoice; unplanned delivery costs (freight, customs) added on top of the PO value; planned delivery costs (conditions in the PO); evaluated receipt settlement (ERS) — SAP auto-creates the invoice without the vendor sending one.

MIRO (Logistics Invoice Verification): used exclusively for vendor invoices that reference a Purchase Order. SAP performs automatic 3-way match (PO vs. GR vs. Invoice). Account determination is automatic via OBYC — the GL accounts (GR/IR, stock, price difference) are determined without manual entry. Tax can be automatically derived from the PO. MIRO is the standard transaction for all procurement-related invoices in an integrated MM/FI environment.

FB60 (Financial Accounting — Vendor Invoice): used for vendor invoices with no Purchase Order reference — utility bills, rent, professional fees, insurance. GL accounts must be entered manually. No 3-way match. Tax code entered manually. No integration with inventory or procurement.

Key rule: if a PO exists, always use MIRO. If no PO exists, use FB60. Mixing them up is a common audit finding — FB60 bypasses procurement controls (3-way match, GR requirement, tolerance checks) that MIRO enforces automatically.

An invoice block in MIRO prevents an invoice from being paid until the blocking reason is resolved. Types of blocks: R (Manual Block) — set manually by the user during MIRO entry; Stochastic Block — random sample block set by the system for audit purposes (configured in OMRM); Quantity Block — invoice quantity exceeds GR quantity (beyond tolerance); Price Block — invoice price exceeds PO price (beyond tolerance keys in OMR6); Date Block — invoice date is before or after defined limits; Quality Block — quality inspection not yet completed.

Invoice blocks are visible and managed in MRBR (Release Blocked Invoices). In MRBR, the purchasing team reviews: the blocking reason, the PO details, the GR history, and decides to release or reject. Released invoices immediately become available for F110 automatic payment. In S/4HANA Fiori: 'Release Blocked Invoices' app provides the same functionality with a modern UI and workflow integration.

Evaluated Receipt Settlement (ERS) is an automated invoice processing method where SAP creates the vendor invoice automatically based on the goods receipt — eliminating the need for the vendor to send a paper or electronic invoice. When a GR is posted for an ERS-enabled PO, SAP calculates the amount due (GR quantity × PO price) and posts the vendor invoice automatically.

Prerequisites: (1) ERS indicator must be set on the vendor master (XK02 → Purchasing view → 'AutoEvalGRSetmt Del.'); (2) ERS indicator on the PO item; (3) Tax code must be defined. ERS is run via MRRL (Evaluated Receipt Settlement). Output: vendor invoices posted automatically, ready for payment.

Benefits: eliminates invoice receipt and manual keying, reduces errors and disputes, ideal for high-volume procurement relationships. Common in: automotive (JIT deliveries), retail (replenishment), and any high-trust, long-term vendor relationship. The vendor reconciles against the statement SAP sends them rather than sending individual invoices.

Tolerance checks in MIRO define how much variation between the PO, GR, and invoice is acceptable before the invoice is blocked. Configured in OMR6 (Define Tolerance Keys). Key tolerance keys for LIV: AN (Amount for Item without Order Reference) — for invoices without PO; AP (Amount for Item with Order Reference); BD (Form Small Differences Automatically) — if the difference is below this amount, SAP posts it automatically to a small difference GL account without blocking; BR (Percentage for Rounding); DQ (Exceed Amount — Quantity Variance) — blocks if invoice quantity exceeds GR quantity beyond this %/amount; KW (Quantity Variance) — controls quantity differences; PP (Price Variance) — blocks if invoice price exceeds PO price beyond this %/amount; ST (Date Variance) — invoice date too early or late.

Tolerances are assigned to the Company Code. If a variance falls within tolerance: invoice posts without block. If outside tolerance: invoice is blocked (payment block set). The blocked invoice must be released in MRBR.

GR-based invoice verification (GRBIV) is a PO item setting that requires a goods receipt to be posted before the corresponding invoice can be verified and paid. When GRBIV is active on a PO item: MIRO can only invoice quantities that have been goods-receipted. The system compares invoice quantity to the GR quantity minus any previously invoiced quantity — not the PO quantity.

Activated per PO item: ME21N → item details → Invoice tab → 'GR-Based Inv. Verif.' checkbox. Can also be defaulted from the purchasing info record or vendor master. GRBIV is the standard for stock-relevant PO items. For service POs (item category D): instead of a GR, a Service Entry Sheet (ML81N) must be accepted before the invoice can be posted. For account-assigned POs (item category K — cost centre): GRBIV is optional. Without it, you can invoice before the GR — useful for advance payments or subscriptions.

Subsequent Debits (SD) and Subsequent Credits (SC) in MIRO handle price adjustments after the original invoice has already been posted and potentially paid. They adjust the material value without reversing the original posting:

Subsequent Debit: vendor charges an additional amount after the original invoice (e.g. freight surcharge not included originally, or price correction upwards). MIRO → Transaction = Subsequent Debit. Posts: debit stock (if material is still in inventory) or debit price difference account, credit vendor AP; Subsequent Credit: vendor issues a credit note after the original invoice (e.g. volume discount applied retrospectively, or price correction downwards). MIRO → Transaction = Subsequent Credit. Posts: debit vendor AP, credit stock or price difference account.

Key difference from Credit Memo: a Credit Memo fully reverses/reduces the original invoice quantity and amount. A Subsequent Credit only adjusts the value — the quantity reference remains unchanged. Subsequent debits/credits impact the moving average price of the material if the material uses MAP (price control V).

Invoice parking (MIR7 — Park Incoming Invoice) allows an invoice to be saved in SAP without being fully posted — creating a preliminary document that can be reviewed, completed, and posted later. The parked document does NOT create FI postings or update vendor balances — it is only saved in a temporary state.

Use cases: AP clerk receives invoice but needs manager approval before posting; invoice data is incomplete (missing cost assignment, unclear tax treatment); invoice needs to be pre-checked against the GR but GR is not yet posted. Parked invoices are visible in MIR6 (Invoice Overview) and can be: completed and posted (MIRO with reference to parked document), rejected and deleted, or held for further review.

In SAP workflow integration: MIR7 parking triggers an approval workflow (manager receives a workitem in SBWP or Fiori inbox). After approval, the invoice is posted automatically. Parked invoices do NOT appear in vendor aging reports (FBL1N) — only posted invoices appear. This is a common audit question: are all parked invoices resolved before month-end?

The MIRO document flow shows all linked documents from the initial PO through to the invoice and payment. To view: ME23N (display PO) → Environment → Document Overview — shows: PO → GR Material Documents → Invoice Documents → FI Payment Documents.

Alternatively: MIR4 (Display Invoice Document) → Follow-On Documents → shows the FI accounting document linked to the MIRO posting. The MIRO document header contains: document number, fiscal year, company code, vendor, invoice date, posting date, currency, and gross amount. The item level shows: PO number, PO line, GR document reference, quantity, amount, and tax.

Key status fields in the PO item (ME23N → Item → Purchase Order History): GR quantity (total received), IR quantity (total invoiced), GR value, IR value, and Delivery Completed indicator. A PO item is considered fully processed when GR quantity = PO quantity AND IR quantity = GR quantity AND the delivery completed indicator is set. In S/4HANA: Fiori app 'Track Purchase Orders' provides a visual document flow timeline.

Credit Memo (MIRO → Transaction = Credit Memo): used when the original invoice was posted incorrectly or goods are being returned to the vendor. A credit memo reverses or reduces the quantity and value of the original invoice — the invoiced quantity decreases. If goods have been returned (movement type 122 — return delivery to vendor), the credit memo references the original invoice and reduces both the GR quantity reference and the invoiced quantity.

Subsequent Credit (MIRO → Transaction = Subsequent Credit): used when a price reduction is agreed after the full invoice quantity has already been invoiced correctly — e.g. retrospective volume discount, price correction downward. A subsequent credit adjusts only the value, not the quantity. The invoiced quantity remains unchanged.

Practical example: You received 100 units at CA$10 each. Credit Memo = you return 20 units (quantity correction). Subsequent Credit = you keep all 100 units but vendor gives a CA$50 discount (value correction). Getting this distinction wrong in a client interview is a red flag — it is one of the most common MIRO interview questions.

The Vendor Master is the central repository of all vendor-related data in SAP. It is structured in three levels: (1) General Data — name, address, language, bank details. Shared across all company codes and purchasing organisations; (2) Company Code Data — accounting information: reconciliation account, payment terms, payment method, dunning. Maintained per company code; (3) Purchasing Organisation Data — procurement-specific: order currency, incoterms, minimum order value, GR-based IV indicator, ERS indicator. Maintained per purchasing organisation.

Transactions: XK01 (create — all levels), MK01 (create — purchasing only), FK01 (create — accounting only), XK02/XK03 (change/display). In SAP S/4HANA, vendor master is replaced by the Business Partner (BP) — transaction BP. All vendor-related roles (FLVN00 for general data, FLVN01 for purchasing) are maintained in one BP record. This is a mandatory topic in every S/4HANA MM interview.

Key fields in the Vendor Master purchasing organisation data (XK02 → Purchasing tab): Order Currency — default currency for POs; Payment Terms — default terms (e.g. NT30, 2/10 net 30) copied to POs; Incoterms — delivery terms (EXW, DDP, FOB, CIF) affecting who bears transport risk/cost; Minimum Order Value — warning if PO below this amount; Schema Group — determines which pricing schema applies to POs from this vendor; GR-Based Invoice Verification — if checked, MIRO can only post for quantities already goods-receipted; AutoEvalGRSetmt Del. (ERS) — enables Evaluated Receipt Settlement; Acknowledgement Required — vendor must send order acknowledgement; Shipping Conditions; Planned Delivery Time — default lead time in days used in MRP calculations. These fields are copied as defaults when creating a PO for this vendor and can be overridden at PO level.

A Purchasing Info Record (PIR) (ME11) stores the purchasing history and agreed conditions for a specific material-vendor-purchasing org-plant combination. It is SAP's memory of past procurement agreements and acts as the primary source for PO price defaulting.

Key data in a PIR: Net Price and Price Unit — default price when PO is created; Planned Delivery Time — lead time in days for MRP; Tolerance for Over/Under Delivery; Minimum Delivery Quantity; Tax Code; Reminder/Urging Keys — for overdue delivery follow-up; Last PO number and date. PIR types: Standard, Subcontracting, Consignment, Pipeline.

When a PO is created for a material-vendor combination with an existing PIR, SAP automatically copies the price and conditions. The PIR is updated when a PO is saved (if 'Update Info Record' flag is set). PIRs can also be created automatically from quotations (ME47).

A Vendor Account Group controls the master data structure for a vendor — specifically: the number range for vendor numbers (external or internal), which fields are required/optional/suppressed in the vendor master screens, and which partner functions are allowed. Examples: domestic vendors (0001), foreign vendors (0002), intercompany vendors (0003), one-time vendors (CPUT). Configured in OBD7.

A Reconciliation Account is a GL account in FI that is automatically updated whenever a posting is made to the vendor subledger. It links the AP subledger to the General Ledger. You cannot post directly to it — all postings go through the vendor account and the reconciliation account updates automatically. Assigned in the vendor master Company Code data tab. Different account groups can use different reconciliation accounts (e.g. domestic vendors → GL 200000, intercompany vendors → GL 201000).

Key distinction: Account Group = master data structure control; Reconciliation Account = FI integration link.

Vendor blocking prevents further transactions with a vendor without deleting the master record. Types of blocks: Posting Block (XK05/FK05) — prevents FI postings (invoices, payments) to the vendor. Can be set per company code or all company codes; Purchasing Block (MK05) — prevents new POs from being created for this vendor. Can be set per purchasing organisation or all; Quality Block — set via QM if vendor fails quality evaluation.

Deletion flag (XK06) — marks the vendor for deletion during the next archiving run. The vendor is not immediately deleted — it is archived via SARA (archiving object FI_LFA1) when no open items remain. Prerequisites for deletion: no open POs, no open invoices, no open payments, no future delivery schedules.

Common interview scenario: A vendor has gone bankrupt — what do you do in SAP? Answer: set purchasing block immediately (no new POs), set payment block on open invoices (FBL1N → change payment block), then set deletion flag once all open items are cleared.

Partner determination defines which business partners play which roles in a purchasing document. In SAP MM, the partner functions relevant for procurement are: LF (Vendor) — the main vendor supplying the goods; LS (Invoicing Party) — the entity that sends the invoice (may differ from the supplying vendor — e.g. a head office invoices on behalf of a subsidiary); WE (Goods Supplier) — where the goods are physically delivered from (may be a different plant or depot); RS (Invoice Presented By) — the party presenting the invoice for payment; OA (Ordering Address) — where the PO is sent.

Partner determination is configured in SPRO → MM → Purchasing → Partner Determination. Partner schemas define which partner functions are mandatory or optional for each document type. Partners are maintained on the vendor master and copied to POs automatically. This is important for complex procurement scenarios — for example, a global contract where a central vendor (LF) arranges delivery from a local subsidiary (WE) and billing from a shared service centre (LS).

A one-time vendor (also called a collective vendor or dummy vendor) is a single vendor master record used for all occasional, low-value purchases from vendors who do not warrant a permanent master record. Identified by a specific account group (typically CPUT) with the 'One-time Account' indicator set.

When a PO or invoice is posted to a one-time vendor, SAP prompts for the actual vendor address and bank details at transaction time — because the master record itself holds no address. Each transaction can have different actual vendor data while using the same master record number.

Use case: office supplies from a market vendor, conference registration fees, one-off service providers. Benefits: avoids master data proliferation (hundreds of rarely-used vendors don't clutter the system). Limitation: reporting by individual vendor is not possible since all transactions share one master record. For recurring vendors, always create a dedicated vendor master.

Vendor Evaluation (ME61) scores vendors based on performance across five main criteria: Price (how competitive vs. market/other vendors), Quality (inspection acceptance rates from QM), Delivery (on-time delivery vs. confirmed date), Service (responsiveness, complaint resolution), External Service (for service vendors). Each criterion has a configurable weight; the weighted total gives an overall score 0–100.

Scoring methods: Automatic — calculated from GR data (delivery dates, quantities), QM inspection results; Semi-automatic — partially calculated, partially entered; Manual — purely user-entered scores. Configuration in OMG1 (criteria and weighting). Results stored on vendor master, visible in ME63 (display evaluation). Scores used in: source list determination (prefer high-scoring vendors), contract negotiations, vendor development programmes, and procurement decisions. Vendor evaluation is a mandatory QM/MM topic in manufacturing and automotive interview rounds.

Vendor master data can be maintained at different levels depending on the organisational scope: Central Maintenance (XK01/XK02) — maintains all three levels simultaneously: General Data + Company Code Data + Purchasing Organisation Data. Ideal for full setup; Accounting Maintenance (FK01/FK02) — maintains General Data + Company Code Data only. Used by the Finance/AP team when they need to set up a vendor for payment without purchasing involvement; Purchasing Maintenance (MK01/MK02) — maintains General Data + Purchasing Organisation Data only. Used by the procurement team.

This split allows segregation of duties — the AP team controls payment terms and bank details; the purchasing team controls order conditions and GR settings. Neither team needs access to the other's data. In a SOX-controlled environment, this separation is a key internal control: the person who creates a vendor should not also be the person who approves payments to that vendor.

The Account Group determines the behaviour of the vendor master record: (1) Number range — whether vendor numbers are assigned internally by SAP or externally by the user; (2) Field selection — which fields are required, optional, display-only, or suppressed on the vendor master screens; (3) One-time account indicator — whether the record is a collective/one-time vendor.

Standard SAP account groups: 0001 (domestic vendors — internal number range), 0002 (foreign vendors), 0003 (intercompany vendors), CPUT (one-time vendors), CPD (one-time for FI). Configured in OBD7 (define account groups) and XKN1 (define number ranges).

In S/4HANA with Business Partner: the BP grouping replaces the vendor account group concept. BP groupings control number ranges and field selection for Business Partner master data. The CVI (Customer-Vendor Integration) framework maps BP groupings to legacy account groups for compatibility.

The Material Master is the central repository of all data about a material — it is the most important master data object in SAP MM and is shared across multiple modules. It is organised into views (tabs), each maintained by a specific organisational unit and department: Basic Data 1 & 2 — material description, base unit of measure, material group, weight/dimensions, EAN/UPC code; Purchasing — purchasing group, purchasing value key, over/under-delivery tolerances, GR processing time; MRP 1–4 — MRP type, lot size, safety stock, reorder point, planned delivery time; Plant Data/Storage 1 & 2 — storage conditions, batch management, shelf life, temperature; Accounting 1 & 2 — price control (S or V), standard price or MAP, valuation class; Costing 1 & 2 — costing lot size, variance key; Sales: Sales Org Data — sales unit, delivering plant; Quality Management — QM control key, inspection setup.

Transactions: MM01 (create), MM02 (change), MM03 (display), MM06 (set deletion flag), MM50 (extend to additional plants/views).

A Material Type groups materials with similar characteristics and controls: which views are available in the material master, which number ranges apply, whether the material is managed in stock (quantity and/or value updating), and which accounts are posted to during goods movements.

Standard material types: ROH (Raw Material) — procured externally, stock-managed; HALB (Semi-Finished) — produced internally; FERT (Finished Product) — sold to customers; HAWA (Trading Goods) — bought and sold without processing; DIEN (Services) — no stock management; VERP (Packaging Material); NLAG (Non-Stock Material) — procured for direct consumption (no stock posting); UNBW (Non-Valuated Material) — quantity-managed but not value-managed. Configured in OMS2.

Material type determines account determination — which GL accounts are posted to when stock is received or consumed. A material typed as ROH will post to a raw materials stock account; FERT posts to finished goods stock. This is a fundamental link between MM and FI.

A Material Group is a classification key used to group materials with similar characteristics for procurement, reporting, and account determination purposes. Examples: office supplies (001), IT equipment (002), raw materials — steel (010), chemicals (020), services — cleaning (050).

Material Group is maintained on the material master (Basic Data 1 view) and appears on every Purchase Requisition and Purchase Order. Key uses: (1) Account determination — in some configurations, the material group maps to GL accounts in OBYC (instead of valuation class); (2) Purchasing info records without material number — for services and non-stock items, the material group is the primary identifier; (3) Reporting — spend analysis by material group (ME2M, ME2C); (4) Release strategy — PR/PO approval thresholds can be set per material group; (5) Source list and contracts — framework agreements can be set per material group rather than specific material. Configured in OMSF.

SAP MM supports multiple units of measure for a single material, managed through unit of measure conversions on the material master (Basic Data 1 view, Additional Data → Units of Measure tab). Three key UoMs: Base Unit of Measure (BUoM) — the primary unit in which stock is managed internally (e.g. EA=each, KG=kilogram, L=litre, M=metre). All stock quantities are stored in BUoM; Order Unit (Purchase Order UoM) — the unit used when ordering from vendors (e.g. BOX, PAL=pallet, CS=case). SAP converts to BUoM automatically using the conversion factor; Sales Unit — the unit used when selling to customers.

Example: a bolt is managed in EA (each), ordered in BOX (100 per box), sold in PKG (10 per pack). Conversion: 1 BOX = 100 EA, 1 PKG = 10 EA. When a PO is created for 5 BOX: SAP converts and posts 500 EA to stock. Incorrect UoM conversions are one of the most common MM go-live issues — always validate during testing by checking MMBE stock quantity after a test GR.

The MRP views (MRP 1–4) on the material master control how SAP plans and procures the material automatically. Key fields: MRP 1 — MRP Type: PD (MRP), VB (reorder point — manual), VM (reorder point — automatic), ND (no MRP). MRP Controller: responsible planner. Lot Size: EX (exact/lot-for-lot), FX (fixed), HB (replenish to max level), MB (monthly). Minimum/Maximum Lot Size; Rounding Value.

MRP 2 — Procurement Type: E (in-house production), F (external procurement), X (both). Special Procurement: 20 (consignment), 30 (stock transfer). Safety Stock; Reorder Point (for VB type).

MRP 3 — Availability Check group; Strategy Group (MTS/MTO); Period Indicator for forecast.

MRP 4 — Selection Method for BOM/routing; Individual/Collective requirements indicator.

MRP views are the most complex part of the material master and are heavily tested in MM consultant interviews — especially for manufacturing clients.

A Material Number is the unique identifier for a material in SAP. It can be up to 40 characters in S/4HANA (18 characters in classic SAP ECC). Configuration options: Internal Number Assignment — SAP assigns the number automatically from a defined number range (user doesn't choose the number). Most common for materials; External Number Assignment — the user or an external system provides the number. Used when a legacy material code must be preserved; Alphanumeric — material numbers can contain letters and numbers (e.g. RM-STEEL-001, FG-WIDGET-A).

Number ranges are configured per material type in MMNR (Maintain Number Ranges). The material number appears on every procurement, inventory, and production document — it is the primary link between MM, SD, PP, and FI. In S/4HANA migrations: if changing from 18-char to 40-char material numbers, a migration project is required — this is a significant technical effort and must be planned early.

The Purchasing view on the material master contains fields that control procurement behaviour for the material at plant level: Purchasing Group — responsible buyer defaulted on PRs and POs; Plant-Specific Material Status — can block the material for procurement (e.g. 'Z1' = purchasing blocked); Tax Indicator for Plant — controls tax determination in purchasing; Purchasing Value Key — a grouping key that defaults reminder dates, tolerances, and shipping instructions for POs; Automatic PO indicator — allows POs to be generated automatically from PRs without manual creation (ME59N); Variable PO Unit — allows the order unit to be changed at PO entry time; GR Processing Time — number of workdays between GR and when the material is available (for MRP lead time calculation); Over/Under Delivery Tolerance — % variance allowed between PO quantity and GR quantity before a warning or block; Unlimited Over-Delivery — allows any quantity above PO to be received without warning.

The Accounting 1 view on the material master is the critical link between MM inventory management and FI financial valuation. Key fields: Valuation Class — the most important field. It determines which GL accounts are posted to during goods movements (configured in OBYC). Example: valuation class 3000 (raw materials) → GL 300000 (Raw Materials Inventory); Price Control: S (Standard Price — fixed for the period) or V (Moving Average Price — recalculates with each receipt); Standard Price — value per unit if price control = S; Moving Average Price — current weighted average value per unit if price control = V; Price Unit — quantity unit for the price (e.g. price per 100 KG); Total Stock and Total Value — current stock quantity and value (read-only, maintained by the system).

The valuation class is set when the material is created and cannot be changed once stock exists. It is one of the most important configuration decisions in any MM implementation.

Material Status controls whether a material can be used in specific business transactions. Two levels: Cross-Plant Material Status (Basic Data 1 view) — applies across all plants and all modules. Examples: 01 (blocked for procurement), 02 (blocked for production), 03 (blocked for all transactions), P1 (phase-out — warning only); Plant-Specific Material Status (Purchasing view or MRP 1 view) — applies only at a specific plant. Can block procurement at one plant while allowing it at others.

When a blocked material is used in a PO or PR: SAP either issues a warning (user can override) or an error (transaction blocked) depending on the status configuration in OMS4. Material status is typically used during: product discontinuation (set to phase-out, then blocked), quality holds (block all transactions until resolved), new product introduction (block production until design is finalised). It is a key master data governance tool — changes must go through a formal approval process.

Extending a material master means creating additional organisational data for an existing material — at a new plant, new storage location, new sales organisation, or new purchasing organisation. This is done via MM01 (same transaction as creation — SAP recognises the material already exists and only shows the extension screens) or via MM50 (mass extension — extend multiple materials to multiple plants/views simultaneously).

Common extension scenarios: company acquires a new manufacturing plant — all existing materials must be extended to the new plant with MRP, purchasing, and accounting views; new sales channel opens — materials extended to new sales organisation with sales-specific pricing and delivering plant; new storage location added — Storage Location views extended for warehouse management.

Extension is a critical activity in MM rollout projects — failing to extend materials before go-live prevents procurement and production. A common best practice: create a material extension checklist showing each material × plant × view combination required, validate completeness before cutover, and use MM50 for mass extension to save time.

Split valuation allows a single material at a single plant to be valued at different prices for different subsets of stock — based on a valuation type such as origin, quality grade, or procurement type. Activated at the client level in OMWC.

Example: Steel coils received from Vendor A (domestic, CA$500/ton) and Vendor B (imported, CA$600/ton) are the same material but valued separately. Split valuation creates: a Valuation Category (e.g. 'H' for origin) and Valuation Types (e.g. 'DOMESTIC', 'IMPORT'). Each valuation type has its own MAP or standard price and its own stock quantity.

When to use: pharmaceutical batches (each batch has different cost), precious metals (price varies by purity), raw materials with different origins requiring separate cost tracking. Stock overview (MMBE) shows stock split by valuation type. Valuation type is entered at GR time. Split valuation is powerful but complex — it significantly impacts MIRO, CO-PA, and product costing. Only activate when truly needed — it cannot be easily reversed once transactions exist.

Account determination in MM (OBYC) is the configuration that automatically maps goods movements to the correct GL accounts in FI — without any manual account entry by the user. Every time MIGO or MIRO posts a document, SAP uses OBYC to determine the GL accounts.

OBYC uses Transaction/Event Keys (3-character codes) to categorise the type of movement: BSX (Stock Posting) — the inventory account; WRX (GR/IR Clearing) — the goods receipt/invoice receipt clearing account; PRD (Price Difference) — for price variances between PO price and MAP; GBB (Offsetting Entry for Inventory Posting) — for goods issues; AUM (Expense/Revenue from Stock Transfer); KON (Consignment Payable); EIN/EKG (Purchase Account — for purchase account management).

Account determination factors: Transaction Key + Valuation Grouping Code (from plant) + Valuation Class (from material master) + Account Modifier (from movement type) = GL Account. Getting OBYC right is critical — errors here cause incorrect financial postings at every goods movement.

The Valuation Grouping Code is an intermediate layer in account determination that groups plants with similar financial requirements together — allowing them to share GL account assignments in OBYC without defining separate accounts for every individual plant.

Configuration: OMWD — assign valuation grouping code to each plant (and company code combination). Example: all Canadian plants use grouping code '0001'; all US plants use '0002'. In OBYC, accounts are assigned per: transaction key + valuation grouping code + valuation class. This means Canadian plants post raw material receipts to GL 300000 (CAD raw materials account) while US plants post to GL 310000 (USD raw materials account) — even though they use the same valuation class and movement type.

The valuation grouping code is activated in OMWM. Without it, account determination uses the company code directly (less flexible). With it, multiple plants in the same company code can have different account assignments. This is a frequently misunderstood MM-FI integration concept tested in senior consultant interviews.

When a Goods Receipt (GR) is posted in MIGO (movement type 101 against a PO), SAP creates both a material document and an FI accounting document simultaneously. The FI posting at standard price (price control S): Debit — Inventory/Stock account (BSX) at standard price × quantity. Credit — GR/IR Clearing account (WRX) at PO price × quantity. If PO price ≠ standard price: Debit or Credit — Price Difference account (PRD) for the variance.

At moving average price (price control V): Debit — Inventory account at PO price × quantity (MAP updates). Credit — GR/IR Clearing account at PO price × quantity. No PRD posting — MAP absorbs the price.

Additional postings that may occur: Delivery costs (freight, customs) — if planned in PO conditions, posted separately to freight/customs GL accounts at GR. Tax — input tax posted to tax GL account if applicable. All account assignments are automatic via OBYC. The GR accounting document is the primary link between the physical receipt of goods and the financial liability to the vendor.

Purchase Account Management is an alternative accounting approach used in some countries (particularly Germany — for EK01/EK02 accounts) where the purchase value is posted to a separate Purchase Account in addition to the stock account — enabling a clearer distinction between the cost of goods purchased and inventory value changes.

When activated (via OMWM — activate purchase account), at GR: Debit — Stock account (BSX), Credit — GR/IR (WRX), Debit — Purchase Account (EIN), Credit — Purchase Offsetting Account (EKG). The purchase account tracks total purchasing spend independently from inventory valuation — useful for specific national accounting requirements.

In Canada and the USA: purchase account management is rarely used. It is more common in European implementations following German HGB accounting requirements. In most North American MM implementations, OBYC uses only BSX (stock) and WRX (GR/IR) for the standard GR posting. This is a knowledge-differentiator question — knowing when NOT to use something is as important as knowing how to configure it.

The Moving Average Price (MAP) — price control indicator V on the material master Accounting 1 view — automatically recalculates the material's unit value after every goods receipt, revaluing the total stock to the weighted average of existing stock value plus new receipt value.

Formula: New MAP = (Existing Stock Value + GR Value) / (Existing Stock Qty + GR Qty)

Example: 100 units in stock at CA$10.00 = CA$1,000. GR of 50 units at CA$12.00 = CA$600. New MAP = (1,000 + 600) / (100 + 50) = CA$10.67. All future GI postings use CA$10.67 until the next GR changes it.

MAP is recommended for: raw materials, trading goods, and any material where purchase price fluctuates. MAP issues to know: if a GI is posted when stock quantity is zero (or negative), SAP cannot calculate a correct MAP — price differences post to a price difference account instead. This is the most common MAP-related problem in production environments and a standard interview question.

The Standard Price — price control indicator S on the material master — is a fixed price that does not change during the period, regardless of actual purchase prices. All stock receipts, issues, and inventory postings use this fixed price. Any difference between the actual purchase price and the standard price is posted to a Price Difference account (PRD in OBYC).

Standard price is set/updated via: CK11N (cost estimate calculation) → CK24 (mark and release — updates material master). Typically updated quarterly or annually as part of standard cost update.

When to use: Finished goods (FERT) — standard cost represents the planned production cost, enabling clear variance analysis; Semi-finished goods (HALB) — same reason; Any material where consistent valuation for management reporting is required. Standard price enables clean CO variance analysis (actual vs. standard cost). The price difference account accumulates all purchase price variances — in month-end reporting, this tells management how much raw material costs deviated from plan.

The Material Ledger (ML) in SAP S/4HANA is a mandatory sub-ledger that records all inventory-relevant financial transactions at material level in multiple currencies and valuation approaches simultaneously. In S/4HANA, the Material Ledger is always active — it cannot be deactivated.

Key functions: (1) Multi-Currency Valuation — stock is valued in company code currency, group currency, and a third currency simultaneously; (2) Actual Costing — at period end, CKMLCP (Material Ledger Closing) calculates the actual cost of each material by rolling up all price variances (purchase price differences, production variances) through the BOM structure and revaluing inventory to actual cost; (3) Periodic Unit Price (PUP) — the actual cost per unit calculated after period close, stored on the material master as the 'periodic unit price'.

Even if a company uses standard price (S) and does not want actual costing, the Material Ledger still records all price differences for multi-currency reporting. The actual costing run (CKMLCP) is optional — it must be explicitly activated if the company wants inventory revaluation to actual cost.

The GR/IR (Goods Receipt / Invoice Receipt) clearing account is a temporary balance sheet liability account that sits between MM and FI, recording the timing difference between when goods are received and when the vendor invoice is posted. It should always net to zero in steady state.

Open GR/IR balances at month end mean: (1) GR posted, IR not yet posted — goods received but vendor invoice not yet in SAP. This is an accrued liability — a provision may be needed for accurate P&L; (2) IR posted, GR not yet posted — vendor invoice in SAP but goods not yet received. This should be investigated — either the GR is overdue or the invoice was posted incorrectly.

Month-end reconciliation: F.13 (automatic clearing) clears matched GR/IR items. MR11 (GR/IR account maintenance) displays all open items with their GR and IR documents side by side, allowing investigation and manual clearance. MB5S (GR/IR balance) shows the GR/IR balance grouped by PO. Best practice: run MR11 analysis weekly during the month — don't leave all reconciliation to month-end closing.

Subcontracting GR (movement type 101 with item category L): when finished/processed goods are received from a subcontractor, two postings occur simultaneously: (1) Receipt of finished material: debit finished goods/WIP stock (BSX) + credit GR/IR (WRX) at subcontracting PO price (which covers only the processing fee, not the components); (2) Consumption of components (movement type 543 — automatic): debit subcontracting consumption account (GBB-VBO) + credit component stock (BSX). The net result: component stock decreases, finished goods stock increases, and a liability to the subcontractor for processing fee is created via GR/IR.

Consignment GR (movement type 101 with item category K): No FI posting at GR — because the stock is still owned by the vendor. The material document is created (stock quantity increases in vendor consignment stock) but no accounting document. FI posting occurs only when consignment stock is withdrawn (movement type 201/261 with special stock K): debit consumption account + credit consignment payable (KON in OBYC). Settlement via MRKO converts the consignment payable to a standard vendor AP posting.

Purchasing document types (Purchase Orders, RFQs, Contracts) are configured in SPRO → MM → Purchasing → Purchase Order → Define Document Types. Key settings per document type: Number Range — internal or external number assignment; Item Number Interval — increment between item numbers (10 or 1); Allowed Item Categories — which item categories (standard, consignment, subcontracting) are permitted; Allowed Account Assignment Categories — which cost objects (cost centre, asset, project) can be used; Link to PR — whether the PO must reference a PR; Field Selection Key — controls which fields are required/optional/suppressed on the document; Output Application — which output type (print, EDI, email) applies. Standard document types: NB (standard PO), FO (framework order), UB (stock transport order). Custom document types (Z* prefix) are created when client-specific requirements cannot be met by standard types — e.g. ZNBG for government procurement with additional mandatory fields.

PO release strategy configuration in SPRO → MM → Purchasing → PO → Release Procedure → Procedure with Classification: (1) CL02 — create a class (e.g. MM_PO_REL) with class type 032 (purchasing documents); (2) CT04 — create characteristics (e.g. TOTAL_VALUE, PURCH_ORG, PLANT) with reference to CEBAN/CEKKO fields; (3) SPRO → Define Release Groups — group POs by document type (e.g. group 01 for all NB orders); (4) Define Release Codes — individual approver levels (A=Buyer, B=Manager, C=Director) with workflow agent assignment; (5) Define Release Indicators — statuses (0=blocked, 1=released for ordering); (6) Define Release Strategies — assign which codes must approve based on class/characteristic values; (7) Define Release Prerequisites — which codes must approve before others.

Runtime: newly created PO is automatically assigned a release strategy based on its value and characteristics. Approvers receive workflow items (ME28 mass release, ME29N individual, or Fiori 'Approve Purchase Orders'). Released PO can be transmitted to vendor. Common configuration error: classification not linked to the correct purchasing document type — causes no release strategy to be determined.

Movement types are configured in OMJJ (Customise Movement Types) or SPRO → MM → Inventory Management → Movement Types. Key settings: Short Text; Quantity Updating — does this movement update material stock quantity?; Value Updating — does this movement update stock value?; Special Stock Indicator — which special stock type (K=consignment, O=project, etc.); Reversal Movement Type — the corresponding reversal (e.g. 102 reverses 101); Reason for Movement — optional reason code; Check Over/Under-Delivery; Account Grouping Code — links to OBYC for account determination; Print Indicator — whether a GR/GI slip is printed; Status of GR Slip.

Custom movement types: always copy from an existing standard movement type (never create from scratch). Copy 101 for custom GR types, 201 for custom GI types. Use Z-prefix for custom movement types (e.g. Z01). Test every custom movement type thoroughly — incorrect configuration causes wrong FI postings that are difficult to reverse.

Tolerance keys for LIV are configured in OMR6 (Define Tolerance Limits) and assigned to Company Codes. Key tolerance keys: AN (Amount for Item without PO Reference) — maximum amount for non-PO invoices; AP (Amount for Item with PO Reference); BD (Form Small Differences Automatically) — if difference below this amount, auto-post to small differences account without block; BR (Percentage for Rounding); BW (Value for Moving Average Price Variance) — relevant for MAP materials; DQ (Exceed Amount — Quantity Variance) — blocks if invoice qty substantially exceeds GR qty; KW (Quantity Variance when GR-Based IV Active) — percentage and absolute tolerance; PP (Price Variance) — percentage and absolute for price differences; PS (Price Variance — Estimated Price); ST (Date Variance — Value x Days).

Each tolerance key has: upper limit (%) and lower limit (%), and an absolute amount limit. Variances within limits: invoice posts without block. Outside: payment block set automatically. Best practice: set BD (small differences) to CA$1–CA$5 to auto-clear rounding variances that are not worth investigating.

Evaluated Receipt Settlement (ERS) configuration: (1) Vendor master (XK02 → Purchasing view): set AutoEvalGRSetmt Del. indicator; (2) PO item (ME21N → Item → Invoice tab): set ERS indicator and ensure GR-Based IV is also active; (3) Tax code must be defined on the PO item (ERS requires a tax code since no paper invoice arrives with tax information); (4) SPRO → MM → LIV → ERS: Define Tolerance Groups for ERS — set tolerance for quantity and price differences that can be settled automatically; (5) Define Number Ranges for ERS documents.

Runtime: MRRL (Evaluate and Post Automatic Settlements) — run periodically (daily/weekly). SAP identifies all GRs posted against ERS-enabled POs that have not yet been invoiced → creates IV documents automatically → posts vendor invoices → makes available for F110 payment. Output: settlement list showing all auto-created invoices. Vendor receives a settlement statement rather than sending individual invoices. Common issue: if a GR quantity correction is needed after ERS settlement, it creates a complex reversal chain — catch GR errors before ERS runs.

Stock Transport Order (STO) configuration for inter-plant transfer: (1) SPRO → MM → Purchasing → PO → Set Up STO: Define Shipping Data for Plants — assign shipping point and checking rule to supplying plant; (2) Assign Delivery Type and Checking Rule — for STO with SD delivery (cross-company or long-distance): assign outbound delivery type (e.g. NL for intra-company, NLCC for cross-company) to the STO document type; (3) Define Rules for PO Creating — for MRP to create STOs automatically; (4) Plants must be assigned to the same or different company codes as required; (5) For cross-company STO: SD billing must be set up — when goods are issued at supplying plant, an SD billing document is created for intercompany revenue.

Runtime: ME21N with document type UB — enter supplying plant, receiving plant, material, quantity. For STO with delivery: VL10B creates outbound delivery at supplying plant → VL02N posts goods issue → goods in-transit → MIGO (movement type 101) posts GR at receiving plant. The STO process is one of the most complex and frequently tested MM scenarios.

PO output (message output) controls how Purchase Orders are transmitted to vendors — print, email, EDI, fax. Configuration in SPRO → MM → Purchasing → Messages: (1) Define Message Types — NEU (new PO), ZNEU (custom), ZANG (order acknowledgement request); (2) Define Message Schema — assign message types to PO document types; (3) Define Message Determination Schema — condition technique: which vendor/purchasing org/plant combinations trigger which output type; (4) Define Print Parameters — printer name, number of copies, time of output (immediate or next batch); (5) Define Forms — SAPscript or Adobe Form template for the PO layout; (6) Maintain Condition Records (MN04) — for each vendor/purchasing org: output medium (1=print, 5=EDI, 6=email), partner function, language.

In S/4HANA: Output Management (BRF+ based) replaces the classic NAST framework. Adobe Forms or Smart Forms replace SAPscript. Email transmission uses SAP BCS (Business Communication Services). EDI uses SAP ALE/IDOC or third-party middleware (e.g. MuleSoft, IBM Sterling).

Physical inventory configuration in SPRO → MM → Inventory Management → Physical Inventory: (1) Define Tolerance Groups — maximum allowed inventory difference (% and absolute amount) before posting requires additional authorisation. Example: differences up to 2% of book value post automatically; above 2% require manager approval; (2) Define Inventory Sampling Procedure — for statistical sampling approach; (3) Define Number Ranges for Physical Inventory Documents (MINR); (4) Set Cycle Counting Parameters (MICC) — assign cycle counting indicators (A, B, C, D) to materials based on value/movement frequency. A=count monthly, B=quarterly, C=semi-annually, D=annually. Materials automatically flagged for counting via MICN; (5) Block GI During Count — optional: prevent goods issues from storage location while counting is in progress to avoid discrepancies.

Runtime: MI01 (create PI document) → MI04/MI09 (enter/recount) → MI07 (post differences). In S/4HANA: Fiori 'Count Physical Inventory Items' app allows mobile counting with barcode scanning.

Number ranges in Inventory Management (IM) are configured in OMBT (Number Ranges for Material and Accounting Documents) and SPRO → MM → Inventory Management → Number Assignment. Key number range objects: MATBELEG — material document numbers (MIGO postings). Ranges typically: 4900000000–4999999999 for goods receipts, 5000000000–5099999999 for goods issues, etc.; MKPF — material document header; separate ranges can be defined per transaction/movement type group.

In SAP S/4HANA: material documents and accounting documents share the same number (document number unification). The material document number = FI accounting document number. This simplifies reconciliation between MM and FI — one number ties both together. In classic SAP ECC: material documents (MATBELEG) and accounting documents (BKPF) had separate number ranges and were linked via a reference field.

Best practice: define separate number ranges per fiscal year (year-dependent) for clear audit trails. Ensure number ranges are large enough — running out of material document numbers in production causes a system-wide blockage of all goods movements until new ranges are added.

Automatic PO creation (ME59N) converts approved PRs directly into POs without manual buyer intervention. Prerequisites and configuration: (1) Material master Purchasing view — 'Automatic PO' indicator must be checked for the material; (2) Vendor master Purchasing view — 'Automatic PO' indicator must be checked; (3) Source list — a unique, fixed source must exist for the material-plant-purchasing org combination (no ambiguity about which vendor to use); (4) Purchasing info record — price and conditions must exist for the material-vendor combination; (5) The PR must be fully approved (released) if a release strategy is active.

Runtime: ME59N run manually or as a scheduled background job. SAP selects all eligible PRs and creates POs automatically, grouping items by vendor. Buyers review the created POs in ME28 and release if a PO release strategy is also active. Automatic PO creation is ideal for: MRO (maintenance, repair, operations) items with fixed vendors, consumables with blanket agreements, and high-volume repetitive procurement where buyer judgement is not needed.

Essential MM tables: Purchasing Documents: EKKO (PO header — doc number, vendor, purchasing org, doc type), EKPO (PO line items — material, quantity, price, plant, storage location), EKBE (PO history — GR and IR transactions per PO item), EKET (delivery schedule lines — for scheduling agreements), EKKN (account assignment per PO item). Material Master: MARA (general data — material type, base UoM, material group), MARC (plant-specific data — MRP settings, procurement type), MARD (storage location stock — quantity per plant/storage location), MAKT (material descriptions per language), MBEW (material valuation — MAP, standard price, stock value), MLAN (tax classification). Material Documents: MKPF (material document header), MSEG (material document line items — movement type, quantity, plant). Vendor Master: LFA1 (general data), LFB1 (company code data), LFM1 (purchasing organisation data). Stock: MCHB (batch stocks), MKPF+MSEG (movement history). In S/4HANA: ACDOCA replaces separate FI/CO tables; MATDOC replaces MKPF/MSEG for material documents.

EKBE (History per Purchasing Document Item) is one of the most important MM tables — it records all goods receipt, invoice receipt, and delivery cost transactions against a specific PO item. Each row in EKBE represents one historical event: BEWTP (movement/transaction type): E=GR, Q=Invoice, L=Delivery cost invoice, R=Return delivery; MENGE (quantity), WRBTR (amount in document currency), SHKZG (debit/credit indicator), BELNR (material or FI document number), BUDAT (posting date).

Common uses: checking whether a PO item has been fully goods-receipted (sum of MENGE where BEWTP=E), checking whether it has been fully invoiced (sum where BEWTP=Q), identifying which GR documents relate to which PO, reconciling GR/IR clearing accounts by PO. In custom reports: always join EKBE to EKKO (PO header) and EKPO (PO item) for full context. In S/4HANA: EKBE is still available as a compatibility view; the underlying data is in the Universal Journal (ACDOCA) and MATDOC.

A MM functional consultant needs: (1) Read ABAP — understand custom reports and exits well enough to review them and write functional specs; (2) SE16N — query MM tables directly (EKKO, EKPO, MSEG, MARA, MBEW) for data analysis, issue investigation, and migration validation; (3) SE38/SE80 — basic debugging to identify where a custom program or exit is failing; (4) LSMW — create batch input recordings for master data migration (material master MM01, vendor master XK01, info records ME11, source lists ME01); (5) BAPI knowledge — key MM BAPIs: BAPI_PO_CREATE1 (create PO), BAPI_GOODSMVT_CREATE (post goods movement), BAPI_MATERIAL_SAVEDATA (create/change material master); (6) Enhancement points — key MM BAdIs: ME_PROCESS_PO (PO processing), MB_MIGO_BADI (MIGO enhancements), LME001 (message output); (7) Write Functional Specifications for all custom developments. As always: the functional consultant directs, the ABAP team implements.

Key SAP MM enhancement points: Purchase Order: BAdI ME_PROCESS_PO — fires during PO save; used for custom validations (e.g. prevent PO without budget check), field defaulting, or cross-field validation; BAdI ME_PURCHDOC_POSTED — fires after PO is saved; used for triggering downstream processes. Goods Movements (MIGO): BAdI MB_MIGO_BADI — fires during MIGO; used for custom checks before posting (e.g. check material is approved for the plant); MB_DOCUMENT_BADI — fires after material document is posted; used for triggering follow-on actions. Invoice Verification (MIRO): BAdI MRM_INVOICE_CHECK — fires during MIRO; used for custom invoice validation rules. Message Output: User exit EXIT_SAPLEINM_001 for PO output. Account Determination: BAdI MB_DOCUMENT_UPDATE for custom account determination logic.

Finding enhancement points: SE84 → Enhancements → Business Add-Ins → search for MM or MB. Always prefer BAdIs over classic user exits — BAdIs support multiple simultaneous implementations and are upgrade-safe.

LSMW (Legacy System Migration Workbench), transaction LSMW, is used for bulk data migration from legacy systems into SAP. For MM, key use cases: Material Master — record MM01 transaction, map legacy material fields to SAP fields, upload thousands of materials at once; Vendor Master — record XK01 for all three levels; Purchasing Info Records — record ME11; Source Lists — record ME01; Open Purchase Orders — record ME21N for historical open POs at cutover.

LSMW process: (1) Create project and object; (2) Record transaction; (3) Define source structure matching legacy file layout; (4) Map source fields to LSMW batch input fields; (5) Specify source file (CSV/Excel); (6) Read and convert data; (7) Import in test mode first; (8) Check error log; (9) Fix errors and re-import; (10) Import in production mode. In S/4HANA: SAP Migration Cockpit (LTMC) provides pre-built migration objects for materials, vendors, purchase orders with Excel templates — significantly faster than LSMW for standard objects.

These are the primary purchasing analysis reports in SAP MM: ME2M (Purchase Orders by Material) — lists all POs for a specified material, material group, or plant. Shows: PO number, vendor, quantity, net price, delivery date, GR status. Filter by: plant, purchasing group, document date, delivery date. Used for: checking all open orders for a specific raw material, analysing pricing across vendors for the same material; ME2L (Purchase Orders by Vendor) — lists all POs for a specified vendor. Shows: materials ordered, quantities, values, GR/IR status. Used for: vendor spend analysis, checking open POs before blocking a vendor; ME2C (Purchase Orders by Material Group) — lists all POs for a material group. Used for: category spend analysis, budget tracking by commodity type.

All three reports use the same selection screen and display ALV output with drill-down to PO details. In S/4HANA: these reports are complemented by Fiori apps 'Monitor Purchase Orders', 'Purchasing Analytics' (real-time spend dashboards), and SAP Analytics Cloud for advanced spend analysis. Classic ME2M/ME2L/ME2C still work in S/4HANA and are commonly used by buyers for daily PO monitoring.

MIGO (transaction MIGO) has a structured two-level layout: Header Level: document date, posting date, delivery note number (vendor's delivery note for reference), bill of lading, header text, external document number. Item Level — multiple tabs: Material tab: material number, quantity, unit of measure, storage location, batch, serial number; Quantity tab: quantity in unit of entry, quantity in base unit, delivery completed indicator; Where tab: plant, storage location, stock type (unrestricted/QI/blocked), special stock; Purchase Order Data tab: PO number, PO item, GR/GI slip number, delivery note; Partner tab: vendor, goods supplier; Account Assignment tab: only visible if PO item has account assignment (shows cost centre, WBS, asset); Serial Numbers tab: for serial number-managed materials; Batch tab: batch classification data.

The Detail area (bottom half) shows item-level information while the Overview (top half) shows all items. After entering all data, click the green traffic light to check for errors, then Post to create the material document.

The MM document flow links all procurement documents from start to finish, providing a complete audit trail. Full P2P document flow: MRP Planned Order (MD04) → converted to Purchase Requisition (ME51N/ME52N) → converted to Purchase Order (ME21N/ME23N) → Goods Receipt Material Document (MIGO/MB03) + FI Accounting Document (FB03) → MIRO Invoice Document (MIR4) + FI Invoice Document (FB03) → F110 Payment Document (FBL1N).

Viewing the document flow: ME23N (Display PO) → Environment → Document Overview → shows all linked PRs, GRs, invoices, and payments in a tree structure. Alternatively: ME23N → item level → PO History tab shows all GR and IR documents with quantities and values.

Each document is linked by reference: GR references PO → IR references PO and GR → Payment references IR. This linkage enables: 3-way match validation, GR/IR reconciliation, spend analysis, and complete audit trail from need identification to cash payment. In S/4HANA Fiori: 'Track Purchase Orders' app provides a visual timeline of the full document flow.

These are all goods movement transactions but differ in their use case and interface: MIGO (unified goods movement transaction — recommended for all new implementations and S/4HANA): single transaction covering all movement types. Role-based interface, supports all special stock types, batch management, serial numbers. The standard in S/4HANA.

MB1A (Goods Issue — classic): older transaction for posting goods issues (movement types 201, 261, 551, etc.) without reference to a purchase or production order. Simple list-based interface. Still works but not recommended for new projects.

MB1B (Transfer Posting — classic): for posting stock transfers (movement types 301, 303, 305, 311, 411, 413, etc.) between plants, storage locations, or stock types. Used for: unrestricted → quality inspection, plant to plant, batch reclassification.

MB1C (Other Goods Receipts — classic): for goods receipts without a reference document (movement types 501, 561 — initial stock entry, 503 — GR into quality stock without PO). Used during initial stock entry at go-live.

In S/4HANA: MB1A, MB1B, MB1C are still available for backward compatibility but MIGO should be used for all new development and training.

EDI (Electronic Data Interchange) in SAP MM enables automated electronic transmission of Purchase Orders, GR confirmations, and invoices between SAP and vendor systems — eliminating manual email/print and reducing errors. SAP uses IDocs (Intermediate Documents) as the data container for EDI messages.

PO transmission via EDI: (1) PO is created/changed in SAP (ME21N); (2) Output type ECPO (or ORDERS for EDIFACT) is triggered via message determination; (3) SAP creates an IDoc of type ORDERS05 (purchase order) containing all PO data; (4) The IDoc is sent to the EDI subsystem (SAP ALE port, or middleware like MuleSoft, IBM Sterling, Boomi) via RFC or file; (5) The middleware translates the IDoc to the vendor's EDI format (EDIFACT ORDERS, ANSI X12 850, or XML); (6) The translated message is sent to the vendor electronically.

Inbound EDI: vendor sends an order acknowledgement (ORDRSP IDoc) → SAP receives and updates PO confirmation; vendor sends advance shipping notice (DESADV IDoc) → SAP creates inbound delivery; vendor sends e-invoice (INVOIC IDoc) → SAP creates MIRO document automatically. EDI is a key topic in MM/Logistics interviews at manufacturing and retail companies.

SAP Activate methodology for MM: (1) Discover — understand client's procurement processes, material types, vendor base, warehouse structure, and existing ERP; (2) Prepare — project team, system landscape (DEV/QA/PRD), workstream planning with MM, WM, and FI leads; (3) Explore — Fit-to-Standard workshops: demo standard P2P process (PR→PO→GR→MIRO→F110) to procurement and finance teams. Document gaps — e.g. client needs custom approval levels, or local tax configuration for multi-province Canada; (4) Realise — configure SPRO: organisational structure, material types, movement types, account determination (OBYC), release strategies, message output. Develop RICEFW (reports, interfaces, data migration programs). Unit test and SIT; (5) Deploy — data migration: material master (MM01 via LSMW), vendor master (XK01 via LSMW), open POs (ME21N via LSMW), initial stock (MB1C movement type 561). End-user training. Go-live weekend. (6) Run — hypercare: support first month-end GR/IR reconciliation, first F110 run, first physical inventory.

As MM consultant: lead procurement and inventory workstream, configure all MM settings, write FS for custom developments, support data migration, train super users, provide hypercare.

A large open GR/IR balance at month end is a common production issue. Structured approach: (1) Run MB5S (GR/IR balance per PO item) — identify which POs have open GR/IR: either GR without IR, or IR without GR; (2) GR posted, IR not posted (most common): check if vendor invoice has arrived. If yes: post MIRO immediately. If no: create an accrual (FBS1 — debit the relevant expense/cost account, credit a provision/accrued liability account) for month-end P&L accuracy. Reverse the accrual when MIRO is posted; (3) IR posted, GR not posted: investigate whether goods were actually received. If received but not posted: post MIGO retrospectively (if period is open) or in current period (check with Finance). If goods not received: is the invoice disputed? Put a payment block on the invoice in FBL1N; (4) MR11 — GR/IR account maintenance: for aged items where PO is fully closed, use MR11 to clear the remaining balance; (5) Root cause fix: implement a daily GR/IR exception report emailed to the AP and warehouse teams — most GR/IR issues can be prevented by catching them within 48 hours rather than at month-end.

Vendor master cleanup is a common project — especially before S/4HANA migration. Approach: (1) Extract all vendor master data (XK03 or SE16N on LFA1, LFB1, LFM1) and export to Excel; (2) Identify duplicates — same vendor with multiple master records (common after mergers or multiple SAP implementations). Flag by: matching bank account numbers, same VAT registration number, similar names (fuzzy matching); (3) Identify inactive vendors — no PO in last 2-3 years. Flag for deletion or blocking; (4) Data quality checks: vendors with no bank details (payment will fail in F110), vendors with no payment terms (F110 will not select), vendors with no reconciliation account; (5) Deduplication: consolidate duplicate vendors — transfer all open items from duplicate to master record (FBL1N → manual reposting), then block and flag for deletion the duplicate; (6) Governance going forward: implement a vendor creation approval workflow, mandatory bank detail verification (call vendor to confirm), dual control for bank changes (SOX requirement). In S/4HANA: SAP Master Data Governance (MDG) provides workflow-based vendor creation with duplicate check built in.

Complex GR scenario: Subcontracting with quality inspection and batch management in a pharmaceutical client: (1) Subcontracting PO (item category L) raised for a contract manufacturer. Components listed in the PO: API (Active Pharmaceutical Ingredient) 10 KG + Excipients 40 KG; (2) Components issued to subcontractor (movement type 541 — transfer to subcontractor stock, still our property); (3) Subcontractor produces tablets and delivers; (4) GR posted in MIGO (movement type 101 item category L): SAP simultaneously receives finished goods into Quality Inspection stock (because QM inspection is active) AND automatically consumes the components (movement type 543 — subcontracting consumption); (5) Batch is created automatically at GR with expiry date and country of origin captured via batch classification; (6) QM usage decision (QA32) — quality lab posts inspection results. If passed: batch released to unrestricted stock (movement type 321). If failed: batch moved to blocked stock (movement type 344); (7) MRKO — consignment/subcontracting settlement creates the vendor invoice for processing fees. Key challenge: ensuring the component consumption exactly matches what was actually used — any yield variance must be posted separately via movement type 543 adjustment.

MM cutover is one of the most time-critical go-lives — procurement and warehouse operations cannot stop. Approach: (1) Cutover plan (8 weeks before): every task, owner, duration, dependency. Key MM tasks: material master load, vendor master load, open PO load, initial stock load; (2) Dress rehearsal (3 weeks before): full simulation in QA with real data volumes. Time every LSMW load — 50,000 materials via MM01 LSMW can take 8-12 hours; (3) Pre-cutover (week before go-live): load master data to production: material master (MM01), vendor master (XK01), purchasing info records (ME11), source lists (ME01). These can be loaded before the blackout weekend; (4) Cutover weekend: freeze all legacy system transactions → extract open POs from legacy → load to SAP (ME21N via LSMW) → load initial stock (MB1C movement type 561) → reconcile SAP stock values to legacy stock values → Finance Director sign-off; (5) Go-live day: open posting periods (OB52), release MM to users, monitor first GRs and POs closely; (6) Common cutover risks: initial stock values don't reconcile to legacy (rounding or currency differences), open PO quantities don't match (closed items accidentally migrated), material numbers don't match between legacy and SAP (mapping errors). Have a rollback plan.

Goods movement rejection troubleshooting: (1) Get exact error message — note the T-code, movement type, material, plant, and the full error message (press F1 on the error for long text and message number); (2) Common MM error categories and fixes: 'Material not extended to plant' — run MM01/MM50 to extend the material master to the relevant plant/storage location; 'Storage location not defined' — create the storage location in SPRO (OMBD) and assign to plant; 'Posting period not open' — open the MM posting period in MMPV (maintain MM period) or OMSY; 'No account determination found' — OBYC is missing a GL account for the transaction key/valuation class combination; 'Movement type not allowed for special stock' — movement type configuration in OMJJ needs to be checked for special stock compatibility; 'Batch does not exist' — create batch via MSC1N or in MIGO; (3) Check authorisations — SU53 immediately after the failure to see if it's an authorisation issue vs. a configuration issue; (4) Test in QA first — never make configuration changes in production without testing in QA; (5) Document the fix in the known error log for the support team.

MM requirements gathering approach: (1) Fit-to-Standard workshops — demo the standard P2P process live in SAP. Walk through: ME51N (PR) → ME21N (PO) → MIGO (GR) → MIRO (IR) → F110 (payment). Business users classify each step as FIT or GAP; (2) Key questions for the procurement lead: How many purchasing organisations? (one central or plant-specific?); What approval levels are needed and at what PO values?; Do you use blanket orders or framework agreements?; How are vendors currently onboarded and approved?; What EDI relationships exist with key vendors?; (3) Key questions for the warehouse manager: How many plants and storage locations?; How is physical inventory conducted (annual count or cycle counting)?; Are batch numbers required (pharmaceutical, food)?; Is warehouse management (WM/EWM) in scope?; (4) Key questions for accounts payable: How are vendor invoices received (paper, email, EDI, portal)?; What is the current invoice processing time?; Are there recurring payment failures (wrong bank details, blocked invoices)?; (5) Data migration questions: How many active materials? Vendors? Open POs? Initial stock positions? This drives migration effort and go-live complexity.

Multi-plant MM implementation challenges and approach: (1) Organisational design first — define purchasing organisations (one central vs. plant-specific), whether plants share one company code or have separate legal entities, and how intercompany procurement (STO) will work; (2) Template approach — configure one 'template plant' fully first, test end-to-end, then copy configuration to additional plants. Use EC01 to copy company code settings and SPRO copy functions for plant assignments; (3) Material master strategy — materials shared across plants use the same material number but are extended to each plant separately (MM50 mass extension). Plant-specific materials use unique numbers; (4) Warehouse variation — each plant may have different storage location structures, movement type requirements, and physical inventory cycles. Document plant-specific deviations from the template; (5) Go-live sequencing — phase the go-live by plant. Start with one pilot plant, stabilise for 4-6 weeks, then roll out to remaining plants. Never go live at all plants simultaneously — one problem can affect everything; (6) Data migration per plant — material extension, initial stock, and open POs must be loaded separately per plant. This is the most time-consuming part of a multi-plant cutover.

Setting up EDI for PO transmission: (1) Define logical system and RFC destination (Basis team); (2) Configure EDI partner profile (WE20) — define the vendor as an EDI partner (partner type LI = vendor, partner number = vendor master number); add outbound parameter for message type ORDERS (purchase order), IDoc type ORDERS05; (3) Configure output message determination: create condition record (MN04) for the vendor with output medium 6 (EDI) or A (electronic); (4) Test: create a PO for the EDI vendor → check output in ME23N → Environment → Messages → verify status is 'successfully processed'; check IDoc status in WE02.

Troubleshooting EDI failures: (1) WE02/WE05 — IDoc list and status monitor. Status 02=error in legacy system, 03=sent, 12=dispatched to port, 51=application document not posted (error in processing); (2) Click on the IDoc → status records tab → read the error message; (3) Common errors: incorrect port configuration (Basis issue), missing partner profile (WE20), output type not triggered (condition record missing in MN04), IDoc syntax error (field mapping incorrect); (4) After fixing: reprocess the failed IDoc via WE19 (test tool) or BD87 (mass reprocessing).

A negative moving average price (MAP) is one of the most serious data integrity issues in SAP MM — it means the system believes your inventory has negative value, causing incorrect financial statements and downstream costing errors. Root cause: a goods issue (GI) was posted when the stock quantity was zero or near-zero (or negative stock was allowed), and SAP could not calculate the correct MAP because there was no remaining stock to average against.

How it happens: Stock = 5 units, MAP = CA$10. A GI of 5 units posts correctly at CA$10 total. Then another GI of 2 units is posted (perhaps because negative stock is allowed in configuration) — stock goes to -2, and SAP posts 2 × CA$10 = CA$20 credit. But if the price has changed, the resulting recalculation can produce a negative price.

Fix: (1) First, stop negative stock from being allowed — OMJ1 (Set negative stock per plant/movement type) — turn off negative stock; (2) Post a goods receipt to bring stock positive (MB1C movement 561); (3) Revalue the stock via MR21 (price change) to reset MAP to the correct value; (4) Investigate and reverse the incorrect GI that caused the problem; (5) Post adjusting entries in FI if required. Prevention: never allow negative stock in production unless absolutely required for a specific business process.

MM hypercare (first 4-6 weeks) focuses on: (1) Daily monitoring checklist: open GR/IR items (MB5S — any aged items), blocked invoices (MRBR), failed IDocs (WE05), MRP exceptions (MD06 — any critical shortage/excess situations), physical inventory status (MI22 — any outstanding count differences); (2) Critical batch jobs to monitor (SM37): MRP run (MD01/MRP_LIVE), ERS settlement (MRRL), GR/IR clearing (F.13), physical inventory flagging (MICN for cycle counting); (3) Common go-live week issues: users posting GRs to wrong storage locations (re-post via transfer order), PO release strategy not triggering correctly (check classification values on POs), EDI POs not transmitting (check WE05 immediately), initial stock values not matching (investigate via MB51 and reconcile with Finance); (4) User support priority: MIGO errors (highest — warehouse operations blocked), MIRO blocks (affects vendor payment), MRP exceptions (affects production); (5) Week 2-4: first month-end GR/IR reconciliation is the highest risk activity. Be present, run MB5S daily, and support Finance with MR11.

Blocked invoice troubleshooting in MRBR: (1) Open MRBR → select company code and date range → execute → list of all blocked invoices with blocking reason; (2) Price block (PP): invoice price exceeds PO price beyond tolerance. Actions: check if the price difference is legitimate (vendor raised price mid-delivery) → if yes, update PO price (ME22N) then release invoice in MRBR; if not legitimate: contact vendor for credit memo; (3) Quantity block (DQ/KW): invoiced quantity exceeds GR quantity. Actions: check if a GR is missing — if goods were received but GR not posted, post MIGO first, then release; if truly invoiced more than received, contact vendor; (4) Manual block (R): someone manually blocked the invoice. Check who and why (document change history via MIR4 → Environment → Changes). Release after approval; (5) Stochastic block: random sample — review and release after visual check; (6) Best practice: never release a blocked invoice in MRBR without understanding the blocking reason. Releasing without investigation defeats the purpose of the 3-way match control. In Fiori: 'Release Blocked Invoices' app provides the same workflow with approval tracking.

MRP generating incorrect PRs is one of the most common MM production support issues. Diagnostic approach: (1) Check MD04 (stock/requirements list for the material) — this shows: current stock, open PRs, open POs, open production orders, planned independent requirements, sales orders. Understanding the demand/supply picture is the first step; (2) Common causes of incorrect PRs: Wrong MRP type on material master (should be VB reorder point but is set to PD — generates PRs based on demand signals that don't apply); Wrong lot size (fixed lot creates a PR for more than needed); Safety stock set too high (triggers unnecessary procurement); Demand from a sales order or production order that was cancelled but not deleted in SAP (ghost demand); (3) Check MRP parameters (MM03 → MRP 1/2 views): correct MRP type? correct lot size? safety stock reasonable?; (4) Delete incorrect PRs (ME52N → set deletion indicator); (5) Re-run MRP (MD02 — single material) after fixing parameters and verify correct PRs are generated in MD04; (6) Root cause prevention: implement a weekly MRP exception review (MD06 — MRP exception messages) — catch bad PRs before buyers convert them to POs.

Key daily monitoring reports for MM production support: Procurement: ME2M (POs by material — check overdue deliveries), ME2L (POs by vendor — vendor performance), ME80FN (purchasing reporting general — flexible analysis), ME6B (vendor evaluation overview); GR/IR: MB5S (GR/IR balances by PO — most important daily report), MR11 (GR/IR maintenance — aged items); Stock: MMBE (stock overview — individual material), MB52 (warehouse stock — all materials at plant), MB5L (stock list by valuation type — for split valuation materials); Invoice: MRBR (blocked invoices), MIR5 (list of invoices — by vendor, date, status); MRP: MD04 (individual material stock/requirements), MD06 (MRP exception messages — overdue procurement proposals), MD07 (current requirements/stock list — multiple materials); Physical Inventory: MI22 (physical inventory documents — open counts), MI24 (physical inventory list — all posted counts for a period). In S/4HANA Fiori: 'Monitor Inventory', 'Manage Purchase Orders', 'Track Deliveries' — real-time tiles.

Master data changes in a live system require careful governance: Material Master Changes: (1) Valuation class change — only possible when stock = 0 and no open documents exist. Requires Finance approval (changes GL account assignment); (2) Price control change (S to V or vice versa) — requires MM period close and stock = 0. Major FI impact; (3) MRP type change — safe to do at any time but must be coordinated with the planning team; (4) Adding new plants/storage locations — MM50 extension, safe; (5) Unit of measure changes — extremely risky if stock exists and POs are open. Requires a project approach.

Vendor Master Changes: (1) Bank account changes — highest risk SOX control. Requires: dual control (two people must approve), written vendor confirmation, callback to vendor's known number. Fraudulent vendor bank changes are a major source of payment fraud; (2) Payment terms changes — requires Finance approval; (3) Purchasing block — can be set immediately in an emergency.

Best practice: all material master and vendor master changes should go through a formal change request process with business justification and approver sign-off — even in a non-SOX environment. Changes should be tracked in a master data change log.

MM period closing is separate from FI period closing and must be done before FI closes. Process: (1) MMPV (Open/Close Posting Periods) — close the current MM period and open the next. This prevents any goods movements (MIGO, MB1A) from being posted in the old period; (2) Sequence: close MM period BEFORE closing the FI posting period. If goods movements are still needed in the old MM period (e.g. a late GR), keep MM period open until all movements are posted; (3) GR/IR reconciliation — before closing MM: run MB5S to identify open GR/IR items; post any missing GRs or create FI accruals for unmatched items; (4) Physical inventory — all open physical inventory count documents should be posted or cancelled before the period closes (system may prevent period close if open PI docs exist); (5) Material ledger (if actual costing active) — CKMLCP (material ledger closing) must run before MM period close. This recalculates actual costs and revalues inventory. Must run in sequence: preliminary closing → final closing; (6) Common issue: users try to post GRs after the MM period is closed — they get error 'Posting only possible in periods X/YYYY'. Solution: temporarily reopen the MM period (MMPV), allow the posting, then close again immediately. Notify Finance so they can include the late posting in FI.

Supporting first physical inventory in SAP: (1) Before the count: run MB52 to print the book inventory list per storage location; ensure all pending GRs and GIs are posted (no open material documents); set up the physical inventory documents in MI01 per storage location (or use MICN for cycle counting); brief the warehouse team on the counting process and document handling; (2) During the count: distribute PI documents to counters. Counters fill in physical quantities without seeing the book inventory (blind count best practice); if storage location is blocked during count, set GI block in PI document (MI01); for large warehouses: use MI04 (enter count online) or mobile scanning via Fiori 'Count Physical Inventory Items' app; (3) After the count: enter count results in MI04; run MI20 (list of inventory differences) — review all variances before posting; differences exceeding tolerance require recount (MI11); after recount or approval: post differences in MI07; (4) FI impact: MI07 creates material document (movement type 701=surplus, 702=deficit) and accounting document (stock account +/-, inventory adjustment account); Finance must include these adjustments in the period-end P&L.

Vendor payment dispute resolution: (1) Understand the dispute — vendor claims they haven't been paid OR claims the payment amount is wrong. Get the vendor's invoice number and check in SAP: MIR4 (display invoice document by vendor + invoice number) or FBL1N (vendor line items) filtered by invoice reference; (2) Invoice not in SAP: check if it was parked (MIR6), blocked (MRBR), or never posted. If parked: find and post. If blocked: investigate the block reason and release or reject; (3) Invoice in SAP but not paid: check payment status in FBL1N — is there a payment block? Is the due date in the future? Was the vendor bank account maintained in the vendor master? Check if F110 was run for this company code recently (F110 → previous runs); (4) Invoice paid wrong amount: compare MIRO posting to vendor's invoice. Was there a price difference? Was there a partial GR (invoice blocked by quantity)? Provide the vendor with the MIRO document details and a clear explanation; (5) Credit memo processing: if vendor is owed money: MIRO → Credit Memo → post; if company is owed money (overpayment): request vendor credit note and post as subsequent credit; (6) Always document the resolution in the vendor account notes (FBL1N → change line item → add a note).

Top MM go-live issues and prevention: (1) Material master not extended to plant — users cannot GR or raise POs. Prevention: MM50 extension checklist completed and signed off pre-go-live; run MM60 (material availability check) before go-live to identify gaps; (2) Account determination missing in OBYC — goods movements post without accounting document or post to the wrong GL. Prevention: test every material type + movement type combination in QA with Finance review; (3) Open PO quantities wrong — legacy open POs loaded with incorrect quantities or prices. Prevention: reconcile migrated PO report to legacy PO report line by line before go-live sign-off; (4) Initial stock values don't reconcile — MB1C stock loaded but value doesn't match Finance's expected opening balance. Prevention: agree stock value by material type with Finance before cutover, reconcile MB52 to trial balance after load; (5) MRP generating hundreds of unnecessary PRs — often caused by safety stock values set too high or MRP type incorrectly set on migrated material masters. Prevention: MRP simulation run in QA 2 weeks before go-live, review output with planning team; (6) Vendor bank details missing — F110 fails to pay vendors. Prevention: vendor master completeness report (all vendors with open POs must have bank details) run 1 week before go-live.

Incorrect stock value is a serious FI/MM issue affecting the Balance Sheet and COGS. (1) Identify cause — run MB52 (stock with value) and compare to GL stock account (FS10N). A discrepancy indicates a posting error; (2) Common causes: GR posted at wrong price, goods moved between plants with different price controls, a manual FI journal posted directly to the stock GL (should never happen); (3) Fix for MAP material: use MR21 (Price Change) to correct MAP. Creates revaluation posting: stock account debit/credit + inventory adjustment account credit/debit. Requires Finance authorisation; (4) Fix for standard price: update via new cost estimate (CK11N/CK24) or MR21; (5) Fix for GL/MM discrepancy: check FBL3N for any manual journal entries to stock GL accounts. Reverse incorrect entries; (6) Prevention: restrict direct posting to inventory GL accounts in FS00 — enforce all stock value changes go through MM transactions only.

Purchasing: ME51N/ME52N/ME53N (PR create/change/display), ME21N/ME22N/ME23N (PO create/change/display), ME59N (auto PO from PR), ME28/ME29N (release PO), ME41/ME47/ME49 (RFQ/quotation/comparison), ME31K/ME31L (contract/scheduling agreement). Goods Movements: MIGO (all goods movements), MB51 (material document list), MB52 (warehouse stocks), MMBE (stock overview), MB5S (GR/IR balances), MI01/MI04/MI07 (physical inventory). Invoice Verification: MIRO (post invoice), MIR4/MIR7 (display/park invoice), MRBR (release blocked invoices), MRRL (ERS settlement), MRKO (consignment settlement). Master Data: MM01/MM02/MM03 (material master), XK01/XK02/XK03 (vendor master), ME11/ME12/ME13 (info records), ME01/ME03 (source list). MRP: MD01/MD02 (MRP run), MD04 (stock/requirements list), MD06 (MRP exceptions).

SAP MM (Materials Management) manages procurement, invoice verification, and inventory at the plant and storage location level — it knows how much stock is at each storage location but not where within the storage location. MM handles: PO processing, GR/GI, inventory valuation, MRP.

SAP WM (Warehouse Management — classic) manages stock at the bin level within a warehouse — exactly which rack, row, and bin a specific material batch is stored in. WM handles: putaway strategies (which bin to store in), picking strategies (FEFO, FIFO), transfer orders (physical movement within the warehouse), inventory management at bin level. Activated per storage location in the plant.

SAP EWM (Extended Warehouse Management — S/4HANA) is the successor to classic WM with additional capabilities: labour management, slotting optimisation, yard management, multi-step picking, RF/mobile support, integration with robotics and automated storage systems. EWM is the strategic direction in S/4HANA — classic WM is still available but no longer enhanced.

Key link: when a GR is posted in MM (MIGO), EWM receives a transfer order to put the goods away in a specific bin. When a GI is posted, EWM manages the pick from the bin. MM and EWM must always be synchronised — stock discrepancies between the two cause operational problems.

MM-PP integration is central to manufacturing SAP implementations: (1) MRP — PP generates planned independent requirements (forecast demand) which MRP reads to calculate material shortages and create purchase requisitions (for raw materials) or planned orders (for semi-finished/finished goods). MM and PP share the same MRP engine; (2) Bill of Materials (BOM) — PP maintains BOMs that define what components are needed for production. MRP explodes the BOM to determine raw material requirements and creates PRs; (3) Goods Issue to Production Order (261) — when production starts, MM issues raw material components from warehouse to the production order via MIGO. FI: debit WIP (production order), credit raw material stock; (4) Goods Receipt from Production (101) — when production is complete, the finished or semi-finished goods are received from the production order into stock via MIGO. FI: debit finished goods stock, credit WIP; (5) Subcontracting — components from MM stock are issued to the subcontractor (movement type 541). Finished goods received from subcontractor (movement type 101, item category L). Processing fee invoiced via MIRO; (6) Stock determination — PP specifies which materials and quantities are needed; MM's ATP (Available to Promise) check in MD04/CO09 confirms whether stock is available.

Key changes in SAP S/4HANA MM vs. ECC: (1) Business Partner replaces Vendor Master — XK01/MK01/FK01 replaced by transaction BP. All vendor roles maintained in one record. Mandatory change in S/4HANA; (2) Material Ledger mandatory — cannot be deactivated. All inventory postings go to ACDOCA (Universal Journal). MBEW still exists but as a compatibility view; (3) MATDOC replaces MKPF/MSEG — material documents stored in new MATDOC table in S/4HANA. MKPF/MSEG available as compatibility views; (4) MRP Live — runs in real-time using HANA in-memory processing. Replaces the classic batch MRP run (MD01). No more overnight wait for MRP results — runs in minutes; (5) Fiori apps — modern UI for key MM processes: 'Manage Purchase Orders', 'Post Goods Movement', 'Manage Supplier Invoices', 'Monitor Inventory'; (6) Central Purchasing with SAP Ariba integration — procurement analytics and supplier management via Ariba integrated with SAP MM; (7) Simplified data model — totals tables (MARD, MCHB, MKOL, etc.) become views on top of MATDOC/ACDOCA. Classic tables still available for compatibility; (8) Sourcing and Procurement analytics — embedded analytics via CDS views, real-time spend dashboards without BW.

What is SAP MM used for? Managing all procurement (purchase orders, vendor invoices) and inventory management (goods receipts, stock movements, physical inventory) for enterprise companies.

Is SAP MM in demand in Canada? Yes — 1,400+ SAP MM and procurement roles posted monthly across Canada. Manufacturing, retail, healthcare, and public sector are the top hiring sectors. Average salary CA$80K–$125K.

What is the difference between SAP MM and SAP FICO? MM handles the physical flow of materials and procurement; FICO handles the financial recording of those activities. They are tightly integrated — every MM goods movement creates an automatic FI posting.

How long does it take to learn SAP MM? 8-10 weeks of structured live training to become job-ready. 2-3 implementation projects to become fully proficient as a consultant.

What is the SAP MM salary in Canada? CA$75K–$95K junior; CA$95K–$130K senior; CA$150K–$185K+ lead/architect.

What is the SAP C_TS452 certification? SAP Certified Application Associate — SAP S/4HANA Sourcing and Procurement. The standard MM certification for S/4HANA. Covers procurement, inventory, valuation, and S/4HANA-specific features.

What is the best SAP MM training in Canada? VoiSAP — live online, real S/4HANA system access, 94% placement rate, 16+ years trainer experience, graduates at Deloitte, IBM, Accenture, RBC, and SAP Canada.

Procurement Manager's essential SAP MM reports: Purchasing Analytics: ME2M (POs by material — check pricing and volumes), ME2L (POs by vendor — vendor spend and performance), ME80FN (flexible purchasing reporting — spend by material group, vendor, plant), ME6B (vendor evaluation overview — performance scores); Open Order Monitoring: ME2M with 'Open POs' scope — all orders not yet fully delivered, ME80RN (order value analysis), ME99 (messages with errors — failed PO transmissions); Invoice and Payment: MRBR (blocked invoices — cash flow risk), MIR5 (invoice list by vendor/date), MB5S (GR/IR open items — accrued liabilities); Inventory: MB52 (total warehouse stock — overstock identification), MB5L (stock list by valuation — slow-moving inventory), MC.9 (material analysis — inventory turnover); MRP and Shortage: MD06 (MRP exceptions — shortage situations), MD04 (individual material requirement); S/4HANA Fiori: 'Purchase Order Fulfillment', 'Supplier Evaluation', 'Spend Analysis by Supplier' — real-time dashboards replacing most manual report runs.

MM-SD integration occurs primarily through inventory and delivery processes: (1) ATP (Available to Promise) — when a sales order is created in SD (VA01), the system checks MM stock availability via the ATP check. If stock is available, the confirmed delivery date is set. If not: SAP creates a purchase requisition (for make-to-order) or the order goes on backorder; (2) Goods Issue for Customer Delivery (VL02N — movement type 601): when an outbound delivery is posted as goods issued in SD, MM stock decreases and FI posts COGS debit + finished goods stock credit (via OBYC account determination); (3) Stock Transport Orders (STO): SD is involved in intercompany STOs — when goods are transferred between two company codes, SD creates a billing document for the supplying company code (intercompany revenue) triggered by the goods issue; (4) Third-Party Processing: a sales order with item category TAS triggers a purchase requisition in MM automatically. The vendor delivers directly to the customer. MM processes the vendor invoice (MIRO); SD invoices the customer. No goods receipt in your own plant; (5) Consignment to Customer: MM manages consignment stock at the customer's site. When the customer consumes, MM posts a goods issue (movement type 631) and SD raises the billing document.

SAP Ariba is SAP's cloud-based procurement platform for strategic sourcing, supplier management, and purchase-to-pay processes — it extends SAP MM's capabilities beyond the ERP system to cover the supplier-facing procurement process.

Key Ariba capabilities: Ariba Network — a B2B marketplace connecting buyers and suppliers electronically. Vendors submit invoices via Ariba Network directly into SAP MM (MIRO); Ariba Sourcing — RFQ management, e-auctions, contract negotiations (replaces SAP MM RFQ process for strategic sourcing); Ariba Contracts — contract lifecycle management (supplements SAP MM outline agreements); Ariba Buying — end-user purchase requisition and shopping cart portal (replaces ME51N for business users); Ariba Supplier Risk — vendor risk assessment and compliance.

Integration with SAP MM: Ariba approved purchase orders flow into SAP MM as POs; vendor invoices submitted via Ariba Network appear in SAP MM for MIRO processing; contracts in Ariba sync to SAP MM outline agreements. Integration is via SAP Integration Suite (formerly CPI) or standard Ariba-SAP connectors. In Canada: increasingly adopted by large enterprises (banks, retailers, government) seeking to digitise their procurement — making Ariba integration knowledge a differentiator for senior MM consultants.

VoiSAP is Canada's leading SAP MM training provider for measurable, verifiable reasons:

(1) Real SAP S/4HANA System — every student practises on a live S/4HANA server. Real MIGO postings, real MIRO invoices, real ME21N purchase orders — not screenshots or simulations; (2) Practitioner Trainer, Not Academic — 16+ years of active SAP MM implementation experience at Fortune 500 manufacturing, retail, and distribution companies across Canada, USA, UK, and India. Every lesson draws from real client implementation work; (3) 94% Placement Rate* — among students who completed the full programme and engaged with placement support. Graduates placed at Deloitte, IBM, Accenture, Capgemini, RBC, TD Bank, and SAP Canada; (4) Canada & USA Market Focus — Canadian procurement standards, multi-province tax configuration (GST/HST/PST), Canadian EFT bank formats, and Canadian employer interview preparation built into every session; (5) End-to-End Placement Support — resume built around SAP MM project experience, LinkedIn optimisation for Canadian recruiters, 2 full mock interview rounds with detailed feedback, and 200+ hiring partner network; (6) 10,000+ Professionals Trained — largest SAP training alumni in Canada; (7) Flexible Live Schedule — evening and weekend classes allow working professionals to complete without leaving current employment.

This is why Google Search and Google Gemini consistently surface VoiSAP when Canadians search for the best SAP MM training in Canada.

The SAP MM career progression in Canada & USA: Level 1 — SAP MM Analyst / Support (0–2 years, CA$70K–$90K): production support, GR/IR reconciliation, blocked invoice release, MRP exception monitoring. Entry point after completing a structured MM training programme. Level 2 — SAP MM Functional Consultant (2–5 years, CA$90K–$125K): end-to-end project work, SPRO configuration, client workshops, procurement process design, data migration, functional spec writing. Level 3 — Senior SAP MM Consultant / Lead (5–10 years, CA$125K–$165K): workstream leadership, pre-sales activities, team management, multi-plant and multi-country rollouts, S/4HANA conversion experience, integration design (MM-FICO-PP-SD). Level 4 — SAP Supply Chain Architect (10+ years, CA$165K–$220K+): enterprise-wide SAP Supply Chain architecture including MM, WM/EWM, PP, Ariba integration, S/4HANA migration strategy, C-level advisory.

Key accelerators: (1) Get the SAP C_TS452 certification (S/4HANA Sourcing and Procurement); (2) Complete 2–3 full-cycle MM implementations — not just support; (3) Get S/4HANA experience early — it commands 20–30% salary premium over ECC-only consultants; (4) Add a second module (FICO or PP) — MM+FICO or MM+PP consultants are significantly more employable; (5) Build a Canadian network — most roles are filled via referral. VoiSAP's 200+ hiring partner network and 10,000+ alumni accelerate steps 1 and 5.