Logical Database: Database Program

PURPOSE
The PNPCE logical database supports the evaluation of HR master data. It includes the
functions of the PNP logical database and offers additional evaluation options. Therefore,
you should use the PNPCE logical database instead of the PNP logical database for all
new developments.
The enhanced functionality of PNPCE in comparison to PNP essentially concerns the
evaluation of Concurrent Employment, that is, the possibility to group evaluate several
assignments/personnel numbers of a person. The new events 'GET PERSON' and 'GET
GROUP' as well as an enhanced syntax for the INFOTYPES statement (addition AS
PERSON TABLE) for the procurement of infotype data enable you to use the new
functionality. The use of these new functions is optional. You can run a PNPCE report
that does not use the new events and the addition for the INFOTYPES statement in a
PNP-compatible session. Since the PNPCE also has an improved selection screen, each
report benefits from this even if the report does not use the functions for evaluating
Concurrent Employment.
PREREQUISITES
A report that wants to use the PNPCE must enter this in its report attributes under Logical
database.
In addition, the PERNR structure must be declared in the report using the 'TABLES
PERNR' statement. You can only use the PERNR structure again in certain
circumstances. The use of the 'GET PERNR' event is therefore forbidden. Instead, use the
'GET PERAS' event. Except for the PERNR-PERNR component, all other components of
the PERNR structure are no longer filled and have initial values. This kind of
programming (with the exception of PERNR-PERNR) is therefore not permitted.
In addition to the 'GET PERAS' event, you can also use the 'GET PERSON' and 'GET
GROUP' events. To be able to use these events, you must declare them using the NODES
statement ('NODES PERSON', 'NODES GROUP', or 'NODES PERAS').
Explanation of Terms
If the 'GET PERSON' and 'GET GROUP' events and the 'AS PERSON TABLE' addition
for the INFOTYPES statement are not used, the report indicates that it does not require
the functionality for evaluating Concurrent Employment. In this case, the report runs in a
PNP-compatible session. This is referred to as PNP mode in the following
documentation. On the other hand, if the report uses the functionality for evaluating
Concurrent Employment we refer to CE mode.
FEATURES
Process of an Evaluation
The PNPCE selection screen offers you as standard a range of functions that you can use
to restrict the personnel number and person selection. These are discussed in more detail
in the following sections. The process is initially as follows regardless of whether the
report runs in CE or PNP mode. All available functions and selection conditions leads to

the selection of personnel numbers. If you use the sorting function, this set of personnel
numbers is then sorted according to the sort criteria you selected. In PNP mode, the GET
PERAS event is triggered as a result for each personnel number.
In CE mode, the persons belonging to the personnel numbers are determined first for all
personnel numbers selected. The GET PERSON event is then triggered for each person.
The person ID is specified in the OBJID component of the PERSON structure.
PERNR_NUM contains the total number of personnel assignments (= personnel
numbers) that this person has and the ALL_PERNRS table, which contains a list of these
personnel numbers regardless of whether they were actually selected or not. The
SELECTED flag is set to X for the personnel numbers selected. The flag is initial for all
personnel numbers that are not selected. The PROCESS flag specifies whether the
personnel number should be processed in the rest of the process. This flag is set to X by
default for the personnel numbers selected. However, the report can set or delete this flag
at the GET PERSON event for all personnel numbers. In this way, report and logical
database communicate with each other which enables the report to control the rest of the
process.
The number of personnel numbers that belong to this group and that are processed
subsequently is in PERNR_NUM. The included ALL_PERNR table contains a list of
these personnel numbers with additional information. The SELECTED flag specifies
whether the current personnel number was originally selected (flag is set) or was marked
by the report as to be processed.
Sort Order
You can sort the list of selected personnel numbers using the Sort function in the
application toolbar. You can choose to include up to seven fields from infotype 0001 for
the sort. Since several data records can exist for infotype 0001 for a personnel number,
you also need to specify for period evaluations (not the case for key date evaluations)
whether the sort should take place according to the values of the last or of the first data
record in the person selection period.
In PNP mode, the sorted sequence determines exactly the sequence in which the GET
PERAS event is called. In CE mode, the sort determines the sequence in which the GET
PERSON event is called. The list of persons is created based on the (sorted) sequence of
personnel numbers.
Retrieving Infotype Data Records
As well as triggering the GET PERSON and GET PERAS events, the logical database
also provides the data records of the infotypes that are requested using the INFOTYPES
statement. In the report, you must specify the INFOTYPES statements where the variable
declarations are made. You should do this in any case before the first code is entered.
In principle, there are three types of INFOTYPES statements:
INFOTYPES nnnn
The nnnn infotype is provided with the data records of the current personnel number at
the GET PERAS event. Only the data records that are in the evaluation period specified
in the selection screen are provided ( this is different to PNP, which provides all data
records by default).

