MK03 — Display Vendor Purchasing View
MK03 displays vendor master data restricted to the general data and purchasing organization data views. It does not show company code (accounting) data such as payment terms, bank details, or reconciliation account, because those live in a separate view that MK-series transactions were built to exclude. Use it to check purchasing-relevant fields like order currency, incoterms, schema group, and purchasing block status.
MK03 is the read-only counterpart of MK01/MK02, showing a vendor's general and purchasing organization data without exposing company code or accounting fields. It is the fast path for a purchasing consultant to verify vendor extension, blocking status, and pricing-relevant settings without needing FI authorization or opening the full XK03 view.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,080 words
Purpose
MK03 displays vendor master data limited to the general data view and the purchasing organization view. It shares the same underlying tables as XK03 but deliberately hides the company code (accounting) view, so fields like payment terms, house bank, or reconciliation account are never shown here even if they exist for the vendor. The one fact that explains most confusion: MK03 is not a smaller vendor, it is a smaller window onto the same vendor. A vendor can look completely fine in MK03 and still be unusable for invoice posting because the company code extension is missing or blocked, and MK03 will never surface that.
When it is used
Reached for whenever a purchasing issue needs vendor confirmation without touching accounting data: checking why a purchase order defaults a wrong incoterm or currency, confirming a vendor is extended to the purchasing organization used on a PO, checking a purchasing block, or verifying the schema group that drives pricing procedure determination. Purchasing consultants without FI authorization use MK03 instead of XK03 for exactly this reason. Fiori equivalents exist for vendor master display in newer stacks, but many P2P teams still default to MK03 because it opens fast and shows only what a purchasing analyst needs, without company code noise.
How to use it in practice
- Enter transaction MK03.
- Enter the vendor account number.
- Enter the purchasing organization if the purchasing org view is needed.
- On the view selection screen, tick General Data and Purchasing Data views as required; leave company code fields unavailable since they are not offered here.
- Confirm and step through the tabs: address, control data, payment transactions (limited), purchasing data, partner functions.
- Check the purchasing organization data screen for order currency, incoterms, minimum order value, schema group vendor, and purchasing block indicator.
Key data objects
- LFA1 - general vendor master data: name, address, country, central deletion and block flags, vendor account group.
- LFM1 - purchasing organization data: order currency, incoterms, purchasing block per purchasing org, schema group, planned delivery time defaults.
- LFM2 - additional purchasing data such as evaluation-relevant fields where used.
- LFB1 - company code data exists for the vendor but is not read or displayed by MK03; its absence or block will not be visible from this transaction.
- WYT3 or partner function tables - vendor partner roles when partner determination is relevant to purchasing.
How to prove it in the data
To confirm a vendor is genuinely extended and open at a given purchasing organization, query LFM1 filtered on the vendor number (LIFNR) and purchasing organization (EKORG), and check the block field for that combination rather than relying on LFA1's central block, which only reflects a global lock. Cross-check LFA1 on the same LIFNR for the central deletion flag and central block flag. If the vendor is missing entirely from LFM1 for the purchasing org in question, that purchasing organization extension was never created, which is a data setup problem, not a MK03 display problem.
ECC vs S/4HANA
The classic MK01/MK02/MK03 transactions continue to exist and function in S/4HANA in the same restricted view style, but the underlying vendor master model has moved to business partner architecture with a vendor role attached. Some implementations steer maintenance toward the business partner transaction while keeping MK-series transactions available for quick display and habit continuity. Behavior for what MK03 shows and hides has not fundamentally changed; the difference is upstream, in how the record is created and synchronized to the business partner tables.
Common pitfalls and how to diagnose them
- Vendor not extended to purchasing organization: MK03 shows the general data view fine but the purchasing data tab is empty or the system throws a message that the vendor is not defined for the given purchasing organization. Check LFM1 for the LIFNR and EKORG combination before assuming a display bug; the fix is extending the vendor via MK01, not troubleshooting MK03 itself.
- Purchasing block mistaken for central block: a vendor can be fully open in LFA1 but blocked at the specific purchasing organization in LFM1. Users see the vendor open in one context (invoice entry, which reads company code data) and blocked in another (PO creation, which reads purchasing org data). Always check the block field at the purchasing org level, not just the header block.
- Confusing missing company code data with a MK03 defect: because MK03 never displays company code data, a consultant who cannot find payment terms or bank details here sometimes escalates it as a bug. It is by design; XK03 or FK03 is the correct transaction for that view.
- Archived or flagged-for-deletion vendor: if the vendor was flagged for deletion at the general or purchasing org level, MK03 still displays it, but subsequent PO creation or info record maintenance will fail. Check the deletion flag fields on LFA1 and LFM1 explicitly rather than trusting that a displayable vendor is a usable vendor.
- Authorization restriction on purchasing organization: a user with an authorization group restriction may get an empty or partial purchasing data view even though the vendor is properly extended. Confirm this is an authorization gap, not a master data gap, by having a broader-access user run the same MK03 lookup.
Whose problem this is
Functional MM or procurement master data team owns vendor purchasing data and purchasing organization extensions. FI or vendor accounting team owns anything in the company code view, which is out of scope for MK03. A clean handover states the vendor number, the purchasing organization involved, and whether the issue is a missing extension, a block, or an authorization restriction, with the relevant LFM1 or LFA1 field values attached.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/mk03ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.