DaBPV: Datenaustausch Anzahl Kinder (in SAP HCM) – Teil 2

Im ersten Teil unserer zweiteiligen Blog-Reihe haben wir den Aufbau und die Zielsetzung des neuen Datenaustauschverfahrens zur Feststellung der Elterneigenschaft in der Pflegeversicherung vorgestellt. Hintergrund ist die zum 01.07.2023 eingeführte differenzierte Beitragsberechnung: Während Kinderlose weiterhin einen Zuschlag zahlen, profitieren Eltern – insbesondere mit mehreren Kindern – künftig von einem Beitragsabschlag.

Im April 2025 wurde nun das DaBPV-Verfahren in SAP HCM ausgeliefert. In diesem Artikel wollen wir die technische Umsetzung näher betrachten.

Start des Verfahrens in SAP HCM

Das DaBPV-Meldeverfahren wird in SAP HCM über die zugehörige Teilapplikation DBPV aktiviert. Im Standard ist die gesetzliche Teilapplikation ab dem 01.07.2025 gültig:

Ab diesem Datum sind Arbeitgeber und Zahlstellen dazu verpflichtet bei Beginn einer Beitragspflicht in der Pflegeversicherung (bspw. durch Beginn einer sozialversicherungspflichtigen Beschäftigung) die Arbeitnehmer bzw. Versorgungsempfänger zum neuen Datenaustauschverfahren zur Beitragsdifferenzierung für die soziale Pflegeversicherung innerhalb von sieben Tagen anzumelden. Bestandsfälle müssen spätestens bis zur Entgeltabrechnung im Dezember 2025 rückwirkend über das Verfahren angemeldet werden (vgl. § 124 SGB IV, § 202a SGB V für Zahlstellen). Bis Ende des Jahres 2025 können Arbeitgeber und Zahlstellen, die sich für einen weichen Einstieg (keine unmittelbare Anmeldung von Bestandsfällen) in das DaBPV-Verfahren entschieden haben, weiterhin das vereinfachte Nachweisverfahren nutzen.

Im Abrechnungsmenü für Deutschland (Transaktion PC01 aus dem SAP Easy Access Menü) befinden sich sämtliche Aktivitäten und Reports des DaBPV-Meldeverfahren unter dem Menüpunkt Folgeaktivitäten -> Periodenunabhängig -> Abrechnungszusatz -> DaBPV-Meldeverfahren:

Ablauf des Verfahrens

Insgesamt besteht der Meldeprozess im DaBPV-Verfahren – wie bei nahezu allen SV-Verfahren in SAP HCM – aus einem jeweils dreistufigen Ausgangs- und Eingangsprozess:

DaBPV-Ausgangsmeldung erstellen

Über den Report RP_PAYDE_DBP_CREATE_NOTIFS (Transaktion HRPAYDE_DBP_NOTIFS) werden zunächst Anmeldungen bzw. Kündigungen für alle selektierten Personalnummern erstellt, die während des Auswertungszeitraums aktiv und in der Pflegeversicherung beitragspflichtig sind bzw. inaktiv werden oder aus der Beitragspflicht ausscheiden. Der Auswertungszeitraum beginnt mit dem Verfahrensstart oder der letztmaligen Anmeldung eines Personalfalls über das Verfahren. Das Ende des Auswertungszeitraums hängt von der Ausprägung des Parameters Vorausblick auf dem Selektionsbild des Reports ab.

Über diesen Parameter kann gesteuert werden, ob Anmeldesachverhalte vorausschauend erkannt werden sollen. Vorausschauende Anmeldungen sind zulässig, wenn abzusehen ist, dass ein PV-pflichtiges Beschftigungsverhältnis entstehen wird. Sollte die Beschäftigung doch nicht eintreten, ist eine sofortige Kündigung notwendig. Folgende Auswahlmöglichkeiten sind im Feld Vorausblick ausgehed vom aktuellen Systemdatum möglich:

• 00 – Kein Vorausblick (Tagesdatum)
• 01 – Bis zum Ende des aktuellen Monats
• 02 – Bis zum Ende des nächsten Monats

