In diesem Blog Beitrag kommen wir noch einmal auf den 3-Way-Match zurück. Diesmal geht es darum, dass man am Anfang eines Einkaufsprozesses bestellt und zum Schluss gibt es natürlich eine Rechnung. Interessant wird es, wenn plötzlich die Bestellbeträge von den Rechnungsbeträgen abweichen. Und besonders interessant wird es, wenn auf der Rechnung mehr Euros stehen als in der Bestellung. Ich zeige Ihnen, wie Sie solche Fälle in SAP finden.
Der 3-Way-Match ist eine klassische interne Kontrolle und stellt darauf ab das Mengen und/oder Beträge an den drei Punkten Bestellungen – Wareneingang – Rechnung übereinstimmen (müssten). Diesmal geht es um die Übereinstimmung Bestellung – Rechnung: und zwar wertmäßig. Das Thema 3-Way-Match hatten wir schon häufiger im Blog. Hier finden Sie die anderen Artikel zu dem Thema:
- 3-Way-Match erster Teil: Geliefert wie bestellt? – Finden Sie es heraus!
- Überlieferungen leicht gemacht
Wie hoch waren die Rechnungsbeträge für die bestellten Leistungen?
Um festzustellen, wie hoch die Rechnungsbeträge waren, muss pro Bestellposition ermittelt werden, wie hoch die Rechnung oder auch die Rechnungen dafür waren, wenn für eine Bestellposition mehrere Rechnungen geschickt wurden. Zum Glück steht das „Schicksal“ einer Bestellposition mit allen Wareneingängen und Rechnungseingängen in der zentralen Tabelle EKBE („Historie zum Einkaufsbeleg“). Folgendes Query ermittelt alle Rechnungsbeträge pro Bestellposition in Belegwährung. Wenn Sie das in Ihrem SAP System ausprobieren wollen, verwenden Sie die SAP Transaktion „DBACOCKPIT“ und navigieren über „Diagnose“ zu „SQL-Editor“ (getestet auf einer SAP HANA):
| 1 | SELECT MANDT, EBELN, EBELP, | Nummer der Bestellung, sowie der Bestellposition |
SUM(CASE WHEN SHKZG='S' THEN WRBTR ELSE 0 END) AMOUNT_IN, | Summe des Rechnungseingangs | |
SUM(CASE WHEN SHKZG='H' THEN WRBTR ELSE 0 END) AMOUNT_OUT, | Summe der z.B. reklamierten Warenbeträge (z.B. wenn auf die Bestellung Gutschriften verbucht wurden) | |
SUM(CASE WHEN SHKZG='S' THEN WRBTR ELSE 0 END) - SUM(CASE WHEN SHKZG='H' THEN WRBTR ELSE 0 END) AMOUNT_TOTAL | Gesamt saldierter Rechnungswert | |
FROM EKBE | Tabelle der „Historie zum Einkaufsbeleg“ | |
WHERE BEWTP='Q' | Schlüsselung für Rechnungsvorgänge | |
GROUP BY MANDT, EBELN, EBELP |
Als Ergebnis kommen in meinem Testdatensatz folgende Ergebnisse:
| MANDT | EBELN | EBELP | AMOUNT_IN | AMOUNT_OUT | AMOUNT_TOTAL |
| 100 | 7700256133 | 10 | 6,28 € | – € | 6,28 € |
| 100 | 7700248864 | 10 | 38,16 € | – € | 38,16 € |
| 100 | 7700249972 | 10 | 867,90 € | – € | 867,90 € |
| 100 | 7700256269 | 10 | 3.754,73 € | – € | 3.754,73 € |
| 100 | 7600229141 | 10 | 23,00 € | – € | 23,00 € |
| 100 | 7600256269 | 30 | 5.476,45 € | – € | 5.476,45 € |
| … | … | … | … | … | … |
Man sieht also sehr genau, wie viel in Rechnung gestellt wurde, herunter gebrochen bis auf die einzelne Bestellposition.
Vergleich mit der Bestellung
Interessant wird es natürlich erst, wenn wir die Rechnungswerte verproben können mit den Bestellwerten, um zu sehen wo Leistungen plötzlich viel teuer wurden als bei der Bestellung bekannt war. Dazu kann man folgendes Query verwenden:
| 2 | SELECT INV.EBELN, INV.EBELP, INV.AMOUNT_TOTAL, EKPO.NETWR, 100.0 * AMOUNT_TOTAL / NETWR-100 PERCENT_TOO_MUCH FROM ( | Nummer der Bestellung, der Bestellposition in der Bestellung, Rechnungssumme, Bestellsumme, Kalkulation, wie viel prozentual in der Rechnung mehr fakturiert wurde |
SELECT MANDT, EBELN, EBELP, | Exakt das Query von weiter oben | |
LEFT JOIN EKPO ON (EKPO.MANDT = INV.MANDT AND EKPO.EBELN = INV.EBELN AND EKPO.EBELP = INV.EBELP) | Ein JOIN auf die SAP Tabelle EKPO, weil sich die zugehörigen Bestellpositionen in der EKPO befinden | |
WHERE INV.AMOUNT_TOTAL > EKPO.NETWR | nur Fälle auflisten, wo die Rechnungssumme über der Bestellsumme lag | |
ORDER BY 100.0*AMOUNT_TOTAL/NETWR-100 DESC | Sortierung nach den Fällen mit der höchsten prozentualen Abweichung |
Mit dieser Auswertung kann man nun sehr gut sehen in welchen Fällen prozentual viel mehr in Rechnung gestellt wurde als bei der Bestellung angenommen:
| EBELN | EBELP | AMOUNT_TOTAL | NETWR | PERCENT_TOO_ MUCH |
| 7700226971 | 30 | 9,60 € | 3,10 € | 209,68 |
| 7700213638 | 10 | 7,37 € | 2,52 € | 192,46 |
| 7700229753 | 10 | 25,90 € | 10,26 € | 152,44 |
| 7700249155 | 80 | 15,10 € | 8,15 € | 85,28 |
| 7700242542 | 10 | 8,93 € | 4,93 € | 81,14 |
| 7700229244 | 20 | 11,76 € | 6,86 € | 71,43 |
| … | … | … | … | … |
Man sieht, dass die obersten Zeilen Fälle sind, wo prozentual viel mehr berechnet wurde (AMOUNT_TOTAL) als der Bestellwert (NETWR). Die gelisteten Fälle sind prozentual beeindruckend, jedoch vom absoluten Betrag eher vernachlässigbar. Also in diesem Datenausschnitt alles halb so schlimm! Aber daraus lässt sich schon eine Empfehlung ableiten: achten Sie auf Fälle mit hoher prozentualer Abweichung, welche auch in Bezug auf den Absolutbetrag hoch sind. Wenn solche Fälle ersichtlich sind, gehen Sie in die Einzelfallprüfung solcher Bestellungen und klären als Moderator gemeinsam mit der Fachabteilung, wie es zu solchen Fällen kommen kann.
Zu kompliziert?
Fragestellungen, wie unterschiedliche Summen auf Bestellungen und Rechnungen, oder Überlieferungen haben wir in zap Audit bereits als beta Indikatoren implementiert. Wenn Sie zap Audit einmal kostenlos testen wollen, dann haben Sie jederzeit mit einem kleinen Buchungskreis die Möglichkeit.
