Kontakt

Ansicht
Dokumentation

RPU40BX_CH_SVLGARTS - Report deaktiviert

RPU40BX_CH_SVLGARTS - Report deaktiviert

Fill RESBD Structure from EBP Component Structure   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Titel

Umsetzreport für Lohnarten der SV (Report XPRA RPU40BX_CH_SVLGARTS)

Verwendung

  • Der Report setzt nach einem Upgrade oder nach dem Einspielen des HR Support Packages, mit dem dieser Report zur Verfügung gestellt wird, die relevanten SV-Lohnarten in der Tabelle T512W für Zielreleases ab 4.0 um. Geändert werden nur schweizer Lohnarten (d.h. Feld Molga='02'). Alle Mandanten, die nicht gemäss Tabelle T100 gegen SAP-Upgrade geschützt sind, werden umgesetzt.
  • Zusätzlich wird eine Verschiebung der zeitlichen Grenze zwischen der Lohnartenschlüsselung zur Verwendung mit dem alten SV-Modul und der Schlüsselung zur Verwendung mit dem neuen SV-Modul durchgeführt, sofern dieses Programm vom RPU40AC0 aufgerufen wird oder die Lohnart 'U31I' existiert.

Überblick

Mit dem Programm können Sie die Sätze von Lohnarten, die sowohl vom alten als auch vom neuen SV-Modul - aber mit unterschiedlicher Schlüsselung - verwendet werden, ab dem 01.01.2002 teilen.

In eine so vorbereitete T512W können Gesetzesänderungen dieser Lohnarten in Form von Sätzen, die das Intervall 01.01.2002-31.12.9999 abdecken, eingespielt werden, ohne dass Überlappungen oder Lücken enstehen können. Eine vollständige Beschreibung der Funktionalität finden Sie unter Funktionsumfang.

Details:

Bisher existierten ein altes Sozialversicherungsmodul in allen Releases und ab 1998 ein neuesSozialversicherungsmodul in den Releases ab 4.0B. Da sich die zur Verwendung mit dem jeweiligen Modul notwendige Schlüsselung der Lohnarten in der Tabelle T512W unterscheidet, muss nach einem Wechsel ein Split im Gültigkeitsintervall der von beiden Modulen verwendeten Lohnarten vorhanden sein.
Die Sätze vor dem Split müssen für Rückrechnungen und Auswertungszwecke die Schlüsselung zur Verwendung mit dem alten SV-Modul enthalten, und die Sätze nach dem Split müssen die Schlüsselung zur Verwendung mit der neuen SV enthalten.
Beispiel: Bei einem Wechsel zum neuen SV-Modul zum 01.01.1998 enthält die Lohnart /102 im Satz vom 01.01.1901-31.12.1997 die Schlüsselung zur Verwendung mit dem alten SV-Modul (die Verarbeitungsklasse 69 hat beispielsweise die Ausprägung INITIAL). Im Satz vom 01.01.1998 - 31.12.9999 enthält die Lohnart die Schlüsselung zur Verwendung mit dem neuen SV-Modul (die Verarbeitungsklasse '69' hat beispielsweise die Ausprägung '5').

In der SAP-Standardauslieferung der Releases 40B und 45B wurden die Lohnarten so ausgeliefert, damit ab 01.01.1998 der Einsatz der neuen SV möglich ist (siehe Beispiel oben). Findet der Wechsel (jeweils zum 01.01.98/99/01/02 mölgich) in einem Release ab 4.0B nicht zum 01.01.1998 statt, muss der Split mit dem Report RPU40AC0 im Produktivmandanten entsprechend "verschoben" werden.

Beispiel: Bei Wechsel zum neuen SV-Modul am 01.01.2000 enthält die Lohnart /102 im Satz vom 01.01.1901-31.12.1999 die Schlüsselung zur Verwendung mit dem alten SV-Modul , im Satz 01.01.2000-31.12.9999 die Schlüsselung zur Verwendung mit dem neuen SV-Modul.).

