Bild von Dennis Jürgensen

Verfasst von

Dennis Jürgensen

Man shopping online with a credit card - isolated over white

Im letzten Blog Artikel haben wir einen generellen Überblick über die Eigenheiten des Zahlprogramms in SAP erhalten. In diesem Blog Post schauen wir nochmal etwas genauer hin und haben 3 Datenanalysen für die Prüfung des Zahlprogramms in SAP vorbereitet.

 

Doch bevor wir uns die Parameter des Zahlprogramms einzelner Zahlläufe oder Funktionstrennungen genauer ansehen, werfen wir erstmal einen Blick auf die SAP Tabellen, in denen Informationen rund um das Zahlprogramm zu finden sind.

 

Wichtige Tabellen des Zahlprogramms in SAP

Im Kern dreht es sich beim Zahlprogramm um die Tabellen, die mit REGU* für Regulierung beginnen und sich wie folgt unterteilen:

  • REGUA Änderung von Zahlungsvorschlägen: Benutzer
  • REGUH Regulierungsdaten aus Zahlprogramm
  • REGUP Bearbeitete Positionen aus Zahlprogramm
  • REGUPO Zustand des Einzelpostens vor der n. Änderung
  • REGUPW Quellensteuerinfo pro Qst.Typ/FI-Belegposition
  • REGUS Durch Zahlungsvorschlag gesperrte Konten
  • REGUT TemSe - Verwaltungsdaten
  • REGUTA Zahlende Buchungskreise von DTA-Dateien
  • REGUV Verwaltungssätze für das Zahlungsprogramm

 

Das erscheint erstmal nach sehr viel Informationen, allerdings wird für die nachfolgenden Analysen nur ein Bruchteil der Tabellen benötigt. Im Wesentlichen steckt die Musik in den Tabelle REGUH, REGUP und REGUV. Eher generelle Informationen über den Zahllauf finden sich in der Tabelle REGUH, wie z.B. das Laufdatum (Feld LAUFD) oder das zusätzliche Identifikationsmerkmal (Feld LAUFI). In REGUV finden sich viele interessante Informationen, wie z.B. ob ein Zahlungsvorschlag bearbeitet wurde, oder ob überhaupt ein Zahlungsvorschlag erstellt wurde. Die Tabelle REGUP ist etwas detaillierter im Hinblick auf die Details von Belegen. Hier finden sich z.B. die Belegnummer, Belegdatum, der Betrag und vieles mehr.

 

Die Prüfung des Zahlungsvorschlags

Im letzten Blog Artikel hatten wir bereits erwähnt, dass die Durchführung eines Zahlungsvorschlags optional ist und beliebig häufig wiederholt werden kann. Außerdem kann er ohne weiteres aus dem SAP System gelöscht werden, sodass Änderungen an freigegebenen Zahlungsvorschlägen unter bestimmten Umständen nur schwer bis gar nicht zu prüfen sind. Anders verhält es sich mit einer Änderung. Das lässt sich ganz einfach in der Tabelle REGUV nachvollziehen. Das Feld XVORB dient in diesem Zusammenhang als Indikator, ob ein Vorschlag bearbeitet wurde oder nicht. Ohne die Auswertung von schriftlichen Freigaben des Zahlungsvorschlags, haben wir so zunächst einen guten Anhaltspunkt, um herauszufinden, ob ein Zahlungsvorschlag geprüft wurde oder nicht. Befindet sich in dem Feld ein "X", dann wurde dieser geändert.

Die Prüfung gestaltet sich demnach denkbar einfach. Am schnellsten ist vermutlich die Methode über die Transkation "SE16" oder "SE16N".

Die Daten für die Eingabemaske sind dann:

Tabelle: REGUV

Feldname: Kennzeichen: Vorschlagslauf bearbeitet, Option: gleich, Von-Wert: '' (leer)

 

Über den Klick auf "F8" oder die Uhr erhalten wir dann als Ergebnis alle Zahlläufe, bei denen der Vorschlagslauf nicht bearbeitet wurde. Die Liste mag bei dem einen oder anderen von Ihnen mit Sicherheit sehr groß sein. Daher wäre an dieser Stelle die Empfehlung, eine Detailprüfung bei denjenigen Zahlungsvorschlägen vorzunehmen, die eine große Anzahl erstellter Zahlungen enthalten. Denn die Wahrscheinlichkeit, dass bei vielen Zahlungen keine bearbeitet werden musste ist deutlich geringer.

 

Die Inexistenz des Zahlungsvorschlags