INFOTYPES nnnn AS PERSON TABLE

The nnnn infotype is provided at the GET GROUP event with the data records of all
personnel numbers that are in the included ALL_PERNRS table (of the GROUP
structure) and for which authorization exists (NO_AUTHORITY flag is not set). Only the
data records that are in the evaluation period specified in the selection screen are
provided. Alternatively, the report can specify which data records are to be provided
using the RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and
RP_SET_DATA_INTERVAL_ALL macros.
INFOTYPES nnnn AS PERSON TABLE MODE P
The nnnn infotype is provided at the GET PERSON event with the data records of all
personnel numbers that are in the included ALL_PERNRS table (of the PERSON
structure). No authorization check is performed and all existing data records are provided
independent of how the evaluation period is defined in the selection screen. The use of
the RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and
RP_SET_DATA_INTERVAL_AL macros also has no influence here.
Selection Options
You can use all the functions and selection options in the selection screen (initially) to
select personnel numbers regardless of whether the report is running in PNP or CE mode.
Only in CE mode, the persons belonging to these personnel numbers are then determined.
The functions that PNPCE provides to restrict the selection are described in the
following. The environment in which these functions are actually used depends on the
report and its report category. You can assign a report category to a report in maintenance
of report attributes (SE38, Attributes, Change button -> HR report category button). The
customer can override this assignment. To do so, perform the Assign Report Categories
Customizing activity under 'Personnel Management' -> 'Human Resources Information
System' -> 'Reporting' -> 'Adjusting the Standard Selection Screen'. Follow the same path
to define and change report categories in the Create Report Categories Customizing
activity. Since the PNP logical database also uses the concept of report categories, ensure
that you assign only one report category that is created specially for the PNPCE database
to a PNPCE report.
Selection Fields of the 0000 and 0001 Infotypes
You can use all the standard fields of the 0000 and 0001 infotypes for selection. You can
also use additional selection fields that are the concatenation of two or more of these
infotype fields. If possible, do not use these concatenated fields because they do not play
a significant role in the selection and can lead to long runtimes in certain circumstances.
You can show and hide the required selection fields using the Selection Fields function in
the application toolbar. The report category defines a preselection of fields that should be
available.
Dynamic Selections
The dynamic selections enable you to select according to any infotype fields and, in
particular, according to customer-specific infotype fields. You can show and hide the
dynamic selections using the Dynamic Selections function in the application toolbar. The
report category controls whether this appears as a dialog box or inplace, that is whether
the dynamic selections are supported at all. The basis for the dynamic selections is a
selection view that defines which infotypes and which fields can be used for selection.

You can define the selection view in the ABAP Workbench. You must choose For any
table as the type of selection view (the For logical database type is not permitted although
you may have presumed differently at first). The report category is used to control which
selection view is used for the dynamic selections. If you use the dynamic selections, the
Restrict by OrgStructure, Search Help, and Selection ID functions are not available.
Restrict by OrgStructure
You can also select personnel numbers by their position in the organizational structure.
To do so, you use the OrgStructure function in the application toolbar. This button
displays the organizational structure. Here you can select the organizational units to
which the personnel numbers to be selected should belong. It is insignificant if the
personnel numbers are assigned to the selected organizational unit directly or to one of its
subordinate organizational units. If you restrict the selection by organizational structure,
the Dynamic Selections, Search Help, and Selection ID functions are not available.
Search Help
You can use the included search helps of the PREM collective search help by clicking
Search Help function in the application toolbar. You can also add customer-specific
search helps here. For a description of how to do this, see the Customizing for Personnel
Management -> Personnel Administration -> Basic Settings -> Maintain Search Helps. If
you use a search help, the Dynamic Selections, Restrict by OrgStructure, and Selection
ID functions are not available.
Selection ID
You can also restrict the number of personnel numbers to be selected using a predefined
selection method called a Selection ID. For information on how to use and create
selection IDs, see the Define Selection IDs Customizing activity under 'Personnel
Management' -> 'Human Resources Information System' -> Define Selection IDs. How
you Specify Groupings of selection IDs is also described here. The selection IDs whose
grouping is stored in the report category are available to you for selection on the PNPCE
selection screen. When you select a selection ID, it is always performed. This happens
either explicitly when you press the button (behind the selected selection ID), or
implicitly when output starts (F8). If you use a selection ID, the Dynamic Selections,
Restrict by OrgStructure, and Search Help functions are not available.
Evaluation Period
The PNPCE (and the PNP) differentiates between the data selection period and the person
selection period. Both these periods are summarized in the term evaluation period.
Whereas the person selection period affects the selection of personnel numbers, the data
selection period controls the retrieval of data requested by the INFOTYPES statement.
You can configure both separately on the selection screen by selecting an appropriate
entry in each list box. Alternatively, you can set up both selection periods at the same
time using a common list box. You can control which entries are in the list boxes (that is
which evaluation intervals are supported) using the report category. The person selection
period you have set up is taken into consideration when the personnel numbers are
selected. Only the personnel numbers are selected that fulfill the selection conditions on
at least one (key) date in the specified person selection period. All data records of the

