Tuesday, September 16, 2008

SAP R/3 : GET PERNR or SELECT or PROVIDE...

To access employee's record in HR module are multiple ways of doing so. You can use GET PERNR, SELECT, PROVIDE or even function modules. However, the question lies on the difference of each of this syntaxes that allows you to access employee information when we are using it for reporting, enhancement and other data queries.

First, GET PERNR is a macro that contains PROVIDE statements and a logic of filteration based on the logical database PNP. GET PERNR allows you to focus on processing data immediately and less worry on the data selection because the PNP automatically provide a set of predefine group of selection screens. You can even modify and set your own selection screens using HR Report Category and still able to use GET PERNR. HR macros are all stored in this table TRMAC. You will see that each of this line items in that table are specific ABAP coding. GET PERNR should be use when your reporting does not max out the database processing (where there is many read and write) or mass processing. Mass processing will not be very suitable to be queried by GET PERNR. GET PERNR gets each record of an employee of a cycle. Each cycle in GET PERNR does 4 events that will listen to set handler to get data, process data, present data and lastly checking if there are user exit or enhancement to the GET PERNR.

Second, SELECT statement/syntaxes are more suitable to query for large data (mass processing) especially if you are downloading employee data at one shot to a text file or to an IDOC for data transfer. You should use SELECT statement to select a lot of employees for a certain condition so to minimise table read transaction so your performance in an ABAP program can focus more on ABAP processing. In my personal opinion, getting side topic a bit, analysis result yield by SE30 after checking a certain ABAP program should have its performance shoulder towards on ABAP processing side. In other words, it is okay to see the percentage falls towards ABAP processing rather than sliding towards database read. High percentage of database reads indicates your program contains a lot of SELECT SINGLE and a whole START-OF-SELECTION filled with SELECT-END SELECT statements. Worse, there might be a possibility that your program contains NESTED SELECT statement. You should group your SELECT statement in one place and gather all data before going to processing stage.

Third, a good mixture usage of GET PERNR and INFOTYPE syntax can help you ease your HR report processing reading your infotype tables a great deal. At each read of GET PERNR, INFOTYPE syntax will be automatically filled with data related to the particular employee so it helps you to reduce coding and in one way, getting correct rows of record for an employee that is time dependent. Time dependent in HR meaning each record of transaction for an employee has a trace of time that dictates the time and date that affect that record. Not all infotype is dependent time. Infotype like 0000 (Action) is time dependent because it can tell you when an employee is recruited, confirm, transfer, promoted, terminated or on leave.

GET PERNR and SELECT statement should be used accordingly to reporting condition. GET PERNR sometime can slows down your report. Also, instead of using PROVIDE statement, you should use GET PERNR because PROVIDE is in the macro itself.

is sky the limit... GET PERNR/PROVIDE/SELECT

No comments: