Bekannte Probleme

Die nachfolgend aufgeführten bekannten Probleme sind aus dem Bereich "Anwendung" von PLANTA project. Weitere bekannte Probleme finden Sie in den folgenden Dokumentationsbereichen:

• Technik/Installation/Update

• Customizing

Bekannte Probleme

Bekannte Probleme mit Lösung

Geplante Aufwände verschwinden, wenn man das Event "Nächtliche Neuplanung" ausführt

Wird das Event "Nächtliche Neuplanung" ausgeführt, verschwindet der geplante Aufwand der Ressourcen (Aufwand-Rest).

Umgehungslösung:

1. in der unter py/api/ppms/customizing/venus/ppms/module_subclasses verwendeten schedule_module.py den Code-Snippet "Alt" durch den Code-Snippet "Neu" ersetzen.

Alt:

        all_projects = [record.pr_id.get_raw_value() for record in self.projects.get_records()]
        
        unload(all_projects)
        reschedule(all_projects)

Neu:

        button_da = self.get_da('button_da')
        if button_da:
            replanning_with_pf = button_da.get_records()[0].get_df('replanning_with_portfolio_button')
            if replanning_with_pf:
                replanning_with_pf.activate()()

2. Die folgenden SQL-Statements auf der Datenbank mit dem PLANTA-User ausführen:

update DT410 set DI041092 = 'button_da' where DI000198 = '007020';
update DT411 set DI041036 = 'replanning_button' where DI000306 = '007020' and DI000307 = 58401;
update DT411 set DI041036 = 'replanning_with_portfolio_button' where DI000306 = '007020' and DI000307 = 756531;

Geplante Aufwände verschwinden, wenn ein Projekt auf "Inaktiv" oder "Archiviert" gesetzt wird (ab DB 39.5.20)

Wird der Status eines Projekts auf Inaktiv oder Archiv gesetzt, werden die geplanten Aufwände der eingeplanten Abteilungsressourcen aus dem Projekt entfernt.

• Ursache:

  • Eine Änderung in py/api/ppms/customizing/venus/ppms/planning_object/project/valueranges.py

• Lösung:

  • In py/api/ppms/customizing/venus/ppms/planning_object/project/valueranges.py alle Vorkommnisse von "reschedule" mit Suchen und Ersetzen durch "schedule_capacity" ersetzen.

Filtern bei Verwendung von Skins mit unterschiedlichen Datumsformaten (internationale Arbeitsumgebungen) funktioniert nicht korrekt

Werden Skins mit unterschiedlichen Datumsformaten verwendet, funktioniert das Filtern auf Oberflächen, die ein anderes Datumsformat verwenden, als die Datumsstrings, die als Filterkriterien im Customizing vorbelegt sind, nicht. 

• Ursache:

  • Für das Filtern nach Datumswerten wird das Datumsformat des Skins verwendet.

• Lösung:

  • Auf den Server 39.5.22 updaten.

  • Eine neue globale Einstellung mit der Python-ID "standard_date_format" erstellen. In dieser globalen Einstellung das Format eintragen, mit dem alle Datumsformate beim Filtern interpretiert werden. Beim Filtern wird dann nicht das Format des Skins, sondern das in der globalen Einstellung hinterlegte Format verwendet (dafür sorgt der Server 39.5.22).

    • Dies bedeutet dann, dass die Filterdatumsstrings aller Datenbereiche systemweit ZWINGEND in diesem Format definiert werden müssen, sowohl diejenigen, die Anwender beim Filtern im Modul Filterkriterien eingeben als auch die im Customizer vorbelegt werden. Bitte beachten Sie, dass im PLANTA-Standard alle im Customizing vorbelegten Filter-Datumsstrings das deutsche Format (000004) haben. Die Darstellung von Datumswerten an der Oberfläche wird dadurch nicht geändert, das bestimmt nach wie vor das Datumsformat im Skin eines Benutzers. 

Fehlerhafte Anzeige nach Löschen von Anwesenheiten in PLANTA pulse

Wird die erweiterte Zeiterfassung für PLANTA-Hybrid genutzt und werden Anwesenheiten in PLANTA pulse erfasst, kann es zur fehlerhaften Anzeige kommen, wenn Anwesenheiten in PLANTA pulse gelöscht werden.
Der Wert in der Datenbank wird gelöscht, doch die Anzeige unter der Skala wird nicht aktualisiert. Im Modul Anwesenheiten wird der korrekte Wert angezeigt.

Python-Fehlermeldung beim Berechnen eines Projekts mit Ressourcen mit unvollständigen Periodendatensätzen ab S 39.5.24

Bei der Berechnung eines Projekts mit einer (oder mehreren) Ressourcen mit unvollständigen Perioden erscheint ab S 39.5.24 eine Python-Fehlermeldung. Dieser ist eine Text-Meldung vorgeschaltet, die darüber informiert, dass die Berechnung abgebrochen wird und gibt die Ursache an. Nach Bestätigung dieser Meldung erscheint weiterhin die Python-Meldung, die jedoch ignoriert werden kann. Die Ursache, die zu dieser Meldung führt (inkonsistente Daten) muss jedoch aktiv behoben werden.