Ausnahme: In Release 3.1I ist eine Verschiebung nicht nötig, da mit dem ausgelieferten neuen SV-Modul für 3.1I bereits ein geschlüsselter Lohnartensatz mitgeliefert wird, mit dem der Einsatz der neuen SV am 01.01.2002 ermöglicht wird.

Wegen der so entstandenen kundenindividuellen Abgrenzung der Lohnarten ist eine Auslieferung von Gesetzesänderungen bei Lohnarten nicht mehr ohne weiteres möglich, da beim Einspielen von geänderten Sätzen mit Beginndatum 01.01.1998 in eine T512W, die für ein anderes SV-Beginndatum als den 01.01.1998 umgestellt wurde, zeitliche Überlappungen entstehen, die zu Fehlern bei der Berechnung führen können.

Durch die Verfügbarkeit des neuen SV-Moduls in Release 3.1I und den zwingenden Einsatz der neuen SV ab 01.01.2002, kann ab 01.01.2002 für die Lohnartensätze der betroffenen Lohnarten wieder ein einheitlicher Stand hergestellt werden, der das Ausliefern von gesetzlichen Änderungen ab 01.01.2002 ermöglicht:
Dieses Programm wird als XPRA ausgeliefert und teilt bei Einspielen des HR Support Package oder bei einem Releasewechsel das den 01.01.2002 enthaltende Gültigkeitsintervall der betroffenen Lohnarten zum 01.01.2002.
Die Schlüsselung vor dem 01.01.2002 wird dabei beibehalten, und ab dem 01.01.2002 wird die Schlüsselung für die Lohnarten eingefügt, die zur Verwendung des neuen SV-Moduls benötigt wird.

Das Programm wird ausserdem vom Report RPU40AC0 aufgerufen, der bei einer Umstellung auf das neue SV-Modul verwendet wird, und verschiebt die Abgrenzung zwischen der Schlüsselung für alte und neue SV auf das individuelle Beginndatum der neuen SV-Berechnung.

Integration

Voraussetzungen

Zusammen mit diesem XPRA werden die Zeitintervalle 01.01.1801 - 31.12.1801 und 01.01.1802 - 31.12.1802 für die betreffenden Lohnarten ausgeliefert. Der Bereich 01.01.1801 - 31.12.1801 enthält die Schlüsselung der Lohnart zur Verwendung mit dem alten SV-Modul und der Bereich 01.01.1802 - 31.12.1802 die Schlüsselung der Lohnart zur Verwendung mit der neuen SV.
Bei Lohnarten des alten SV-Moduls, die mit dem neuen SV-Modul obsolet geworden sind, sind im Bereich 01.01.1802 - 31.12.1802 die meisten Felder der Lohnartenschlüsselung mit INITIAL geschlüsselt. Diese "Musterschlüsselungen" werden zum Ausführen des Programms benötigt, auch, wenn es indirekt über den Report RPU40AC0 gestartet wird. Daher dürfen diese Einträge auf keinen Fall gelöscht werden.

Beachten Sie, dass zeitliche Überlappungen, ebenso wie Lücken, bei Sätzen derselben Lohnart eine erfolgreiche Umsetzung verhindern können.
Ausnahme: Es werden diejenigen zeitlichen Lücken bei einer Lohnart erkannt und repariert, die infolge einer Lohnartenauslieferung ab 01.01.2002 in einer T512W entstehen können, die nicht durch dieses XPRA vorbereitet wurde.

Funktionsumfang

Funktionalität bei Ausführung als XPRA:

