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

Bekannte Probleme

Problem

Die Summe der unter der Skala dargestellten Aufwand-Rest-Werte einer Ressource kann Rundungsdifferenzen zu dem Aufwand-Rest-Wert dieser Ressource (Fenster 2) aufweisen. Grund: Der Aufwand-Rest-Wert summiert alle Belastungen und stellt dann den Gesamtwert gerundet dar, während die Werte unter der Skala die gerundeten Teilsummen der Belastungen pro Skalenraster darstellen, z.B. pro Monat. Siehe auch Legende im Modul Terminplan.

Beim PDF-Export werden Effekte z.B. auf Balken aktuell nicht unterstützt.

Aufgrund eines MS-Excel-Problems kann es beim Export nach Excel z.B. auf Währungsfeldern in der Excel-Datei zu Formatänderungen kommen, wenn die exportierte Datei zuvor gespeichert wurde.

In Modulen mit Charts kommt es im Bereich dieser beim Scrollen und Zoomen zu einem schwarzen Flackern. Hierbei handelt es sich um ein bestehendes Windows-Problem. Weitere Informationen dazu finden Sie hier.

Ordnet man einem Projekt ein Prozessmodell zu, welches in der ersten Phase keine Prozessschritte enthält, wird am unteren Rand des Moduls Prozessstatus folgende Fehlermeldung ausgegeben: Local Variable akt_pos referenced before assignment. Fehlen die Prozessschritte in den weiteren Phasen des Prozessmodels, wird die Fehlermeldung nicht ausgegeben.
Beim Ändern einer fachlichen ID eines Hauptprojekts kommt es im Modul Teilprojekte gelegentlich zum Vertauschen der Reihenfolge von Unterprojekten, die sich auf der gleichen Strukturebene befinden.
Die Rückmeldung auf Request-Prozessschritte ist zurzeit nicht möglich.

Bekannte Probleme mit Lösung

Leerer Risiken/Chancen-Chart im Portfolio-Infoboard

In den Datenbank-Versionen 39.5.22 und älter in Kombination mit dem Client ab Version 39.5.34.0 werden Risiken/Chancen-Charts im Modul Infoboard (Portfolio) leer angezeigt. 

  • Ursache:
    • Customizing-Einstellung
  • Lösung:
    • Im Datenbereich 057288 das DI062992 (DF-ID 779571) von F9 auf F1 umstellen.

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:

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:


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:

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.

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

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 

Fehlende Jira-Felder im Terminplan nach Verknüpfung mit Jira-System (behoben mit DB 39.5.22)

Obwohl ein PLANTA project-System mit einem Jira-System verknüpft wurde, fehlen im Modul Terminplan die notwendigen Elemente zum Synchronisieren der Vorgänge mit Jira.

  • Lösung: die in py/api/ppms/customizing/venus/ppms/module_subclasses verwendete schedule_module.py mit der folgenden ersetzen: schedule_module.py

Geplante Aufwände verschwinden, wenn man das Event "Nächtliche Neuplanung" ausführt (behoben mit DB 39.5.22)

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

  • Umgehungslösung: 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)
PY


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

Geplante Aufwände verschwinden, wenn ein Projekt auf "Inaktiv" oder "Archiviert" gesetzt wird (behoben mit DB 39.5.22)

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:
    • Auf DB 39.5.22 updaten. 
    • In py/api/ppms/customizing/venus/ppms/planning_object/project/valueranges.py alle Vorkommnisse von "reschedule" mit Suchen und Ersetzen durch "schedule_capacity" ersetzen (dafür sorgt DB 39.5.22).

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. 

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:

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)