• Ursache:

  • Das Problem entsteht, wenn eine Berechnung eines Projekts durchgeführt wird, das eine oder mehrere Ressourcen enthält, deren Periodendatensätze im Zeitraum, für den die Ressource(n) eingeplant ist/sind, nicht vollständig sind oder die Ressource gar keine Perioden aufweist, obwohl die Felder Startperiode und Endperiode gefüllt sind. Beide Fälle stellen Dateninkonsistenzen dar.

• Lösung:

  • Für die betroffenen Ressourcen für den gewünschten Zeitraum Periodendatensätze aktualisieren.

Terminrechnung

Bei der Parameterkonstellation Wunsch-Anfang und Wunsch-Ende in der Vergangenheit, Aktive Heutelinie = , Fixierung = 1 kann es vorkommen, dass das Kalk. Ende eines Vorgangs vor dem Kalk. Anfang liegt (z.B. bei gesetztem Ist-Anfang in der Vergangenheit).

• Ursache:

  • Der Konflikt zwischen den Parametern Fixierung = 1 und Aktive Heutelinie = . Anders formuliert: Der Vorgang soll heute anfangen, obwohl er in der Vergangenheit fixiert ist.

• Lösung:

  • Den Parameter Splitting = setzen.

Verhalten von Belastung-Rest bei Verwendung von Belastungskurve MAN

Sind beim Verwenden der Belastungskurve MAN noch keine Ist-Termine gesetzt, werden bei der manuellen Eingabe von Belastung-Rest, die Werte zwar in Belastung-Soll übernommen, jedoch nicht auf Aufwand-Soll verdichtet.

• Umgehungslösung: Nach der Eingabe von Belastung-Rest und der Berechnung des Terminplans den Aufwand-Rest auf den Aufwand-Soll kopieren.

Im Modul Einplanungen fehlen Aufwandsbalken

Wenn eine Ressource an einem der Tage, an dem sie eingeplant ist (d.h. Aufwand-Rest besitzt), nicht verfügbar ist, fehlt für die Ressource für diesen Tag der Aufwandsbalken im Modul Einplanungen .

• Customizing-Lösung:

  • Im Modul Datenbereiche den Datenbereich 050314 öffnen.

  • Für DI001364 den Eintrag in Filtern von löschen.

  • Speichern.

Aktualisierung nach Änderungen an Ressourcenstrukturen

Wird in einer bestehenden Ressourcenstruktur eine Ressource "umgehängt" oder aus der Struktur entfernt, aktualisiert sich die verfügbare Kapazität und die Auslastung einer direkt übergeordneten Ressource automatisch, die einer übergeordneten Ressource von der höheren Strukturebene jedoch nicht.

• Lösung: Um die Aktualisierung auf allen Strukturebenen zu gewährleisten, muss im Modul Neuplanung (Berechnung aller Planungsobjekte) eine Entlastung und anschließend eine Neuplanung aller Projekte durchgeführt werden.

Problem beim Verwenden von benutzerspezifischen und allgemeinen Modulvarianten-Favoriten

Ist in einem Modul eine Modulvariante als Favorit für alle Benutzer definiert und legt ein Benutzer eine benutzerspezifische Modulvariante als seinen Favoriten fest, wird die vorherige Favorit-Variante für alle Benutzer als Favorit deaktiviert.

• Customizing-Lösung: Die Modulvariante, die für alle Benutzer standardmäßig ausgewählt werden soll, nicht als Favorit deklarieren. Stattdessen beim Modulaufruf prüfen, ob der Benutzer einen benutzerspezifischen Favorit hat, und je nachdem den Favoriten oder die gewünschte Modulvariante wählen. Hierfür im Makro des Moduls in der on_initial_focus() -Methode folgenden Code aufnehmen:

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)

• Als standard_favorite muss die Modulvarianten-ID angegeben werden, die für alle Benutzer als Favorit gelten soll.

Druckkopf wird in einem Untermodul in der Druckvorschau nicht angezeigt

In einem Untermodul in der Druckvorschau wird der Druckkopf oder die Fußzeile nicht angezeigt.

• Customizing-Lösung: In das Makro des Untermoduls, in dem der Druckkopf oder die Fußzeile nicht angezeigt wird, in die on_load() -Methode die folgende Zeile aufnehmen:

mod_obj.get_das()

Unscharfe Schrift unter Windows Server 2008 und Windows 7

Bei der Verwendung von PLANTA auf den Windows-Versionen Server 2008 und 7 kommt es zur unscharfen Anzeige der Schrift. Der Grund dafür ist, dass die global in PLANTA verwendete Schriftart Roboto auf diesen Windows-Versionen nicht installiert ist.

• Lösung: Im Client-Verzeichnis in der Datei \Resources\defaultSkingSettings in der Zeile GlobalFontName:Roboto die Schriftart Roboto durch eine gängige Schriftart, z.B. Arial, ersetzen.