requested infotypes that are valid on at least one (key) date in the specified data selection
period are retrieved by default for these personnel numbers. You can set up a different
procedure using the RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY,
and RP_
SET_DATA_INTERVAL_ALL macros. Retrieving data records for infotypes that were
defined by the AS PERSON TABLE MODE P addition is an exception. In this case, all
data records are retrieved independent of the data selection period.
The payroll period should be considered as a special feature for the evaluation period.
You can select either the current payroll period or another payroll period. You must enter
the payroll area in both cases. The evaluation period is calculated from these
specifications. This interval is used as evaluation period (as person selection period and
as data selection period) for the further (internal) processing.
The report can query the evaluation period used via the PN structure. The BEGDA and
ENDDA contain the data selection period whereas BEGPS and ENDPS contain the
person selection period. Inversely, the report can also set the data and person selection
period explicitly. The report must also fill the relevant components of the PN structure at
the START-OF-SELECTION event. This is only meaningful if the manual maintenance
of the evaluation period was hidden using the report category.
Communication Between Report and PNPCE
Additional macros still exist in the TRMAC table, which has in the meanwhile become
obsolete. Do not use these macros for any purpose. You can find all the macros defined in
PNP that affect the functionality of the logical database in the DBPNPCECOM include.
They have a slightly different spelling; underscore_ instead of hyphen-, for example
RP_PROVIDE_FROM_LAST instead of PROVIDE-FROM-LAST. Some of the
TRMAC macros in the DBPNPCECOM include were redefined with the same spelling
but without the functionality so that any incorrect use (of the TRMAC macros) leads to a
syntax error and is therefore excluded.
The following describes the functions made available by the switches and macros defined
in the DBPNPCECOM include. For information about the exact syntax for calling a
macro in view of its parameters and type specifications, see the definition of the macro in
the DBPNPCECOM include.
Evaluation Period in the PN Structure
The PN structure contains information about the evaluation period for which the
evaluation is started regardless of how this is specified on the selection screen. A report
should access the fields of the PN structure only if it requires this information and should
not access the PNPBEGDA, PNPENDDA, and other selection fields of the selection
screen.
The PN-BEGPS and PN-ENDPS fields contain the person selection period for which the
personnel number selection was performed. The PN-BEGDA and PN-ENDDA fields
contain the data selection period.
The report can also fill the PN-BEGDA, PN-ENDDA, PN-BEGPS, and PN-ENDPS
fields with values at the START-OF-SELECTION event and in doing so, specifies the

