You can read in the system documentation for operation ADDMB the following recommendation:
“You should only use operation ADDMB in period end processing under IF EOM. If you use the operation in day processing (between BDAY and EDAY), it may cause errors if there is a recalculation.”
I try to explain in this post what the problem is.
Within the catalogue of operations for time evaluation we have ADDDB and ADDMB and function CUMBT. They update three tables: TES that only exists during running time and ZES and SALDO that are stored in the cluster B2 as part of the time evaluation results. These tables are where the time types are stored: SALDO for the period and ZES and TES for de individual days (i.e. the record structure contains the day). ADDDB updates TES and then on call of function CUMBT the time type is removed from TES, placed in ZES and collected in SALDO all depending on the settings for the time type in T555A (i.e. fields EISUM and MOSUM). ADDMB updates SALDO.
Let’s assume that we use ADDMB during the day processing against what SAP recommends. Assume that time evaluation has run up to 15th of the period and that the execution flow executed one ADDMB instruction on the 10th. If you run again time evaluation and the first day calculated is the 16 all works just fine as RPTIME would just add information to ZES and SALDO in the cluster B2. But if your calculation starts on the 12th because some change has triggered a recalculation what do you think it happens?
When recalculation starts on the 12th it is clear that something needs to be done with ZES and SALDO before the execution can start: the values coming from days that are going to be calculated again needs somehow to be removed. There is an easy solution for the ZES table: just delete all entries where the day is bigger or equal to the 12th; remember that the day is part of the information in ZES and therefore available in the record itself. But what happens with SALDO? What criteria do you use to clean up some values and left untouched others? Actually this is why SAP recommends you not to use it: there is no way to do it. What RPTIME does is to wipe out SALDO (not really, more on this later) and rebuild it again using the ZES table and the configuration in T555A. It also needs to bring in the SALDO from the previous period and do the transfers required from period to period before ZES is looped (T555A-VORMO and related fields in the single screen of V_T555A)
You can see all this happening at running time around the point where the execution stack is as follows:
| | FORM
| POS_PERIOD_TABLES_1
| RPTIME00
|
| | FORM
| POS_PERIOD_TABLES_1
| RPTIME00
|
| | FORM
| EVALUATE_PERIOD
| RPTIME00
|
| | FORM
| %_GET_PERNR
| RPTIME00
|
Another interesting related learning from FORM POS_PERIOD_TABLES_1 is what exactly means the use of value ‘2’ for field T55A-MOSUM. Before I said that SALDO was wiped out before being reconstructed out of ZES. Well this was not precise, time types where MOSUM = ‘2’ are not deleted and will not be recreated neither from ZES. A time type in cluster B2 in SALDO will always be there at the start of the next calculation (for the same period) regardless when the starting day of the recalculation is.
LOOP AT SALDO.
MOVE SALDO-ZTART TO RE_ZTART.
PERFORM RE555A.
IF T555A-MOSUM EQ '2'.
HSALDO = SALDO.
APPEND HSALDO.
CHAR2 = SPACE.
ELSE.
DELETE SALDO.
ENDIF.
ENDLOOP.
When it comes to table ZES and for time types where T555A-EISUM=’2’, RPTIME keeps the existing time types in ZES regardless of the starting day of the recalculation. Then before each day is calculated moves the time types from ZES into TES (removing from ZES) before you take the control in the schema for the day processing.