Split zum 01.01.2002:
Herstellen eines Splits in der Tabelle T512W zum 01.01.2002 bei denjenigen schweizer Lohnarten (d.h. Feld MOLGA = '02' in T512W), die sowohl vom alten als auch vom neuen SV-Modul (mit veränderter Lohnartenschlüsselung) verwendet werden, falls nicht schon ein solcher Split existiert, wie folgt:
Wenn ein Zeitintervall mit ENDDA=31.12.9999 und BEGDA < 01.01.2002 (BEGDA sei 01.01.xxxx) existiert, dann

  • wird das Intervall vom 01.01.xxxx - 31.12.9999 gelöscht und mit ENDDA=31.12.2001 neu eingefügt.

  • Zusätzlich wird ein Intervall mit BEGDA=01.01.2002, ENDDA=31.12.9999 und Schlüsselung für neue SV neu eingefügt.

Beispiel (Umstellung auf neue SV zum 01.01.1999 erfolgt):
Eingabe: a[01.01.1901;31.12.1998], n[01.01.1999;31.12.9999]
Ausgabe:a[01.01.1901;31.12.1998], n[01.01.1999;31.12.2001], n*[01.01.2002;31.12.9999]

(n* ... Lohnartenschlüsselung für neue SV: aus dem Bereich [01.01.1802;31.12.1802] kopiert)

Schliessen von Lücken, die durch Lohnartenauslieferungen entstanden sind
Zusäzlich wird noch der Fall behandelt, dass eine Lohnartenauslieferung ab 2002 (z.B. neue Eintrage 2002-2003;2004-9999) zusammen mit dem dieses XPRA enthaltenden HR Support Package beim Upgrade eingebunden wird und die Lohnarten noch nicht umgesetzt wurden. In diesem Fall ensteht eine Lücke (z.B. 1998-2001), weil das XPRA keine Chance hat, der Auslieferung zuvorzukommen, die dann durch einen entsprechenden Satz mit Schlüsselung für die neue SV aufgefüllt wird.

Das heißt, wenn

  • kein Eintrag mit ENDDA=31.12.9999 und Begda < 01.01.2002 existiert

  • und ein Eintrag mit Begda = 01.01.2002 existiert

  • und kein Eintrag mit Endda = 31.12.2001 existiert (d.h. Lücke vor 2002) ,

wird die Lücke zwischen dem Folgetag des maximalen vorhandenen Endedatums < 01.01.2002 und dem 31.12.2001 durch Einfügen eines Satzes mit Schlüsselung zur Verwendung für die neue SV geschlossen.
I.d.R. kann eine Lücke dadurch entstehen, daß ein Satz mit Schlüsselung für neue SV und Endda =31.12.9999 durch Einspielen eines Eintrags mit höherem Begda gelöscht wird, deshalb wird die Lücke mit Schlüsselung für neue SV aufgefüllt.

Beispiel :
Eingabe: a[01.01.1901;31.12.1997], n[01.01.2002;31.12.2003], n[01.01.2004;31.12.9999]
Ausgabe:a[01.01.1901;31.12.1997], nn[01.01.1999;31.12.2000], n[01.01.2002;31.12.2003], n[01.01.2004;31.12.9999]

Verlängern auf den 31.12.9999, Teilen zum 01.01.2002 und Einfügen einer "leeren" Schlüsselung ab 2002 von obsoleten Lohnarten des alten SV-Moduls:

Dies behebt u.a. einen Fehler bei der Lohnartenauslieferung zu Release 40B und 45 von Lohnarten der alten SV, die in der neuen SV nicht mehr verwendet werden. Diese Lohnarten wurden fälschlicherweise mit ENDDA = 31.12.1998 neu ausgeliefert. Dies würde zur einer Ablehnung in der Abrechnung führen, wenn alte Ergebnisse nach dem 31.12.1998 eingelesen werden (z.B. bei Wiedereintritt). Falls nötig, verlängert das XPRA das insgesamt abgedeckte Gültigkeitsintervall bis zum 31.12.9999, wobei ein Split zum 01.01.2002 erzeugt wird, ab dem die Schlüsselung vom 01.01.1802-31.12.1802 der betreffenden Lohnart kopiert wird.

