Known Issues

The known issues listed below refer to the Customizing area. Further known issues can be found in the following documentation areas:

Problem
Newly created OLEs are not immediately displayed in the OLEs module, but only after restarting the system.
The EXPAND() value range function is only calculated once.
In grouping areas the DDI of which is an incarnation DI, problems may occur when you try to insert new groups. Hence, the Sub-DI of the incarnation DI with Function = CO should be used.
The Oracle error in the OCIError: ORA-24432: The returned instruction is no tagged instruction. log file is not a real error message but a warning and can be ignored.
Display issues may occur in modules with activated Next to parent area parameter and existing relations between the data areas.
Post-delete events do not currently work in Python, as the DtpRecord to be transferred no longer exists at that point.

Known Issues with Solution

Problem with `mod_obj.menu(91)` / Action ID 91

The system crashes when menu item 91 is included in a module. This can be done using a Python macro or an action ID in the data area.

In order to avoid errors, 91 should no longer be used as an action ID on a data field with DF beahvior = c2.
In all macros in which mod_obj.menu(91) is used to insert child data areas you now have to explicitly specify in which data area a record is to be inserted. This is done via the DA Python ID.
Solution:

Python

Old: 
mod_obj=ppms.get_target_module()
mod_obj.menu(91)

New:
inv_rec=ppms.get_context_df().get_record()
inv_rec.insert_child(str(DA-Python-ID))

The advantage of this procedure is that here you can decide precisely in which data area a record is inserted.

Database error message when saving in Q1B and Q2B after a CU deployment

When saving changes in the customizing schemas !Q1B and !Q2B (e.g. in the Modules or Data Areas modules), a database error message is displayed after CU deployment.

Solution:
- You have to manually set the HIBERNATE_SEQUENCE to the highest status of the data available in the history tables.

Overwrite More Complex Python Customizings

For information

It is usually recommended that you use the Import Wrapper to change standard functionalities.
For certain programming, however, this is not possible. In such cases you have to proceed as follows:
- The code in the file that is stored under /planta_de/ must be adjusted.
- The change must be documented in the ICOU.
- Upon each update, the change must be restored.

Details

Example of such a programming:
- The apply_project_parameter_heredity function is opened by create_project_by_type in create_project.py.
- This function in turn opens insert_project_child_records for copying the stakeholders of a main project to a subproject.
- If the insert_project_child_records function is overwritten by the import wrappers, this will not have any influence on this behavior.

Reason:
- Both functions are located in the same module, which visualizes their local name space.
- If the _apply_project_parameter_heredity function now wants to open the insert_project_child_records function, this function is first looked for in the local name space before the search is extended.
- So if the function is overwritten in the customer directory, the code never gets to search there because the function is already found in the local namespace.

Fixed Issues

Problem with the Validation of New Individual Mapping Functions (resolved from DB 39.5.25)

New individual mapping functions are not recognized by the interface validation.

Reason: The customizing was changed to use the category attribute for the class name, but there was still a place where the name attribute was searched for.
Solution: Please replace the following entry in the src/Python/py/api/ppms/customizing/venus/ppms/interface/blocks/base.py file:

        for listbox_record in category_record.get_children(447, ['name', 'description']):
            name = listbox_record.name.get_value()

        for listbox_record in category_record.get_children(447, ['category', 'description']):
            name = listbox_record.category.get_value()

UUIDs in PLANTA link data tables (fixed from DB 39.5.24)

PLANTA link incorrectly requires a mandatory UUID for data tables that are used in interfaces and expects that the UUID possesses "uuid" as Python ID.

Solution: Please replace the following entries in the py/api/ppms/customizing/venus/ppms/interface/modules/mts.py file:

            uuid_di = dtp_record.get_di('uuid')

        try:
            uuid_di = dtp_record.get_di('uuid')
        except ppms.NonexistentDataItem:
            return

Problem with the Validation of New Individual Mapping Functions (resolved from DB 39.5.24)