evaluation period.
The report uses the INFOTYPES statement to request infotype data records that are read
and made available by PNPCE. The report can specify that it only requires data records
that are valid in the specified period using the 'VALID FROM .. TO ..' addition.
Unfortunately, you cannot use the 'VALID FROM .. TO ..' addition in most cases because
it does not accept dynamic date specification. It only accepts constants. If you do not use
the 'VALID FROM .. TO ..' addition, PNPCE returns all data records that are in the
specified data selection period on the selection screen by default.
The INFOTYPES statement can use the MODE addition to control whether the infotype
should be processed and how this should proceed. If the addition is not used, this
corresponds to a MODE Y and the PNPCE logical database reads the infotype and places
it in the internal infotype table. MODE N enables the internal infotype table to be
declared but no infotype data records are read by the PNPCE logical database. MODE P
can only be used together with the 'AS PERSON TABLE' addition and causes all infotype
data records of all personnel numbers of a person to be read at the GET PERSON event
without authorization check or period restriction.
The report can use the PNP_SET_INFTY_MODE_BY_NAME and
PNP_SET_INFTY_MODE_BY_NUMBER macros to change the MODE specified by
the INFOTYPES statement (dynamically) at runtime. The macros must be called at the
INITIALIZATION or START-OF-SELECTION events. The
PNP_SET_INFTY_MODE_BY_NAME macro sets the MODE for an individual infotype
whose name you specify in the first parameter. Do not confuse the name of the infotype,
P0001 or PP0001 for example, with the number of the infotype 0001 You should use the
RP_SET_INFTY_MODE_BY_NUMBER macro in the same way but instead of entering
the name in the first parameter, enter the number of the infotype. Since the same infotype
can be used several times (under different names) when you use the INFOTYPES
additions 'AS PERSON TABLE' or 'NAME ...', this macro sets the MODE for all
infotypes of the same number.
Reading Time Management Infotypes: RP_READ_ALL_TIME_ITY,
RP_READ_ALL_PERSON_TIME_ITY
Time management infotypes (2000-2999) often contain a large number of data records,
particularly if positive recording is implemented. If a dataset that is too large is requested
using the INFOTYPES statements, this can lead to performance problems or in an
extreme case, to memory overflow. For this reason, there are the
RP_READ_ALL_TIME_ITY and RP_READ_ALL_PERSON_TIME_ITY macros,
which can be used to read time management data in a targeted manner. The time
management infotypes are defined by the INFOTYPES statement with the MODE N
addition. This enables the internal infotype table to be declared but no data is read (at the
moment) by the PNPCE logical database. The report can then decide at the GET GROUP
and GET PERAS events whether it wants to read the time management data and for
which period. At the GET GROUP event, the report can call the
RP_READ_ALL_PERSON_TIME_ITY macro to read all time management data on the

personnel numbers of a person that should be processed. In other words, the time
management data that is in the included ALL_PERNRS table of the GROUP structure.
The data is then written to the infotypes that were declared by the INFOTYPES statement
with the AS PERSON TABLE addition.
However, at the GET PERAS event, the report can call the RP_READ_ALL_TIME_ITY
macro to read the time management data on the current personnel number. In both cases,
you must specify the period in which the data records should be valid when the macro is
called. The PNP-SW-IGNORELOCKEDRECORDS switch is also taken account of in
both cases and controls whether locked data records are read or not. In addition, an
authorization check is performed for all data records. If no authorization exists for a data
record, this data record is rejected (that is, it is not placed in the infotype table). If data
records are rejected because of missing authorization, the PNP-SW-AUTH-SKIPPEDRECORD global switch is set to 1. This switch is otherwise set to 0.
Locked Data Records: PNP-SW-IGNORELOCKEDRECORDS
In HR master data maintenance, you can lock individual infotype data records. These data
records are normally ignored during evaluations using PNPCE. If you set the PNP-SWIGNORELOCKEDRECORDS switch to N (at the INITIALIZATION or START-OFSELECTION events), the report can however instruct PNPCE to read locked data records
too.
Authorization Check: PNP_SW_SKIP_PERNR,
PNP_GET_AUTH_SKIPPED_PERNRS
The PNPCE logical database performs an authorization check for all infotype data
records that are requested by the report using the INFOTYPES statement. If no
authorization exists for even one individual data record of one of the infotypes used,
processing of the personnel numbers is terminated by default. In PNP mode, this means
that the GET PERAS event (for the personnel number) is skipped. The report is only
aware of this if it then (if possible at the END-OF-SELECTION event) calls the
PNP_GET_AUTH_SKIPPED_PERNRS macro, which returns a list of the skipped
personnel numbers.
In CE mode, the NO_AUTHORITY flag is set in the included ALL_PERNRS table at the
GET GROUP event, which indicates to the report that no authorization exists. The
following event, GET PERAS, is also not executed for this personnel number. As in PNP
mode, the report can get a list of the personnel numbers for which no authorization exists
using the PNP_GET_AUTH_SKIPPED_PERNRS macro.
You can enter different settings using the PNP_SW_SKIP_PERNR switch. If you set this
switch (at the INITIALIZATION or START-OF-SELECTION events) to N, no more
personnel numbers (without authorization) are skipped. Only the data records for which
no authorization exists are rejected (that is, not made available). The report has no way of
knowing that data records are being withheld from it.
Mass Access By Array-Fetch: PNPCE_ARRAY_FETCH_SIZE
The infotype data records are not read for each personnel number individually but in a
mass access for several personnel numbers simultaneously. This reduces the number of
database accesses and performance can be considerably improved. You cannot read the
infotype data records of all personnel numbers at once since this can lead to problems
with memory space depending on the number of selected personnel numbers and existing

