MK02 — Change Vendor Purchasing and General Data
MK02 changes a vendor master record's general data and purchasing organization data (payment terms at purchasing org level, incoterms, order currency, purchasing blocks, partner functions). It does not expose the company code (accounting) segment - bank details, reconciliation account, dunning, withholding tax at company code level require FK02 or the combined XK02 transaction instead.
This page covers MK02, the purchasing-view-only vendor change transaction, including the structural split between MM and FI vendor data that causes most confusion, the tables the save actually touches, and the diagnostic order for missing fields, blocked saves, and changes that do not propagate to open documents. It also notes the business partner shift on S/4HANA.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,195 words
Purpose
MK02 changes an existing vendor master record restricted to two segments: general data (address, control data, communication) shared across the client, and purchasing organization data (order currency, payment terms at purchasing org level, incoterms, minimum order value, purchasing block, partner functions). It deliberately excludes the company code segment - bank details, reconciliation account, payment methods, dunning, withholding tax at company code level - which lives in FK02 or the combined XK02. The single structural fact that explains most confusion: MK02 and FK02 edit the same physical vendor record from two different screen subsets, and a field missing in MK02 is very often not missing, just out of scope for this transaction.
When it is used
Reached for whenever a buyer or purchasing master data team needs to update purchasing-relevant vendor attributes without touching accounting data - changing a purchasing block, adjusting the order currency for a purchasing org, correcting incoterms, or adding a new purchasing organization to an existing vendor. It sits in vendor master maintenance, upstream of every purchase order, contract, and info record that pulls default values from LFM1. Consultants use FK02 or XK02 instead when the change involves bank details or company code data, and use the BP transaction on systems where business partner is the mandatory entry point, with MK02 either disabled or acting as a compatibility wrapper.
How to use it in practice
- Enter vendor number, purchasing organization (and company code only if the general data screens require it for authorization checks, since the accounting screens themselves are not shown)
- Select which screens to display: general data, purchasing data, or both, via the selection screen checkboxes
- Navigate through the general data tabs (address, control, payment transactions at general level) if selected
- Navigate through the purchasing organization data tabs (order currency, terms of payment, incoterms, purchasing block, partner functions)
- Change the required fields; fields greyed out indicate a field status control or a segment not yet extended to that vendor
- Save; review the change document popup if field-level logging is active for the changed fields
Key data objects
- LFA1 - general vendor data: name, address, central deletion flag, central block, account group, one-time vendor flag
- LFM1 - purchasing organization data: order currency, terms of payment, purchasing block per org, planning-relevant fields, minimum order value
- LFM2 - additional purchasing data: partner functions and purchasing-org-specific defaults not covered in LFM1
- LFBK - bank details at general level, editable here only if the account group's screen layout exposes it outside the company code segment
- CDHDR and CDPOS - change documents recording who changed which field on the vendor master, when logging is switched on for the relevant fields
How to prove it in the data
To confirm a purchasing-level block or wrong terms of payment, query LFM1 filtered on the vendor number and purchasing organization and compare against what the buyer expects - the purchasing block field and terms of payment field live here, not in LFA1. To confirm a change actually happened and when, query CDHDR filtered on object class for vendor master and the vendor number, then join to CDPOS on the same document number to see the old and new field values. To rule out a central block masquerading as a purchasing issue, check LFA1 for the vendor first before assuming the problem is purchasing-org specific.
ECC vs S/4HANA
On S/4HANA, vendor master data is technically business partner data with a vendor role, and the BP transaction is the SAP-recommended maintenance path. MK02 typically remains callable, either working directly against the underlying tables through the business partner synchronization layer or redirecting into BP screens depending on system configuration. The purchasing-versus-accounting screen split described above still holds conceptually even when the front end is BP, since the vendor role's purchasing view and company code view remain separate logical segments.
Common pitfalls and how to diagnose them
- Segment not extended: fields on the purchasing tab are entirely absent or the tab itself does not appear because the vendor has never been extended to that purchasing organization. This is not a field-selection issue and MK02 cannot fix it; the purchasing organization has to be added first, which functionally means running MK01 for that org against the existing vendor number.
- Field greyed out versus field missing: a greyed-out field usually means the field status group tied to the account group marks it as display-only in this context, often because the value is meant to be maintained centrally or is display-only after a certain business event (for example after invoices exist). A missing tab means the segment was never created, which is a different fix.
- Central lock, not purchasing lock: the vendor can be blocked centrally in LFA1 (deletion flag or central block) which looks identical from the purchasing screen to a purchasing-org-level block in LFM1 but has a different root cause and a different owner to unblock it. Check LFA1 before assuming the purchasing block field is wrong.
- Authorization split: a user with authorization for the purchasing organization but not for the associated company code, or the reverse, gets a save error or a suppressed screen that looks like a data problem but is an authorization object mismatch on the vendor's organizational assignment.
- Changes do not retro-apply: updating payment terms, incoterms, or currency in MK02 changes the master record going forward only. Open purchase orders, active source lists, and existing info records keep the values captured at their own creation time; the reflex fix of just changing the vendor and expecting the open PO to update itself is wrong, the PO needs its own change.
- Mass change expectations: using MK02 one vendor at a time when dozens of vendors need the same field changed is the wrong tool; mass vendor maintenance functionality exists for that and using MK02 repeatedly increases the chance of an inconsistent rollout across vendors.
Whose problem this is
Functional MM master data ownership for purchasing-org fields, terms of payment defaults, and purchasing blocks. FI master data ownership for anything living in the company code segment, which is out of MK02's scope entirely. Basis or security ownership when the symptom is an authorization object on purchasing organization or company code. A good handover states the vendor number, purchasing organization, exact field, and whether the problem reproduces in FK02/XK02 as well.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/mk02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.