You can change the start date and end dates for objects in Organizational Management (OM) directly from the PP01, PP02, PPOME, or POxx screens for most infotypes, with the exception of infotype 1000. To change the start and end dates for infotype 1000, you need to execute one of two available reports. One changes the start date and the other changes the end date. You can also use these reports to change the start and end dates for all other infotypes of objects in OM. Some of the key features of these reports are not well documented, and many users are unaware of their existence.

Note
Although you can change start and end dates for infotypes (with the exception of infotype 1000) using transaction codes PP02, PPOME, or POxx, I prefer using transaction code PP01. It provides a single screen from which you can edit any OM object type. POxx transaction codes have been defined to modify a specific object type. Table 1 shows some of the transaction codes in the POxx series.

Table 1

Transaction codes for editing infotypes

 

You use transaction code RE_RHBEGDA0 to change the start date of an object and transaction code RE_RHGRENZ4 to change the end date (Table 2).

Tabel 2

Programs and transactions

Changing the Start Date

Once you execute report RE_RHBEGDA0 many fields are available for selection (Figure 1):

• Evaluation path: Enter the evaluation path for the selection of objects for which the start date needs to be changed in the Evaluation Path field. If this field is blank, then the system modifies all the related objects for the selected objects.
• Status vector: Enter the status of those objects (such as Active, Planned, or Submitted) that have to be modified. When this value is blank, the system uses the default value, which is 1 (Active Objects).
• Display depth: The depth to which the system displays the related objects (for which the start date is being modified) on the screen. If this value is blank, then the system displays all the related objects.
• Infotypes: You must enter the infotypes that need to be modified. If blank, then all the infotypes for the selected object are modified.
• Subtypes: Enter the subtypes for the infotypes that need to be modified. If blank, the system modifies all the subtypes for the selected object or infotype.
• Old start date: This is the current start date of the object for which you are changing the start date. If the date entered is not the start date of the object, then the object is not processed. (For example, if you are trying to modify the start date of a position whose current start date is Jan. 1, 2010, but you enter Jan. 2, 2010, then the position is not processed.) If no value is entered, then the system uses the current system date as the old start date.
• New start date: Enter the new start date for the object. If no value is entered, then the system takes the current system date.
• Lock objects: If this option is selected, then the system locks the selected objects so that during the processing, no other user is able to modify the object
• Display changed records: The system displays the list of all affected records. If this is not selected, then the system just displays the number of records modified.
• Test run: Checking this option executes the report in test mode and the database is not updated. If not selected, the database is updated.

Figure 1

Selection fields for report RE_RHBEGDA0 (change start date report)

Changing the End Date

Apart from the selection fields discussed above these additional fields are available in report RE_RHGRENZ4 (Figure 2):

• Historical record 
• Delete records with start date after delimit date
• Change/delete subsequent records in case of time constraints

Figure 2

Selection fields for report RE_RHBEGDA0 (change start date report)

Historical Record

Records marked as historical in this check box cannot be displayed or edited through transaction code PP01. However, they can be reported. If a record was previously marked as historical, when the report is executed without the check box marked, then the historical mark is reversed.

Delete Records with Start Date after Delimit Date

When this box is checked, all the records whose start date falls after the new end date (delimit date) are deleted. If this option is not selected, then these records are unaffected. For example, position 50010700, which has a start date of January 1, 2010, and an end date of December 31, 9999, has two infotypes. One is infotype 1007 (vacancy), which has a start date of January 1, 2011 (Figure 3). Another is infotype 1008 (account assignment), which has a start date of January 1, 2012 (Figure 4).

Figure 3

Vacancy infotype

Figure 4

Account assignment infotype

If you try to change the end date of this position, with the new end date being December 31, 2010 (old end date was December 31, 9999), you have two scenarios:

Scenario 1: If the Delete records with start date after delimit date check box is not checked, then there is no impact on the vacancy and account assignment infotypes. They continue to exist and the position end date is changed to December 31, 2010. Figure 5 is the output of the report. For infotypes 1007 and 1008, there is no change in dates. Since the start dates of these two infotypes are after the new end date, they are unaffected.

Figure 5

Report run with the flag not checked