data records. For this reason, the personnel numbers are segmented into blocks of a fixed
size and the personnel numbers of a block are always read together. The size of the block
is set to 100 by default (this means that the personnel numbers from 100 persons are
processed at the same time). The report can change this setting using the
PNPCE_ARRAY_FETCH_SIZE switch at the INITIALIZATION or START-OFSELECTION event. Be very careful if you change this value. If the value is set too high,
it can lead to a memory overflow. If the value is too low, performance is affected. You
must choose a suitable value based on the number of requested infotypes and their
expected datasets.
Locking Persons/Personnel Numbers
By default, the logical database does not lock any personnel numbers or persons.
However, the report can request this. In CE mode, the report must set the
PNPCE_ENQUEUE_PERSONS switch to X. This enables the LDB to set locks for all
personnel numbers of a person. The person is regarded as locked and is processed further
only if all personnel numbers have been successfully locked. Otherwise, they are skipped.
It is the reports task to remove this lock. To do so, the report calls the
PNPCE_DEQUEUE_PERSON macro by specifying the person ID. Persons that could
not be locked and were skipped are logged by the logical database. After processing has
finished, the report can query this list using the
PNPCE_GET_ENQ_FAILED_PERSONS macro. However, not all persons are logged,
only the first N persons. The report can find out how many this is exactly using the
PNPCE_LOG_ENQ_FAILED_PERSONS switch. 1 means that all persons should be
logged. If the report calls the PNPCE_GET_ENQ_FAILED_PERSONS macro, the total
number of skipped persons is returned with the first N logged persons.
In PNP mode, individual personnel numbers can be locked. The report (and PNP) must
set the PNP-SW-ENQUEUPERNR switch to Y to enable this. The report is here also
responsible for unlocking the personnel numbers and can call the
PNP_DEQUEUE_PERNR macro for this by specifying the personnel number. The report
can get a list of the personnel numbers that could not be locked by calling the
PNP_GET_ENQ_FAILED_PERNRS macro. Only the first N personnel numbers and the
total number of skipped personnel numbers are returned. The number of personnel
numbers that should be logged can be specified using the
PNP_LOG_ENQ_FAILED_PERNRS switch. 1 means that all personnel numbers should
be logged.
Determining the First Data Record in the Period: RP_PROVIDE_FROM_FRST
The RP_PROVIDE_FROM_FRST macro analyzes the infotype data records that were
transferred in an internal table to the macro with regard to the specified period. It places
the first data record that is valid in the specified period (the data record with the lowest
ENDDA) in the header of the internal table. If no data record exists in the specified
period, the PNP-SW-FOUND global switch is set to 0. Otherwise it has the value 1. If the
infotype contains subtypes, you also need to specify the subtype for which the last valid
data record should be determined. If you do not specify the subtype, the result is
undefined. In addition, the data records of the internal table must be sorted according to
primary key. The data records are sorted if the data records were determined by PNPCE
logical database using the INFOTYPES statement. Analyze the implementation of the
macro if the exact functions of the macro are unclear. If in doubt, do not use the macro.

Instead implement a suitable solution for the report in question.

