HRMD IDOC modification - date fields in E1PITYP and E1Pnnnn lead to errors

It is caused by improper IDOC data, please refer to SAP Note 1795606 & 134085.

Below are main points of these 2 notes:

In general terms, when an iDoc is posted in UPDATE mode, for each infotype and subtype sent, the data existing in the target between E1PITYP-BEGDA and E1PITYP-ENDDA will be DELETED. Then, the data contained below in the corresponding E1Pnnnn segment(s) is INSERTED in the database (please note that idocs with INSERT mode do not behave like that: they will first delete the full object, and then will create it again from the data contained in the idoc, if that is possible).

The IDoc for HR master and organistion data is set up in a hierarchy such as the following example shows:
IDoc 0000000000100030 Current status: 64
     |__ Control record direction: Inbound sender: LS/  /AHRCLNT003
     |__ Data records total number: 000018
     |   |__ E1PLOGI segment: 000001 header for an HR object
     |      |__ E1PITYP segment: 000002  HR: HR: trasported
     |      |     |__ E1P0000 segment: 000003  HR: Infotyp 0000
     |      |__ E1PITYP segment: 000004  HR: HR: transported
     |      |     |__ E1P0001 segment: 000005  HR: Infotyp 0001
     |      |__ E1PITYP segment: 000006  HR: HR: transported
     |      |     |__ E1P0002 segment: 000007  HR: Infotyp 0002
     |      |__ E1PITYP segment: 000008  HR: HR: transported
     |      |     |__ E1P0006 segment: 000009  HR: Infotyp 0003
     |      |__ E1PITYP Segment: 000010  HR: HR: transported
     |      |     |__ E1P0006 segment: 000011  HR: Infotyp 0006
     |      |     |__ E1P0006 segment: 000012  HR: Infotyp 0006
     |      |     |__ E1P0006 segment: 000013  HR: Infotyp 0006
     |      |__ E1PITYP segment: 000014  HR: HR: transported
     |      |     |__ E1P0006 segment: 000015  HR: Infotyp 0006
     |      |__ E1PITYP segment: 000016  HR: HR: transported
     |            |__ E1P0009 segment: 000017  HR: Infotyp 0009
     |__ status records

For each object to be distributed (for example for each person or for each organizational unit), there is an E1PLOGI segment, which contains the key of the object (plan variant that must be active, object type (=P for a person) and Object ID = Personnel no.), a proof flag should remain empty and the type of operation (U for Update- and I for the Insert mode to be used, see documentation RHALEINI).

Under every E1PLOGI segment, an E1PITYP segment hangs for every infotype and subtype to be distributed for the object described in the E1PLOGI. This segment again contains the entire key (same one!) of the object (plan version, object type and object ID). It also contains the infotype and the subtype, for which the data in the E1Pnnnn segment (located below) follows, as well as starting and ending dates of the maximum change period.
The change period has the following significance: In the update mode the data records, which are complete between E1PITYP-BEGDA and E1PITYP-ENDDA, are deleted in the target system first for the entered Infotype/subtype. (Relationships are then deleted if they were created at an earler time via the distribution). Then the data records are created from the IDoc.
The low date (18000101) and high date (99991231) should be in the insert mode.
Several E1Pnnnn segments can hang for precisely the same infotype nnnn under an E1PITYP segment. 'nnnn' stands for the number of the infotype, which was reported in the previous E1PITYP segment. Data is stored this way for the infotype 0006, for example, in segments E1P0006, namely one for every address record (a person could have moved several times). (For a possible temporary residence, a new E1PITYP segment is needed because it deals with another subtype.) The E1Pnnnn segments are set up as follows: The personnel number, the infotype and the subtype must again contain the same values as in the respective E1PITYP segment. The other two obgligatory fields are the beginning and the end of the validity for the data in this segment, (which must not be identical to the period of validity in the E1PITYP segment). The fields follow (they are naturally different for every infotype) which are filled with the values in the corresponding infotype fields on the HR database.
Ultimately you are responsible for consistency of this data. SAP saves this data directly on the database without checking the single fields and consistency of the data records (time constraints check, writing change pointers, value check) because the consistency for an R/3 - R/3 lingage is of course ensured.
As of Release 4.6 another E1PORIG segment hangs if distributed organistion management is activated (flag ALE REPLI and/or ALE REPPA
in table T77S0) under each E1PLOGI. The IDoc hierarchy then looks as follows:

IDoc 0000000000100030 current status: 64     |__ Control record direction: Inbound sender: LS/  /AHRCLNT003
    |__ Data records total number: 000017
    |   |__ E1PLOGI segment: 000001  header for an HR object
    |      |__ E1PORIG segment: 000002  HR: Original system for
    |      |__ E1PITYP segment: 000003  HR: HR: tranported
    |      |     |__ E1P0000 segment: 000004  HR: Infotyp 0000
    |      |__ E1PITYP segment: 000005  HR: HR: transported
    |      |     |__ E1P0001 segment: 000006  HR: Infotyp 0001
    |      |__ E1PITYP segment: 000007  HR: HR: transported
    |      |     |__ E1P0002 segment: 000008  HR: Infotyp 0002
    |      |__ E1PITYP segment: 000009  HR: HR: transported
    |      |     |__ E1P0003 segment: 000010  HR: Infotyp 0003
    |      |__ E1PITYP segment: 000011  HR: HR: transported
    |      |     |__ E1P0006 segment: 000012  HR: Infotyp 0006
    |      |     |__ E1P0006 segment: 000013  HR: Infotyp 0006
    |      |     |__ E1P0006 Segment: 000014  HR: Infotyp 0006
    |      |__ E1PITYP segment: 000015  HR: HR: transported
    |      |     |__ E1P0006 segment: 000016  HR: Infotyp 0006
    |      |__ E1PITYP segment: 000017  HR: HR: transported
    |            |__ E1P0009 segment: 000018  HR: Infotyp 0009
    |__ status records

The E1PORIG segment again contains the key of the object (plan variant, object type, object ID), as well as the start and end date of the period when it is valid in the original system, the other user and the original system containing the maintenance authorization for the object.