PH 260 in SAP HCM: Warum PA_TRAVEL korrekt gebuchte Reisen trotzdem nicht vernichtet

Der Testlauf der jährlichen Datenvernichtung in PU22 ist fast durch, dann bleiben ein paar Dutzend Personalnummern hängen: PH 260, „Trip number … period 000 version 99 does not have correct transfer status“, Reise für Reise, obwohl jede dieser Reisen seit Jahren abgerechnet, nach FI gebucht und bezahlt ist. Wer jetzt an den Reisen schraubt, sucht an der falschen Stelle. Die Meldung entsteht in der Prüfung des ILM-Objekts PA_TRAVEL, und was sie prüft, legt nicht die Reise fest, sondern die Gruppe in PU22, die SAP technisch Archivierungsgruppe nennt, auch wenn sie im Modus Datenvernichtung läuft. Der Fall stammt aus einer jährlichen Datenvernichtung, nicht aus einer Archivierung; die Prüfung ist für beide Lauftypen dieselbe. Dieser Beitrag zeigt, wo die Meldung im Standard entsteht, welche drei Kennzeichen sie steuern, warum auch alte Reiseversionen durchfallen und welche zwei Wege aus der Situation herausführen.

Wo PH 260 entsteht: die Aufrufkette hinter PU22

PU22 ist nur der Rahmen. Der Testlauf einer Gruppe, ob für Archivierung oder Datenvernichtung, läuft über eine Kette von Programmen: RPUARTX0 ruft RPUARBXS, das je nach Selektion RPUARBXT (PNP-Selektion) oder RPUARBXU (alle Personalnummern der Gruppe) startet. Beide binden den Include RPUARBX1 ein, dessen Form CHECK_PERNR pro Personalnummer die Prüfungen für Abrechnung, Zeit und Reisen anstößt. Für die Reisen ruft sie den Funktionsbaustein RP_ARCHIVE_CHECK_TRAVEL_PERNR. Dort steht die Prüfung, die PH 260 auslöst.

Wer die Stelle selbst sucht: Der Verwendungsnachweis in SE91 auf PH 260 führt direkt in den Baustein. Ein externer Breakpoint auf RAISE trip_status_error und ein Testlauf für eine einzige betroffene Personalnummer zeigen die Werte, auf die geprüft wird. Die SUBMIT-Kette selbst muss man dafür nicht durchlaufen.

Was der Baustein prüft

RP_ARCHIVE_CHECK_TRAVEL_PERNR liest über TRIPS_LIST_PERIO_HEAD alle Periodensätze der Person aus PTRV_PERIO, inklusive alter Versionen, und läuft darüber. Für jede Reise, deren Abrechnungsperiode vor dem Stichtag der Gruppe endet, wird eine einzige Bedingung geprüft:

IF calc_stat = 'X' AND t_perio-ueblg CO ' 2'
OR fi_stat = 'X' AND t_perio-uebrf CO ' 2'
OR dme_stat = 'X' AND t_perio-uebdt CO ' 2'.

Die drei Felder sind die Übergabekennzeichen der Reise in PTRV_PERIO: UEBLG für die Übergabe an die Abrechnung, UEBRF für die Übergabe an die Finanzbuchhaltung, UEBDT für die Übergabe an den Datenträger. Leer oder 2 gilt als „nicht übergeleitet“. Trifft eine der drei Teilbedingungen zu, schreibt der Baustein PH 260 mit Reisenummer, Periode und Version ins Protokoll und weist die Personalnummer ab. Einzige Ausnahme: stornierte Reisen in Version 99 ohne jede Übergabe werden durchgewinkt.

Entscheidend ist, woher calc_stat, fi_stat und dme_stat kommen. Nicht aus der Reise, sondern aus der Gruppendefinition in PU22: T51B2-TRIND_CALC, TRIND_FI und TRIND_DME. Das sind die drei Ankreuzfelder, die beim Anlegen der Gruppe in PU22 unter „Additional Trip Data“ erscheinen: Transfer to Payroll, Transfer to Financial Accounting, Transfer with Data Carrier.

