Information

  • An option for distributing additional postings of resources to parent resources is to be made available in the application. This option should be an alternative to the calculation variant which is currently used in PLANTA standard.
  • At the same time these postings are to be historized in order to be able to reverse them if necessary. 
  • For further information on the application, please click here.

Activation

Information

  • This functionality is realized via the following events on table DT472 Loads: 
    • server.scheduling.insert_booking_event 
    • server.scheduling.update_booking_event 
    • server.scheduling.delete_booking_event
  • The functionality can thus be switched on and off by (de)activating these three events under System Customizer → Events → Data-Driven Events.

Operation Principle

Information

  • All three events call Jython functions which are responsible for any logical changes - i.e. scheduling itself is not affected (in the native code). Instead, the new algorithm ensures that after inserting/changing/deleting loads with actual effort changes are logged in the loads and remaining effort of resource assignments before scheduling (and in such a way that scheduling does not make any further modifications to them).
  • The entire Jython code for this is contained in the jython/server/scheduling/scheduling.py, the jython directory is located directly below the PLANTA server directory.
  • The standard implementation uses the parent resource as a target resource on which the excess load is posted. You can change this individually in the scheduling.py file by overwriting the find_customized_resource_assignment_for_load file (see the comments in the source code). 
  • From a logical point of view, the find_customized_resource_assignment_for_load function is always run first (in the find_resource_assignment_for_load function) whenever a target resource assignment is searched, and, if it returns None, a fallback on find_group_resource_assignment takes place, searching a resource assignment with the parent resource. 
  • If this is not desired – i.e. if only a different kind of logic is to be analyzed in find_customized_resource_assignment_for_load and the individual resource assignment is to be selected as a target resource when  find_customized_resource_assignment_for_load returns None, the find_customized_resource_assignment_for_load line in the find_group_resource_assignment function should be commented out. 

Historization

Information

  • In data table 805 Posting history, all Actual postings (and reverse postings) made are saved. The data saved in the table also determines the sequence in which postings arereset. 
  • In each actual posting, a new record will be created in this table (each with next higher POSITION, if there are already entries for loads with this LOAD_UUID), whereas LOAD_ACT and possibly BOOKED_EFFORT will be set. 
  • If a posting reduces both remaining load of its own resource assignment and of its target resource assignment, there will be two records. 
  • In reverse postings of a particular load all records which are assigned to this load via LOAD_UUID, are always searched for in the reverse order of the record creation (by the Position attribute). In these records, CANCELLED_EFFORT, and possibly CANCELLED_BOOKED_EFFORT, will be set, which means that this effort is no longer taken into account in future reverse postings. 
  • Multiple records can be written in one reverse posting here as well.