Kontakt

Ansicht
Dokumentation

RPU40BX_CH_SVLGARTS - Report Deactivated

RPU40BX_CH_SVLGARTS - Report Deactivated

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   CPI1466 during Backup  
This documentation is copyright by SAP AG.
SAP E-Book

Title

Conversion report for SI wage types (report XPRA RPU40BX_CH_SVLGARTS)

Purpose

  • After an upgrade, or after the HR Support Package that includes this report has been imported, the report converts relevant SI wage types in table T512W for target releases as of 4.0. Only Swiss wage types (that is, 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 to be 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 wage types that are used by the old and the new SI module but with different coding.

Legal changes to these wage types can be imported in T512W, once it has been prepared this way, in the form of records that cover the interval 01.01.2002-12.31.9999. Overlaps and gaps cannot arise. For a full description of the functionality, see the section entitled Scope of Functions.

Details:

Up until now, an old social insurance module existed in all releases; as of 1998, a new social insurance module existed in releases as of 4.0B. The wage type coding in table T512W that enables wage types to be used in these modules is not the same. After a change has occurred, the validity interval of wage types used by both modules must therefore contain a split.
Records before the split must contain coding that enables the old SI module to be used so that retroactive accounting and evaluations can be performed. Records after the split must contain coding that enables the new SI module to be used.
Example: If a change to the new SI module occurs on 01.01.1998, the record from 01.01.1901 to 31.12.1997 of wage type /102 contains coding that enables the old SI module to be used (processing class 69, for example, has specification INITIAL). In the record from 01.01.1998 to 31.12.9999, the wage type contains coding that enables the new SI module to be used (processing class '69', for example, has specification '5').

In the standard SAP system for Releases 40B and 45B, wage types were delivered so that new SI can be used as of 01.01.1998 (see the example above). If the change (which is possible on 01.01.98/99/01/02) does not take 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, the record from 01.01.1901 to 31.12.1999 of wage type /102 contains coding that enables the old SI module to be used; the record from 01.01.2000 to 12.31.9999 contains coding that enables the new SI module to be used.

Exception: no postponement is necessary in Release 3.1I because the new SI module delivered with 3.1I already includes a coded wage type record that enables new SI to be used on 01.01.2002.

This customer-specific delimitation of wage types means that legal changes cannot simply be delivered for wage types because importing changed records with a start date of 01.01.1998 into a table T512W for which an SI start date other than 01.01.1998 has been converted would lead to overlaps that could cause errors when calculations are performed.

The availability of the new SI module in Release 3.1I, and the obligatory use of new SI as of 01.01.2002, mean that a uniform status can be re-established as of 01.01.2002 for the records of affected wage types. This uniform status enables legal changes to be delivered again as of 01.01.2002:
This program is delivered as an XPRA. When an HR Support Package is imported, or when an upgrade takes place, it divides the validity interval of the affected wage types that contains 01.01.2002; it does so on 01.01.2002.
Coding before 01.01.2002 is retained. As of 01.01.2002, coding is inserted for wage types to enable the new SI module to be used.

The program is accessed by report RPU40AC0, which is used when the conversion to the new SI module takes place, and postpones the delimitation between the coding for old and new SI to the individual start date of the new SI calculation.

Integration

Prerequisites

The time intervals 01.01.1801 - 12.31.1801 and 01.01.1802 - 12.31.1802 are delivered for the affected wage types together with this XPRA. The range 01.01.1801 - 12.31.1801 contains wage type coding that enables the old SI module to be used. The range 01.01.1802 - 12.31.1802 contains wage type coding that enables the new SI module to be used.
In the case of wage types with the old SI module that have become obsolete with the new SI module, most of the fields for wage type coding in the range 01.01.1802 - 12.31.1802 are INITIAL. This "model coding" is required to execute the program, even if it is started indirectly by report RPU40AC0. Therefore, these entries MUST NOT be deleted.

Note: overlaps and gaps in records pertaining to the same wage type can prevent the conversion from taking place successfully.
Exception: wage type gaps are identified and repaired that arise because of wage types being delivered as of 01.01.2002 to a T512W that has 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 and new SI module (with changed wage type coding), assuming that such a split 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 with ENDDA=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 wage types (such as new entries 2002-2003;2004-9999) is included in an upgrade as of 2002, together with the HR Support Package that contains this XPRA. In this case, a gap arises (for example, 1998-2001) because the XPRA has no opportunity to anticipate the delivery that is then filled 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 before 2002),

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 with coding 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 being imported. 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 Releases 40B and 45 that used old SI and are no longer used with new SI. These wage types were delivered again by mistake with ENDDA = 12.31.1998. This would lead to a rejection in payroll if old results are imported after 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 wage type's coding of 01.01.1802-12.31.1802 is copied.