Das Missverständnis bei den Übergabekennzeichen

Der Dialogtext lautet „In this archiving group, only trips with the following statuses are archived“. Das liest sich wie eine Auswahl erlaubter Zustände. Technisch ist jedes angekreuzte Kennzeichen aber eine Pflichtbedingung: Die Reise muss über diesen Weg übergeleitet sein, sonst fällt sie durch. Wer alle drei ankreuzt, verlangt von jeder Reise alle drei Übergaben. Wer nur „Transfer to Payroll“ ankreuzt, verlangt von jeder Reise die Übergabe an die Abrechnung, und zwar unabhängig davon, ob die Reise fachlich jemals diesen Weg nehmen sollte.

Genau hier entsteht das Muster, das in Mehrländer-Systemen regelmäßig auftaucht. Die Vernichtungsgruppe wurde für die Hauptpopulation definiert, deren Reisen über die Abrechnung ausgezahlt werden. Für eine Teilpopulation, oft ein einzelnes Land, stehen die Kennzeichen jedoch anders: UEBRF 1, UEBDT 1, UEBLG leer. Jede dieser Reisen scheitert an der ersten Teilbedingung. Der Blick in PTRV_PERIO zeigt dann abgerechnete, gebuchte, bezahlte Reisen mit einem einzigen leeren Feld, und dieses Feld ist fachlich korrekt leer.

Warum das heikel ist: Wer die Meldung als Datenfehler liest, korrigiert FI- oder Datenträgerstatus an Reisen, die ohnehin in Ordnung sind, und wundert sich, dass der nächste Testlauf dieselben Reisen wieder meldet. Die einzige Stellschraube, die etwas ändert, ist UEBLG beziehungsweise das Gruppenkennzeichen dahinter.

Die wahrscheinlichste Ursache: migrierte Reisedaten

Woher kommen Reisen, deren Übergabekennzeichen nicht zur Gruppe passen? In den Fällen, die wir in den letzten Jahren bei Kunden gesehen haben, lag der Grund fast immer in einer lange zurückliegenden Migration. Die Reisedaten wurden aus einem Altsystem übernommen, als abgerechnet und bezahlt markiert, in diesem System aber nie durch eine Reisekostenabrechnung und die anschließenden Übergaben an Abrechnung, FI oder Datenträger geführt. Die Übergabekennzeichen stehen dann so, wie das Migrationsprogramm sie gesetzt hat: einige auf „übergeleitet“, andere leer, je nachdem, was der Migrationsentwickler für nötig hielt.

Solche Reisen fallen jahrelang nicht auf. Sie werden nicht mehr angefasst, tauchen in keiner Abrechnung mehr auf und stören niemanden, bis die Datenvernichtung das erste Mal auf sie zugreift und die Gruppenprüfung sie an einem Feld misst, das nie jemand bewusst gefüllt hat. Dass die Betroffenen häufig aus einem einzelnen Land oder einer einzelnen Gesellschaft stammen, erklärt sich dann aus der Migrationshistorie, nicht aus einem abweichenden Auszahlungsweg: Es ist die Population, die damals übernommen wurde.

Es gibt andere Konstellationen, etwa Reisen, die tatsächlich über FI statt über die Abrechnung ausgezahlt wurden, oder Testreisen aus der Einführungsphase. Wer PH 260 im Protokoll sieht, sollte die Migration aber als erste Hypothese prüfen: Liegen die betroffenen Reisen alle vor einem bestimmten Stichtag, und fällt dieser Stichtag mit einem Systemwechsel zusammen, ist der Fall in aller Regel klar.

Die Versionsfalle: 97 und 98 werden mitgeprüft

