Known Issues

The known issues listed below refer to the "application" of PLANTA project. Further known issues can be found in the following documentation areas:

• Technology/Installation/Update

• Customizing

Known Issues

Known Issues with Solution

Planned effort disappears when the "Nocturnal replanning" event is executed 

If the "Nocturnal replanning" event is executed, the planned effort of the resources (remaining effort) disappears.

• Workaround: in the schedule_module.py used under py/api/ppms/customizing/venus/ppms/module_subclasses, replace the code snippet "Old" by the code snippet "New".

Old:

        all_projects = [record.pr_id.get_raw_value() for record in self.projects.get_records()]
        
        unload(all_projects)
        reschedule(all_projects)

New:

        button_da = self.get_da('button_da')
        if button_da:
            replanning_with_pf = button_da.get_records()[0].get_df('replanning_with_portfolio_button')
            if replanning_with_pf:
                replanning_with_pf.activate()

Planned effort disappears when a project is set to “Inactive” or “Archived” 

If the Status of a project is set to Inactive or Archive, the planned effort of the planned department resources is deleted from the project.

• Reason:

  • A change made in py/api/ppms/customizing/venus/ppms/planning_object/project/valueranges.py

• Solution:

  • Update to DB 39.5.22.

  • In py/api/ppms/customizing/venus/ppms/planning_object/project/valueranges.py, search all occurrences of "reschedule" via search & replace and replace by "schedule_capacity" (DB 39.5.22 takes care of this).

Missing Jira fields in the Schedule after linkage with Jira system  

Although a PLANTA project system has been linked to a Jira system, the necessary elements for the synchronization of the tasks are missing in the Schedule module.

• Solution: replace the schedule_module.py used in py/api/ppms/customizing/venus/ppms/module_subclasses by the following: schedule_module.py

Filtering does not work correctly when using skins with different date formats (international working environments).

If you use skins with different date formats, filtering does not work on interfaces which use a different date format than that used for the date strings which are preset as filter criteria in customizing.

• Reason:

  • For filtering by date values, the date format of the skins is used.

• Solution:

  • Update to Server 39.5.22.

  • Create a new global setting with "standard_date_format" Python ID. In this global setting, enter the format which is to be used to interpret all date formats during filtering. As a result, the format of the skin is not used during filtering but the format defined in the global setting (Server 39.5.22 takes care of this).

    • This means that the filter data strings of all data areas MUST be defined in this format system-wide. This includes filter data strings entered by the user when filtering in the Filter Criteria module and filter data strings preset in the customizer. Please note that in PLANTA standard all filter date strings preset in the customizing have the German format (000004). This has no impact on the display of date values on the interface which is still defined by the date format in the skin of a user.

Incorrect Display after Deletion of Presence Time in PLANTA pulse

Using extended time recording for PLANTA Hybrid and recording presence time in PLANTA pulse, may result in incorrect display when presence time is deleted in PLANTA pulse.
The value in the database will be deleted, however, the display below the scale will not be updated. In the Presence module, the correct value will be displayed.

Python error message when calculating a project with resources with incomplete period records from S 39.5.24

When calculating a project with one (or more) resources with incomplete periods, a Python error message is displayed from S 39.5.24. The Python message is preceded by a text message which informs you about the abortion of the calculation and specifies the cause. After you have confirmed this message, the Python message will still be displayed but can be ignored. However, the cause leading to this message (inconsistent data) must be actively rectified.

• Reason:

  • The problem arises when a project is calculated which contains one or more resources the period records of which are incomplete in the period for which the resource(s) is/are planned or when the resource has no periods at all, although the Start period and End period fields are filled. Both cases represent data inconsistencies.

• Solution:

  • Refresh period records for the resources concerned in the required period.

Scheduling

In parameter constellations where Requested start and Requested end lie in the past, Active today’s line = , Fixing = 1, it may occur that the Calc. end of a task lies before the Calc. start (e.g. when the set Actual start is in the past).

• Reason:

  • The conflict between the Fixing = 1 and Active today’s line = . In other words: The task is to start today although it is frozen in the past.

• Solution:

  • Set the Split parameter = .

Behavior of remaining load when using MAN load profiles

If you use the MAN load profile and no actual dates have been set yet, the values will be transferred to Planned load when you enter the Remaining load manually but they will not be summarized to Planned effort.

• Workaround: After entering the remaining load and calculating the schedule, copy the remaining effort to the planned effort.

Effort bars are missing in the Resource Planning module

If a resource is not available on one of the days for which he/she is planned (i.e. does not have any Remaining effort ), the effort bar for the resource in the Resource Planning module will be missing for that day.

• Customizing solution:

  • Open data area 050314 in the module customizer.

  • Delete the entry for DI001364 in the Filter from parameter.

  • Save.

Updates after changes to resource structures

If a resource in an existing resource structure is "reassigned" or removed from the structure, the available capacity and utilization of a direct parent resource is automatically updated, but that of a parent resource from the higher structure level is not.

• Solution: In order to ensure an update at all structural levels, you have to unload and subsequently replan all projects in the Replanning (Calculation of all Projects) module.