Kündigungen hingegen werden nicht vorausschauend erzeugt, da diese ein bestehendes Abonnement zum Zeitpunkt der Übertragung unmittelbar beenden.

Wenn Sie den “weichen Einstieg” – also die spätere rückwirkende Anmeldung der Bestandsfälle – nutzen möchten, können Sie wie folgt vorgehen: werten Sie bspw. via Mitarbeiterliste oder Query alle zum 30.06.2025 abzurechnenden Beschäftigten und Versorgungsempfänger aus und schließen Sie diese PNR über die Mehrfachselektion im Report aus. Zum späteren Zeitpunkt, wenn Sie die Bestandsabfrage durchführen wollen, löschen Sie den PNR-Ausschluss dann wieder heraus.

DaBPV-Historienanfragen erstellen

Neben dem Standardverfahren mit der Erstellung von Anmeldungen und Kündigungen können mit dem Report RP_PAYDE_DBP_CREATE_NOTIFS_HIS (Transaktion HRPAYDE_DBP_NOTIFS_H) für einzelne Personalfälle auch Historienanfragen erstellt werden. Diese ist immer dann notwendig, wenn Elterneigenschaft und Kinderanzahl für einen Zeitraum vor Erstanmeldung bzw. Verfahrensstart abgefragt werden müssen. Dies ist bspw. bei rückwirkenden Eintritten bzw. Zahlungsbeginnen für Versorgungsbezüge um den Verfahrensstart herum der Fall.

Da eine Historienanfrage kein Abonnement einrichtet und für einen abgeschlossenen, zurückliegenden Zeitraum erstellt wird, ist im Selektionsbild neben dem gewünschten Zeitraum auch zwingend die entsprechende Personalnummer anzugeben, da der Report andernfalls nicht ausführbar ist.

Der Report erstellt dann Historienanfragen des DaBPV-Verfahrens für alle selektierten Personalnummern, die während des Auswertungszeitraums aktiv und in der Pflegeversicherung beitragspflichtig waren. Liegt innerhalb des Auswertungszeitraums eine Periode vor, in denen die Personalnummer inaktiv oder nicht beitragspflichtig war, wird für diese keine Historienanfrage gestellt. Es kann in diesen Fällen vorkommen, dass für eine Personalnummer mehrere Historienanfragen gestellt werden. Die Stammdaten (z.B. Steuer Identifikationsnummer, Geburtsdatum) werden jeweils zum Tagesdatum ausgewertet. Der weitere Verarbeitungsprozess für Historienanfragen entspricht dem Ablauf der Verarbeitung einer gewöhnlichen DaBPV-Ausgangsmeldung.

Zusammenfassung Ausgangsmeldungen

Bei der Erstellung von Ausgangsmeldungen (Meldungen durch den Arbeitgeber) können damit grundsätzlich folgende Meldesachverhalte eintreten:

Meldungsart	sachverhalt
Anmeldung	Richtet ein neues Abo ein
Historienanfrage	Anfrage ohne Einrichtung eines Abos
Kündigung	Beendet ein bestehendes Abo

DaBPV-Meldedateien erstellen und versenden

Der Report RP_PAYDE_DBP_CREATE_FILES (Transaktion HRPAYDE_DBP_FILES) erstellt anschließend auf der Grundlage aller zu übertragenden DaBPV-Ausgangsmeldungen für jeden Absender eine Meldedatei und übergibt sie für den Versand zur Annahmestelle der Deutschen Rentenversicherung an den B2A-Manager (Transaktion PB2A).

Im B2A-Manager können die erstellten Meldedateien unter dem Bereich SV und dem Dokumenttyp OARP (DaBPV-Verfahren Outgoing) angezeigt und an die DSRV versendet werden.

DaBPV-Rückmeldungen abholen und zuordnen

Die Abholung der Rückmeldungen aus dem DaBPV-Verfahren erfolgt über den Report RPCSVPD0_IN (Transaktion PC00_M01_RPCSVPD0_IN). Der Report dient zum Abholen von Verarbeitungsergebnissen und Rückmeldungen in mehreren SV-Meldeverfahren und wird im Zuge der Auslieferung des DaBPV-Verfahrens um dieses erweitert. Über den Parameter Art des Datenaustauschs im Selektionsbild wird gesteuert, für welches Verfahren Rückmeldungen abgeholt werden sollen. Für das DaBPV-Verfahren ist die Ausprägung des Parameters mit APR „DaBPV: Ausgangsmeldungen“ oder RPA „DaBPV: Eingangsmeldungen“ zu füllen.

