LFM1 table — Vendor Purchasing Organization Data Table

Each row in LFM1 represents the purchasing view of one vendor for one purchasing organization. A vendor extended to three purchasing organizations has three rows here, and each row can carry different payment terms, order currency, incoterms and control settings even though the underlying business partner is the same. This is the data that a purchase order actually inherits by default when it is created against that vendor and purchasing org combination, before any manual override at the PO line. It is maintained in the vendor master purchasing organization data view and is a mandatory extension step before a vendor can be used on a PO issued from that org, distinct from the general data in LFA1 and the accounting-relevant data in LFB1.

MANDT plus LIFNR plus EKORG form the key, so any selective read restricts on both LIFNR and EKORG together, never LIFNR alone. The table is small relative to transaction tables like EKPO or MSEG, so a full table scan on vendor number alone is usually fine, but pulling it without EKORG produces multiple rows per vendor and silently doubles or triples counts in any join to EKKO if the analyst forgets the org is part of the join. When comparing a value seen on a PO against what LFM1 shows, always confirm which purchasing org the PO actually used, because a vendor can look inconsistent across purchasing orgs when it is in fact configured correctly for each one separately.

Symptom: invoices for a vendor are blocked or postable before goods receipt when the business expects invoice-only-after-GR. Selection: read LFM1 for that LIFNR and the EKORG used on the disputed PO and check WEBRE. If WEBRE is blank, GR-based invoice verification is not active for that vendor and org, and MIRO will accept the PO reference directly regardless of receipt status, which is expected behavior, not a defect.

LFM1 continues to exist as a transparent table in S/4HANA and is still where the purchasing organization vendor data physically sits. The vendor master itself has moved toward business partner as the leading object for maintenance, with LFM1 populated in the background through the business partner vendor role synchronization rather than maintained directly, but reporting and joins written against LFM1 still work unchanged.

Master data governance or the MM/procurement configuration team owns vendor purchasing org data, since ZTERM, WAERS, incoterms and the GR-based IV flag are business-agreed settings, not free text. Functional MM consultants investigate discrepancies by comparing LFM1 against the actual PO and info record values; changes to the underlying defaults require sign-off from procurement, not a technical fix.

LFA1 holds vendor general data and LFB1 holds company code data; both are maintained alongside LFM1 through the vendor master maintenance transactions. EINA and EINE carry the purchasing info record data that can override LFM1 defaults at the vendor-material level. EKKO carries the purchase order header that actually consumes LFM1's defaults at creation time.