Im Baustein steht ein Kommentar, man betrachte nur die jeweils aktuelle Version einer Reise, die immer zuerst in der Tabelle stehe. Die zugehörige Anweisung CHECK zw_reinr <> t_perio-reinr überspringt aber nur Folgesätze, wenn die Versionen derselben Reise direkt hintereinander liegen. In der Praxis tauchen im Protokoll deshalb neben Version 99 auch Einträge mit Version 97 oder 98 auf: alte Stände einer Reise, die vor einer Korrektur oder Nachberechnung gültig waren.

Für die Korrektur heißt das: Es reicht nicht, Version 99 in Ordnung zu bringen. Jede Version einer betroffenen Reise, die vor dem Stichtag der Gruppe liegt, muss die Bedingung erfüllen. Wer das übersieht, bekommt nach der ersten Korrekturrunde eine zweite, kleinere Fehlerliste, diesmal mit zweistelligen Versionsnummern.

Zwei Wege aus der Situation

1. Die Gruppe an die Population anpassen

Verlangt die Gruppe einen Übergabeweg, den eine Population nie nutzt, ist die Gruppendefinition für diese Population falsch. Der saubere Weg ist eine eigene Gruppe in PU22 für das betroffene Land mit genau den Kennzeichen, die dort gelten, also FI und Datenträger statt Abrechnung. Die Personalnummern werden aus der bestehenden Gruppe für PA_TRAVEL gelöst (PU22, Zuordnung löschen) und der neuen Gruppe zugeordnet.

Der Haken liegt in der Versionsfalle: Hat eine Reise alte Versionen, in denen FI und Datenträger noch leer waren, scheitert sie auch in der neuen Gruppe, nur jetzt an der zweiten statt an der ersten Teilbedingung. Dieser Weg funktioniert deshalb nur, wenn alle Versionen aller relevanten Reisen das gewählte Muster tragen. Das lässt sich vorab in PTRV_PERIO prüfen, bevor man die Gruppe anlegt.

2. Das fehlende Kennzeichen an den Reisen setzen

Der pragmatische Weg lässt die Gruppe unverändert und setzt UEBLG in PTRV_PERIO auf den Wert für „übergeleitet“, für alle Versionen der betroffenen Reisen, in denen das Feld leer oder 2 ist, beschränkt auf Reisen mit Periodenende vor dem Stichtag der Gruppe. Jüngere Reisen bleiben unangetastet; dort hat ein leeres UEBLG noch eine Bedeutung.

Das ist ein Eingriff in Bewegungsdaten und will dokumentiert sein: Man setzt ein Kennzeichen für eine Übergabe, die nie stattgefunden hat. Für Reisen, die vor über einem Jahrzehnt abgerechnet und verbucht wurden, hat das keine fachliche Wirkung mehr, es ist nur noch die Freigabe für die Datenvernichtung. Umsetzen sollte man es über einen kleinen Report mit Testmodus, Selektion nach Personalnummer und Stichtag und einer Vorher-Nachher-Liste, nicht per Tabellenpflege im Produktivsystem. In einem Testsystem verifiziert: Nach dem Setzen von UEBLG auf allen Versionen lief der Testlauf der Gruppe fehlerfrei durch.

Kein Showstopper, aber eine Entscheidung

Ein Blick in den Baustein klärt auch, wie schlimm die Meldung überhaupt ist. Im Testlauf (l_testrun = X) führt PH 260 zu RAISE trip_status_error, die Personalnummer wird abgewiesen. Im Produktivlauf über RPUARBX0 nimmt der Baustein den anderen Zweig: Er löscht lediglich den IT0283-Satz für PA_TRAVEL dieser Personalnummer und läuft weiter. Die Reisen werden dann schlicht nicht vernichtet und bleiben im System, PA_CALC und PA_TIME derselben Gruppe sind nicht betroffen.