Der Report RP_PAYDE_DBP_ASSIGN_NOTIFS (Transaktion HRPAYDE_DBP_ASSIGN) selektiert dann die Eingangsmeldungen, die über den B2A-Manager empfangen wurden (Status empfangen) und ordnet sie zur Personalnummer und zur auslösenden Ausgangsmeldung zu.

DaBPV-Rückmeldungen verarbeiten

Die anschließende Verarbeitung der Rückmeldungen der DSRV erfolgt über den Report RP_PAYDE_DBP_PROCESS_NOTIFS (Transaktion HRPAYDE_DBP_PROCESS). Grundsätzlich können folgende Rückmeldesachverhalte vorliegen (Meldungen durch das BZSt):

Meldungsart	Sachverhalt
Antwort	Antwort auf eine Anmeldung (Einrichtung eines Abonnements) oder Historienanfrage
Proaktive Meldung	Proaktive Meldung des BZSt bei aktivem Abonnement
Kündigungsbestätigung	Bestätigung über Ende eines Abonements
Kündigungsmitteilung	Proaktive Kündigung durch BZSt bspw. durch Tod des Beschäftigten oder Wechsel der Steuer-ID
Fehlerrückmeldung	Abweisung eines einzelnen Datensatzes
Fehlerrückmeldung Kündigung	Abweisung eines einzelnen Datensatzes einer Kündigung

Je nach Art der Rückmeldung durch das BZSt erfolgen dann unterschiedliche Verarbeitungsschritte:

• Erstmalige Rückmeldungen des BZSt mit Daten zur Elterneigenschaft und zur Kinderanzahl: Handelt es sich bei einer Rückmeldung des BZSt um eine erstmalige Rückmeldung, so wird der Inhalt der Meldung gegen die bereits systemseitig vorhandenen Kinderdaten verprobt. Grundsätzlich können dabei die folgenden 3 Fälle vorliegen:
  • Es sind bisher noch keine Daten zur Kinderanzahl im System vorhanden: In diesem Fall werden die Daten automatisch vom System in den Infotypen 0700 Subtyp DBPV übernommen und als für die Abrechnung relevant gekennzeichnet.
  • Es sind bereits Daten zur Anzahl der Kinder in Infotyp 0013 vorhanden: Die Daten im Infotyp 0013 werden dann mit den Daten aus der DaBPV-Meldung zum Stichtag der Anmeldung verglichen. Stimmen die Daten überein, so erfolgt die automatische Übernahme in den Infotypen 0700 Subtyp DBPV und die Kennzeichnung der Daten als abrechnungsrelevant. Weichen die abgerufenen Daten von der in Infotyp 0013 hinterlegten Kinderanzahl ab, so wird der entsprechende Fall dem Sachbearbeiter als Prüffall vorgelegt.
  • Es sind bereits Daten zur Anzahl der Kinder in Infotyp 0021 vorhanden: In diesem Fall werden die Daten für den gesamten Zeitraum der Meldung mit den bereits im System vorliegenden Daten verglichen. Bei einer Übereinstimmung erfolgt die automatische Übernahme der Daten als abrechnungsrelevant. Bei Abweichungen erhält der zuständige Sachbearbeiter den Sachverhalt als Prüffall.