Postpone start date for using new SI in table T512W to 01.01.2002 for an upgrade if conversion to new SI took place on 01.01.2002 in 3.1I before the upgrade.
This is recognized by wage type 'U31I', which is delivered with new SI in 3.1I. In all other cases, the postponement only takes place if access 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 must execute report RPU40AC0 to adapt various tables that depend on this date when you upgrade to the new SI module and after an upgrade with source release 4.0B. RPU40AC0 accesses program RPU40BX_CH_SVLGARTS for table T512W. The program postpones the limit between coding for old and new SI in the validity interval of the affected wage types to the customer-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 type delivery for 4.0 and 4.5 (LGART='/*','M*','S*') undoes the postponement, as it were. If new SI was implemented in Release 3.1I, the start date is most certainly 01.01.2002. When the upgrade takes place, this is automatically recognized and corrected by wage type 'U31I'.

The start date for source release 4.0B, however, is 01.01.xxxx with xxxx from {1998,1999,2000,2001,2002}; it cannot be determined automatically. After an upgrade with source release < 4.5, the start date must therefore be maintained manually and report RPU40AC0 must be started.

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 above changes are made in all clients of table T000. If it is executed using report RPU40AC0, only the client in which RPU40AC0 is started is converted.

Clients without Swiss wage types are not changed, and the client is regarded as successfully processed.

Wage types used in Swiss social insurance calculations are only changed if they were reused after the 1998 revision of social insurance with different coding, or if they are SI wage types that are no longer used by the new social insurance module.
A complete list of these wage types in included in form routine INIT_MAIN.

Database commits take place client-by-client for clients in which at least one wage type can be changed successfully without errors occurring when the database is then changed. Even if it is not possible to convert all the wage types in a client, as many wage types as possible are converted. The log records these clients as "partially converted".
If a second run is performed, successfully changed wage types are not changed again. This means that the XPRA can be restarted.
Ideally, all three or four processing steps are performed for all wage types without errors, or no Swiss wage types are found in this client, which means that no conversion-relevant data exists. These clients are recorded in the log as "successfully processed".

When the XPRA runs in releases up to 4.6C, a backup of the affected wage types is created (before changes are made) in table T599U with the key [MANDT]DAT512CH999 or [MANDT]VER512CH999. In later releases, the backup is created by a version entry with the key [MANDT]VE512BCH999 in table T599U and data entries with application indicator 'C' in table T512B.

When the XPRA runs, changes are made to T512W, T599U, and T512B without a transport connection, and locks are set. If the XPRA is executed indirectly by starting report RPU40AC0, the latter deals with the locks/unlocks and transport connection.

Selection

Standard Variants

Output

A log is output. Errors are logged on level 2, and the conversion's success is logged for each client on level 3. There are five statuses:

  1. Successfully processed and changed
  2. Already in target status and not changed
  3. Only partially changed because of errors
  4. Not converted because of errors
  5. Not changed because no data relevant to conversion exists

Statuses 3 and 4 are errors. Statuses 1 and 3 indicate that changes have been made on the database.

Finally, the system displays summarizing messages about the number of successfully processed clients (that is, no errors occurred), partially converted clients (at least one, but not all wage types successfully converted and written to the database), and changed clients (changes were made on the database).

If this program is executed using report RPU40AC0, the start date, end date, and wage type of inserted and changed records are also output. Inserted records are flagged with '+' and deleted records with '-'. You may have to expand the log to see these messages. If the message "Client not converted because of errors" is displayed, any changes that have been logged are not effective.

Activities

Example






ROGBILLS - Synchronize billing plans   ROGBILLS - Synchronize billing plans  
This documentation is copyright by SAP AG.

Length: 14993 Date: 20240520 Time: 131402     sap01-206 ( 298 ms )