The documentation from version 39.5.17 of PLANTA project can be found in the new PLANTA Online Help.

Reverse Postings

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

New from DB 39.5.13

Details
  • From version DB 39.5.13 it is possible to use automatic reverse postings. In this case, reverse postings are created invisibly in the background upon deletion/correction of actual postings the deletion/adjustment of which is technically forbidden (see the cases above).
    • 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 fix key dates but brings the advantage that wrong postings can now generally be corrected. Whether these options should be used is an individual decision which brings about both advantages and disadvantages.
    • If you do not use automatic reverse postings, you have to continue to work with manual reverse postings. PLANTA, however, expressly advises you to use automatic reverse postings to minimize possible error sources.

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

         PLANTA project









 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten
This site is powered by the TWiki collaboration platform Powered by Perl