• (Proaktive) Rückmeldungen im laufenden Verfahren: Sofern im Infotyp 0700 Subtyp DBPV nach dem erstmaligen Abruf Daten vorliegen, die abrechnungsrelevant sind, werden alle weiteren proaktiven Rückmeldungen des BZSt automatisiert verarbeitet. Wenn hingegen Daten vorliegen, die für die Abrechnung als nicht relevant hinterlegt sind, entsteht erneut ein Prüffall für den zuständigen Sachbearbeiter.
• Kündigungsbestätigungen: Die Bestätigung einer angefragten Kündigung wird in der Regel automatisch prozessiert. Der Infotyp 0700 wird dabei allerdings nicht abgegrenzt, ein manuelles Abgrenzen des Infotyps 0700 ist nicht erforderlich.
• Kündigungsmitteilungen: Proaktive Kündigungsmitteilungen für bestehende Abonnements durch das BZSt werden nicht automatisch verarbeitet und dem zuständigen Sachbearbeiter als Prüffall vorgelegt.
• Fehlerrückmeldungen: Fehlerrückmeldungen werden ebenfalls nicht automatisch verarbeitet. Fehlerhafte Rückmeldungen werden dem Sachbearbeiter zur Prüfung des Sachverhalts vorgelegt.

Auswirkungen auf die Stammdatenpflege

Zur Erfassung der Elterneigenschaft und der Kinderanzahl wird mit dem DaBPV-Meldeverfahren ein neuer Subtyp DBPV (DaBPV: Daten zu den PV-Kindern) des Infotyps 0700 (Elektronischer Datenaustausch) ausgeliefert. Er dient zur Speicherung der Daten, die für eine Personalnummer über das Verfahren abgerufen werden. Pro Zeitscheibe einer Rückmeldung aus dem DaBPV-Verfahren wird immer eine entsprechende Zeitscheibe des Infotyps 0700 angelegt. Der neue Subtyp des IT0700 enthält folgende Felder und Ausprägungen:

Feld	Mögliche Ausprägungen
Elterneigenschaft	X – Ja / – Nein
Anzahl Kinder	0 – 99
in der Abrechnung verwenden	X – Ja / – Nein

Über das Feld In der Abrechnung verwenden wird festgelegt, ob die über das DaBPV-Verfahren abgerufenen Daten zur Berechnung des Beitragssatzes in der Pflegeversicherung verwendet werden sollen. Die Ausprägung des Feldes wird beim Verarbeiten einer Rückmeldung stets auf “ja”, bei Prüffällen durch den Sachbearbeiter in der Sachbearbeiterliste festgelegt (“ja” oder “nein”). Eine nachträgliche Anpassung der Abrechnungsrelevanz ist möglich. Sonstige manuelle Anpassungen des DBPV-Subtyps, wie bspw. nachträgliche Eintragungen weiterer Kinder, sind nicht zulässig. Wenn die Daten aus der Rückmeldung nicht verwendet werden sollen, dann erfolgt die Ermittlung des Beitragssatzes anhand alternativer Kinderdaten. Im Standard wird dazu der Infotyp 0021 (Familie/Bezugsperson) verwendet. Dort müssen die zu berücksichtigenden Kinder vollständig mitsamt dem Geburtsdatum erfasst werden.

Das Feld Anzahl Kinder im Infotyp 0013 (Sozialvers. D) wird mit dem Start des Verfahrens nicht länger verwendet. Sobald für einen Personalfall Daten über das DaBPV-Verfahren vorhanden sind, findet die Kinderanzahl aus Infotyp 0013 in der Abrechnung für diesen Zeitraum keine Berücksichtigung mehr. Wichtig: Dies ist selbst dann der Fall, wenn die Daten im Infotyp als nicht abrechnungsrelevant gekennzeichnet sind! Für Infotypzeiträume ab dem 01.01.2026 wird das Feld ausgeblendet, sofern es keine Daten enthält.

Wenn weder der Subtyp DBPV noch der Infotyp 0021 als Datenquelle zur Verwaltung der Kinderanzahl verwendet werden sollen, ist eine kundeneigene Implementierung möglich. Die Anpassung dafür kann über eine Implementierung des BAdI HRPAYDE_DBP_B_ALT_CHILDREN (Berücksichtigung von alternativen Datenquellen zur Kinderanzahl) vorgenommen werden.

Weitere Hilfsreports

Sachbearbeiterliste für DaBPV-Meldungen

In der Sachbearbeiterliste (Report RP_PAYDE_DBP_LIST, Transaktion HRPAYDE_DBP_LIST) werden alle aktuellen Ausgangs- und Eingangsmeldungen gemeinsam angezeigt.

