Bekannte Probleme

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:

PY

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.