Problems in the use of user-specific and general module variant favorites

If a module variant has been defined as a favorite for all users and then one user defines an individual module variant as his favorite, the previous favorite variant will be deactivated for all users.

• Customizing solution: Do not declare the module variant which is to be selected for all users by default as a favorite. Instead, check whether the user has a user-specific favorite and then select the favorite or the required module variant respectively. For this purpose, include the following code in the on_initial_focus() method in the macro of the module:

standard_favorite= '2000000002' # <- Replace with the standard (not user specific) favorite MV-ID

    module_rec405 = ppms.search_record(405, [mod_obj.get_id()], ['id'])
    mv_recs500 = module_rec405.get_children(500, di_list=['user', 'favorite', 'variant_id'])
    user_has_favorite = False
    for rec in mv_recs500:
        if rec.user.get_value() == ppms.uvar_get('@1') and rec.favorite.get_value():
            mod_obj.apply_mv_by_id(rec.variant_id.get_value())
            user_has_favorite = True
            break
    if not user_has_favorite:
        mod_obj.apply_mv_by_id(standard_favorite)

• The module variant ID that is to be applied as a favorite to all users must be specified as standard_favorite.

Print header is not displayed in print preview in a submodule.

The print head or footer is not displayed in a submodule in the print preview.

• Customizing solution: Copy the following line to the on_load() method in the macro of the submodule in which the print header or footer is not displayed.

mod_obj.get_das()

Blurry font under Windows Server 2008 and Windows 7

The use of PLANTA under Windows versions Server 2008 and 7 results in fuzzy typeface. The reason for this is that the Roboto font used in PLANTA is not installed in these Window versions.

• Solution: Replace the Roboto font by a common font, e.g. Arial, in the \Resources\defaultSkingSettings file in the GlobalFontName:Roboto line in the Client directory.

Fixed Issues

PPT export does not work (resolved from DB 39.5.19)

Solution:

• There is a new function: planta_test.set_send_customizing_names(True/False)

• The standard value (for ensuring the functionality of the webclient) is True, the Powerpoint_Export (api/ppms/customizing/venus/ppms/module_subclasses/powerpoint_export.py -> PowerpointExportCaller) must be run with set_send_customizing_names(False).

Incorrect error messages when attempting to delete resources (resolved with DB 39.5.19)

If you try to delete a resource assignment with remaining or actual effort in the Schedule module, the Deletion not allowed in this data area message will be displayed.

• Solution:

  • Extract the following zip-file in the /migration/customizing directory: Ressourcenzuordnungen_löschen.zip

  • Import and execute migration packet.

Incorrect remaining effort values below the scale (resolved with DB 39.5.19)

In the Schedule module, the remaining effort values are displayed incorrectly under the scale.

• Reason:

  • Formats of the respective DIs

• Solution:

  • In the customizer Change the column type of DI066454 and DI066456 in DT204 from "Number w/o DP, up to 9 digits" to "Number with DP".

This solution does not resolve the problem occurring under particular planning constellations that in the display under the scale there is a rounding difference between all remaining effort values and the remaining effort values displayed per scale grid. For further information, see here.

You will only see the changed Remaining effort values below the scale after refreshing the Schedule module (resolved with DB 39.5.19)

If remaining effort values are created or changed in the Schedule module, the new values will not be visible below the scale after saving or scheduling but only after refreshing the module, e.g. via

• Solution: Replace the start_tcalc.py file in the /py/api/ppms/customizing/venus/ppms/ server directory by the following file: start_tcalc.py

For some tasks, Remaining duration is always at 1 and cannot be changed manually.(resolved with DB 39.5.18)

For some tasks, the manually allocated remaining duration is overwritten by a 1 after scheduling.

• Reason:

  • In certain planning constellations, it may occur that Planned duration is empty. In such cases, scheduling sets the Remaining duration to 1. If an actual start date is entered or if it already exists, the Remaining durationcannot be changed manually anymore. When trying to change it, it is reset to 1 in scheduling.

• Solution:

  • Unhide the Remaining duration field in the Schedule module.

  • Enter 1.

  • Allocate the required remaining duration.

  • Perform a scheduling.

Project creation not possible after updating to DB 39.5.17 (resolved with DB 39.5.18)

After updating to DB 39.5.17, no projects can be created under MSSQL.

• Reason:

  • Failure of the AddUUIDtoProjectStructure migration packet during update

• Solution: Please run the following script on the database: fix_project_structure_table.sql

Error message displayed after the deletion of process model phases (resolved with DB 39.5.17)

If a process phase that is active in a project is deleted in the Process Model Templates module, a Python error message is displayed when you open this project or the project overview.

Time recording below the scale is not possible when working with multiple calendars (resolved with DB 39.5.17)

If you use time recording variant 2 (global Time recording variant = 2 parameter) and have created multiple calendars in the Calendar module, the recording of hours worked will not be possible in the Time Recording module directly below the scale or a Python message will be displayed (MSSQL systems).

Error message which is displayed when users with portfolio role (portfolio modules) log on (resolved with DB 39.5.17)