SAP-TabelleObjektLFA1ModulMM_P2P

Tabelle LFA1 — LFA1 Lieferantenstammdaten Allgemeine Daten

LFA1 enthält einen Eintrag pro Lieferantennummer und speichert die mandantenunabhängigen allgemeinen Daten wie Name, Adresse, Land und zentrale Steuerungsmerkmale wie die zentralen Lösch- und Buchungssperren. Sie enthält keine Buchungskreis- oder Einkaufsorganisationsdaten; diese sind in LFB1 und LFM1 hinterlegt. Fehlende Lieferantenstammdaten bedeuten in der Regel, dass die Nummer hier zwar existiert, aber nie auf die für eine Transaktion erforderliche Organisationsebene erweitert wurde.

LFA1 ist die Stammtafel des Lieferantenstamms, ein Eintrag pro Lieferantenkontonummer, der den allgemeinen Datensegment enthält, der keinem Buchungskreis oder keiner Einkaufsorganisation zugeordnet ist. Diese Seite behandelt, was tatsächlich schiefgeht, wenn ein Lieferant in einer Bestellung oder Rechnung nicht verwendet werden kann, und wie man eine echte Stammdatenlücke von einer Erweiterungslücke in LFB1 oder LFM1 unterscheidet.

Veröffentlicht am 15. Sept. 2026· 992 Wörter

Was sie speichert

Ein Eintrag in LFA1 repräsentiert eine einzelne Lieferantenkontonummer auf der allgemeinen Datenebene: Name, Adresse, Land, Sprache, Suchbegriffe, Steuernummern, Bankreferenzindikator und Kontengruppe. Diese Daten werden über jeden Buchungskreis und jede Einkaufsorganisation hinweg geteilt, in die der Lieferant später erweitert wird. LFA1 enthält keine Zahlungsbedingungen, Abstimmkonten oder Einkaufsbedingungen; diese sind organisationsabhängig und befinden sich in LFB1 (Buchungskreis) und LFM1 (Einkaufsorganisation). Eine in LFA1 existierende Lieferantennummer bedeutet lediglich, dass der Geschäftspartner zentral angelegt wurde, nicht aber, dass er in einer Bestellung oder einer Rechnung in einem bestimmten Buchungskreis verwendet werden kann. Zentrale Sperr- und Löschkennzeichen sind ebenfalls hier hinterlegt, weshalb ein Lieferant in einem Buchungskreis verwendbar sein kann, aber zentral für alle neuen Buchungen überall gesperrt ist.

Schlüsselfelder

MANDT - Mandant, immer das erste Feld in jeder Selektion
LIFNR - Lieferantenkontonummer, der Schlüssel, der zu jeder anderen Lieferantentabelle verknüpft
NAME1 - Lieferantenname, wie er auf Korrespondenz gedruckt und in Matchcode-Suchen verwendet wird
LAND1 - Länderschlüssel, steuert die Steuer- und Adresslogik
ORT01 - Ort
PSTLZ - Postleitzahl
STRAS - Straße und Hausnummer
SPRAS - Sprachschlüssel für Korrespondenz und Langtext
KTOKK - Kontengruppe des Lieferanten, steuert den Feldstatus und Nummernkreis bei der Anlage
SPERR - zentrales Buchungssperrkennzeichen
LOEVM - zentrales Löschkennzeichen
STCD1 - Steuernummer 1, üblicherweise die lokale Steuerregistrierung
STCD2 - Steuernummer 2
KONZS - Konzernschlüssel, zur Identifizierung verwandter Lieferanten innerhalb desselben Konzerns

Wie sie in das Datenmodell eingebunden ist

LFA1-LIFNR = LFB1-LIFNR, Verknüpfung zu buchungskreisspezifischen Daten wie Abstimmkonto und Zahlungsbedingungen
LFA1-LIFNR = LFM1-LIFNR, Verknüpfung zu Einkaufsorganisationsdaten wie Bestellwährung und Lieferbedingungen
LFA1-LIFNR = EKKO-LIFNR, Verknüpfung zu Bestellanforderungen, die an den Lieferanten gerichtet sind
LFA1-LIFNR = RBKP-LIFNR, Verknüpfung zu eingehenden Rechnungen, die dem Lieferanten gebucht wurden

Wie man sie sicher liest

