PA_PIDX in SAP HCM: Warum der Löschlauf grün meldet und PPOIX trotzdem voll bleibt

Der Vernichtungslauf für das ILM-Objekt PA_PIDX endet ohne Fehler, das Protokoll ist unauffällig, die Statistik leer — und die Tabelle PPOIX enthält genau so viele Sätze wie vorher. Kein Kurzdump, kein roter Jobstatus, keine erkennbare Fehlkonfiguration. Die Ursache liegt fast immer in den Plausibilitätsprüfungen des Schreibprogramms RPAR6W00: Sie greifen regelkonform, verwerfen dabei aber deutlich mehr, als man erwartet, und melden das Ergebnis unterhalb der Schwelle, auf die im Betrieb geschaut wird. Dieser Beitrag erklärt, welche drei Prüfungen das sind, welches Risiko dahintersteckt und was Sie im System prüfen sollten.

Was PA_PIDX behandelt — und wo es ansetzt

PA_PIDX ist für die Index-Tabellen der Abrechnungsbuchung zuständig: PPOIX als Index vom Abrechnungsergebnis zum Buchungsbeleg und PPOPX als Index von alter zu neuer Belegposition, bei der Laufart PM stattdessen PPMIX. Das Schreibprogramm ist RPAR6W00, das Löschen selbst übernimmt anschließend das Löschprogramm des Objekts.

Entscheidend für das Verständnis ist der Einstiegspunkt. Man würde erwarten, dass ein Programm, das PPOIX leeren soll, auch PPOIX selektiert. RPAR6W00 tut etwas anderes: Es ermittelt zuerst über die Statustabelle der Buchungsläufe die in Frage kommenden Lauf-IDs, prüft diese Läufe, und liest die Index-Tabellen erst danach über die Lauf-IDs nach, die die Prüfung überstanden haben. PPOIX ist damit nie die Grundmenge, sondern immer nur eine Folge davon, welche Buchungsläufe durchkommen.

Drei Prüfungen, die den Lauf leer laufen lassen

1. Läufe, die es in der Statustabelle nicht gibt

Die erste Prüfstufe arbeitet ausschließlich auf Buchungslaufebene. Verworfen werden Simulationsläufe, Läufe mit einem Status außerhalb der zugelassenen Werte und Läufe, die laut ihrem Attribut bereits index-archiviert wurden — letzteres ausdrücklich, damit kein leeres Archiv über ein bestehendes geschrieben wird. Effektiv bleiben von den in der Statusliste hinterlegten Werten nur die Status 40, 50, 63, 64 sowie 70 und 81 ohne gesetztes Archivattribut übrig; die Status 80 und 82 werden ausnahmslos wieder aussortiert.

Interessanter ist der Fall davor. Index-Einträge, deren Lauf-ID in der Statustabelle gar nicht geführt wird oder dort mit abweichender Laufart steht, sind über RPAR6W00 nicht erreichbar. Sie werden nicht abgelehnt — sie kommen nie in die Selektion und tauchen im Protokoll auch nicht auf. Solche Waisen entstehen typischerweise durch Altdatenbestände, frühere manuelle Eingriffe oder Systemzusammenlegungen und bleiben liegen, egal wie oft der Lauf wiederholt wird.

2. Ein Personalfall genügt, um den ganzen Buchungslauf zu stoppen

Die zweite Stufe ist fachlich sauber begründet: Die Daten eines Buchungslaufs dürfen erst dann vernichtet werden, wenn zu seinen Ergebnissen keine künftige Rückrechnung mehr möglich ist. Dazu liest RPAR6W00 je Personalnummer den Infotyp 0283 („Archivierung/Datenvernichtung“), nimmt aus dem Subtyp 0001 das tiefste Rückrechnungsdatum aus dem Feld PRDAA und vergleicht es über das Abrechnungsergebnisverzeichnis mit den Periodenenden. Daraus ergibt sich eine Grenzsequenznummer — alles darüber liegt noch im Rückrechnungshorizont und darf nicht weg.

