Title
Conversion report for SI wage types (report XPRA RPU40BX_CH_SVLGARTS)

• After an upgrade, or after the HR Support Package that includes this
report has been imported, the report converts relevant SI wage types intable T512W for target releases as of 4.0. Only Swiss wage types (thatis, the molga field = '02') are changed. All clients that are not
protected from SAP upgrades by table T100 are converted.

• If this program is accessed by RPU40AC0, or if wage type 'U31I' exists,
the time limit between wage type coding to enable the old SI module tobe used and coding to enable the new SI module to be used is postponed.

Overview
As of 01.01.2002, this program enables you to divide records of wagetypes that are used by the old and the new SI module but with differentcoding.
Legal changes to these wage types can be imported in T512W, once it hasbeen prepared this way, in the form of records that cover the interval01.01.2002-12.31.9999. Overlaps and gaps cannot arise. For a fulldescription of the functionality, see the section entitled Scope ofFunctions.

Details:
Up until now, an old social insurance module existed in allreleases; as of 1998, a new social insurance module existed inreleases as of 4.0B. The wage type coding in table T512W that enableswage types to be used in these modules is not the same. After a changehas occurred, the validity interval of wage types used by both modulesmust therefore contain a split.
Records before the split must contain coding that enables the old SImodule to be used so that retroactive accounting and evaluations can beperformed. Records after the split must contain coding that enables thenew SI module to be used.
Example: If a change to the new SI module occurs on 01.01.1998, therecord from 01.01.1901 to 31.12.1997 of wage type /102 contains codingthat enables the old SI module to be used (processing class 69, forexample, has specification INITIAL). In the record from 01.01.1998 to31.12.9999, the wage type contains coding that enables the new SImodule to be used (processing class '69', for example, hasspecification '5').
In the standard SAP system for Releases 40B and 45B, wage types weredelivered so that new SI can be used as of 01.01.1998 (see the exampleabove). If the change (which is possible on 01.01.98/99/01/02) does nottake place on 01.01.1998 in a release as of 4.0B, the split must be"postponed" accordingly using report RPU40AC0 in the production client.
Example: if the change to the new SI module occurs on 01.01.2000, therecord from 01.01.1901 to 31.12.1999 of wage type /102 contains codingthat enables the old SI module to be used; the record from 01.01.2000to 12.31.9999 contains coding that enables the new SI module to beused.
Exception: no postponement is necessary in Release 3.1I because the newSI module delivered with 3.1I already includes a coded wage type recordthat enables new SI to be used on 01.01.2002.
This customer-specific delimitation of wage types means that legalchanges cannot simply be delivered for wage types because importingchanged records with a start date of 01.01.1998 into a table T512W forwhich an SI start date other than 01.01.1998 has been converted wouldlead to overlaps that could cause errors when calculations areperformed.
The availability of the new SI module in Release 3.1I, and theobligatory use of new SI as of 01.01.2002, mean that a uniform statuscan be re-established as of 01.01.2002 for the records of affected wagetypes. This uniform status enables legal changes to be delivered againas of 01.01.2002:
This program is delivered as an XPRA. When an HR Support Package isimported, or when an upgrade takes place, it divides the validityinterval of the affected wage types that contains 01.01.2002; it doesso on 01.01.2002.
Coding before 01.01.2002 is retained. As of 01.01.2002, coding isinserted for wage types to enable the new SI module to be used.
The program is accessed by report RPU40AC0, which is used when theconversion to the new SI module takes place, and postpones thedelimitation between the coding for old and new SI to the individualstart date of the new SI calculation.

Prerequisites
The time intervals 01.01.1801 - 12.31.1801 and 01.01.1802 - 12.31.1802are delivered for the affected wage types together with this XPRA. Therange 01.01.1801 - 12.31.1801 contains wage type coding thatenables the old SI module to be used. The range 01.01.1802 -12.31.1802 contains wage type coding that enables the new SI moduleto be used.
In the case of wage types with the old SI module that have becomeobsolete with the new SI module, most of the fields for wage typecoding in the range 01.01.1802 - 12.31.1802 are INITIAL. This "modelcoding" is required to execute the program, even if it is startedindirectly by report RPU40AC0. Therefore, these entries MUST NOT bedeleted.
Note: overlaps and gaps in records pertaining to the same wage typecan prevent the conversion from taking place successfully.
Exception: wage type gaps are identified and repaired that arisebecause of wage types being delivered as of 01.01.2002 to a T512W thathas not been prepared by this XPRA.

