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:
Known Issues
Problem |
---|
There may be rounding differences in the sum of the Remaining effort of a resource shown below the scale compared to the Remaining effort value of the resource in question (window 2). Reason: The Remaining effort value is a sum of all loads and represents the rounded total value while the values below the scale represent the rounded subtotal of the loads per scale grid, e.g. per month. See also the legend in the Schedule module. |
Currently, effects, e.g. on bars, are not supported in PDF export. |
Due to an MS-Excel problem, there may be format changes, e.g. on currency fields in the Excel file, if the exported file has been saved before. |
In modules with charts, black stains occur when scrolling and zooming in areas containing such charts. This is an existing Windows problem. For further information, please see here. |
If you assign a process model to a project which has no process steps in the first phase, the following error message will be displayed at the bottom of the Process Status module: Local Variable akt_pos referenced before assignment . If the process steps are missing in the other phases of the process model, the error message will not be displayed. |
When you change the functional ID of a main project, the order of subprojects that are at the same structural level may sometimes be mixed up in the Subprojects module. |
At the moment, it is not possible to report hours worked on request process steps. |
Known Issues with Solution
Planned effort disappears when a project is set to “Inactive” or “Archived” (from DB 39.5.20)
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
- A change made in
- Solution:
- In
py/api/ppms/customizing/venus/ppms/planning_object/project/valueranges.py
, use search and replace to replace all occurrences of "reschedule" by "schedule_capacity".
- In
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 Data Areas module.
- Delete the entry for DI001364 in Filter from .
- 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 theGlobalFontName: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 withset_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
- Failure of the
- 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).