Schränken Sie immer zuerst nach MANDT ein, obwohl die meisten Berichtstools dies implizit setzen. LIFNR ist der natürliche Schlüssel und ist bei Kenntnis sehr selektiv; die Auswahl nach NAME1 oder LAND1 ohne einen Buchungskreisfilter liefert rauschende, duplikat-anfällige Ergebnisse, da dieselbe juristische Person unter mehreren Lieferantennummern erscheinen kann. LFA1 allein ist eine kleine, schnelle Tabelle, die nach Primärschlüssel gescannt werden kann, aber sie sagt nichts darüber aus, ob der Lieferant irgendwo verwendbar ist; schließen Sie aus einem sauberen LFA1-Eintrag nicht, dass der Lieferant buchen kann. Bevor ein Lieferant als vollständig eingerichtet betrachtet wird, müssen sowohl die Buchungskreiserweiterung in LFB1 als auch die Einkaufsorganisationserweiterung in LFM1 separat überprüft werden.

Wie man es in den Daten nachweisen kann

Symptom: Ein Einkäufer meldet, dass der Lieferant bei der Erstellung einer Bestellung für eine bestimmte Einkaufsorganisation nicht ausgewählt werden kann. Selektieren Sie LFA1 nach LIFNR, um zu bestätigen, dass der Lieferant zentral existiert und dass SPERR und LOEVM leer sind. Selektieren Sie dann LFM1 mit derselben LIFNR und der betreffenden Einkaufsorganisation. Wenn kein Eintrag zurückkommt, wurde der Lieferant zwar zentral angelegt, aber nie auf diese Einkaufsorganisation erweitert, was die eigentliche Ursache ist, und keine Stammdatenkorruption in LFA1.

ECC vs. S/4HANA

In S/4HANA werden Lieferantenstammdaten technisch über das Business Partner-Modell gespeichert, wobei LFA1 als Kompatibilitätssicht über die zugrunde liegenden Business Partner-Tabellen beibehalten wird, damit bestehende Berichte und kundenspezifischer Code, die LIFNR verwenden, weiterhin funktionieren. Lesevorgänge auf LFA1 funktionieren weiterhin; die Neuanlage von Lieferanten wird voraussichtlich über die Business Partner-Pflege und nicht über die klassischen Lieferantentransaktionen erfolgen. Der Feldinhalt und das Verhalten für allgemeine Daten sind aus Berichtsperspektive weitgehend unverändert, obwohl die Quelle der Wahrheit verschoben wurde.

Häufige Fallstricke

Annahme, dass ein in LFA1 sichtbarer Lieferant für Beschaffung oder Zahlung bereit ist; ohne einen passenden LFB1-Eintrag für den Buchungskreis und einen LFM1-Eintrag für die Einkaufsorganisation wird keine Transaktion ihn akzeptieren
SPERR als einzige relevante Sperre behandeln; eine buchungskreisspezifische Buchungssperre in LFB1 oder eine einkaufsorganisationsspezifische Sperre in LFM1 kann eine Transaktion stoppen, selbst wenn LFA1-SPERR leer ist
Suche nach NAME1 und Annahme, dass eine Übereinstimmung einen Lieferanten bedeutet; doppelte Lieferantenanlage ist üblich, und mehrere LIFNR-Werte können nahezu identische Namen und Adressen aufweisen
LOEVM so interpretieren, dass der Lieferant aus der Datenbank gelöscht wurde; es ist ein Löschkennzeichen, das auf die Archivierung wartet, der Stammsatz und seine gesamte Historie sind noch vorhanden und verknüpfbar
KTOKK ignorieren, wenn zwei Lieferanten verglichen werden, die sich unterschiedlich verhalten; die Kontengruppe steuert, welche Felder obligatorisch oder ausgeblendet sind, und erklärt offensichtliche Inkonsistenzen zwischen Lieferantendaten
Vergessen, dass Adress- und Steuerfelder in LFA1 global geteilt werden; eine Änderung, die für die Berichtsanforderungen eines Buchungskreises vorgenommen wird, betrifft jeden Buchungskreis, der diesen Lieferanten verwendet

Wessen Problem das ist

Die Governance der Lieferantenstammdaten liegt beim MM-Stammdaten- oder Lieferantenpflegeteam, oft einer Shared-Service-Funktion, nicht beim Anforderer oder Einkäufer. Die Erweiterung auf neue Buchungskreise oder Einkaufsorganisationen erfordert typischerweise eine formale Anfrage über dieses Team, da sie die Abstimmkontenzuordnung und Zahlungsbedingungen betrifft, denen auch die Finanzabteilung zustimmen muss.