Reverse Postings

• 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).
• 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:
• Approval
• SAP status
• Imported on or Imported by

Explanation

• 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.

Attention

• The above mentioned cases deal with the deletion of values in posting records.
• This is to be differentiated from the deletion of complete 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 does reverse posting 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

Record	Actual load	Cost type	Date	Example
1) Original record	Old actual load	Old cost type	Old date	5, KC0002, 01/01/19
2) Reverse posting record	Old actual load with minus sign	Old cost type	Old date	- 5, KC0002, 01/01/19

• Adjustment of the Actual load value of the posting, e.g. from 5 to 4

Record	Actual load	Cost type	Date	Example
1) Original record	Old actual load	Old cost type	Old date	5, KC0002, 01/01/19
2) Reverse posting record	Old actual load with minus sign	Old cost type	Old date	- 5, KC0002, 01/01/19
3) New record	New actual load	Old cost type	Old date	4, KC0002, 01/01/19

• Adjustment of the cost type or of the date of the posting
  • For automatic reverse postings this case is only supported from DB 39.5.14.

Record	Actual load	Cost type	Date	Example
1) Original record	Old actual load	Old cost type	Old date	5, KC0002, 01/01/19
2) Reverse posting record	Old actual load with minus sign	Old cost type	Old date	- 5, KC0002, 01/01/19
3) New record	Old actual load	New cost type	Old date	5, KC0001, 01/01/19

New from DB 39.5.13

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.

Show overview of possible combinations  Hide overview of possible combinations 

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
    • Progress
    • Check Reported Hours
  • Department manager
    • ICA
    • Actual Hours
• 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.

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).

The procedure in the Time Recording, Cost Posting and Revenues Posting modules is identical.

• Actual value is to be deleted
  • Insert a new record below the load record to be canceled and set all values except Actual load/Actual costs/Actual revenues like in the original record.
    • Enter the same value as in the reference record with a minus symbol in the Actual load/Actual costs/Actual revenues field.
• Actual value is to be changed
  • Insert a new record below the load record to be canceled and set all values except Actual load/Actual costs/Actual revenues like in the original record.
    • Enter the same value as in the reference record with a minus symbol in the Actual load/Actual costs/Actual revenues field.
  • Insert another record and set all values except Actual load/Actual costs/Actual revenues like in the original record.
    • Enter the actual cost value in the Actual load (Actual costs/Actual revenues) field.
• Cost type or date is to be changed
  • Insert a new record below the load record to be canceled and set all values except Actual load/Actual costs/Actual revenues like in the original record.
    • Enter the same value as in the reference record with a minus symbol in the Actual load/Actual costs/Actual revenues field.
  • Insert another record and set Actual load/Actual costs/Actual revenues like in the in the original record.
  • Enter the required new cost type or date value.
    • If a new parameter is only entered for one of the two parameters, the other value remains the same as in the original record.