Wer die betroffenen Reisen in diesem Jahr nicht korrigieren will oder kann, kann den Vernichtungslauf also freigeben. Die Reisen bleiben im System, bis die Ursache behoben ist, und tauchen im nächsten Zyklus wieder auf. Das ist eine bewusste Entscheidung im Löschkonzept, kein technischer Zwang. Wie Sie solche Protokollbefunde grundsätzlich einordnen, haben wir in Löschlauf in SAP HCM: drei Fehlerarten beschrieben; ein anderer typischer Blocker sind die Verwaltungssätze der Abrechnungskreise in T569V.

Was Sie jetzt prüfen sollten

Erstens: die Gruppendefinition. Öffnen Sie die Gruppe in PU22 im Anzeigemodus und notieren Sie, welche der drei Übergabekennzeichen gesetzt sind. Vergleichen Sie das mit dem tatsächlichen Auszahlungsweg der Reisen in jedem Land, das die Gruppe abdeckt. Weicht ein Land ab, ist die Gruppe für dieses Land falsch definiert.

Zweitens: eine betroffene Reise in PTRV_PERIO. Legen Sie für eine gemeldete Reise die Felder UEBLG, UEBRF und UEBDT aller Versionen neben die Gruppenkennzeichen. Das genügt, um die Ursache zu bestätigen, bevor jemand Daten anfasst.

Drittens: die alten Versionen. Filtern Sie PTRV_PERIO für die betroffenen Personalnummern auf PDVRS ungleich 99. Jede dieser Zeilen wird vom Baustein ebenfalls geprüft und muss mit korrigiert werden, gleich welchen Weg Sie wählen.

Viertens: die Freigabeentscheidung. Klären Sie mit der Fachseite, ob die Reisen in diesem Zyklus vernichtet werden müssen oder ob der Produktivlauf mit dem automatischen Herausnehmen der PA_TRAVEL-Zuordnung akzeptabel ist. Beides ist vertretbar, aber es sollte im Protokoll des Löschlaufs nachvollziehbar sein, warum.

Fazit

PH 260 bei PA_TRAVEL ist eine Konfigurationsmeldung im Gewand eines Datenfehlers. Die Prüfung in RP_ARCHIVE_CHECK_TRAVEL_PERNR ist knapp und eindeutig, nur steuert sie etwas, das in PU22 wie eine harmlose Auswahl aussieht: drei Kennzeichen der Gruppendefinition, von denen jedes eine Pflicht für jede einzelne Reise bedeutet. Sobald eine Population einen anderen Auszahlungsweg nutzt als die Gruppe voraussetzt, fallen ihre Reisen durch, so korrekt sie fachlich auch sind. Dazu kommt die Versionsfalle, die jede Korrektur auf alle Reiseversionen ausdehnt.

Die Befunde in diesem Beitrag stammen aus der Analyse genau dieses Bausteins und dieses ILM-Objekts; die Einordnung der Migration als häufigste Ursache aus mehreren Kundenprojekten mit demselben Muster. Ob andere Reisekosten-Objekte wie FITV_DDLOG ähnliche Gruppenabhängigkeiten haben, ist eine eigene Prüfung wert und nicht Teil dieser Aussage.

Aus über hundert DSGVO-Projekten im SAP-HCM-Umfeld nehmen wir bei hoelterhoff.consulting vor allem eines mit: Protokollmeldungen des Löschlaufs beschreiben selten die Ursache, sondern die Stelle, an der eine Prüfung aufgegeben hat. Wer den Weg von der Meldung zum prüfenden Coding einmal gegangen ist, erspart sich bei der nächsten jährlichen Vernichtung die Korrektur an der falschen Stelle.

Wenn Sie Ihre Löschläufe und deren Protokolle zentral auswerten wollen, statt jede Meldung einzeln im Debugger zu verfolgen, schauen Sie sich RunScope an. Und wenn Sie bei der Einordnung konkreter Protokollbefunde Unterstützung brauchen, sprechen Sie uns an.