However, this does not present correct data, as the position exists from January 1, 2010, to December 31, 2010. The infotypes for this position exist from January 1, 2011, and January 1, 2010. You should not use this option in a live client. It has the ability to create invalid data situations such as the one mentioned here. Scenario 2 is the correct use of this check box.

Scenario 2: When the flag is checked and the report executed, the system deletes the records with a start date after the new end date. In the above example, the vacancy and account assignment records are deleted as their start date is after the new end date. (The new end date is December 31, 2010.) Figure 6 shows the output of the report.

Figure 6

Report output with the flag checked and notation Record Deleted in the Result column

Change/Delete Subsequent Records in Case of Time Constraints

This option checks for the time constraint and then based on that it takes an action, either deleting the records or changing the start dates of the other records. For example, infotype 1027 (site dependent) has a time constraint of 1 (Figure 7). Time constraint 1 allows for a maximum of one infotype record of the same type for the same object at the same time, without any gaps.

Figure 7

Site-dependent infotype

Figure 7 shows two records. The first is from January 1, 2011, to December 31, 9999. The second is from January 1, 2010, to December 31, 2010. There are no gaps between these two records. If I try to change the end date for the second record from December 31, 2010, to December 1, 2010, then what would happen? Again there are two scenarios:

With the flag not checked: When the flag is not checked and the report is executed, the output would be similar to Figure 8. The end date of the record is changed from December 31, 2010, to December 1, 2010.

Figure 8

Output of the report with flag not selected

Now let’s take a look at the infotype record. In the infotype record in Figure 9, you see a gap between the two records (i.e., there is no data for the period from December 2, 2010, to December 31, 2010). This is because I changed the end date from December 31, 2010, to December 1, 2010. Because the infotype time constraint is 1 there should not be any gaps. This type of data may lead to many inconsistencies such as incorrect reporting.

Figure 9

Infotype record after the execution of the report

With the flag checked: If you execute the same report with the flag checked, the output of the report looks what you see in Figure 10.

Figure 10

Report output with the check box Change/delete subsequent records in case of time constraints

The system has changed the end date of the first record and the start date of second record so there are no gaps between the records and the infotype is in line with its time constraint value (Figure 11). Now there are no gaps. The system also modified the start date of the second record.

Figure 11

Infotype record after the execution of the report

Impact of Changing the Start and End Dates

Changing the start and end dates is not as simple as it looks because they have a cascading effect in other modules.

Impact on Personnel Administration and Payroll

The following example shows the impact of change in the start dates on PA and payroll. Position 20012922 has a begin date of January 1, 2010, and an end date of December 31, 9999. An employee was assigned to this position and the employee date of joining is January 1, 2010. A relationship of A008 is created for the position in OM and the position details are also displayed in the Org Assignment infotype. If this position start date is changed from January 1, 2010, to February 1, 2010, then what would the effect be? There are two scenarios, and this depends on the switch PLOGI ORGA.

Switch PLOGI ORGA defines the integration between OM and PA. If the integration switch is active, then if any OM object is changed that is relevant in infotype 0001, these changes are transferred to infotype 0001 and are also reflected in infotype 0001. Similarly, if any OM object is changed in infotype 0001, then these changes are transferred to OM.

Scenario 1: PLOGI ORGA Switch Is Active

When the start date of the position is changed to February 1, 2010, that implies the position ceases to exist for the period of January 1, 2010, to January 31, 2010. In infotype 0001, there is a split and two records are created. Prior to the change in the position start date, there was a single record in infotype 0001 for the period of January 1, 2010, to December 12, 9999 (Figure 12). After the position start date is changed, infotype 0001 has two records (Figure 13).

Figure 12

Organizational assignment infotype overview with the actual position

Figure 13

Organizational assignment infotype overview after the change in start date

One record has dates of January 1, 2010, to January 31, 2010, and the other record is from February 1, 2010, to December 31, 9999. For the first record the position is 999999, which is the default position as per switch PLOGI-PRELI. During this period the previously assigned position does not exist as the object start date was changed (Figure 14). For the second record, there is assignment of both the position and the cost center (Figure 15).

Figure 14

Infotype 0001 record with the default position after the change in the start date of the position

Figure 15

Infotype 0001 record with the second record, which has the position assigned

