Tabelle EKPO — Positionstabelle für Einkaufsbelege

Eine Zeile in EKPO repräsentiert eine einzelne Position eines Einkaufsbelegs: Material oder Dienstleistung, Werk, Lagerort, Bestellmenge, Preiskonditionen auf Kopf- und Positionsebene, Kontierung und Positionstyp sowie eine Reihe von Statuskennzeichen, die zeigen, ob die Position gelöscht, lieferabgeschlossen oder rechnungsabgeschlossen ist. Der Belegkopf (Lieferant, Einkaufsorganisation, Belegart, Währung) befindet sich in EKKO und wird hier nicht wiederholt. Eine Lieferplan- oder Kontraktposition in EKPO trägt typischerweise eine nominale oder null Zielmenge, wobei der tatsächliche Lieferplan in EKET liegt. Textpositionen und einige Dienstleistungspositionen haben überhaupt keinen Materialstammbezug, was normal und kein Datenfehler ist. EKPO ist die Tabelle, die die meisten Leute meinen, wenn sie von einer Bestellposition sprechen.

Der Primärschlüssel ist MANDT plus EBELN plus EBELP, daher ist das Mandantenfeld implizit und jede Auswahl muss danach abgegrenzt werden. Wählen Sie niemals nur nach MATNR in einem Live-System; es ist nicht selektiv und würde die gesamte Positionspopulation durchsuchen. Schränken Sie immer nach einem EBELN-Wert oder -Bereich ein, wenn die Belegnummer bereits bekannt ist, oder joinen Sie zuerst über EKKO und filtern Sie nach Belegart, Einkaufsorganisation oder Erstellungsdatum, bevor Sie EKPO-Zeilen abrufen. Verwenden Sie LOEKZ gleich Leerzeichen, um gelöschte Positionen auszuschließen, und ELIKZ/EREKZ nur als Erstfilter, nicht als Beweis für die physische Erledigung. Auf jeder klassischen Datenbank ist die Tabelle groß genug, dass ein uneingeschränkter MATNR- oder WERKS-Scan ein echtes Performance-Problem darstellt; auf HANA ist es tolerierbar, aber immer noch verschwenderisch.

Symptom: Eine Bestellposition wird in einer Reporting-Liste immer noch als offen angezeigt, obwohl das Unternehmen davon ausgeht, dass Wareneingang und Rechnung beide erledigt sind. Selektieren Sie EKPO für das bekannte EBELN und EBELP und überprüfen Sie ELIKZ und EREKZ direkt. Wenn beide leer sind, betrachtet das System die Position als offen, unabhängig davon, was gebucht wurde. Der nächste Schritt ist der Vergleich von EKPO-MENGE mit den kumulierten Mengen in EKBE für dasselbe EBELN/EBELP, da eine Teillieferung oder eine Stornierung die Erledigungskennzeichen auch nach realer Lieferung ungesetzt lassen kann.

EKPO bleibt eine physische Tabelle in S/4HANA und enthält weiterhin Einkaufsbelegpositionen; sie wurde nicht stillgelegt oder durch eine Kompatibilitätssicht auf der Persistenzschicht ersetzt, wie es bei einigen Finanztabellen der Fall war. Einige Felder, die an ältere Preisfindungs- oder klassische Kontierungsszenarien gebunden sind, gelten in neueren Beschaffungsszenarien als veraltet, und es existieren zusätzliche Positionstypen für fortgeschrittene Beschaffungsprozesse, aber die Tabellenstruktur und ihre Rolle als Positionsgegenstück zu EKKO ist unverändert geblieben. Berichtsebenen, die auf CDS-Views aufbauen, lesen typischerweise darunterliegend über EKPO.

Ein Einkaufs- oder MM-Berater ist für die Interpretation der Positionsstatus-, Positionstypen- und Kontierungsfelder zuständig. Preis- und steuerlich relevante Felder werden oft mit FI oder Controlling geteilt, wenn die Position ein Kostenobjekt trägt. Der Einkäufer oder Prozesseigner des Beschaffungsprozesses ist die richtige Person, um die Absicht hinter einem ungewöhnlichen Positionstyp oder einer Kontierungswahl in den Daten zu bestätigen.

EKKO ist die Kopftabelle, zu der jede EKPO-Zeile gehört. EKET enthält den Lieferplan für Lieferplan- und Forecast-Positionen. EKKN enthält die Kontierungsdetails pro Position. EKBE enthält die tatsächliche Wareneingangs- und Rechnungshistorie. EBAN ist die ursprüngliche Banf, wenn die Bestellposition aus einer Banf stammte. Transaktion ME21N erstellt Einkaufsbelege, ME22N ändert sie, ME23N zeigt sie an, und MIGO oder Rechnungsprüfungstransaktionen buchen die Folgebelege, die EKBE füllen, während EKPO als Referenz gelesen wird.