Skip to Content

If you are running time evaluation and payroll in your SAP system integration is about PY fetching the time wage types generated during time accounting. Internal B2 tables involved are ZL, ALP and C1. But let’s focus on the ZL for this discussion without lose of generality.

If you have a look to the standard payroll schema, for example CH00 for Switzerland; as you dive in into the gross calculation part, at some point you will see a call to function DAYPR using schema TC00 as a parameter. The lines involved look like this in my system:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IF
 
PDC
IMPRT
 
B2
PRINT
NP
ZL
DAYPR
TC00
PDC
ELSE
 
 
DAYPR
TC00
 
ENDIF
 
 

 

“IF PDC” is true if the employee has at least one day in the period where time evaluation should run. If this is the case see that PY will import ZL from cluster B2. But the rest looks very similar in the two branches of execution: DAYPR TC00 with or without parameter PDC. What’s the difference?

Without PDR you are telling to DAYPR to execute schema TC00 over the full payroll period. ZL table will be populated only using TC00.

With PDR parameter you are telling to DAYPR to apply TC00 only starting one day later of the last day calculated in time accounting. Obviously you have ZL records for the previous days so you are better off using this information. DAYPR does this checking an internal variable that holds the last day calculated in B2 (BEZUG-DATUM) and checking that your time management status in IT7 is not ‘0’ (this is not the best check as the IF statement is considering also status = ‘7’ as “no PDC”). All this happens when your stack of calls look like this:

 

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

     

      

      

      

     

 

 

 

 

 

 

FORM
RPCALCC0
GENERATE_WAGETYPES
FORM
RPCALCC0
MAIN_FUDAYPR
FORM
RPCALCC0
FUDAYPR
FORM
RPCALCC0
AS-FUNKTION
FORM
RPCALCC0
ASLOOP
FORM
RPCALCC0
MONATSABRECHNUNG
FORM
RPCALCC0
RUECKRECHNUNG
FORM
RPCALCC0
MAIN
FORM
RPCALCC0
%_GET_PERNR
FORM
SAPDBPNP
FILL_INFOTYPE_TABLES_AND_PUT
FORM
SAPDBPNP
PUTPERN
FORM
SAPDBPNP
LOOP_AT_INDEX_AND_PUT
FORM
SAPDBPNP
PUT_PERNR
FORM
SAPDBPNP
%_ROOT
EVENT
RPCALCC0
SYSTEM-EXIT

 

     

and the code looks like this (this code sits within a loop trough all days in the period implemented with LOOP PSP):

 

     IF GEN_PARM2 EQ 'PDC'.
* nur tage, die noch nicht ausgewertet sind:
        IF PSP-DATUM GT BEZUG-DATUM OR WPBP-ZTERF EQ '0'.
          PERFORM DAY_ACTIVE.
          IF WPBP-ZTERF NE '0' AND     "hochgerechneter Zeitraum
            NEW_ZL_ENTRY EQ YES.       "LA wurde erzeugt
            IF PSP-DATUM LT FIRST_NEW_ZL_WT OR
                                  FIRST_NEW_ZL_WT IS INITIAL.
              FIRST_NEW_ZL_WT = PSP-DATUM.
            ENDIF.
          ENDIF.
        ELSE.
*         PERFORM USE_OLD_RESULTS.  "evtl alte Ergebnisse uebernehmen
        ENDIF.
      ELSE.
* alle Tage:
        PERFORM DAY_ACTIVE.
      ENDIF.

So Payroll goes on its own using schema TC00 for the days not available in the B2 cluster. Does it mean that next month when the B2 cluster is complete the payroll will retro-calculate the period to correct errors. Well not always, only if it is required. If your time schema contains the sentence: CHK RPR; the RPTIME00 program will check changes in the ZL and will set the P0003-RRDAT date based on these changes. So it means that ZL needs to change to have a retro triggered from time accounting.

Am I missing something or there is a design problem here? Notice that it can be the case that ZL does not change but still be different to that that TCOO has calculated. In hat case the retro calculation is nto set but it is needed. If you know or are ready to run the test please let me know.

In another post i will write about the CHK function. This is a funny function as it is not executed as any other function during the schema interpretation by RPTIME00 but is used to set some flags that drive the RPTIME00 program when the schema is loaded.

Access the SAP standard documentation that originated these comments here: http://help.sap.com/saphelp_erp60_sp/helpdata/en/68/67ad0498e711d295d900a0c930669b/frameset.htm

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Pinki Goswami
    Liked your blog, explains the technicality of the Payroll driver behaviour…am looking forward to a blog which explains how the time WTs are created and then imported in PAyroll…..
    (0) 

Leave a Reply