Prob wth Extending HRMD_A06 basic type

Question

Hi All,
I have some custom fields in PA0002 table. So i extended HRMD_A06 and in user-exits i am populating custom fields. Out bound side everything is OK. But it is giving 51 error in inbound side. Probelm with read_namtb subroutine. it is chking the custom segment in T777D table...
I am unable to solve the problem. Can anyone hlp me in this regard.

Answer 1

May be this helps you !!
<b>
FYI</b>
<b>Symptom</b>The standard scenario for the distribution of HR master data and organizational data via message type HRMD_A only covers a limited number of infotypes.
Additional standard infotypes should be distributed using a customer enhancement.
Other terms
PFAL, RHALEINI, HRMD_A
Reason and Prerequisites
In the standard scenario, only infotypes are distributed, which are required for a distributed HR in a non HR-system.
Solution
The following activities are required if standard infotype Pnnnn (with nnnn = infotype number) is to be distributed in addition.
Consider the restrictions at the end of this note in particular!
Release 3.1
1. Source code corrections:
According to the attachment (programs not contained in the standard system), repairs are necessary in the Includes LRHA2U06 and UP50RU01.
You only have to change Include UP50RU01 if it is a PA infotype.
If you also want to distribute infotypes starting with 2nnn or 9nnn, an additional repair in Include LRHALF01 is necessary. Remember that in this case the Infotype 2011 is stored differently than the other infotypes and cannot therefore be distributed.
Note that these changes are not contained in the standard system.
2. Customizing:
Transaction WE31 for Z1Pnnnn (in the sending system and the receiving system):
For each additional infotype, create a new segment type Z1Pnnnn (with nnnn = infotype number).
Transaction SM30 for table T777D only for PD infotypes (in the sending system and the receiving system):
For the entry infotype nnnn, enter Z1Pnnnn in field IDOC segment.
Transaction WE30 for ZRMD_A01 (in the sending system and the receiving system):
With Transaction WE30, create extension ZRMD_A01.
Create E1PITYP as a reference segment type, as child segments of this, the extension segment types Z1Pnnnn. As an IDoc type, create ZRMD_A01 for the basic IDoc type HRMD_A01 and extension ZRMD_A01.
Transaction WE82 (in the sending system and the receiving system):
The entry for message type HRMD_A and basic IDoc type HRMD_A01 is copied to a new entry with the extension ZRMD_A01.
Transaction WE20 (in the sending system):
In the sending system, for the partner number of the receiving system in the outbound parameters, enter ZRMD_A01 as idoc type in the line for entry message type HRMD_A.
Transaction WE57 (in the receiving system):
Copy the entry for function module name IDOC_INPUT_HRMD, basic IDoc type HRMD_A01 and message type HRMD_A, and enter ZRMD_A01 in the field extension.
As of Release 4.0B
1. Source code corrections:
Implement the attached advance corrections or:
Apply Hot Package for 4.0B:   SAPKH40B02 or
Legal Change Patch for 4.0B:  SAPKE40B02
The Include UP50RU01 must only be changed if it is a PA infotype.
Include UP50RU01 is not contained in the Hot Package and must be changed in accordance with the advance correction if the Legal Change Patch is not applied.
After applying the Hot Package (and manually repairing the UP50RU01) or the Legal Change Patch, only the Customizing activities are necessary.
2. Customizing
Transaction WE31 for Z1Pnnnn (in the sending system and the receiving system) :
For each additional infotype, create a new segment type Z1Pnnnn (with nnnn = infotype number). The function "Create by copying" can be used to reduce the work load.
Transaction SM30 for table T777D (in the sending system and the receiving system):
For entry infotype nnnn, enter Z1Pnnnn in field IDOC segment.
Transaction WE30 for ZRMD_A02 (in the sending system and the receiving system):
With Transaction WE30, recreate extension ZRMD_A02.
The linked basic type is HRMD_A02. Insert the new Z1Pnnnn segments as child segments of E1PITYP.
Transaction WE82 (in the sending system and the receiving system):
Copy the entry for message type HRMD_A and basic type HRMD_A02 to a new entry with extension type ZRMD_A02.
Transaction WE20 (in the sending system):
In the sending system enter ZRMD_A02 as an 'Extension' for the partner number of the receiving system in the outbound parameters in the entry message type HRMD_A with basic type HRMD_A02.
Transaction WE57 (in the receiving system):
Copy the entry for the FM name IDOC_INPUT_HRMD, basic type HRMD_A02 and message type HRMD_A, and in field 'Extension' enter ZRMD_A02.
As of Release 4.5A
Here, the Customizing activities described in Release 4.0B are to be carried out.
As of Release 4.5A, HRMD_A03 is used as the basic type and ZRMD_A03 is used as the extension type.
As of Release 4.6A, HRMD_A04 is used as a basic type and ZRMD_A04 is used as an extension type.
As of Release 4.6C, HRMD_A05 is used as a basic type and ZRMD_A05 is used as an extension type.
As of Release 4.70, HRMD_A06 is used as a basic type and ZRMD_A06 is used as an extension type.
Restrictions:
SAP cannot offer any support concerning compatibility with different releases for the additional infotypes of the enhancement in the standard system. For release specific changes to the infotypes of the enhancement a client-specific solution must be found (project solution).
Other known restrictions:
Known restrictions are listed here with possible solution approaches. If you should discover a restriction that is not yet documented, you can inform us of this via the R/3 SAPNet Frontend with a low priority problem message.
01/25/1999: PA infotypes with subtypes are not found in T591A
For infotypes in personnel administration, whose subtypes are stored in a different table than T591A according to table T582A, distribution works in the transfer mode 'Insert' and using the change pointers. Distribution in the transfer mode 'Update' does not work. The approach to solve the problem is a customer-specific extension of the routine HR_INFTY_GET in program RHALEINI by the corresponding infotype/subtype combinations.
02/01/1999: Workflow infotypes
Workflow infotypes, thus in the area 12xx, are not supported since the object type workflow is not supported in the standard ALE scenario. The approach to solve the problem is the use of the manual transport connection (RHMOVE30).
05/17/1999: Infotype 2011
The Infotype 2011 is stored differently than the other infotypes and therefore cannot be distributed.
11/09/2000: Segment for infotypes with a width of more than 1000 characters
The maximum width of a segment is 1000 characters. For this reason it cannot be generated automatically for infotypes with a width of more than 1000 characters.
A possible solution is to create the segment manually and to only insert the key fields and the application fields that are really needed in the segment in order to avoid exceeding the 1000 characters. The values of the fields are transported from infotype into the segment and vice versa in the case of infotypes that are distributed additionally. The reason is that the fields have the same names in segment and infotype.
07/17/2002: In ALE inbound processing, only the data records of the infotypes are posted - similar to the infotypes to be distributed in the standard. No additional functions regarding possibly dependent or derived data in other (database) tables are executed. A solution approach is to distribute the dependent or derived data in a separate (customer) scenario or implement a customer exit (RHALE001) or a BADI (HRALE00INBOUND_IDOC) with the desired functionality.
<b></b>