Behobene Probleme 

PPT-Export funktioniert nicht (behoben mit DB 39.5.19)

Lösung:

• Es gibt eine neue Funktion: planta_test.set_send_customizing_names(True/False)

• Der Standardwert (um die funktionalität des webclients zu gewährleisten) ist True, der Powerpoint_Export (api/ppms/customizing/venus/ppms/module_subclasses/powerpoint_export.py -> PowerpointExportCaller) muss mit set_send_customizing_names(False) ausgeführt werden.

Inkorrekte Fehlermeldung beim Versuch Ressourcenzuordnungen zu löschen (behoben mit DB 39.5.19)

Wird versucht, im Modul Terminplan eine Ressourcenzuordnung zu löschen, die Rest- oder Ist-Aufwand aufweist, wird die Meldung Löschen in diesem Datenbereich nicht erlaubt ausgegeben. 

• Lösung: 

  • Die folgende zip-Datei im Ordner /migration/customizing entpacken: Ressourcenzuordnungen_löschen.zip

  • Migrationspaket einlesen und ausführen.

Inkorrekte Aufwand-Rest-Werte unter der Skala (behoben mit DB 39.5.19)

Im Modul Terminplan werden die Aufwand-Rest-Werte unter der Skala inkorrekt dargestellt.

• Ursache:

  • Formate der entsprechenden DIs 

• Lösung:

  • Im Customizer: In der DT204 den Spaltentyp der DI066454 und DI066456 von "Zahl ohne NK, bis 9 Stellen" auf "Zahl mit NK" umstellen.

Diese Lösung behebt nicht das in bestimmten Planungskonstellationen auftretende Problem der Rundungsdifferenzen zwischen den gesamten Aufwand-Rest-Werten und den pro Skalenraster dargestellten  Aufwand-Rest-Werten unter der Skala. Mehr dazu siehe hier.

Die geänderten Aufwand-Rest-Werte sind erst nach Aktualisierung des Moduls Terminplan unter der Skala aktuell (behoben mit DB 39.5.19)

Werden im Modul Terminplan Aufwand-Rest-Werte erfasst oder geändert, sind die neuen Werte unter der Skala nicht nach Speichern oder Berechnen des Terminplans ersichtlich, sondern erst nach Aktualisieren des Moduls, z.B. über den Button

• Lösung: Im Serververzeichnis unter /py/api/ppms/customizing/venus/ppms/ die Datei start_tcalc.py durch diese Datei ersetzen: start_tcalc.py

Bei manchen Vorgängen ist Dauer-Rest immer 1 und lässt sich manuell nicht verändern (behoben mit DB 39.5.18)

Bei manchen Vorgängen wird die manuell vergebene Dauer-Rest nach der Terminrechnung immer mit einer 1 Überschrieben.

• Ursache:

  • In bestimmten Planungskonstellationen kann es vorkommen, dass die Dauer-Soll leer ist. Die Terminrechnung setzt in diesen Fällen die Dauer-Rest auf 1. Wird danach ein Ist-Anfangstermin eingetragen oder ist er bereits vorhanden, kann die Dauer-Rest nicht mehr manuell geändert werden. Versucht man das, wird sie von der Terminrechnung wieder auf die 1 zurückgesetzt.

• Lösung:

  • Im Modul Terminplan das Feld Dauer-Soll einblenden.

  • Eine 1 eintragen.

  • Die gewünschte Dauer-Rest vergeben.

  • Terminrechnung durchführen.

Keine Projektanlage möglich nach Update auf DB 39.5.17 (behoben mit DB 39.5.18)

Es können keine Projekte nach dem Update auf die DB 39.5.17 unter MSSQL angelegt werden.

• Ursache:

  • Das Fehlschlagen des Migrationspakets AddUUIDtoProjectStructure beim Update

• Lösung: Bitte das folgende Script auf der Datenbank ausführen: fix_project_structure_table.sql

Fehlermeldung nach Löschen von Prozessmodell-Phasen (behoben mit DB 39.5.17)

Wurde eine Prozessphase, die in einem Projekt aktiv ist, im Modul Prozessmodell-Templates gelöscht, wird beim Aufruf dieses Projekts oder der Projektübersicht eine Python-Fehlermeldung ausgegeben.

Keine Zeiterfassung unter Skala beim Arbeiten mit mehreren Kalendern möglich  (behoben mit DB 39.5.17)

Ist bei Ihnen die Zeiterfassungs-Variante 2 im Einsatz (Globaler Parameter  Zeiterfassungs-Variante= 2 ) und haben Sie im Modul  Kalender  mehrere Kalender erfasst, ist die Erfassung der Arbeitsstunden im Modul  Zeiterfassung  direkt unter der Sakala nicht möglich oder es wird eine Python-Meldung ausgegeben (MSSQL-Systeme).

Fehlermeldung beim Einloggen von Benutzern mit Portfolio-Rolle (Portfoliomodulen) (behoben mit DB 39.5.17)