Determining the Last Data Record in the Period: RP_PROVIDE_FROM_LAST
The RP_PROVIDE_FROM_LAST macro analyzes the infotype data records that were
transferred in an internal table to the macro with regard to the specified period. It places
the last data record that is valid in the specified period (the data record with the highest
ENDDA) in the header of the internal table. If no data record exists in the specified
period, the PNP-SW-FOUND global switch is set to 0. Otherwise it has the value 1. If the
infotype contains subtypes, you also need to specify the subtype for which the last valid
data record should be determined. If you do not specify the subtype, the result is
undefined. In addition, the data records of the internal table must be sorted according to
primary key. The data records are sorted if the data records were determined by PNPCE
logical database using the INFOTYPES statement. A special feature of infotypes with
time constraint 3 in this case is that the data record with the highest ENDDA is not
necessarily returned, but the first data record (if it exists) that is valid on the end date of
the specified period. Analyze the implementation of the macro if the exact functions of
the macro are unclear. If in doubt, do not use the macro. Instead implement a suitab
le solution for the report in question.
Reading Infotypes: RP_READ_INFOTYPE
The RP_READ_INFOTYPE macro reads the data records of an infotype for the specified
personnel numbers that are valid in the specified period, and writes these to the internal
table specified. This table must be completed correctly. If no data records exist in the
specified period, the PNP-SW-FOUND global switch is set to 0. Otherwise it has the
value 1. In addition, an authorization check is performed for all data records. If no
authorization exists for a data record, this data record is rejected (that is, it is not placed
in the internal table). If data records are rejected because of missing authorization, the
PNP-SW-AUTH-SKIPPED-RECORD global switch is set to 1. This switch is otherwise
set to 0. The PNP-SW-IGNORELOCKEDRECORDS switch is also taken account of
when the data records are read and controls whether locked data records are read or not.
Normally, infotypes are read using the HR_READ_INFOTYPE function module. The
RP_READ_INFOTYPE macro can improve performance when the data records have
already been read by PNPCE and are in the internal buffer. PNPCE only read the data
records that were requested by the report using the INFOTYPES statement. In addition,
the buffer is deleted again at the latest after 100 processed personnel numbers. If however
the report requests the data records using an INFOTYPES statement, it is not particularly
meaningful to request the data records again for the same personnel number using the
RP_READ_INFOTYPE macro. The buffer is only useful when the data records are called
for a different personnel number if these personnel numbers belong to the block of the
100 current buffered personnel numbers. Always weigh up the advantages of this macro
against the consequences of its use for performance.
Excluding Withdrawn Employees: RP_SEL_EIN_AUS_INIT
If this macro is called at the INITIALIZATION event, only personnel numbers are
selected that do not have the status withdrawn in the specified person selection period.
From a technical point of view, the select option PNPSTAT2 (STAT2 from infotype 0000)
is filled with ' 0' for this. This is a default value for the selection condition displayed on
the selection screen that the user can change or delete at a later date.
Progress Indicator: PNPCE_NO_PROGRESS_INDICATOR,

PNPCE_PROGRESS_BLOCK_SIZE
The PNPCE logical database uses the standard technique of displaying processing
progress (process indicator). If the report wants to set up its own progress indicator or
does not want to have a progress indicator displayed, it can switch this indicator off by
setting the PNPCE_NO_PROGRESS_INDICATOR switch to X. The
PNPCE_PROGRESS_BLOCK_SIZE switch enables the report to control how often (that
is, after how many processed persons) the progress indicator should be updated. If the
progress indicator is updated too often, performance suffers.
Payroll Grouping: PNPCE_GROUPING_FROM_PAYROLL
If you set the switch to X, the grouping of personnel numbers (as returned at the GET
GROUP event) should be performed on the basis of payroll data.
Personnel Numbers Skipped Due to Error: PNP_GET_ERR_SKIPPED_PERNRS
A special logic for determining data records is implemented in PNPCE for certain
infotypes. This is performed using a function module
(HR_COST_DISTRIBUTION_GET) for infotypes 0027 and 0266. In the case of an
error, the function module can trigger an exception. PNPCE reacts to an exception by
terminating processing of the personnel numbers for which the error occurred (that is, the
PUT PERAS event is not triggered). If the report wants to know which personnel
numbers were skipped due to this error, it can call the
PNP_GET_ERR_SKIPPED_PERNRS macro.
Comments
Headers of Infotype Tables
PNPCE fills the table body with infotypes defined by INFOTYPES. It does not fill
headers. These are initialized. Therefore, it is not permitted to program headers. This is in
part different in the PNP logical database. In certain cases, the header is also filled but in
many cases it is not filled. Since this depends on various factors, which, in particular,
cannot be traced or controlled by the report, you are also not permitted to program
headers.
Infotype Administration Table $RINFO$
In the $RINFO$ table, infotypes are managed that the report defines using the
INFOTYPES statement. It is defined in the DBPNPCECOM include so that the report
also has access to this table. You are forbidden to manually modify this table for the
purpose of changing infotype characteristics by the report. Instead, use the macros that
enable you to set the infotype characteristics (set the MODE by
PNP_SET_INFTY_MODE_BY_NAME and
PNP_SET_INFTY_MODE_BY_NUMBER; set the validity period by
RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and
RP_SET_DATA_INTERVAL_ALL).
Starting a PNPCE Report Using Preselected Personnel Number Set/Person Set
You can also start a PNPCE report using an externally predefined personnel number set.
You must provide the PNPINDEX parameter with the relevant personnel number when
you call the report using SUBMIT. Since, technically speaking, the select option for
PNPINDEX is hidden, you must specify the personnel numbers in a RANGE structure
that consists of SIGN, OPTION, and LOW. For each personnel number, SIGN must