Because of this split, the employee is marked for a retroactive payroll run, if the payroll has already been run. After the retro payroll run, during posting there are errors in the posting document. This is because there was no cost center assignment for the first record, and a cost assignment existed during the original payroll run. The same error that occurred during payroll posting in the retro run due to missing cost center, would also occur in the regular run.

When a default position is assigned, then the cost center field in infotype 0001 would be blank. (Figure 14). Having a blank cost center can result in errors during payroll posting if a substitute cost center is not maintained.

The default position can also cause errors in workflow. For example, say the position whose start date was changed is a manager position with many people reporting to it. When any wrong start date is given to this position, then all the workflows triggered before the new start date would result in errors, because the approver (manager) position is no longer available before the new start date.

Instead of changing the start date from January 1, 2010, to February 1, 2010, if you change the end date to November 31, 2010, then there will be a split in infotype 0001, with two records created.

One record would have a start date of January 1, 2010, and an end date of November 31, 2010. The second record would have a start date of December 1, 2010, and an end date of December 31, 9999. For the second record the position is defaulted and the cost center would be blank. When the posting is run for this period, it results in errors as there is no cost center assignment.

Scenario 2: PLOGI ORGA Switch Is Inactive

When the start date of the position is changed, then only the dates for OM objects in OM are changed and there are no changes in infotype 0001 (i.e., there are no splits in infotype 0001, unlike in the previous case). No retroactive calculations are triggered. The next time payroll is run, only the February payroll runs. The posting also happens for the month of February.

This results in data inconsistency. Because of the records from OM, the position exists from February 1, 2010, and the cost center to the position also was assigned from February 1, 2010. Per the record from infotype 0001, the position is assigned to the employee from January 1, 2010, and the cost center is assigned to the employee from January 1, 2010. However, the actual assignment was from February 1, 2010.

Impact of Changing Start and End Dates on Other Organizational Objects

Each object in OM is related to many infotypes, and in addition, one OM object can be related or linked to other OM objects. Therefore, changing the start and end dates of an OM object has an impact on other OM objects, and also on the infotypes created for that object.

Changing the Start Date of Infotypes Other Than Infotype 1000

If you are changing the start date of a specific infotype (but not 1000), then only that infotype start date is changed, and it does not affect any other objects or infotypes. However, you cannot change the start date of those infotypes beyond the start date of infotype 1000 or beyond the start date of the related object (in the case of infotype 1001).

In Figure 16, I tried to change the start date of relationship 1001-A003 from January 1, 2010, to December 1, 2009, for position 20012945. The start date of position 20012945 was January 1, 2010, and the start date of the related object was also January 1, 2010. (For the relationship 1001-A003, the related object is O with Object ID 10002077.) 

If you observe the result, the start date was not changed because the related object (the organizational unit) did not exist on December 1, 2009. Therefore, the new start date would be the start date of the related object. (The system therefore gave the result as New Strtdate = StrtDate of related object, which is January 1, 2010.)

Figure 16

Changing the start date of a relationship, when the start date of a related object is earlier than the new start date

Changing the Start Date of Infotype 1000

If you change the start date of an object (infotype 1000), it has a cascading effect on the related infotypes. When the object infotype start date is changed, then all the related infotype start dates are changed, with the exception of infotype 1001.

For various subtypes of the relationship infotype (1001), changing the start date also depends on the start date of the related objects. You can only change the start date if the related object exists in the new start date. Otherwise, the start date is changed to the start date of the related object (Figure 17). When the position start date is changed from January 1, 2010, to December 1, 2009, the object infotype date and all other infotypes dates (except infotype 1001, subtypes A003 and A012) were changed to December 1, 2009. For infotype 1001, the date was changed to December 10, 2009. This is because the related object start date is December 10, 2009. (For both the subtypes of infotypes 1001, the related object was same.)

Figure 17

Impact of changing the start date of infotype 1000

Similarly when the end date of the object is changed (infotype 1000), then all the related infotypes, including infotype 1001 and their subtypes dates, are changed and the records are delimited with the new end date.

Vamsi Mohan

Vamsi Mohan works as an SAP ERP HCM consultant. He has been working in SAP ERP HCM for the past seven years in various assignments. Vamsi has rich experience in time management, payroll, LSO, ESS, and has been part of many implementations. Prior to joining Accenture, he was associated with TCS, IBM, and Dell. Vamsi has a master’s degree in business administration.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.