Verschieben des Beginndatums für den Einsatz der neuen SV in der Tabelle T512W auf den 01.01.2002 bei einem Upgrade, wenn vor dem Upgrade auf die neue SV im 3.1I zum 01.01.2002 umgestellt wurde.
Dies wird anhand der mit der neuen SV im 3.1I ausgelieferten Lohnart 'U31I' erkannt. In allen anderen Fällen erfolgt eine Verschiebung nur im Zusammenhang mit einem Aufruf durch den Report RPU40AC0.

Beispiel:
Eingabe: a[01.01.1901;31.12.1997], n[01.01.1998;31.12.2001], n*[01.01.2002;31.12.9999]
Ausgabe: a[01.01.1901;31.12.2001], n[01.01.2002;31.12.9999]

Zusätzliche Funktionalität bei Ausführen mit dem Report RPU40AC0

Wenn das Beginndatum der neuen SV-Berechnung nicht der 01.01.1998 ist, müssen Sie bei einem Wechsel auf das neue SV-Modul und nach einem Upgrade mit einem Quellrelease 4.0B mit dem Report RPU40AC0 verschiedene von diesem Datum abhängige Tabellen anpassen. Für die Tabelle T512W ruft der RPU40AC0 das Programm RPU40BX_CH_SVLGARTS auf, das dann eine Verschiebung der Grenze zwischen Schlüsselung für alte und neue SV im Gültigkeitsintervall der betroffenen Lohnarten auf das kundenindividuelle SV-Beginndatum vornimmt.

Beim Wechsel zum neuem SV-Modul ist diese Verschiebung immer notwendig. Beim Upgrade aus einem Quellrelease < 4.5 wird durch eine generische Lohnartenauslieferung zu 4.0 und 4.5 (LGART='/*','M*','S*') die Verschiebung quasi rückgängig gemacht. Wenn die neue SV in Release 3.1I eingeführt wurde, ist das Beginndatum mit Sicherheit der 01.01.2002. Dies wird automatisch beim Upgrade über Lohnart 'U31I' erkannt und korrigiert.

Für Quellrelease 4.0B dagegen ist das Beginndatum der 01.01.xxxx mit xxxx aus {1998,1999,2000,2001,2002} und kann nicht mit Sicherheit automatisch bestimmt werden. Deshalb muss hier nach einem Upgrade mit Quellrelease < 4.5 nach dem Upgrade das Beginndatum manuell gepflegt und der Report RPU40AC0 gestartet werden.

Beispiel: ( a ... Schlüsselung alte SV; n ... neue SV)

Ausgangszustand: /102= { a[01.01.1902;31.12.1997], n[01.01.1998;31.12.2001], n[01.01.2002;31.12.2004], n[01.01.2005;31.12.9999].} d.h. SV_BEGDA_ALT = 01.01.1998

Zielzustand nach Verschiebung auf SV_BEGDA_NEU = 01.01.2001: { a[01.01.1902;31.12.2000], a[01.01.2001;31.12.2001], n[01.01.2002;31.12.2004], n[01.01.2005;31.12.9999].}

Allgemeines:,,

Wird das Programm RPU40BX_CH_SVLGARTS als XPRA ausgeführt, werden obige Änderungen in allen Mandanten der Tabelle T000 vorgenommen. Bei Ausführung über den Report RPU40AC0 wird genau der Mandant, in dem der RPU40AC0 gestartet wird, umgesetzt.

In Mandanten, die keine schweizer Lohnarten besitzen, werden keine Änderungen durchgeführt, und der Mandant wird als erfolgreich bearbeitet betrachtet.

Geändert werden nur Lohnarten der schweizer Sozialversicherungsberechnung, die im Rahmen der Sozialversicherungsüberarbeitung 1998 mit veränderter Schlüsselung wiederverwendet wurden, sowie die vom neuen Sozialversicherungsmodul nicht mehr verwendeteten SV-Lohnarten.
Eine vollständige Liste dieser Lohnarten ist in der Formroutine INIT_MAIN enthalten.

