SAP Library / MM / P2P / Cheat sheet
SAP MM / P2P cheat sheet
26 objects in 3 groups. Each links to its full reviewed page.
T-Codes14
- ME21NME21N creates a purchase order: the formal commitment to a supplier for materials or services at agreed prices and dates. Header data covers supplier, purchasing organisation, group and terms, while each item carries material, quantity, delivery date, plant and account assignment. Saving the order makes it available for goods receipt and invoice verification.
- ME22NME22N changes an existing purchase order. Quantities, prices, delivery dates, texts and account assignments can be adjusted within what the document status, release strategy and field selection allow. Every change is versioned and can trigger a new output to the supplier, and what is already received or invoiced limits how far a change can go.
- ME23NME23N displays a purchase order in read-only mode. It is the safe transaction for support, audit and reconciliation work: you read supplier, terms, item quantities, prices, delivery dates and account assignments, together with the purchase order history that lists every goods receipt and invoice posted against each item.
- ME51NME51N is used to create purchase requisitions for materials, services or consumables with quantity, delivery date and account assignment. It is most useful when a business requirement must enter the procurement pipeline before source determination and purchase-order creation. Work from the exact document, organizational level and business date, then verify downstream status or accounting evidence before changing master data or configuration.
- ME52NME52N is the transaction used to change an existing purchase requisition: quantities, dates, account assignment, source of supply, and item status. It cannot create a new requisition. Once a requisition item is referenced by a PO, RFQ, or has already been released, many fields become restricted or trigger a fresh approval cycle on save.
- ME53NME53N is the display-only transaction for a purchase requisition, showing the Enjoy-style single-screen layout with item overview, account assignment, and release status tabs. It is used to check requisition data, release status, and source-of-supply assignment without risk of accidental change, which is why it is the safe default when a requisition just needs to be read, not edited.
- MIGOMIGO is the single entry point for goods movements: goods receipt against a purchase order or production order, goods issue, transfer posting and stock-type change. You choose the action, the reference document and the movement type, and posting creates a material document that updates stock and, for valuated stock, the corresponding accounting document.
- MIROMIRO enters an incoming supplier invoice with reference to a purchasing document. The invoice is matched against the purchase order and the goods receipt, tolerances decide whether a difference is accepted or blocked, and posting creates the accounting document that clears GR/IR and opens the payable to the supplier.
- MM01MM01 creates a material master record or extends an existing material number to a new organizational level (plant, storage location, sales area, valuation area). It is not a single flat record: data is split across views (basic data, purchasing, MRP, accounting, sales, etc.), and which views appear depends on the material type and industry sector chosen at the start.
- MM02MM02 changes existing material master records: base unit, purchasing data, plant data, valuation, sales views, and more. It is also the transaction used to extend a material to a new plant, storage location, or sales organization, because the org level entered on the initial screen determines which views and which existing or new records open.
- MM03MM03 is the display-only transaction for the material master, showing whichever views (Basic Data, Purchasing, MRP, Accounting, Sales, Storage) exist for the material at the organizational levels entered. It reads live from MARA, MARC, MBEW, MVKE, MARD, MAKT and related tables with no save. If a view is missing on the selection screen, the material was never extended to that plant, sales area or storage location.
- MMBEMMBE is used to display material stock by plant, storage location, batch and stock type with drilldown into special stocks. It is most useful when users need to prove where quantity exists before diagnosing a goods-movement, ATP or inventory discrepancy. Work from the exact document, organizational level and business date, then verify downstream status or accounting evidence before changing master data or configuration.
- MRBRMRBR is used to review and release invoices blocked for payment because of price, quantity or tolerance checks. It is most useful when MIRO documents posted but payment is blocked until procurement/receiving differences are resolved. Work from the exact document, organizational level and business date, then verify downstream status or accounting evidence before changing master data or configuration.
- OBYCOBYC is used to configure G/L account determination for inventory management transactions such as BSX, WRX and GBB. It is most useful when goods movements or invoice postings hit the wrong account or fail with missing account determination. Start with the exact organizational keys and business date, then prove the result from SAP documents, balances or logs before changing configuration or reposting data.
Key Tables8
- MARAMARA stores the client-level general data for a material: material type, base unit of measure, material group, weights, and status flags. It holds exactly one row per material number, independent of plant, storage location, sales organization or valuation area. Anything plant-specific, sales-specific or valuation-specific lives in MARC, MVKE or MBEW instead, joined back to MARA on MATNR.
- MARCMARC holds the plant-specific data for a material: MRP type and controller, procurement type, planned delivery time, goods receipt processing time, purchasing group, lot size parameters, and plant-level status. One row exists per material per plant. It is the table that determines whether a material can be planned, procured, or produced at a given plant, independent of its global MARA record.
- MARDMARD holds the stock quantities for a material at storage location level within a plant: unrestricted, quality inspection, blocked, and stock-in-transfer quantities. It does not hold value (that is MBEW), does not hold batch-specific quantities (that is MCHB), and a missing row does not prove zero stock across the material.
- EKKOEKKO stores one row per purchasing document header, covering purchase orders, contracts, scheduling agreements and RFQs. It holds vendor, purchasing organization, document type, currency, terms and release status, but no quantities or values, which live at item level in EKPO.
- EKPOEKPO stores one row per item of a purchasing document header held in EKKO: purchase orders, contracts, scheduling agreements, RFQs. It holds material, plant, quantity, price, account assignment category, item category and completion indicators for that line. It does not hold cumulative goods receipt or invoice quantities; those live in EKBE.
- EKBEEKBE is the purchase order history table. Each row records one posted follow-on event against a PO item, for example a goods receipt, an invoice receipt, an order acknowledgment, or a subsequent debit or credit, tagged with a transaction/event type field so the same PO item can accumulate many rows across its life.
- EBANEBAN stores one line item of a purchase requisition per row, keyed by requisition number BANFN and item number BNFPO. It holds the requested material or service, quantity, plant, account assignment category, release status, and, once the requisition has been converted, the resulting purchase order number and item. It does not hold the PO itself.
- MATDOCMATDOC is the S/4HANA table that stores material document header and item data together, replacing the separate MKPF and MSEG tables of the classic data model. MSEG and MKPF still exist as compatibility views built on MATDOC, so old reports keep working, but the physical data for every goods movement now lives in this one wide table.
Common Issues4
- Purchase order release strategy not triggeringThe release strategy tab on the purchase order shows no strategy, or shows one that never asks for approval, because the classification values on the PO (value, purchasing organisation, plant, material group, account assignment category) do not match any configured combination, or because a change made after release was not flagged as release-relevant and did not reset the release status.
- GR IR account mismatch at period endA GR/IR mismatch at period end means the goods-receipt/invoice-receipt clearing account is carrying a balance instead of netting to zero, almost always because quantities or values posted at goods receipt do not match what was posted at invoice receipt for the same purchase order line, leaving open items that finance cannot explain and that accumulate month over month if not investigated line by line.
- Goods receipt posting to the wrong G/L accountA goods receipt normally lands on the wrong G/L account because the material's valuation class does not map to the expected account in automatic account determination (OBYC), or because the account assignment category on the purchase order overrides the standard inventory posting with a cost center, order, or asset account that was itself set up incorrectly. Reversing the document does not fix it because the reversal uses the same determination logic.
- Invoice blocked for price variance in MMAn invoice is blocked for price variance when the price on the incoming invoice differs from the purchase order (or goods receipt) price by more than the tolerance configured for the relevant tolerance key. The invoice still posts financially but is held from payment until someone in MRBR releases it or the underlying price is corrected.