Über diesen Report können Sachbearbeiter die Prüffälle und Fehlerrückmeldungen einsehen und bearbeiten. Die Bearbeitung der qualifizierten Rückmeldungen unterscheidet sich je nach Art und Status der Rückmeldung und erfolgt über die entsprechenden Drucktasten in der Übersichtsleiste.

Neben der Sachbearbeiterliste mit der Möglichkeit zur Bearbeitung von Meldungen aus dem Arbeitsvorrat wird eine Sachbearbeiterliste zur reinen Anzeige der Meldungen zur Verfügung gestellt (Report RP_PAYDE_DBP_LIST_DIS, Transaktion HRPAYDE_DBP_LIST_DIS).

Fallbeispiele

Im Folgenden wollen wir zwei Fallbeispiele betrachten, die den Ablauf des DaBPV-Verfahrens von der Verarbeitung der Eingangsmeldungen bis zur Übernahme der Daten ins System beschreiben.

Fallbeispiel 1 – Erstmalige Anmeldung bei übereinstimmenden Kinderdaten (Kein Prüffall)

Mit dem Start des Verfahrens zum 01.07.2025 wird eine Anmeldung an die DSRV übertragen, auf die eine Rückmeldung erfolgt. Die Rückmeldung wird in der Sachbearbeiterliste im Status zu verarbeiten angezeigt. Über das Prüfzeichen öffnet sich aus der Sachbearbeiterliste heraus ein Fenster, dass einen Abgleich der Kinderdaten ermöglicht. Dabei werden die Daten aus der Meldung des BZSt mit den aktuellen Daten in Infotyp 0700 sowie mit den alternativen Kinderdaten (in unserem Fall aus IT0021) verglichen:

In diesem Beispiel liegen keine Abweichungen zwischen den über das DaBPV-Verfahren abgerufenen Daten und den Alternativdaten im System vor, sodass es sich nicht um einen Prüffall handelt. Eine Bearbeitung über die Sachbearbeiterliste ist nicht notwendig, soll hier nur aufzeigen, welche Prüfung die Eingangsverarbeitung ausführen wird. Die Rückmeldung kann unmittelbar über die Ausführung des Reports zur Verarbeitung der DaBPV-Eingangsmeldungen prozessiert werden:

Nach der Verarbeitung der Rückmeldung ändert sich der Status der Sachbearbeiterliste von zu verarbeiten auf verarbeitet. Beim Aufruf der Prüfung stimmen die Daten in IT0700 nun mit den Meldungsdaten und den Alternativdaten aus IT0021 überein:

Die Daten aus der Antwort werden in den Infotypen 0700 Subtyp DBPV übernommen und als abrechnungsrelevant gekennzeichnet:

Fallbeispiel 2.1 – Verarbeitung einer Rückmeldung mit Abweichungen zu den vorhandenen Kinderdaten (Prüffall)

Mit dem Start des Verfahrens zum 01.07.2025 wird eine Anmeldung erstellt, auf die eine Antwort des BZSt erfolgt. Die Rückmeldung wird über die Sachbearbeiterliste im Status zu verarbeiten angezeigt. Beim Vergleich der Kinderdaten über das Prüfzeichen in der Spalte Vergleich fällt nun auf, dass es zwischen den Daten aus der Rückmeldung des BZSt und den systemseitig vorhandenen Daten aus Infotyp 0021 Differenzen gibt: Das Geburtsdatum des ältesten Kindes wurde in Infotyp 0021 einen Monat zu früh hinterlegt (falscher Monat).

Wenn die Eingangsmeldung über den Report zur Verarbeitung der DaBPV-Meldungen prozessiert wird, wird für die Personalnummer die oben bereits gezeigte Prüfung im Hintergrund ausgeführt und entsprechend eine Fehlermeldung generiert.

Betrachtet man nach Ausführung des Verarbeitungsreports erneut die Sachbearbeiterliste, so fällt auf, dass die Rückmeldung sich nun nicht mehr im Status zu verarbeiten sondern im Status zu prüfen befindet. Nun muss über die Schaltflächen Daten verwenden bzw. Daten nicht verwenden eine Entscheidung vom Sachbearbeiter getroffen werden, ob die Daten aus der Rückmeldung bei der Übernahme in den Infotyp 0700 als abrechnungsrelevant gekennzeichnet werden sollen oder nicht. Übernommen werden die Daten in jedem Fall in den IT0700, lediglich die Abrechnungsrelevanz kann durch die Entscheidung beeinflusst werden.

