The aim of this wiki is to outline some of the common problems surrounding program PRAA that is used to update master data vendor from HR to FI.
RPRAPA00 is a program that can be run as a scheduled batch job with variant to update HR master data vendor to process payment and update detail in FI (commonly transaction XK03 etc) or else directly by the transaction PRAA. The wiki page will also outline some of the more common issues that might occur during this process as due to the structure of the program, only specific data can be processed.
1. Infotypes included in the standard PRAA program:
In the standard functionality, only the following infoypes are automatically included as the structure BLFA1 has some limitations;
Actions (Infotype 0000)
Organizational Assignment (Infotype 0001)
Personal Data (Infotype 0002)
Permanent Residence (Infotype 0006 Subtype 1)
Bank Details (Infotype 0009 Subtype 0 or 2)
In relation to these infotypes, several points should be noted:
2. Communications Infotype 105 Subtype 001
By default, the commuciations infotype for address (Infotype 105, subtype 001) is NOT included, if this isrequired to be included, then you should look at note 570023 which outlines the possible BAdI implementations you can use in BADI_EXITS_RPRAPA00 and also note 407827 which provides the Interface SAMPLE_PROCESS_00002040 for this purpose.
3. Address Infotype 006 Subtype 001:
There are some technical limitations to the length of the address field within the strucure BLFA1 and these are filled as follows:
(General Vendor Master Record Part 1 (Batch Input)):
- STYPE Batch Input Interface Record Type
- TBNAM Table name
- ANRED Title
- NAME1 Name 1
- NAME2 Name 2
- NAME3 Name 3
- NAME4 Name 4
- SORTL Sort field
- STRAS House number and street
- PFACH P.O. Box
- ORT01 City
- PSTLZ Postal Code
- ORT02 District
- PSTL2 P.O. Box postal code
- LAND1 Country key
- REGIO Region (State, Province, County)
- SPRAS Language Acc. to ISO 639 (Batch Input Field)
Note 663350 is also provided for scenarios where you need to transfer more than 40 characters for the street address so this might be useful too. As PRAA used infotype 006 subtype 001 to transfer from HR to FI, problems can for example arise with the field street name (P0006-STRAS). If the street name has more than 40 characters this information can not be processed. The field stays blank in FI. This is a standard system behavior. as you can see from XK02, it indicates "Street/House number", therefore, house number should be put there. .
For the following situations, two empty routines are supplied in the includes RPRAPAEX and RPRAPAEX_001 which you can adapt to your requirements.
If the address editing in the vendor master record does not suit your requirements, it can also be changed. For this purpose you have the user exit routine 'set_address_by_user'.
In addition to this, the field house number (HOUSE_NUM1) is not part of the structure BLFA1 and therefore as you see cannot be used to fill the house number into
This can be overcome by using the the user exit e.g user exit set_address_by_user in include report RPRAPAEX.
This can be reached by entering transaction SE51, then MP000600 and screen 2000 (SE51 screenpainter) and then selecting the layout editor tab - see the examples below:
and to see the attributes:
One further point to remember though is that when the second part of the batch job is processed (job RFBIKR00) Any modification in PRAA might need also need to be adjusted, for example the field HOUSE_NUM1 if it is added, will then also be looked for during the update by RFBIKR00
This could be overcome by copying the standard program RPRAPA00 in another ZRRAPA00 or YPRAPA00 and modify source code to transport the desired infotype and then checking the BAdI provided BADI_EXITS_RPRAPA00 with method SET_VALUES_FOR_BLFA1 570023 with neccessary modification in custom RFBIKR00 program.
4.Transfer of Bank Data (Infotype 009 subtype 00 or subtype 02)
A common query can relate to whether both subtype 00 AND 02 can be transferred using PRAA to FI and this is covered in more detail in the KBA 1660957
In fact for RPRAPA00 it is designed that the program takes only ONE record of bank data. If the subtype 2 is maintained, then this will be taken otherwise the subtype 0.
This program should only give a help to create vendors. If there are special issues, this must be maintained manually or with modification but even with the use of the BAdI I mentioned but still considering the confines of even the BADI_EXITS_RPRAPA00, it is a technical constraint that only ONE bank account subtype can be processed at a time. .
When you enter the Date the infotype will read today/other date. When the infotype 0009 subtype 02 in this point of time is not filled then it will read the infotype 0009 subtype 00.
If you maintain subtpye 0 and 2, the subtype 2 is transported to FI so if you want to maintain more than 1 bank details on the vendor, you have to maintain the vendor master data direct in FI and cannot use the RPRAPA00 program.
5. LFB1-AKONT and Tax Code information:
Please note, as per the standard infotypes already mentioned, tax information infotype is not handled within RPRAPA00 or updated. What this also means that for vendor master.that If the reference vendor XXXXXX has no tax information as per table LFBW, then the vendor to be updated is made equal to the reference vendor and has no tax information as well.
570023 - User exits for the generation of vendors with
663350 - RPRAPA00: Street name with more than 40 characters
407827 - RFFO: mail payment advice notes
1660957- Program RPRAPA00 (PRAA) can only transfer one bank account for vendor.
1622514- Logical file name "FI_TV_RPRAPA00" does not exist.
1593603- Duplicate vendors created for single employee using RPRAPA00