Access all selected personnel numbers using LDB in HCM/HR

[dschiener]

Hi there,

I am searching for a possibility to access all selected personnel numbers when using logical database in ABAP HCM/HR.

Example:

NODES: peras.
TABLES: pernr.

START-OF-SELECTION.

GET peras.

In the GET peras event an implicit loop is performed over all selected personnel numbers.
I want to know in which internal table these personnel numbers are stored in LDB and if I can access them.

I do not want to do anything like this as workaround:

DATA personnel_numbers TYPE STANDARD TABLE of persno.
GET peras.
INSERT pernr-pernr INTO TABLE personnel_numbers.

I am interessted in the underlying storage of the LDB!

Can anyone help out?

BR

[RaymondGiuseppi]

Execute transaction SE36 on the logical database PNPCE and analyze the source of form PUT_PERAS in the database program SAPDBPNPCE.

(Hint: Look for 'some global variables for PUT events')

[dschiener]

Hi @RaymondGiuseppi,

thank you for your hint ;)!

By debugging I guess that I am searching for partition_pernrs in FORM PUT_PERAS in DBPNPCEN003:

*     check select-options for infty 0000 and 0001 entered on sel-screen
      PERFORM reduce_pernrs_applying_selops USING g_pn-begps
                                                  g_pn-endps
                                         CHANGING partition_pernrs."I/O

Is there any way to access this variable from a report, e.g. dirty assign or a solution that's not that dirty :D...?

Furthermore I guess this routine will only be performed and therefore partition_pernrs be filled when executing GET peras or an alternative node event?

I would like to have the selection functionality of LDB via selection screen but without the looping over all selected personnel numbers. For my use case the resulting array of selected personnel numbers would already do.

BR

[RaymondGiuseppi]

If your program uses the LDB

• 'Dirty' assign values of the global area of the DB program (in DBPNPCETOP names starting with g_)
• Execute a FORM in the program, insure that those calls wont break the program logic

Else

• From an external program that doesn't use the LDB you can use FM LDB_PROCESS