In unserem Beispiel stellen wir fest, dass bei der Stammdatenpflege ein Fehler unterlaufen ist und die Daten aus der DaBPV-Rückmeldung plausibel sind. Die Daten werden daher durch das Nutzen der Drucktaste Daten verwenden als abrechnungsrelevant übernommen. Der Status der Antwort springt in der Sachbearbeiterliste auf manuell verarbeitet um und auch die Entscheidung über die Verwendung der Daten in der Abrechnung ist in der Spalte Nachrichtentext einsehbar.

In Infotyp 0700 Subtyp DBPV sind die Daten im Feld in der Abrechnung verwenden mit ja gekennzeichnet und der Infotyp 0021 wird übersteuert.

Fallbeispiel 2.2 – Verarbeitung einer Rückmeldung mit Abweichungen zu den vorhandenen Kinderdaten (Prüffall)

Bei der Prüfung der Ausgangssituation aus Fallbeispiel 2.1 stellen wir fest, dass die Daten, die in Infotyp 0021 erfasst wurden, korrekt sind und fehlerhafte Daten vom BZSt übermittelt wurden. Der Prüffall wird in der Sachbearbeiterliste daher durch das Drücken der Schaltfläche Daten nicht verwenden bearbeitet.

Die Daten werden dennoch in den Infotyp 0700 Subtyp DBPV übernommen, sind jedoch im Feld in der Abrechnung verwenden mit nein gekennzeichnet. In der Abrechnung werden daher weiterhin die Daten aus Infotyp 0021 genutzt.

Customizing des Verfahrens

Im Standard erfolgt die Bearbeitung von Prüffällen bei erstmaligen Rückmeldungen grundsätzlich wie im Abschnitt DaBPV-Rückmeldungen verarbeiten und den Fallbeispielen beschrieben. Alternativ kann die Handhabung der Prüffälle aber auch durch Customizing-Einstellungen des Verfahrens angepasst werden. Die Daten aus der Rückmeldung können bei entsprechender Einstellung auch dann automatisch als abrechnungsrelevant übernommen werden, wenn Abweichungen zu alternativen Kinderdaten in Infotyp 0013 oder 0021 vorliegen.

Die Handhabung von Prüffällen kann außerdem durch eine kundeneigene Implementierung des BAdIs HRPAYDE_DBP_B_CHK_PROC_RPLY (Festlegung zu Prüffällen bei erstmaligen Rückmeldungen) erweitert bzw. übersteuert werden.

Mit der erstmaligen Verarbeitung von DaBPV-Daten im Infotyp 0700 verliert das Prüffall-Customizing im weiteren Verfahren an Relevanz. Ab diesem Punkt werden proaktive Rückmeldungen des Bundeszentralamts für Steuern (BZSt) im Regelfall automatisch übernommen. Eine Ausnahme bilden hier Personalfälle, deren DBPV-Daten im Infotyp 0700 als nicht abrechnungsrelevant gekennzeichnet sind. In diesem Fall muss der zuständige Sachbearbeiter erneut entscheiden, ob eine Übernahme der Daten erfolgen soll.

Zudem ist über Customizing auch eine Anbindung des DaBPV-Verfahrens an das Notification Tool möglich (Bereich SV; Teilbereich DBP).

---

Haben Sie weitere Fragen oder benötigen Sie Unterstützung bei der Umsetzung des Verfahrens?

Sprechen Sie uns auch gerne an! Einen direkten Link zum Kontaktformular finden Sie hier. Oder schauen Sie sich unseren SAP HCM Support Package Service L365 an.

Gibt es evtl. ein Thema, was Sie „brennend“ interessiert und worüber wir unbedingt schreiben sollten?

Dann schicken Sie uns Ihre Idee gerne per Mail über das folgende Kontaktformular! Vielen Dank im Voraus!