Automatic Reverse Postings
Information
- From version DB 39.5.13, it is possible to set the recording of reverse postings (negative postings) to "automatically" and to define in which case automatic reverse postings are to be created. This is controlled via the
posting_cancelation
global parameter.
- If the automatic creation of reverse postings is activated, the respective reversal values are displayed in the background when deleting/changing actual values (if the condition defined in the global parameter is applicable) and do not have to be recorded manually.
- If the automatic creation of reverse postings is deactivated, reverse postings must be created manually as in previous versions.
- Automatic reverse postings only take effect when you delete/change actual load values, however, they do not take effect when you delete all posting records.
Procedure for activated automatic reverse postings
- actual hours in the Time Recording module
- depending on the time recording variant used, either delete/change the required value directly below the scale or in the respective load record in the Actual field
- Actual costs in the Cost Posting module
- delete/change the value in the required record in the Actual costs field.
- Actual revenues in the Revenues Posting module
- delete/change the value in the Actual revenues field in the required record.
Details on Automatic Postings
When are automatic reverse postings created?
- Via the
posting_cancelation
global parameter you can control when automatic reverse postings are to be created (Bitflag):
- 0: deactivate automatic reverse postings
- 1: automatic reverse postings for exported postings (SAP Status = set)
- 2: automatic reverse postings for approved postings (Approval = set)
- 4: automatic reverse postings for postings before the key date (if Load date Key date performance )
- 8: automatic reverse postings for imported postings (Imported on or Imported by set or if there is a record in the pulse table in which PLANTA_ID = UUID from DT472)
- 15: Automatic reverse postings for all above mentioned cases.
- The parameter is a bitflag.
Value |
Export |
Approval |
Key date |
Import |
0 |
- |
- |
- |
- |
1 |
x |
- |
- |
- |
2 |
- |
x |
- |
- |
3 |
x |
x |
- |
- |
4 |
- |
- |
x |
- |
5 |
x |
- |
x |
- |
6 |
- |
x |
x |
- |
7 |
x |
x |
x |
- |
8 |
- |
- |
- |
x |
9 |
x |
- |
- |
x |
10 |
- |
x |
- |
x |
11 |
x |
x |
- |
x |
12 |
- |
- |
x |
x |
13 |
x |
- |
x |
x |
14 |
- |
x |
x |
x |
15 |
x |
x |
x |
x |
Attention
- When you use the 4, 5, 6, 7, 12, 13, 14, 15 setting, the effect of the Key date performance parameter is virtually undermined. Data can be created manually before or on the key date and already existing postings can be corrected or deleted (e.g. incorrect ones). Reverse postings are then automatically created for them, so that the changes can also be traced before the key date.
Traceability of reverse postings
- In the following modules, the project manage or the department manager can view the reverse postings as well as the canceled records for analysis purposes.
- Project manager
- Department manager
- Both reverse posting records (canceled postings and reverse postings) are differentiated from other records by a traffic light (the same as for completed tasks in the schedule).
Details
- Since reverse postings are saved in DT472 Load just like regular postings, you can filter them out in individual modules via the Canceled/Reverse posting parameter if you do not want to have them displayed.