Löschlauf in SAP HCM: drei Fehlerarten und was aktuelle SAP-Hinweise dazu sagen

Ein Löschlauf in SAP HCM kann auf drei grundsätzlich verschiedene Arten danebengehen: Er löscht zu wenig, er löscht zu viel — oder er scheitert an einer Fehlkonfiguration, die in Wahrheit gar keine ist. Bemerkenswert ist, dass sich zu jeder dieser drei Fehlerarten in den vergangenen Wochen ein aktueller SAP-Hinweis finden lässt. Wir haben sie gesichtet und für die Praxis eingeordnet.

Drei Fehlerarten beim Löschen in SAP HCM

1. Zu wenig gelöscht: Ausgeschiedene Mitarbeiter fallen aus der Selektion

Mit SAP-Hinweis 3780168 (15.07.2026, Komponente PA-PA-XX) korrigiert SAP einen Fehler in der Vorverarbeitung der Archivierungs- und Vernichtungsläufe — also in dem Schritt, der überhaupt erst ermittelt, welche Daten in Frage kommen.

Der Kern: Bei zeitrelevanten Archivierungsobjekten wurde das maximale Selektionsdatum auf das früheste Änderungsdatum aus dem Abrechnungsstatus (Infotyp 0003, Feld BDERR) minus einen Tag zurückgesetzt und zusätzlich an das Ende der Abrechnungsperiode angepasst. Für Mitarbeiter mit dem Status ausgetreten oder inaktiv konnte das dazu führen, dass nicht alle Datensätze selektiert wurden. Die Korrektur verzichtet für zeitrelevante Infotypen künftig auf die Anpassung ans Periodenende.

Warum das heikel ist: Der Lauf meldet Erfolg. Ein Teil der Daten, der hätte gelöscht werden müssen, bleibt aber im System liegen — ausgerechnet bei der Personengruppe, um die es beim Löschen am meisten geht. Ausgeschiedene Mitarbeiter fallen im Tagesgeschäft niemandem auf; eine Lücke hier bemerkt im Zweifel erst die Prüfung.

Der Hinweis ist eine Folgekorrektur zu SAP-Hinweis 3221862 und damit Teil einer Kette von Fixes an derselben Stelle. Betroffen sind die Softwarekomponenten SAP_HRRXX 604/608 sowie S4HCMRXX 100 bis 102.

2. Zu viel gelöscht: ein Infotyp, der niemals verschwinden darf

Der umgekehrte Fall steckt in SAP-Hinweis 3775402 (16.07.2026, Komponente PY-DE-BA). Hier ging die Vernichtung zu weit.

In der Vernichtungsstruktur des Archivierungsobjekts HRCDEBA („HR: betriebliche Altersversorgung“) war der Infotyp 0203 („Renten-/Bewertungsstatus bAV“) enthalten. Dieser Infotyp hat allerdings die Zeitbindung A: Er muss genau einmal existieren, gilt vom 01.01.1800 bis 31.12.9999, darf keine Splits haben und darf nicht gelöscht werden. Ein solcher Satz gehört strukturell nicht in eine Datenvernichtung.

Die Folge zeigte sich zeitversetzt: Nach der Vernichtung quittierte das System den Versuch, den Infotyp im Rahmen einer Personalmaßnahme im Hintergrund wieder anzulegen, mit der Warnung HRPA_ARCH022 („Daten bis … vernichtet: Daten sollen nicht geändert werden“). Ausgelöst wird die Prüfung über einen Eintrag im Infotyp 0283 („Archivierung/Datenvernichtung“) zum Subtyp 0066. Das System landet in einem Widerspruch: Ein Satz gilt als vernichtet, muss laut Datenmodell aber vorhanden sein.

Die Korrektur entfernt den Infotyp aus der Vernichtungsstruktur. Wichtig für die Praxis: Wer den Hinweis vorab über SNOTE einspielt, muss zusätzlich manuell ran — in Transaktion AOBJ die Strukturdefinition von HRCDEBA aufrufen und prüfen, ob Satz-Nummer 30 mit dem Segment PA0203 noch enthalten ist. Falls ja, wird die Zeile gelöscht. Mit dem Support Package kommt das Archivierungsobjekt bereits korrigiert. Betroffen sind SAP_HRCDE 604/608 und S4HCMCDE 100 bis 102.