Die Datenbank-Commits erfolgen jeweils mandantenweise für die Mandanten, in denen mindestens eine Lohnart erfolgreich geändert werden kann und kein Fehler beim abschliessenden Ändern auf der Datenbank auftritt. D.h., auch wenn nicht alle Lohnarten eines Mandanten umgesetzt werden können, werden so viele Lohnarten soweit wie möglich umgesetzt. Im Protokoll werden diese Mandanten als "teilweise umgesetzt" bezeichnet.
Bei einem zweiten Lauf werden keine weiteren Änderungen an den bereits erfolgreich umgesetzten Lohnarten vorgenommen, d.h. das XPRA ist wiederaufsetzbar.
Im Idealfall können für alle Lohnarten alle drei bzw. vier Verarbeitungsschritte ohne Fehler durchgeführt werden, oder es wurden keine schweizer Lohnarten in diesem Mandanten gefunden, d.h. keine umsetzungsrelevanten Daten sind vorhanden. Diese Mandanten werden im Protokoll als "erfolgreich bearbeitet" bezeichnet.

Im XPRA-Lauf wird in Releases bis 4.6C vor Durchführung von Änderungen eine Sicherungskopie der betroffenen Lohnarten in der Tabelle T599U mit dem Schlüssel [MANDT]DAT512CH999 bzw. [MANDT]VER512CH999 erstellt. In den nachfolgenden Releases ist die Sicherungskopie dagegen über einen Versionseintrag mit Schlüssel [MANDT]VE512BCH999 in der Tabelle T599U und Dateneinträgen mit dem Anwendungskennzeichen 'C' in der Tabelle T512B realisiert.

Im XPRA-Lauf erfolgen Änderungen an T512W, T599U und T512B ohne Transportanschluss und Sperren. Bei indirekter Ausführung über Starten des Reports RPU40AC0 übernimmt dieser das Sperren/Entsperren und den Transportanschluss.

Selektion

Standardvarianten

Ausgabe

Es wird ein Protokoll ausgegeben. Neben den Fehlern auf Level 2 wird für jeden Mandanten der Erfolg der Umsetzung auf Level 3 protokolliert. Es gibt fünf Fälle:

  1. erfolgreich bearbeitet und geändert
  2. bereits im Zielzustand und wird nicht geändert
  3. wegen Fehler nur teilweise geändert
  4. wegen Fehler nicht umgesetzt
  5. nicht geändert, da keine umsetzungsrelevanten Daten vorhanden

Dabei sind die Fälle 3 und 4 als Fehler anzusehen. In den Fällen 1 und 3 sind Änderungen auf der Datenbank erfolgt.

Am Ende erfolgen zusammenfassende Meldungen über die Anzahl der erfolgreich bearbeiteten (d.h. keine Fehler aufgetreten), teilweise umgesetzten (mindestens eine aber nicht alle Lohnarten erfolgreich umgesetzt und auf die Datenbank geschrieben) und geänderten (Änderungen auf der Datenbank wurden vorgenommen) Mandanten.

Wenn dieses Programm über den Report RPU40AC0 ausgeführt wird, werden zusätzlich Beginndatum, Endedatum und Lohnart der eingefügten und geänderten Sätze ausgegeben. Eingefügte Sätze sind mit '+' und gelöschte Sätze mit '-' gekennzeichnet. Eventuell muss das Protokoll expandiert werden, um diese Meldungen zu sehen. Wenn die Meldung "Mandant wegen Fehler nicht umgesetzt" folgt, sind eventuell protokollierte Änderungen nicht wirksam.

Aktivitäten

Beispiel






RFUMSV00 - Advance Return for Tax on Sales/Purchases   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 17948 Date: 20240601 Time: 115124     sap01-206 ( 354 ms )