Ansicht
Dokumentation
RPIDEPBSVAVG_VLTSV_P10_MELDE - Determine Changes Regarding Reimbursement Acc. to Sec.10 VersStaatsV
ROGBILLS - Synchronize billing plans SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3upThis documentation is copyright by SAP AG.
Purpose
The report RPIDEPBSVAVG_VLTSV_P10_MELDE is used to create notifications from receiving public sector employers to ceding public sector employers in accordance with §10 of the German treaty on sharing of pension costs (Versorgungslastenteilungs-Staatsvertrag).
Note: Requirements
In accordance with §10 Para.2 VsorglastVteilStVtrG, the affected public sector employers have to report changes to circumstances that are relevant for reimbursement. The requirement dealt with here is the creation of statements with regard to changes by the receiving public sector employer (subsequently called PS employer B), such as discontinuation of a pension holder and inclusion of the associated surviving dependents, to be sent to the ceding public sector employer (subsequently called PS employer A).
The first approach we tried was to evaluate the payroll results in the same way as for the Evaluation of Pension Payment Reimbursements report (RPLEROD0). The differentiation here would be that the new report should not determine amounts but rather changes with regard to the existence of pension holders and their surviving dependents.
However, due to a technical restriction, we decided not to use a similar logic to process payroll results for changes with regard to the pension holder and their affected surviving dependents. Instead, we selected a completely new approach. With the evaluation of the payroll results, the assignment to the previous PS employer would be missing in the Work Relationships infotype (0845) as the key for the previous PS employer in the Provider field (P0845-TRGER) is two digits in length, and the key for the new Previous PS Employer field (P0845-DH_FRUEHER) in the central address management is eight digits in length. We deemed it inappropriate to enhance the Pension payroll structure with an eight-digit address key, particularly as we are talking about a change notification with regard to changes of the master data, which does not require payroll to be run for the personnel numbers.
In the end, we decided that the new report evaluates the master data and saves this data in corresponding new tables for tracking at a later point in time. These tables are explained in detail later on in this documentation, and are called: Administration Table for Reimbursements Sec.10 VersStaatsV (PAPBSDEVA_VLTSV2), Status History for Reimbursements Acc. to Sec.10 VersStaatsV (PAPBSDEVA_VLTSV3), and Reporting Data for Reimbursements Acc. to Sec.10 VersStaatsV (PAPBSDEVA_VLTSV4).
At the same time, we decided to separate the technical notification creation from the printing of the statements. This means that the evaluation of the master data and saving of the changed data to new database tables is separate from the printing of the notifications.
This notification report RPIDEPBSVAVG_VLTSV_P10_MELDE writes the data with the pension-relevant changes to tables, and the print report RPIDEPBSVAVG_VLTSV_P10_DRUCK prints the statements based on the notifications created by the notification report.
The Test Run checkbox is available on the selection screens of both reports. When the checkbox is selected, only a log is created and no changes are made to the database tables.
Integration
Prerequisites
Features
Creation of Notifications
The report RPIDEPBSVAVG_VLTSV_P10_MELDE creates the so-called notifications. A notification due to a change of reimbursement-relevant circumstances refers to a change of the master data that results in a statement with the changed data. The result of a notification is a notification table that displays the number of pension-relevant pension recipients for a pension holder for periods that are defined by 'Start Date' and 'End Date'. The notification data table consists of the columns: Start Date, End Date, No. of Holders, No. of Widows, No. of Half-Orphans, No. of Orphans.
The report can be started at any time. It compares the current dataset determined at the runtime of the report with the last reported dataset, or rather the status of the relevant master data saved the last time that the print report RPIDEPBSVAVG_VLTSV_P10_DRUCK was called (without test run). If there is a difference between the current data and the saved data, the new dataset is written with the current data. This is a new notification. This dataset is then used as a reference for the comparison the next time that the notification report RPIDEPBSVAVG_VLTSV_P10_MELDE is called. Due to this processing logic, the report can be started at any time and the changes do not necessarily have to be communicated on a yearly basis; instead, the change notifications can be created on a daily, weekly, or monthly basis or according to another schedule. The report does not have a "Reimbursement Year" parameter such as the one used by report RPLEROD0.
The notification report RPIDEPBSVAVG_VLTSV_P10_MELDE processes the personnel numbers of pension holders for surviving dependents' pension with regular reimbursement according to §10 VsorglastVteilStVtrG. The personnel numbers of surviving dependents are not to be included in the selection and they do not appear in the log under their own personnel numbers, but rather as the number of widows, half-orphans, and orphans for the relevant pension holders. The surviving dependents' data is imported and depicted by the system when processing the associated pension holders.
Example 1: Notifications for 2011
In this example, the notification report is started at the beginning of the year 2012 to create notifications for the year 2011. The example describes the case of a pension holder who died in June 2011 with three associated surviving dependents. The pension starts in July 2011 for the widow and the two half-orphans. At the end of November 2011, one of the half-orphans completed their education and the entitlement to orphan's pension ends.
This results in the following notification table as of January 1, 2011:
| Start Date | End Date | No. of Holders | No. of Widows | No. of Half-Orphans | No. of Orphans |
|---|---|---|---|---|---|
| 01.01.2011 | 30.06.2011 | 1 | 0 | 0 | 0 |
| 01.07.2011 | 30.11.2011 | 0 | 1 | 2 | 0 |
| 01.12.2011 | 31.12.9999 | 0 | 1 | 1 | 0 |
Depiction of the pension-relevant circumstances in tabular form as used in the log and in the statement
Example 2: Notification After Retroactive Change to Master Data
In the example, we change the case described previously. June 2011 was mistakenly entered as the month of the pension holder's death, but in fact it was July 2011. This error was only discovered after the notification for 2012 has already been sent and must now be corrected retroactively by changing the master data. When you run the notification report at the start of 2013 to create the notifications for the year 2012, this master data change for the year 2011 is also taken into account. Due to this change, when the report is run again, the end date for the pension of the pension holder is moved to July 31, 2011 and the start date for the surviving dependents is moved to August 1, 2011.
This results in the following notification table, whereby the differences to the status of the notifications for 2011 from example 1 are underlined:
| Start Date | End Date | No. of Holders | No. of Widows | No. of Half-Orphans | No. of Orphans |
|---|---|---|---|---|---|
| 01.01.2011 | 31.07.2011 | 1 | 0 | 0 | 0 |
| 01.08.2011 | 30.11.2011 | 0 | 1 | 2 | 0 |
| 01.12.2011 | 31.12.9999 | 0 | 1 | 1 | 0 |
Processing Logic of Report Based on Example 2
When the system compares the current data (after the retroactive change based on example 2) with the data previously reported in accordance with example 1, this results in a difference in the first line for the end date in the first period (from 01.01.2011-30.06.2011 to 01.01.2011-31.07.2011). In the table PAPBSDEVA_VLTSV4, the first entry with the start date 01.01.2011 ends on 30.06.2011. The current period determined by the report evaluation is from 01.01.2011 to 31.07.2011. This new data record with the changed end date and the subsequent periods as of 01.08.2011 for the surviving dependents are depicted in the statement. The changes to the old notification are underlined in the example above. The period 01.12.2011 to 31.12.9999 is communicated again, even if there are no changes for this period.
The term Notification
A notification contains the periods with the relevant number of pension holders and surviving dependents that exist since the last change. The notification starts with the period for which changes were made and contains all subsequent periods.
The notifications themselves are not changed; instead, new notifications with up-to-date contents are created.
The term Withdrawal
A withdrawal does not refer to an individual notification or an individual period; instead, it means the complete retraction of a reported reimbursement case for a previous Public Sector employer if this employer incorrectly received a notification for a pension case that did not involve the employer.
Note with regard to the technical implementation- The report runs on the logical database PNP. At the time of the event GET PERNR, the imported personnel number is processed. Personnel numbers that have infotype 0845 (Work Relationships) with the legal basis 'Regular Reimbursement Sec.10 VersStaatsV' are relevant. This means that only retired public sector employees or pension holders are considered.
Printing of Notifications
The print report RPIDEPBSVAVG_VLTSV_P10_DRUCK creates the statements with the change communications on the basis of the data written by this notification report RPIDEPBSVAVG_VLTSV_P10_MELDE. The change of the status is decisive here. The print report creates the statement. The log output of both reports shows the personnel numbers affected by the changes and the corresponding data. The depiction with periods and the corresponding number of relevant pension recipients is depicted similarly in the statement.
The print report groups together into one statement the changes for previous public sector employers that are assigned to a common accounting office based on the view Assign Accounting Offices to Public Sector Employer (V_T7DEPBSVLT0B). Likewise, individual personnel numbers with common previous public sector employers are grouped together in one statement. The data transferred to the statement can be depicted as follows with regard to their table structure. These are nested tables.
Example of the data transferred to the statement:
| Field | Short Description |
|---|---|
| DH_FRUEHER (Previous PS Employer) | PERSONEN_UND_MELDEDATEN |
| (List with entries of the structure: | |
| PERNR, NAME, GBDAT, reporting data table) | |
| PS Employer A | [(1001, name_A, 01.07.1940, [reporting data table_A]), |
| (1002, name_B, 01.08.1940, [reporting data table_B]), | |
| (1003, name_C, 01.09.1940, [reporting data table_C]) | |
| PS Employer B | [(1011, name_D, 01.07.1941, [reporting data table_D]), |
| (1012, name_E, 01.08.1942, [reporting data table_E]) |
The data contained in the reporting data tables (reporting data table_A, reporting data table_B, reporting data table_C, reporting data table_D, and reporting data table_E) looks like this:
| Start Date | End Date | No. of Holders | No. of Widows | No. of Half-Orphans | No. of Orphans |
|---|---|---|---|---|---|
| 01.01.2011 | 31.07.2011 | 1 | 0 | 0 | 0 |
| 01.08.2011 | 30.11.2011 | 0 | 1 | 2 | 0 |
| 01.12.2011 | 31.12.9999 | 0 | 1 | 1 | 0 |
Tables for Saving Data for Notifications
Three tables are delivered for saving the notification data: an Administration Table for Reimbursements Sec.10 VersStaatsV (PAPBSDEVA_VLTSV2), a table with the Status History for Reimbursements Acc. to Sec.10 VersStaatsV(PAPBSDEVA_VLTSV3), and a table with the Reporting Data for Reimbursements Acc. to Sec.10 VersStaatsV (PAPBSDEVA_VLTSV4). The entries in the individual tables can be uniquely identified by the system based on the GUIDs and the data that belongs together for a notification can then be linked in the three different tables using these GUIDs. The notification report RPIDEPBSVAVG_VLTSV_P10_MELDE writes entries with the status New. The print report RPIDEPBSVAVG_VLTSV_P10_DRUCK writes entries with the status Printed.
Administration Table: Administration Table for Reimbursements Sec.10 VersStaatsV (PAPBSDEVA_VLTSV2)
In the administration table, an entry with the last valid status is stored for a notification. In addition, this table is the only table to contain the personnel numbers, so this table provides access to a personnel number when evaluating the data.
The GUID is the key field of the table.
| Field | Short Description |
|---|---|
| GUID | Uniue key for identifying a notification |
| PERNR | Personnel number of the pension holder being processed |
| DH_FRUEHER | Address key of the previous public sector employer |
| STORNO_FRUEH_DH | Complete withdrawal of the case with the previous employer |
| STATUS | Status of notifications with regard to §10 VLTSV ('New', 'Printed') |
| MELDEZEITR_BEGDA | Start date of the change notifications according to §10 VersStaatsV |
The field MELDEZEITR_BEGDA contains the date as of which the periods from the table PAPBSDEVA_VLTSV4 are to be reported. All periods as of January 1, 2011 are contained in the table PAPBSDEVA_VLTSV4; therefore, the date as of which the periods are to be communicated is also saved here.
Example Data of the Administration Table
The administration table contains the following data, for example:
For the personnel numbers
1001 and 1002, a notification is contained in each case with the
GUID 0005 and the GUID 0024 respectively.
Both personnel numbers have the public sector employer A as their previous
employer. For the personnel number 1001, the notification already has the
status Printed, and the notification for personnel number 1002 has the status New.
| GUID | PERNR | DH_FRUEHER | STORNO_FRUEH_DH | STATUS | MELDEZEITR_BEGDA |
|---|---|---|---|---|---|
| 0005 | 1001 | PS Employer A | Printed | 01.01.2011 | |
| 0024 | 1002 | PS Employer A | New | 01.06.2012 |
If the notification report were to be started again for this dataset without preceding master data changes, then the old entry for GUID 0024 for the personnel number 1002 would be deleted and a new entry would be created with GUID 0031 and otherwise unchanged data.
| GUID | PERNR | DH_FRUEHER | STORNO_FRUEH_DH | STATUS | MELDEZEITR_BEGDA |
|---|---|---|---|---|---|
| 0005 | 1001 | PS Employer A | Printed | 01.01.2011 | |
| 0031 | 1002 | PS Employer A | New | 01.06.2012 |
Table for Status History: Status History for Reimbursements Acc. to Sec.10 VersStaatsV (PAPBSDEVA_VLTSV3)
The complete history for each notification is contained in the table for the status history. This includes the relevant status and the creation information such as the date, time, action (the report through which the entry was created), and user of the creation. The table is used to determine the GUID of the last printed notification. The corresponding data for this GUID is read from the reporting data table PAPBSDEVA_VLTSV4. Based on the comparison with the current data, new entries are created if necessary.
Key fields are GUID and SEQNR.
| Field | Short Description |
|---|---|
| GUID | Uniue key for identifying a notification |
| SEQNR | Sequential number for history with regard to §10 VersStaatsV |
| STATUS | Status of notifications with regard to §10 VLTSV |
| ERSTELL_DATUM | Date when table entry is created |
| ERSTELL_UHRZEIT | Time when table entry was created |
| ERSTELL_AKTION | Information about which action led to the creation of an entry |
| ERSTELL_USER | User Name |
The key field SEQNR contains a sequential number, starting with 1. The sequence number SEQNR is created by the system for a notification with the specified GUID when the status is changed.
Example Data of the Status History
The status table could appear as follows once the notification report and print report have run:
| GUID | SEQNR | STATUS | ERSTELL_DATUM | ERSTELL_UHRZEIT | ERSTELL_AKTION | ERSTELL_USER |
|---|---|---|---|---|---|---|
| 0005 | 001 | New | 16.01.2012 | 15:35:10 | Notification report | PAdm user |
| 0005 | 001 | Printed | 17.01.2012 | 09:05:15 | Print report | PAdm user |
| 0018 | 001 | New | 02.08.2012 | 14:12:33 | Notification report | PAdm user |
| 0019 | 001 | New | 02.08.2012 | 14:12:33 | Notification report | PAdm user |
For the notification with GUID 0005, the entry with the status New continues to exist here, in contrast to the administration table PAPBSDEVA_VLTSV2.
Table for Reporting Data: Reporting Data for Reimbursements Acc. to Sec.10 VersStaatsV (PAPBSDEVA_VLTSV4)
The table for reporting data contains the periods with the corresponding number of relevant pension recipients.
Key fields are GUID and ENDDA.
| Field | Short Description |
|---|---|
| GUID | Uniue key for identifying a notification |
| ENDDA | Valid to |
| BEGDA | Valid from |
| ANZ_URHEBER | No. of Holders |
| ANZ_WITWE | No. of Widows |
| ANZ_HALBWAISE | No. of Half-Orphans |
| ANZ_VOLLWAISE | No. of Orphans |
Processing Logic of Report in Detail
The reports RPIDEPBSVAVG_VLTSV_P10_MELDE and RPIDEPBSVAVG_VLTSV_P10_DRUCK are PNP reports. The selection is purely via the personnel number of the pension holder. The collection of data for the associated surviving dependents required for the evaluation does not occur in the system for the event GET PERNR, but rather by the explicit reading of the corresponding personnel numbers that refer to the corresponding pension holder in the Pension Payments infotype (0322). To do this, the report uses the method CL_HRDEPBSVAVG_VLTSV_TOOLS=>GET_INTERVALS_VERSEMPF_P10 that is used in the Reimbursements infotype (0846) to depict the periods with the corresponding number of pension holders, widows, half-orphans, and orphans. The system saves the dataset determined at the report runtime to the database tables PAPBSDEVA_VLTSV2, PAPBSDEVA_VLTSV3, and PAPBSDEVA_VLTSV4. Based on this table, differences can be determined at a later point in time and reported.
Process flow after the start of the notification report (even after repeated starts):
- The report builds a temporary work table for personnel numbers just processed with the current data as of January 1, 2011. This table is called TAB_AKTUELLE_DATEN. In doing so, the relevant surviving dependents are taken into consideration.
- The report determines the GUID that contains the last printed notification. The last reported dataset from the database table PAPBSDEVA_VLTSV4 is read for this GUID. This table is called TAB_VORHERIGE_DATEN. If this is the first time that the data is created, then this table is empty.
- Comparison of the two tables TAB_AKTUELLE_DATEN and TAB_VORHERIGE_DATEN
- If the tables are identical, the system does not create a notification for the affected personnel number.
- If the tables are not identical, the system writes new entries in the tables PAPBSDEVA_VLTSV2, PAPBSDEVA_VLTSV3, and PAPBSDEVA_VLTSV4 for the data of the table TAB_AKTUELLE_DATEN with a new GUID.
Special Feature: Change of Previous Public Sector Employer
Changing the previous public sector employer in the Work Relationships infotype (0845) results in special processing. In this case, the system creates a withdrawal notification for the public sector employer that was entered until now as the previous PS employer, subject to the condition that a notification was already printed. For a withdrawal notification, the field STORNO_FRUEH_DH is selected in the administration table. The reporting data table with the periods then remains empty. In addition, a notification is to be created for the previous public sector employer that is now entered, in the usual form with the periods as of January 1, 2011.
Example of a Withdrawal
The public sector employer C was incorrectly entered in the Work Relationships infotype (0845) as the previous employer. This error was only discovered after the report RPIDEPBSVAVG_VLTSV_P10_DRUCK had run and the statements had been created and sent. Once the master data is corrected by entering the public sector employer A and starting the notification report RPIDEPBSVAVG_VLTSV_P10_MELDE again, the administration table now appears like this:
| GUID | PERNR | DH_FRUEHER | STORNO_FRUEH_DH | STATUS | MELDEZEITR_BEGDA |
|---|---|---|---|---|---|
| 0005 | 1001 | PS Employer C | Printed | 01.01.2011 | |
| 0018 | 1001 | PS Employer C | X | New | 01.01.2011 |
| 0019 | 1001 | PS Employer A | New | 01.01.2011 |
The notification report writes a withdrawal entry for the employer C (GUID 0018) and an entry for communication to employer A (GUID 0019).
Customizing of the Tables for the Statement
The example statement is delivered in the table framework for the control of SAP Interactive Forms by Adobe and Smart Forms under the logical form name HR_DE_VLTSV_P10 (Change Notification for Reimbursements VLTSV Sec.10) in the group HR_DE_VAER (' Grouping PAdm and Reimbursements ').
You can activate your customer-specific form in Customizing by choosing Payroll: Germany -> Configure Form Control for Print Output -> Control Data for Output Categories and Form Names.
Printing the Statement Again as of a Specific Date
When you start to use the report, you can use the functions for repeating the printing of the statement that has already been printed and restricting the reporting data table to periods as of a specific key date. In this way, you can avoid printing statements with the reporting data as of January 1, 2011 for the entire dataset of reimbursement cases according to §10 VsorglastVteilStVtrG if you have already communicated the changes for the year 2011.
At the first runtime, the notification report fills the new datatables with the complete dataset because the new database tables are still empty and the complete current data is included in the notifications when compared with the empty dataset. If you have already created the change notifications for the year 2011 in another way without this report, you do not require the depictions of all reporting data as of January 1, 2011. To restrict the creation of statements and in order not to create statements with changes as of January 1, 2011 for the entire dataset, you can use the Repeat run parameter in the print report RPIDEPBSVAVG_VLTSV_P10_DRUCK and enter a date in the Reporting Start parameter for the repetition run to restrict the creation of statements, for example, to periods as of the key date January 1, 2012. In this way, only changes that occurred as of this Reporting Start date are actually printed in the statements.
Selection
Other Selections group box
- Previous PS Employer
The parameter Previous PS Employer is used to enter the ceding public sector employer to restrict the evaluation.
Evaluation Criteria group box
- Evaluation Date
The Evaluation Date parameter provides the date for reading the assignment of the payroll office and the addresses from the central address management. In addition, this date is used for the assignment of the company code and the employee subgroup, which are displayed in the log. This is not the entry of the date for the evaluation period with regard to the change notifications, like the Reimbursement Year parameter from the report RPLEROD0.
- Subapplication Reporting
The Subapplication Reporting parameter is used to specify the subapplication for Reporting. The default value is the subapplication VADM.
- Test run
The Test run parameter is used purely for the log output without making changes to the database tables.
Options group box
- Take Account of Company Code
The Take Account of Company Code parameter controls the sequence of the output in the log. If this checkbox is selected, the output occurs sorted according to company code.
- Include Employee Subgroup
The Include Employee Subgroup parameter controls the sequence of the output in the log. If this checkbox is selected, the output occurs sorted according to employee subgroup.
- Use Accounting Offices
The Use Accounting Offices parameter controls the sequence of the output in the log. This parameter does not have any effect on the creation of the statements. The statements to previous public sector employers that are assigned to an accounting office are grouped together independently of this parameter.
Standard Variants
Output
Log Output
You can use the PAL(Applikation Log) layout to configure the sorting in accordance with your requirements. However, this does not have any effect on the sequence used when creating the statements. Each personnel number is printed in the log with the periods and associated columns as the pension holder or with the number of surviving dependents as of the period in which changes occur.
Activities
Example
General Data in Customer Master General Material Data
This documentation is copyright by SAP AG.
Length: 38581 Date: 20240520 Time: 104241 sap01-206 ( 533 ms )