Der kritische Punkt ist nicht die Prüfung, sondern ihre Granularität. Geprüft wird je Personalnummer, verworfen wird je Buchungslauf. Fällt ein einziger Personalfall durch, wird nicht dieser Fall übersprungen, sondern die komplette Lauf-ID aus der Schlüsselmenge entfernt — mit allen übrigen Index-Sätzen daran. Bei produktiven Buchungsläufen über mehrere tausend Personalfälle genügt damit eine Person, um die Daten aller anderen im System zu halten. Und die Wahrscheinlichkeit, dass in einem großen Lauf ausnahmslos niemand mehr im Rückrechnungshorizont liegt, ist bei üblichen Rückrechnungstiefen über lange Zeiträume klein.

Genau dasselbe passiert bei der Prüfung auf Vernichtungssperren: Trägt eine einzige Personalnummer im Lauf einen Legal Hold über den Infotyp 3246, wird ebenfalls der gesamte Lauf zurückgestellt. Eine bewusst selektiv gesetzte Sperre wirkt an dieser Stelle also gar nicht selektiv — sie zieht den ganzen Buchungslauf mit.

Für die Rückrechnungsprüfung gibt es einen Schalter im Customizing: die Tabelle T77S0 mit der Gruppe POST und der Semantik ARCHI. Ist er gesetzt, unterbleibt die Prüfung, und ein Lauf kann auch dann archiviert werden, wenn spätere Abrechnungsergebnisse auf ihn zurückrechnen. Wichtig für die Praxis: Bei der ILM-Aktion Vernichten wird dieser Schalter übergangen — dort läuft die Prüfung in jedem Fall. Wer den Schalter aus der klassischen Archivierung kennt und im Vernichtungsszenario dieselbe Wirkung erwartet, sucht den Fehler an der falschen Stelle.

3. Fehlt der Infotyp 0283, wird gar nichts vernichtet

Die dritte Prüfung ist die unangenehmste, weil sie kein Fehlerbild erzeugt, sondern schlicht Stille. Findet RPAR6W00 für eine Personalnummer keinen Satz im Infotyp 0283, bleibt das Vergleichsdatum auf dem technischen Minimalwert stehen. Damit erfüllt praktisch jeder Satz des Ergebnisverzeichnisses die Ausschlussbedingung, die Grenzsequenznummer rutscht auf den kleinsten möglichen Wert — und über den Mechanismus aus Punkt 2 fällt der komplette Lauf. Dasselbe passiert, wenn der Lesezugriff auf den Infotyp an einer fehlenden Berechtigung des ausführenden Benutzers scheitert.

Ein fehlender Satz ist hier nicht neutral, sondern der schlechteste Fall. Das Programm entscheidet sich im Zweifel gegen das Vernichten, was fachlich vertretbar ist. Nur unterscheidet niemand mehr zwischen „nichts fällig“ und „Voraussetzung nicht erfüllt“, wenn beides denselben leeren Lauf produziert.

Dahinter steht eine Reihenfolgeabhängigkeit, die kein Customizing erzwingt: Der Infotyp 0283 wird durch den Vernichtungslauf der Abrechnungsergebnisse gefüllt. Wer den Buchungsindex vor den Abrechnungsergebnissen angeht, arbeitet gegen eine Vorbedingung, die noch nicht existiert. Wie stark solche Abhängigkeiten in SAP HCM wirken, haben wir in einem eigenen Beitrag zur richtigen Reihenfolge bei der Datenlöschung beschrieben.

Das Protokoll kennt die Antwort

RPAR6W00 schweigt nicht wirklich. Zu jeder verworfenen Lauf-ID schreibt es eine Begründung ins Protokoll — als Information oder Warnung, mit Texten wie „Simulationslauf“, „falscher Status“ oder einem Verweis auf die nicht erfüllten Kriterien der Datenvernichtung. Zusätzlich gibt der Report eine zweiteilige Statistik aus: archivierte und übersprungene Buchungsläufe. Sind dort alle Läufe unter „übersprungen“ gelistet, ist die Ursache bereits eingegrenzt. Nur endet der Job trotzdem regulär, und wer im Batch-Monitor auf die Ampel schaut, sieht grün.

