3-Way-Match erster Teil: Geliefert wie bestellt? – Finden Sie es heraus!

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“:

1SELECT 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) CPUDTDatum 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:

MANDTEBELNEBELPQUANTITY_INQUANTITY_OUTQUANTITY_TOTALBLDAT
1005600276136102.00002.00027.12.2016
10056002466811010.000010.00020.09.2016
100560023997710110.00001.100.00018.11.2016
1005600256169103.754.73003.754.73003.02.2017
10056002299431010.000010.00022.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:

2SELECT 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,
SUM(CASE WHEN SHKZG='S' THEN MENGE ELSE 0 END) QUANTITY_IN,
SUM(CASE WHEN SHKZG='H' THEN MENGE ELSE 0 END) QUANTITY_OUT,
SUM(CASE WHEN SHKZG='S' THEN MENGE ELSE 0 END) - SUM(CASE WHEN SHKZG='H' THEN MENGE ELSE 0 END) QUANTITY_TOTAL,
MAX(CPUDT) CPUDT
FROM EKBE
WHERE BEWTP='E'
GROUP BY MANDT, EBELN, EBELP) GR
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_TOTALwenn 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:

3SELECT 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,
SUM(CASE WHEN SHKZG='S' THEN MENGE ELSE 0 END) QUANTITY_IN,
SUM(CASE WHEN SHKZG='H' THEN MENGE ELSE 0 END) QUANTITY_OUT,
SUM(CASE WHEN SHKZG='S' THEN MENGE ELSE 0 END) - SUM(CASE WHEN SHKZG='H' THEN MENGE ELSE 0 END) QUANTITY_TOTAL,
MAX(CPUDT) CPUDT
FROM EKBE
WHERE BEWTP='E'
GROUP BY MANDT, EBELN, EBELP) GR
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:

MANDTEBELNEBELPAEDATCPUDTDAY_INTERVAL
10068002511361022.12.201627.12.20165
10068002466831016.09.201620.09.20164
10068002499721001.11.201618.11.201617
10068002582691020.04.201703.02.2017-76
10068002294431019.01.201622.01.20163

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.

Artikel teilen

Facebook
Twitter
XING
LinkedIn