contain the value I, OPTION the value EQ, and LOW the personnel number. For
SUBMIT, the range table should be transferred to PNPINDEX by the IN operator.
Example:
RANGES: pernr_index FOR pernr-pernr.
CLEAR pernr_index.
pernr_index-sign = 'I'.
pernr_index-option = 'EQ'.
pernr_index-low = '00000815'.
APPEND pernr_index.
SUBMIT pnpce_report WITH pnpindex IN pernr_index.
If a set of personnel numbers is defined in this way, you cannot use the Dynamic
Selections, Restrict by OrgStructure, Search Help, and Selection ID functions to (further)
restrict the set of personnel numbers. However, the conditions entered for the selection
fields of infotypes 0000 and 0001 are taken into account.
Similarly, you can start a PNPCE report with a specified set of persons. You must provide
the PNPPERID parameter with the relevant person IDs when you call the report using
SUBMIT. Unlike PNPINDEX, PNPPERID is not a range but is an internal table whose
row type is the PERSONID data element.
Example:
DATA: personid_index TYPE STANDARD TABLE OF personid.
APPEND '00000815' TO personid_index.
SUBMIT pnpce_rerpot WITH pnpperid = personid_index.
If a set of persons is defined in this way, you cannot define a set of personnel numbers
(using PNPINDEX) at the same time. Also in this case, you cannot use the Dynamic
Selections, Restrict by OrgStructure, Search Help, and Selection ID functions to (further)
restrict the set of personnel numbers.
Using Several Selection Options Simultaneously
In addition to selecting fields of infotypes 0000 and 0001 as described above, PNPCE
offers six other options for selecting personnel numbers. They are selection using
dynamic selections, using organizational structure, using search help, using selection ID,
and by explicitly specifying a personnel number set in PNPINDEX or a person set in
PNPPERID when you call the report. These six options exclude each other, that is you
can only use one of these options at a time. Appropriate queries on the selection screen
attempt to ensure this. It can happen in certain cases, however, that more than one of
these functions is used (for example, when you call the PNPCE report by explicitly
specifying a personnel number set in PNPINDEX as well as one of the variants to be used
in which dynamic selections were also stored). In this case, only one function, which is
the first function used, is taken into account with regard to the following sequence:
Dynamic Selections
Restrict by OrgStructure
Search Help
Selection ID
Explicit Specification or Personnel Numbers in PNPINDEX
Explicit Specification or Persons in PNPPERID
The personnel number set found this way is always restricted further by the selection
conditions specified in the 0000 and 0001 infotypes.

Example
PNP Mode (without functions for evaluating concurrent employment)
TABLES: PERNR.
NODES: PERAS.
INFOTYPES: 0006 NAME P0006.
GET PERAS.
* table P0006 is filled with infotype 0006 data of PERNR
* stored in PERAS-PERNR
WRITE :/ PERAS-PERNR.
...
CE Mode (with function for evaluating concurrent employment)
TABLES: PERNR.
NODES: PERSON, GROUP, PERAS.
INFOTYPES: 0001 NAME ALL_0001 AS PERSON TABLE MODE P.
INFOTYPES: 0001 NAME PP0001 AS PERSON TABLE.
INFOTYPES: 0006 NAME P0006.
GET PERSON.
* table ALL_0001 is filled with infotype 0001 data of all PERNRs
* stored in PERSON-ALL_PERNRS without authority check !!!
WRITE :/ PERSON-OBJID.
...
GET GROUP.
* table P0001 is filled with infotype 0001 data of all PERNRs
* stored in GROUP-ALL_PERNRS
WRITE :/ GROUP-GROUPING_REASON, GROUP-GROUPING_VALUE.
...
GET PERAS.
* table P0006 is filled with infotype 0006 data of PERNR
* stored in PERAS-PERNR
WRITE :/ PERAS-PERNR.
...