Deshalb gilt für PA_PIDX wie für jedes andere Löschobjekt: Ein grüner Job ist kein Nachweis. Der Nachweis steckt im Protokoll und im Mengengerüst. Genau dort setzt RunScope aus der HCM DSGVO PowerSuite an: Läufe werden ihrem ILM-Objekt zugeordnet, auffällige Läufe sind filterbar, und ein Doppelklick springt direkt in die Standard-Protokollsicht der Transaktion SARA — statt SM37, SLG1 und SARA parallel offen zu halten.

Was Sie jetzt prüfen sollten

Erstens: die Statistik des Schreiblaufs lesen. Stehen alle Buchungsläufe unter „übersprungen“? Dann sagt die zugehörige Protokollmeldung, welche der drei Prüfungen gegriffen hat — das erspart jede weitere Suche.

Zweitens: PPOIX gegen die Statustabelle abgleichen. Ermitteln Sie die Lauf-IDs, die in PPOIX vorkommen, aber in der Statustabelle der Buchungsläufe fehlen oder dort mit abweichender Laufart geführt werden. Diese Menge wird RPAR6W00 nie erfassen; sie braucht eine eigene, dokumentierte Entscheidung.

Drittens: Status und Archivattribut der betroffenen Läufe prüfen. Liegen die Läufe außerhalb von 40, 50, 63, 64, 70 und 81, oder ist bei Status 70 beziehungsweise 81 das Archivattribut schon gesetzt, sind sie für dieses Objekt erledigt — unabhängig davon, ob PPOIX noch Sätze enthält.

Viertens: Infotyp 0283 stichprobenhaft nachrechnen. Nehmen Sie einige betroffene Personalnummern und prüfen Sie, ob überhaupt ein Satz zum Subtyp 0001 existiert und wie PRDAA zu den Periodenenden im Ergebnisverzeichnis und zu den Sequenznummern in PPOIX steht. Fehlt der Satz, ist die Ursache gefunden.

Fünftens: Schalter und Aktion zusammen betrachten. Lesen Sie den Wert in T77S0 zu POST und ARCHI — und klären Sie, ob Sie mit Archivieren oder mit Vernichten arbeiten. Beim Vernichten hilft der Schalter nicht.

Sechstens: Vernichtungssperren gegen die Läufe stellen. Prüfen Sie, ob im betroffenen Buchungslauf Personalnummern mit einem Legal Hold enthalten sind. Eine einzige genügt, um den Lauf zurückzustellen.

Fazit

PA_PIDX scheitert nicht laut, sondern leise — in Prüfungen, die für sich genommen alle sinnvoll sind: Statusfilter, Rückrechnungsschutz, Sperrlogik. Zum Problem werden sie durch die Kombination aus personenbezogener Prüfung und laufbezogenem Verwerfen, durch die Abhängigkeit von einem Infotyp, den ein anderes Objekt füllen muss, und durch die Art, wie das Ergebnis mitgeteilt wird.

Praktisch heißt das für dieses Objekt: Vor dem nächsten Lauf klären, ob die Abrechnungsergebnisse vorher dran waren, und nach dem Lauf die Statistik lesen statt den Jobstatus. Ob andere HR-Vernichtungsobjekte ähnlich gebaut sind, lässt sich nicht pauschal sagen — das entscheidet das jeweilige Schreibprogramm und gehört je Objekt einmal geprüft und dokumentiert. Dass gerade bei ausgetretenen und inaktiven Mitarbeitern auch andere Gründe für eine unvollständige Selektion in Frage kommen, haben wir zuletzt anhand aktueller SAP-Hinweise zu drei Fehlerarten beim Löschen beschrieben.

Aus über hundert DSGVO-Projekten im SAP-HCM-Umfeld nehmen wir bei hoelterhoff.consulting vor allem eines mit: Die unangenehmen Lücken entstehen nicht dort, wo etwas kaputt ist, sondern dort, wo alles funktioniert und niemand nachgesehen hat.

Sie wollen wissen, was Ihre Löschläufe wirklich vernichtet haben? Sehen Sie sich RunScope an oder sprechen Sie uns an.