Information

  • A reverse posting is a posting which cancels out another posting. I.e. a reverse posting is identical with the original posting in all parameters (project, task, date, cost type), actual load is equally high but negative.
    • In PLANTA, postings or posting records are load records with actual data (actual hours, actual costs, and actual revenues).
      • Load records or simply Loads are records at the lowest planning level in the project. In these records, planned (remaining) or already recorded (actual) hours worked/costs of the task resource per time unit, e.g. per day or month, etc. are displayed. For further information, see the Schedule module.
  • In particular cases, reverse postings must be recorded in PLANTA project since the deletion/correction of already recorded actual dates is prevented by the PLANTA software (standard). This is the case if the following or one of the following parameters are set:

Reason

  • In the above mentioned cases, the prevention of deletion is necessary, e.g. to
    • avoid the differences between target and source system after transfer to or import from an external system.

Details

  • In PLANTA standard, automatic reverse postings are used. This means that reverse postings are created invisibly in the background upon deletion/correction of actual postings the deletion/adjustment of which is technically forbidden.
    • The new function now also offers an option to create reverse postings for postings before or on the key date, which virtually softens up the fixed key dates but with the advantage that incorrect postings can now generally be corrected. Whether these options should be used is an individual decision which brings about both advantages and disadvantages.
  • If automatic reverse postings are not to be used for particular reasons, reverse postings can also be created manually. PLANTA, however, expressly advises you to use automatic reverse postings to minimize possible error sources.

Caution

  • The above mentioned cases deal with the deletion of values in load records.
  • This is to be differentiated from the deletion of entire posting records. Although it is technically possible, PLANTA expressly advises against it (with a few exceptions)
    • since it is not intercepted by automatic reverse postings
    • since the mechanism of prevention, as described above, does not take effect here and the deletion of load records thus leads to inconsistencies upon transfer to external systems
    • since it furthermore influences the calculation of the Remaining values. For details, see here

Principle

How do reverse postings work?

  • Regardless of how reverse postings are created (manually or automatically), they are based on the same principle.
  • Depending on whether the load value of the posting is deleted or whether the load value, the cost type, or the date is changed, there are 2 or 3 records (in the case of automatic reverse postings they are in the background):
  • Deletion of the Actual load value of the posting
RecordActual loadCost typeDateExample
1. Original recordformer actual loadformer cost typeformer date5, KC0002, 1/1/2019
2. Reverse posting recordformer actual load with minus signformer cost typeformer date- 5, KC0002, 1/1/2019
  • Adjust the Actual load value of the posting, e.g. from 5 to 4
RecordActual loadCost typeDateExample
1) Original recordformer actual loadformer cost typeformer date5, KC0002, 1/1/2019
2. Reverse posting recordformer actual load with minus signformer cost typeformer date- 5, KC0002, 1/1/2019
3. New recordnew actual loadformer cost typeformer date4, KC0002, 1/1/2019
  • Adjustment of the cost type or of the date of the posting
    • For automatic automatic reverse postings, this case is only supported from DB 39.5.14.
RecordActual loadCost typeDateExample
1) Original recordformer actual loadformer cost typeformer date5, KC0002, 1/1/2019
2. Reverse posting recordformer actual load with minus signformer cost typeformer date- 5, KC0002, 1/1/2019
3. New recordformer actual loadnew cost typeformer date5, KC0001, 1/1/2019

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 global Reverse posting variant 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 time scale or in the respective load record in the Actual field
  • Actual costs in the Post Costs module
    • delete/change the value in the required record in the Actual costs field.
  • Actual revenues in the Post Revenues module
    • delete/change the value in the Actual revenues field in the required record.

Details on Automatic Reverse Postings

When are automatic reverse postings created?

  • Via the Reverse posting variant global parameter you can control when automatic reverse postings are to be created (Bitflag):
    • 0: deactivate automatic reverse postings
    • 1: automatic reverse posting for exported loads ( SAP status = set)
    • 2: automatic reverse posting for approved loads ( Approval = set)
    • 4: automatic reverse postings for loads before the key date (if load date <= key date )
    • 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----
    1x---
    2-x--
    3xx--
    4--x-
    5x-x-
    6-xx-
    7xxx-
    8---x
    9x--x
    10-x-x
    11xx-x
    12--xx
    13x-xx
    14-xxx
    15xxxx

Caution

  • When you use the 4, 5, 6, 7, 12, 13, 14, 15 setting, the effect of the Key date performance parameter will be canceled out. 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 or department manager can view the reverse postings as well as the canceled records for analysis purposes.
  • 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 Reverse Postings parameter if you do not want to have them displayed.

Manual Reverse Postings

Information

  • Manual reverse postings are recorded for deactivated or non-existing (up to DB 39.5.13) automatic reverse postings (for examples, see the "Principle" chapter).

Procedure in the Time Recording, Post Costs, and Post Revenues modules.