Up until now, infotypes for Personnel Administration were stored in the
table PREL and infotypes for Recruitment were stored in the table PAPL.
As of release 3.0, each infotype will have its own table. The following naming
conventions apply:
At the same time, the matchcode objects PREM for HR master data and PAPM
for applicant master data will be replaced by transparent matchcodes.
The matchcode records will no longer be stored in a pool table within the SAP
system, but will instead be defined in the corresponding infotype table - this
will be done using database indexes.
The conversion of the standard infotypes will take place automatically
during the change in release using program RPU3XPRA.
Please read the program documentation
Automatic Start of PREL and PAPL Conversion and
Convert
PREL and PAPL into Transparent Tables .
The conversion of customer-specific infotypes will not be carried out
immediately. Different preparations have to be made in the data
dictionary.
In addition read
Creating
a transparent table for an infotype .
Then start program RPU30000 to convert customer-specific infotypes.
Converting to transparent tables does not affect the programs that are used by the logical database PNP. This also has no affect on the module pools for customer-specific infotypes.
Only the programs that used to be read directly from the tables PREL or PAPL using 'SELECT' need to be converted. Please make sure that these programs are only help programs, as they are overlooked by every authorization check.
When you convert matchcodes, customer-specific matchcodes are lost. Read the section Maintain matchcodes in the implementation guide for information on how to recreate matchcodes.
If you have programs that have access to the standard SAP matchcodes, you may have to adapt these. The key fields SUBTY, BEGDA, ENDDA etc now have the suffix '_nnnn' (infotype), i.e. BEGDA_0001, ENDDA_0001 etc.
All of the entries in the table for
infotype characteristics have been transported. If you have made any changes within the SAP name range, they have been overwritten and must be maintained manually.
Converting to transparent tables does not affect the user.
Converting to transparent matchcodes has far-reaching consequences:
In matchcode 'K', most of the fields for the infotype Organizational
Assignment are available. It is also possible to use this to search for the
current (i.e. most up-to-date) last name and first name of an employee.
If you only have the employee's last name and first name and no other data
from their organizational assignment, you should use matchcode 'N' for
performance reasons.
When you are choosing the search procedure (i.e the matchcode ID) only the
matchcodes IDs relevant to that environment will be offered.
When you are maintaining HR master data, you will only be offered matchcodes
'K' (Organizational Assignment), and 'N' (Last name - first name) and all the
customer-specific matchcodes.
The experienced user can also access a matchcode by entering a specific matchcode ID, for example, by entering '=G', the matchcode for date of birth is called up.
Im Reporting more matchcode IDs are available, like matchcode 'G' for date of birth or 'M' for dates, for example.