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

Bekannte Probleme

Problem
Neu angelegte OLEs werden nicht sofort im Modul OLEs angezeigt, sondern erst nach Neustart des Systems.
Die Wertebereich-Funktion EXPAND() wird nur einmal berechnet.
In Gruppierungsbereichen, deren DDI ein Inkarnations-DI ist, kann es zu Problemen beim Einfügen neuer Gruppen kommen. Daher sollte stattdessen das Unter-DI des Inkarnations-DI mit der Funktion = KO verwendet werden.
Der Oracle-Fehler im Logfile OCIError: ORA-24432: Die zurückgegebene Anweisung ist keine Tagged-Anweisung. ist keine wirkliche Fehlermeldung, sondern eine Warnung und kann ignoriert werden.

In Modulen mit aktiviertem Parameter Neben Oberbereich und bestehenden Relationen zwischen den Datenbereichen kann es zu Darstellungsproblemen kommen.

Post-Delete-Events funktionieren derzeit in Python nicht, da der zu übergebende DtpRecord zu dem Zeitpunkt bereits nicht mehr existiert.

Bekannte Probleme mit Lösung

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

  • Wir empfehlen, für individuellen Code ein package unter /py/ anzulegen und dort alle Dateien abzulegen. 
  • Zum Überschreiben von Modulfunktionalitäten müssen neue Klassen angelegt werden, die von den Standard-Klassen erben und die notwendigen Funktionalitäten anpassen. Die Modulunterklasse auf dem Modul soll dann auf die individuelle Klasse umgestellt werden, was vom ICOU nach Update wiederhergestellt wird.
  • Zum Anpassen von Funktionen, die nicht an Module gebunden sind, müssen die Standarddateien angepasst werden und das ganze entsprechend in Source Control verwaltet werden und bei Update mit dem neuen PLANTA-Stand gemerged werden. 

Details

  • Beispiel Fall 2:
    • Die Funktion apply_project_parameter_heredity wird von create_project_by_type in create_project.py aufgerufen.
    • Diese Funktion ruft wiederum insert_project_child_records auf, um die Stakeholder bei einem Teilprojekt vom Hauptprojekt zu kopieren.
    • Wird die Funktion insert_project_child_records ü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.