Bild von Prof. Dr. Nick Gehrke

Verfasst von

Prof. Dr. Nick Gehrke

Woman sigining electronic receipt of delivered package

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,
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_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,
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:

 

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. Wenn Sie Fragen zu zap Audit haben, dann buchen Sie doch ganz unverbindlich einen Termin:

 

Termin vereinbaren

 

Kommentare