3. Weder noch: wenn das vermeintliche Problem Standardverhalten ist

Der dritte Fall ist kein Fehler, sondern ein Missverständnis — eines, das in Projekten regelmäßig Zeit kostet. Zwei SAP-Wissensdatenbankartikel stellen es jetzt klar.

KBA 3027032 (02.07.2026) beantwortet die Frage, warum sich für bestimmte HR-Archivierungsobjekte in Transaktion SARA kein Store-Step ausführen lässt. Die Antwort: Viele HR-bezogene Archivierungsobjekte sind ausschließlich für die Vernichtung vorgesehen. Dort erzeugt das Write-Programm nur temporär eine Archivdatei; das Delete-Programm entfernt anschließend die Daten aus den Tabellen und räumt temporäre Dateien und Verwaltungssätze wieder ab. Ein dauerhaftes Ablegen im ILM-Store ergibt in diesem Szenario keinen Sinn — und ist deshalb auch nicht vorgesehen. Nur für einzelne Objekte ist beides möglich: echte Archivierung samt Store und Vernichtung.

KBA 2990812 (17.06.2026) ergänzt die Kehrseite: Bei diesen reinen Vernichtungsobjekten — darunter das Vernichtungsobjekt für die Personalnummer selbst — fehlt in Transaktion IRMPOL die Spalte „Berechtigungsgruppe“. Auch das ist Standard, denn ILM-Blocking greift ausschließlich im Archivierungsszenario. Wer davon nichts weiß, sucht an dieser Stelle einen Customizing-Fehler, den es nicht gibt.

Was Sie jetzt prüfen sollten

Erstens: Patch-Stand abgleichen. Prüfen Sie, ob 3780168 beziehungsweise der zugehörige Support-Package-Stand in Ihrem System eingespielt ist — insbesondere bei S4HCMRXX 100 bis 102. Der technische Stand entscheidet mit darüber, ob Ihre Löschung vollständig ist.

Zweitens: Vernichtungsstrukturen durchsehen. Kontrollieren Sie in AOBJ für die eingesetzten Archivierungsobjekte, ob dort Infotypen mit Zeitbindung A enthalten sind. Diese gehören generell nicht in eine Vernichtung — HRCDEBA war ein konkreter Fall, das Muster ist allgemeiner.

Drittens: Objekte vorab klassifizieren. Ordnen Sie jedes relevante HR-Archivierungsobjekt einer Kategorie zu: reine Vernichtung oder Archivierung mit Store-Step und Vernichtung. Das erspart geplante Store-Steps, die nie funktionieren werden, und Diskussionen über fehlende Berechtigungsgruppen.

Viertens: Vollständigkeit stichprobenhaft messen. Ein grüner Job ist kein Nachweis. Prüfen Sie gezielt für ausgetretene und inaktive Mitarbeiter, ob bei zeitrelevanten Objekten wirklich alle fälligen Sätze erfasst wurden.

Fazit

Löschen im SAP HCM ist eine Gratwanderung: zu wenig löschen verletzt Fristen, zu viel löschen zerstört Daten, die das System zwingend braucht. Dazwischen liegt ein Bereich, in dem vermeintliche Fehler schlicht dokumentiertes Standardverhalten sind.

Alle drei Hinweise sind einzeln schnell abgearbeitet. Die Lehre daraus ist grundsätzlicher: Ein Löschkonzept ist kein einmaliges Projektergebnis, sondern muss mitgepflegt werden. Selektionslogik, Patch-Stände und Strukturdefinitionen verändern sich — und jede dieser Stellschrauben entscheidet mit, ob am Ende wirklich gelöscht ist, was gelöscht sein sollte, und erhalten bleibt, was bleiben muss.

Aus über hundert DSGVO-Projekten im SAP-HCM-Umfeld nehmen wir bei hoelterhoff.consulting vor allem eines mit: Die Compliance entscheidet sich selten an der großen Strategie, sondern an solchen Details.