Bekannte Probleme

Die nachfolgend aufgeführten bekannten Probleme sind aus dem Bereich Customizing. Weitere bekannte Probleme finden Sie in den folgenden Dokumentationsbereichen:

• Anwendung

• Technik/Installation/Update

Bekannte Probleme

Bekannte Probleme mit Lösung

Probleme mit Migrationspaket CalculateDepartmentAbsence

Das Migrationspaket CalculateDepartmentAbsence schlägt auf MSSQL-Systemen fehl.

• Ursache: Das Paket verwendet temporäre Tabellen, die erst ab MSSQL-Version 39.5.23 unterstützt werden.

• Umgehungslösung:

  • Wurde das Update auf DB 39.5.23 noch nicht durchgeführt, bitte den Parameter persistent_db_session unter config/globals.conf aktivieren (auf “true” setzen).

  • Wurde das Update bereits durchgeführt und das Migrationspaket ist fehlgeschlagen, kann ein Customizer die Datei bearbeiten und das „#“ manuell entfernen, um die temporären Tabellen in echte Tabellen umzuwandeln. Anschließend das Migrationspaket erneut ausführen.

Problem mit mod_obj.menu(91) / Aktions-ID 91

Das System hängt sich auf, wenn Menüpunkt 91 in ein Modul eingebunden wird. Dies kann durch ein Python-Makro oder eine Aktions-ID im Datenbereich passieren.

• Auf einem Datenfeld mit DF-Verhalten = c2 sollte als Aktions-ID keine 91 mehr vergeben werden, um Fehler zu vermeiden.

• In allen Makros, in denen mod_obj.menu(91) verwendet wird, um einen untergeordneten Datenbereich einzufügen, muss man nun explizit angeben, in welchem Datenbereich ein Datensatz eingefügt werden soll. Dies geschieht über die DA-Python-ID.

• Lösung:

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

• Der Vorteil dieser Vorgehensweise ist, dass genau darüber entschieden werden kann, in welchem Datenbereich ein Datensatz eingefügt wird.

Datenbank-Fehlermeldung beim Speichern in der Q1B und Q2B nach einem CU-Deployment

Beim Speichern von Änderungen in den Customizing-Schemas Q1B und Q2B (z.B. im Modul Module oder Datenbereiche) tritt nach einem CU-Deployment eine Datenbank-Fehlermeldung auf.

• Lösung:

  • Die HIBERNATE_SEQUENCE muss manuell auf den höchsten Stand der in den History-Tabellen vorhanden Daten gesetzt werden.

Überschreiben von komplexeren Python-Customizings

Informationen

• Standardmäßig wird empfohlen, die Import-Wrapper zu nutzen, um Standard-Funktionalitäten abzuändern.

• Bei bestimmten Programmierungen ist dies aber nicht möglich. In diesen Fällen muss wie folgt vorgegangen werden:

  • Der Code in der Datei, die unter /planta_de/ liegt muss angepasst werden.

  • Die Veränderung muss im ICOU dokumentiert werden.

  • Bei jedem Update muss die Änderung wieder zurückgespielt werden.

Details

• Beispiel für eine solche Programmierung:

  • Die Funktion apply_project_parameter_heredity wird von create_project_by_type in create_project.py aufgerufen.

  • Diese Funktion ruft wiederrum insert_project_child_records auf, um die Stakeholder bei einem Teilprojekt vom Hauptprojekt zu kopieren.

  • Wird die Funktion insert_project_child_records durch die Import-Wrapper überschrieben, hat das keine Auswirkung auf dieses Verhalten.

• Begründung:

  • Beide Funktionen befinden sich im gleichen Modul, was ihren lokalen Namespace darstellt.

  • Will nun die Funktion _apply_project_parameter_heredity die Funktion insert_project_child_records aufrufen, wird nach dieser Funktion erst im lokalen Namespace gesucht, bevor die Suche ausgeweitet wird.

  • Ist die Funktion also im customer-Verzeichnis überschrieben, kommt der Code nie soweit, dass er dort nachschauen müsste, weil die Funktion bereits im lokalen Namespace gefunden wird.

Behobene Probleme