Unser heutiges Thema betrifft einen „Klassiker“ im Bereich der internen Kontrollen im Einkauf: Der 3-Way-Match. Der 3-Way-Match als Kontrolle geht davon aus, dass Bestellmengen, Wareneingangsmengen und vom Lieferanten in Rechnung gestellte Mengen sich entsprechen müssten. Wie üblich wollen wir uns der Sache datenorientiert nähern. Ich zeige, wie man in den SAP Daten sieht, wie es um den 3-Way-Match bei Ihnen bestellt ist. Als Anwendungsfall sehen wir uns diesmal an, inwiefern Wareneingang und Bestellung übereinstimmen.
In einem der letzten Blog Beiträge wurden die sogenannten Liefermengentoleranzgrenzen in SAP untersucht. Mit den Liefermengentoleranzgrenzen kann man festlegen, inwieweit eine Bestellung mengenmäßig überliefert werden darf. Jedoch kann man durch eine Analyse der Liefermengentoleranzgrenzen nicht herausfinden, ob eine Überlieferung auch tatsächlich stattgefunden hat. Aber letztlich ist natürlich entscheidend, ob’s passiert ist und nicht, ob es theoretisch passieren könnte!
Wie viel wurde denn geliefert?
Um festzustellen, ob so viel geliefert wurde wie bestellt, müssen alle Wareneingänge für eine Bestellposition mengenmäßig zusammengerechnet werden. Zum Glück gibt es in SAP eine zentrale Quelle, wo man dieses findet. In der Tabelle „EKBE“ („Historie zum Einkaufsbeleg“) findet man zu jeder Bestellposition die Wareneingänge und auch die Rechnungseingänge. Wir interessieren uns für die Wareneingänge und ermitteln die Menge dann mit folgendem SQL Query. Wenn Sie das in Ihrem SAP System ausprobieren wollen, verwenden Sie die SAP Transaktion „DBACOCKPIT“ und navigieren über „Diagnose“ zu „SQL-Editor“:
| 1 | SELECT MANDT, EBELN, EBELP, | Die Nummer der Bestellung, sowie der Bestellposition |
SUM(CASE WHEN SHKZG='S' THEN MENGE ELSE 0 END) QUANTITY_IN, | Summe über alle eingehenden Mengen | |
SUM(CASE WHEN SHKZG='H' THEN MENGE ELSE 0 END) QUANTITY_OUT, | Summe über alle ausgehenden Mengen | |
SUM(CASE WHEN SHKZG='S' THEN MENGE ELSE 0 END) - SUM(CASE WHEN SHKZG='H' THEN MENGE ELSE 0 END) QUANTITY_TOTAL, | Im Saldo erhaltene und eingegangene Mengen | |
MAX(CPUDT) CPUDT | Datum der Erfassung des letzten Wareneingangs | |
FROM EKBE | „Historie zum Einkaufsbeleg“ | |
WHERE BEWTP='E' | Kennzeichen für „Wareneingang“ | |
GROUP BY MANDT, EBELN, EBELP |
In meinem Testdatensatz kommt dabei z.B. folgendes heraus:
| MANDT | EBELN | EBELP | QUANTITY_IN | QUANTITY_OUT | QUANTITY_TOTAL | BLDAT |
|---|---|---|---|---|---|---|
| 100 | 5600276136 | 10 | 2.000 | 0 | 2.000 | 27.12.2016 |
| 100 | 5600246681 | 10 | 10.000 | 0 | 10.000 | 20.09.2016 |
| 100 | 5600239977 | 10 | 110.000 | 0 | 1.100.000 | 18.11.2016 |
| 100 | 5600256169 | 10 | 3.754.730 | 0 | 3.754.730 | 03.02.2017 |
| 100 | 5600229943 | 10 | 10.000 | 0 | 10.000 | 22.01.2016 |
| … | … | … | … | … | … | … |
QUANTITY_TOTAL zeigt an, wie groß die gelieferte Menge für die Bestellposition insgesamt war.
Das ist schon einmal die „halbe Miete“. Diese Mengen müssen jetzt mit den Bestellmengen abgeglichen werden.
Abgleich mit der ursprünglichen Bestellung
Bestellungen und Bestellpositionen befinden sich in den SAP Tabellen EKKO („Einkaufsbelegkopf“) und EKPO („Einkaufsbelegposition“). Jetzt müssen die Mengen der Bestellpositionen mit den gelieferten Mengen aus den Wareneingängen abgeglichen werden. Natürlich sind vor allem die Fälle interessant, wo tatsächliche Überlieferungen stattfanden. Das geht per SQL dann so:
| 2 | SELECT EKPO.MANDT, EKPO.EBELN, EKPO.EBELP, EKPO.MENGE, GR.QUANTITY_TOTAL FROM ( | Die Bestellbelegnummer, Bestellposition, bestellte Menge und insgesamt gelieferte Menge |
SELECT MANDT, EBELN, EBELP, | Exakt das Query von oben | |
JOIN EKPO ON (GR.MANDT=EKPO.MANDT AND GR.EBELN=EKPO.EBELN AND GR.EBELP=EKPO.EBELP) | JOIN auf die ursprüngliche Bestellposition, | |
WHERE EKPO.MENGE < GR.QUANTITY_TOTAL | wenn die gelieferte Menge größer ist als die bestellte Menge |
Die Ergebnismenge dieses Queries zeigt Ihnen alle Bestellpositionen, die tatsächlich überliefert wurden.
Wenn wir schon dabei sind: Die Messung der Liefertreue
Wenn wir schon dabei sind, machen wir gleich eine kleine Exkursion und überlegen, was wir noch auswerten könnten. Wo wir schon bei Wareneingängen sind, könnte man noch auswerten, wie schnell geliefert wurde. Damit könnte man die Liefertreue untersuchen. Also untersuchen wir, wie lange es gedauert hat von der Bestellung bis zur letzten Warenlieferung auf eine Bestellposition:
| 3 | SELECT EKPO.MANDT, EKPO.EBELN, EKPO.EBELP, EKPO.AEDAT, GR.CPUDT, DAYS_BETWEEN(TO_DATE(AEDAT), TO_DATE(GR.CPUDT)) DAY_INTERVAL FROM ( | Die Bestellbelegnummer, Bestellposition, Datum der Bestellposition, Datum der Erfassung des letzten Wareneingangs, Differenz zwischen Datum der Bestellposition und Erfassung des letzten Wareneingangs |
SELECT MANDT, EBELN, EBELP, | Exakt das Query von oben | |
JOIN EKPO ON (GR.MANDT=EKPO.MANDT AND GR.EBELN=EKPO.EBELN AND GR.EBELP=EKPO.EBELP) | JOIN auf die ursprüngliche Bestellposition |
In meinem Testdatensatz kommt dabei z.B. folgendes heraus:
| MANDT | EBELN | EBELP | AEDAT | CPUDT | DAY_INTERVAL |
|---|---|---|---|---|---|
| 100 | 6800251136 | 10 | 22.12.2016 | 27.12.2016 | 5 |
| 100 | 6800246683 | 10 | 16.09.2016 | 20.09.2016 | 4 |
| 100 | 6800249972 | 10 | 01.11.2016 | 18.11.2016 | 17 |
| 100 | 6800258269 | 10 | 20.04.2017 | 03.02.2017 | -76 |
| 100 | 6800229443 | 10 | 19.01.2016 | 22.01.2016 | 3 |
| … | … | … | … | … | … |
DAY_INTERVAL zeigt, wie viele Tage zwischen dem Datum der Bestellposition und dem Datum der Erfassung des letzten Wareneingangs liegen. Um sicher zu gehen, dass es sich in dem Feld AEDAT um das Erstelldatum der Bestellposition handelt, reicht ein Blick in die Änderungsbelege (Tabellen CDPOS/CDHDR). Gibt es hier keine Einträge zu der zu untersuchenden Bestellposition, dann gab es nach dem Datum in AEDAT auch keine Änderungen – es kann sich damit nur um die Erstellung der Bestellposition handeln. Wenn dies berücksichtigt wird, dann kann man auf diese Art und Weise auf die Geschwindigkeit der Lieferung schließen (=Liefertreue). Aber es ist Vorsicht geboten: Das geht natürlich nur, wenn die Bestellungen auch tatsächlich gemäß üblichem Einkaufsprozess angelegt wurden. In dem beispielhaften Ergebnis oben kommen einem diesbezüglich Zweifel, da es auch einen negativen Zeitraum von -76 Tagen gibt. Bedeutet: Wareneingang vor Bestellung. Wie kann das sein? Wahrscheinlich ist das passiert, was in vielen Unternehmen passiert: Bestellung wurde nach dem Wareneingang angelegt. Dann ist es natürlich kein Wunder das der 3-Way-Match funktioniert! Negative Tagesintervalle sind insofern eine Indikation für eine Prozessanomalie im Einkauf und können schlimmstenfalls auch als Umgehung einer internen Kontrolle interpretiert werden…
Sie suchen eine automatisierte Lösung?
Der beschriebene Datenindikator in diesem Blog Artikel ist bereits in zap Audit enthalten. Ganz unabhängig davon, ob Ihnen die Rechte zum Ausführen von SQL in SAP fehlen, oder Sie neben diesem Indikator noch mehr als 135 weitere Datenindikatoren auswerten möchten, zap Audit automatisiert alle manuellen Tätigkeiten, die automatisierbar sind. Sie müssen dann lediglich noch die Ergebnisse bewerten und würdigen.
