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