Features

Functions when XPRA is executed:
Split on 01.01.2002:
Creates a split in table T512W on 01.01.2002 for those Swiss wage types(that is, the field MOLGA = '02' in T512W) that are used by the old andnew SI module (with changed wage type coding), assuming that such asplit does not exist already, as follows:
If a time interval exists with ENDDA=12.31.9999 and BEGDA < 01.01.2002(BEGDA is 01.01.xxxx), then
The interval 01.01.xxxx - 31.12.9999 is deleted and then inserted withENDDA=12.31.2001.
An interval is also inserted with BEGDA=01.01.2002, ENDDA=12.31.9999,and coding for new SI.
Example (conversion to new SI on 01.01.1999):
Input: a[01.01.1901;12.31.1998], n[01.01.1999;12.31.9999]
Output: a[01.01.1901;12.31.1998], n[01.01.1999;12.31.2001],n*[01.01.2002;12.31.9999]
(n* ... wage type coding for new SI: copied from range[01.01.1802;12.31.1802])
Closing gaps caused by wage type deliveries
A situation is also handled in which a delivery of unconverted wagetypes (such as new entries 2002-2003;2004-9999) is included in anupgrade as of 2002, together with the HR Support Package that containsthis XPRA. In this case, a gap arises (for example, 1998-2001) becausethe XPRA has no opportunity to anticipate the delivery that is thenfilled by a corresponding record with coding for new SI.
This means that if
No entry exists with ENDDA=12.31.9999 and Begda < 01.01.2002
And one entry exists with Begda = 01.01.2002
And no entry exists with Endda = 12.31.2001 (that is, gap before2002),
then the gap between the next day of the maximum available end date <01.01.2002 and 12.31.2001 is closed by the insertion of a record withcoding that enables new SI to be used.
Usually, a gap can arise by a record with coding for new SI and Endda =12.31.9999 being deleted by an entry with a higher Begda beingimported. Therefore, the gap is filled with coding for new SI.
Example:
Input: a[01.01.1901;12.31.1997], n[01.01.2002;12.31.2003],n[01.01.2004;12.31.9999]
Output: a[01.01.1901;12.31.1997], nn[01.01.1999;12.31.2000],n[01.01.2002;12.31.2003], n[01.01.2004;12.31.9999]
Extend to 12.31.9999, divide on 01.01.2002, and insert "empty"coding as of 2002 for obsolete wage types of old SI module:
This removes an error associated with wage types delivered for Releases40B and 45 that used old SI and are no longer used with new SI. Thesewage types were delivered again by mistake with ENDDA = 12.31.1998.This would lead to a rejection in payroll if old results are importedafter 12.31.1998 (if an employee re-enters the company, for example).If necessary, the XPRA extends the validity period to 12.31.9999,whereby a split is created on 01.01.2002 as of when the affected wagetype's coding of 01.01.1802-12.31.1802 is copied.
Postpone start date for using new SI in table T512W to 01.01.2002for an upgrade if conversion to new SI took place on 01.01.2002 in3.1I before the upgrade.
This is recognized by wage type 'U31I', which is delivered with new SIin 3.1I. In all other cases, the postponement only takes place ifaccess is made by report RPU40AC0.
Example:
Input: a[01.01.1901;12.31.1997], n[01.01.1998;12.31.2001],n*[01.01.2002;12.31.9999]
Output: a[01.01.1901;12.31.2001], n[01.01.2002;12.31.9999]