Aber was ist eigentlich, wenn gar kein Zahlungsvorschlag durchgeführt wurde? Dann kann in der Folge auch gar keiner bearbeitet worden sein. Genau dieser Fragestellung widmen wir uns als nächstes. Die notwendigen Informationen finden sich ebenfalls in der Tabelle REGUV in dem Feld XVORE.

Eine Prüfung ist ebenfalls wieder schnell gemacht. Dafür nutzen wir erneut die Transaktion "SE16" bzw. "SE16N" mit der folgenden Eingabemaske:

Tabelle: REGUV

Feldname: Kennzeichen: Vorschlagslauf durchgeführt, Option: gleich, Von-Wert: '' (leer)

Feldname: Kennzeichen: Echtlauf durchgeführt, Option: gleich, Von-Wert: 'X'

 

Die zweite Selektion (Echtlauf durchgeführt) beschränkt die Ergebnismenge lediglich auf alle Zahlläufe, die auch tatsächlich durchgeführt wurden. Bei der entstandenen Ergebnisliste gilt es nun zu prüfen, warum kein Zahlungsvorschlag erstellt wurde. Unter Umständen gibt es dafür einen einfach Grund, sodass die Prüfung recht zügig abgeschlossen sein kann. So wäre es z.B. denkbar, dass lediglich eine geringe Anzahl an Zahlungen beglichen wurden und die Prüfung vorab manuell stattgefunden hat.

 

Der Klassiker in der Prüfung: Funktionstrennungskonflikte beim Zahlprogramm

Funktionstrennungskonflikte bergen immer ein gewisses Potential für dolose Handlungen. Speziell im Bereich der Zahlungen sollte daher mal genauer hingeschaut werden, da der Liquiditätsabfluss schneller gehen kann, als man denkt. Um die Prüfung zu erleichtern habe ich Ihnen ein SQL Query gebastelt (auf HANA getestet). Um das Query direkt in SAP zu verwenden, rufen Sie die Transaktion "DBACOCKPIT" auf und navigieren Sie über "Diagnose" zu "SQL-Editor":

 

1

SELECT DISTINCT BKPF.MANDT, BKPF.BUKRS, BKPF.GJAHR, BKPF.USNAM, BKPF.BELNR, BKPF.TCODE, BSEG.AUGBL, B2.TCODE, LAUFD, LAUFI, XVORL FROM BKPF
LEFT JOIN REGUP ON (BKPF.MANDT = REGUP.MANDT AND BKPF.BUKRS = REGUP.BUKRS AND BKPF.GJAHR=REGUP.GJAHR AND BKPF.BELNR=REGUP.BELNR)
LEFT JOIN BSEG ON (BKPF.MANDT = BSEG.MANDT AND BKPF.BUKRS = BSEG.BUKRS AND BKPF.GJAHR=BSEG.GJAHR AND BKPF.BELNR=BSEG.BELNR)
JOIN BKPF AS B2 ON (BSEG.MANDT = B2.MANDT AND BSEG.BUKRS = B2.BUKRS AND BSEG.AUGGJ=B2.GJAHR AND BSEG.AUGBL=B2.BELNR)
WHERE BKPF.TCODE='FB01' AND B2.TCODE='F110' AND BKPF.USNAM=B2.USNAM AND BKPF.TCODE!=B2.TCODE AND BKPF.stblg='' and b2.stblg=''

 

Als Ergebnis erhält man schnell und übersichtlich eine Liste aller Belegpaare, die zueinander einen Funktionstrennungskonflikt (Nutzername (USNAM) ist gleich und die Transaktionen stehen miteinander in Konflikt (FB01 - Beleg buchen und F110 - Maschineller Zahlungsverkehr) darstellen. Außerdem wurden Stornos ausgeschlossen (STBLG=''). Mit diesem Vorgehen finden Sie allerdings nur Konflikte, die prozessual direkt aufeinander folgen. In zap Audit werden auch Konflikte gefunden, bei denen weitere Aktivitäten zwischen der Buchung eines Belegs und dem maschinellen Zahlen liegen, z.B. bei nachträglicher Änderung einer Rechnung.

Ein Analyse von diversen Funktionstrennungskonflikten ist in zap Audit bereits integriert, sodass die SAP Tabellen automatisch analysiert werden und Sie als Prüfer nur noch den Feststellungen nachgehen müssen. Auf diese Weise unterstützen wir Sie bei Ihrer Prüfung und Sie können sich auf die wirklich wichtigen Dinge konzentrieren: das Prüfen! Also warum probieren Sie zap Audit nicht mal kostenlos aus? Einfach kurz Kontakt aufnehmen und direkt loslegen:

 

Kontakt