Additional functions if report RPU40AC0 is executed
If the start date of the new SI calculation is not 01.01.1998, you mustexecute report RPU40AC0 to adapt various tables that depend on thisdate when you upgrade to the new SI module and after an upgrade withsource release 4.0B. RPU40AC0 accesses program RPU40BX_CH_SVLGARTS fortable T512W. The program postpones the limit between coding for old andnew SI in the validity interval of the affected wage types to thecustomer-specific SI start date.
This postponement is always needed for an upgrade to the new SI module.If you upgrade from a source release < 4.5, a generic wage typedelivery for 4.0 and 4.5 (LGART='/*','M*','S*') undoes thepostponement, as it were. If new SI was implemented in Release 3.1I,the start date is most certainly 01.01.2002. When the upgrade takesplace, this is automatically recognized and corrected by wage type'U31I'.
The start date for source release 4.0B, however, is 01.01.xxxx withxxxx from {1998,1999,2000,2001,2002}; it cannot be determinedautomatically. After an upgrade with source release < 4.5, the startdate must therefore be maintained manually and report RPU40AC0 must bestarted.
Example: ( a ... coding old SI; n ... new SV)
Initial situation: /102= { a[01.01.1902;12.31.1997],n[01.01.1998;12.31.2001], n[01.01.2002;12.31.2004],n[01.01.2005;12.31.9999].} i.e. SV_BEGDA_ALT = 01.01.1998
Target situation after postponement to SV_BEGDA_NEU = 01.01.2001: {a[01.01.1902;12.31.2000], a[01.01.2001;12.31.2001],n[01.01.2002;12.31.2004], n[01.01.2005;12.31.9999].}

General:,,
If program RPU40BX_CH_SVLGARTS is executed as an XPRA, the abovechanges are made in all clients of table T000. If it is executed usingreport RPU40AC0, only the client in which RPU40AC0 is started isconverted.
Clients without Swiss wage types are not changed, and the client isregarded as successfully processed.
Wage types used in Swiss social insurance calculations are only changedif they were reused after the 1998 revision of social insurance withdifferent coding, or if they are SI wage types that are no longer usedby the new social insurance module.
A complete list of these wage types in included in form routineINIT_MAIN.
Database commits take place client-by-client for clients in which atleast one wage type can be changed successfully without errorsoccurring when the database is then changed. Even if it is not possibleto convert all the wage types in a client, as many wage types aspossible are converted. The log records these clients as "partiallyconverted".
If a second run is performed, successfully changed wage types are notchanged again. This means that the XPRA can be restarted.
Ideally, all three or four processing steps are performed for all wagetypes without errors, or no Swiss wage types are found in this client,which means that no conversion-relevant data exists. These clients arerecorded in the log as "successfully processed".
When the XPRA runs in releases up to 4.6C, a backup of the affectedwage types is created (before changes are made) in table T599U with thekey [MANDT]DAT512CH999 or [MANDT]VER512CH999. In later releases, thebackup is created by a version entry with the key [MANDT]VE512BCH999 intable T599U and data entries with application indicator 'C' in tableT512B.
When the XPRA runs, changes are made to T512W, T599U, and T512B withouta transport connection, and locks are set. If the XPRA is executedindirectly by starting report RPU40AC0, the latter deals with thelocks/unlocks and transport connection.

Output
A log is output. Errors are logged on level 2, and the conversion'ssuccess is logged for each client on level 3. There are five statuses:
Successfully processed and changed
Already in target status and not changed
Only partially changed because of errors
Not converted because of errors
Not changed because no data relevant to conversion exists
Statuses 3 and 4 are errors. Statuses 1 and 3 indicate that changeshave been made on the database.
Finally, the system displays summarizing messages about the number ofsuccessfully processed clients (that is, no errors occurred), partiallyconverted clients (at least one, but not all wage types successfullyconverted and written to the database), and changed clients (changeswere made on the database).
If this program is executed using report RPU40AC0, the start date, enddate, and wage type of inserted and changed records are also output.Inserted records are flagged with '+' and deleted records with '-'. Youmay have to expand the log to see these messages. If the message"Client not converted because of errors" is displayed, any changes thathave been logged are not effective.