Feature-Wunschliste

1. offizieller Beitrag

    Pünktlich zu Weihnachten meine Wunschliste, was ich gerne in vertec noch an Features hätte. Alles eher kleinere Ergänzungen aus der Welt der Berichte/Scripts/Customizing. Ich würde mich freuen, wenn vertec etwas davon implementieren könnte. Danke.


    Möglichkeit, auf einem (erweiterten) Office-Bericht wieder mehrere Word-Vorlagen als (Sprach-)Varianten zu hinterlegen

    In den Legacy Office-Berichten konnten mehrere Sprachversionen der Vorlagen hinterlegt werden. In den neuen Office-Berichten gibt es stattdessen den Übersetzungsmechanismus, der ganz gut funktioniert, wenn in einer eher zahlenlastigen Auswertung einzelne Wörter oder Begriffe übersetzt werden sollen. Wir haben jedoch einige Dokumente (z.B. Vollmachten, Auftragsbestätigungen, Vollständigkeitserklärungen), die oft nur die Adresse und den Kundennamen aus vertec holen, aber aus umfangreichen Legal-Textblöcken bestehen, die teilweise statisch sind, teilweise über ein Flag aus vertec ein- oder ausgeblendet werden. Für diese ist der Übersetzungsmechanismus nicht gut geeignet, und eine Alternative wie früher wäre wünschenswert. Der aktuelle Workaround besteht darin, entweder im selben Bericht alle Sprachen hintereinander mit verschiedenen Bands zu haben, oder separate Office-Berichte zu führen und mit Anzeigebedingungen nur die zutreffende Sprache anzuzeigen, was aber beides auch schwerfällig ist.

    Mein Vorschlag könnte sogar verallgemeinert werden, indem auf einem Office-Bericht unabhängig von der Sprache (bei gleichem Code für alle) mehrere Word-Vorlagen als Varianten hinterlegt werden, und dann im Code über eine Context-Variable gesteuert wird welche verwendet wird. Damit könnten neben verschiedenen Sprachen auch z.B. verschiedene zeitpunktabhängige Versionen eines Dokuments, oder je Projekttyp verschiedene Rechnungslayouts (für verschiedene Mandanten in der Unternehmensgruppe) einfach und ohne Redundanz implementiert werden.

    Im Hinblick auf das absehbare Ende der Legacy Office Berichte wird eine solche Möglichkeit noch wichtiger und würde den Umstieg deutlich erleichtern - ich merke wie mich beim Ersatz einiger Legacy-Berichte vor allem das Problem der Mehrsprachigkeit noch etwas ratlos zurücklässt.


    Bei (erweiterten) Office-Berichten aus dem Code auf die angelegte Aktivität zugreifen

    Bei einigen unserer Berichte würde ich gerne nach der Berichtserstellung eine Zusammenfassung in die Aktivität schreiben (Bsp. vor der Berichterstellung wird via Dialog abgefragt, welche Elemente/Textblöcke angedruckt werden, oder eine optionale Adresse ausgewählt, oder es ergibt sich aus der Berichterstellung der Gesamtpreis einer Offerte, usw.)

    Bei den Legacy-Berichten gab es dafür eine spezielle Funktion AfterReport, die bei den Office-Berichten fehlt. Und aus dem Berichtscode komme ich zwar an allfällige Aktivitäten des Objekts heran, aber nicht an die mit dem Bericht, da diese offenbar erst nach dem Durchlauf des Scripts angelegt wird.


    Auch bei Listenscripts die Möglichkeit, eine Anzeigebedingung anzugeben

    Bei Scripts auf einem Einzelobjekt lassen sich Berechtigungen am einfachsten über eine Anzeigebedingung, die den eingeloggten User abfragt, umsetzen (mir ist klar dass das alternativ auch über Benutzergruppen geht, ist aber dort komplexer und erfahrungsgemäss fehleranfälliger). Bei Scripts auf Listen wird die Anzeigebedingung aktuell ignoriert. Heute gar nicht umsetzbar ist, ein Listenscript nur auf einer bestimmten Listenauswertung anzubieten (sondern es erscheint immer auf allen Listen, die die entsprechende Klasse enthalten).

    Falls eine Auswertung beliebiger Bedingungen auf Listenscripts zu Performanceproblemen führt, könnte das ev. eingeschränkt werden, dass nur auf globale Objekte (v.a. eingeloggter User) oder den Listencontainer selbst, aber nicht auf dessen Einträge abgefragt werden kann.


    Bei Änderungs-Eventscripts auf den vorherigen Zustand des geänderten Felds zugreifen

    Denkbar wäre zusätzlich zu den bestehenden Variablen args.eventmember und args.eventtype noch eine weitere Variable z.B. args.previousvalue einzuführen, die den Zustand des Felds vor der gemachten Änderung übergibt.

    Damit könnten einfach Sicherheitsabfragen oder Eingabeprüfungen gemacht, und eine Feldänderung wenn nötig rückgängig gemacht werden.


    Bei XML-Grids auf Seiten die Möglichkeit, Schrift- und Hintergrundfarbe dynamisch als OCL Expression anzugeben

    Aktuell können im Seiten-Customizing in den Grid-Tabellen nur fixe Farben pro Spalte angelegt werden. Wünschenswert wäre, hier zumindest die Farben, ev. auch noch weitere Eigenschaften analog den Listeneinstellungen, dynamisch aus dem Zeileninhalt zu berechnen.


    Bei Scriptbuttons die Möglichkeit, das argobject oder einen zusätzlichen Parameter als Expression festzulegen

    Damit würde es möglich, in einer Seite mehrere Buttons zu platzieren, die dasselbe Script aufrufen, aber leicht verschiedene Dinge tun (z.B. verschiedene Vorgaben eintragen, verschiedene verlinkte Objekte aufrufen etc.). Im Moment geht das nur, indem mehrere sehr ähnliche Scripts parallel registriert werden, oder in einem Script mittels Dialog unterschieden wird was zu tun ist.

    • Offizieller Beitrag

    Vielen herzlichen Dank für die Anregungen und Feedback! Da spricht ein Vertec Connoisseur.


    Kurz vor Weihnachten noch einige Bemerkungen und Rückfragen:


    Möglichkeit, auf einem (erweiterten) Office-Bericht wieder mehrere Word-Vorlagen als (Sprach-)Varianten zu hinterlegen


    Wir haben uns ganz bewusst für nur eine Vorlage entschieden, sehen aber natürlich die Nachteile gegenüber den Legacy Office-Berichten, die Sie erwähnen. Warum eine Vorlage: weil man so auch nur eine pflegen muss, da Word ja keine (automatische) Möglichkeit zur Verlinkung und Vererbung von Vorlagen kennt. Ein grosser Vorteil der Office-Berichte ist ja, dass man den Code nur einmal hat (in den Legacy Office-Berichten hat man den pro Sprachvariante), und wir haben gerade mit 6.6.0.3 (https://www.vertec.com/ch/kb/vertec-version-6-6/) an der Wiederverwendbarkeit von Code gearbeitet (über die neue reportdef Eigenschaft). Sie könnten also mit dieser Version schon verschiedene Sprachvarianten haben (als unabhängige Reportobjekte und folglich auch unabhängig Word-Dokumente) und den gemeinsamen Code via import von einem zentralen Modul laden. Schauen Sie sich das doch mal an und geben Sie uns ein Feedback, ob das schon genügend ist.


    Bei (erweiterten) Office-Berichten aus dem Code auf die angelegte Aktivität zugreifen


    Ja, das ist eine Einschränkung. Der Reportcode selber ist dabei einfach sehr weit weg von der Dokumentenspeicherung (und folglich der Aktivität), da eine Abhängigkkeit einzubauen wird nicht einfach sein. Dass man die Aktivität im AfterReport im VBA hatte war eher ein Nebeneffekt, aber wir wissen, dass der geschätzt wurde. Ich nehme Ihre Anregung mal in interne Diskussionen mit.


    Auch bei Listenscripts die Möglichkeit, eine Anzeigebedingung anzugeben


    Die Anzeigebedingung ist ja eine OCL Expression, bei einem Einzelobjekt ist ja total klar, worauf die ausgeführt wird (nämlich auf dem Objekt). Bei einer Liste ist das hingegen nicht klar: auf dem Container (Ordner, Linkcontainer) oder gar auf der Liste? Der erste Fall würde vermutlich nicht viel nützen, im zweiten Fall würde man dann durch alle Objekte der Liste durchfahren und irgendwas abfragen, was zu Performanceproblemen führen kann, wenn die Expression "teuer" ist - bei jedem Rechtsklick müsste man also warten. Das hat uns abgeschreckt, es gibt schon genügend Gelegenheit in Vertec, mit komplexen Customizings die Performance zu beeinträchtigen.


    Darf ich fragen was Sie im Hinterkopf haben? Welche Art von Anzeigebdingung wäre das denn? Wenn es nur um das Login geht, könnte man auch mit Berechtigungen erwirken, dass gewisse Skripts für gewisse Users nicht zur Verfügung stehen.


    Bei Änderungs-Eventscripts auf den vorherigen Zustand des geänderten Felds zugreifen


    Das ist fast unmöglich, denn die ganze Business-Logik hat den neuen Wert schon verarbeitet. Auch funktionieren die Event-Skripts ja auch auf Listen, da wäre es noch komplexer. Wenn Sie das aber für gewisse simplen Members haben wollen, kann das einfach via ein "Schattenfeld" (z.B. via keys) gemacht werden, so à là:

    Code
    if wir_wollen_den_neuen_wert_doch_nicht:
    argobject.meinfeld = argobject.getkeystring("schatten_meinfeld")
else:
    # machen was immer ich noch machen will
    argobject.setkey("schatten_meinfeld", argobject.meinfeld)


    Bei Scriptbuttons die Möglichkeit, das argobject oder einen zusätzlichen Parameter als Expression festzulegen


    Schauen Sie mal die neuen Custom Renderer an, da gibt es den display_type = "button", siehe https://www.vertec.com/ch/kb/custom-renderer/. Beim Klicken wird button_clicked(self, rowobj, expression) aufgerufen, hier kann man nur schon über die übergebene Expression dann anderen Code aufrufen. Wenn das nicht geht, halt einfach verschiedene Renderers machen für die unterschiedlichen Buttons, welche dann eine weitere Python Funktion aufruft mit einem Parameter.

    Danke für die Hinweise. Gerade bei den neuen Custom Renderern sehe ich viele interessante Möglichkeiten. Allerdings konnte ich mich damit bisher nur theoretisch befassen, da wir noch am Planen eines geeigneten Updatefensters auf 6.6 sind.


    zu 1 (mehrere Word-Vorlagen auf Office-Berichten):

    Der naheliegende Workaround ist sicher, verschiedene (Sprach-/ Mandanten-/ Versions- usw.) Varianten als grösstenteils identische separate Berichte anzulegen. Die Möglichkeit, den Code zu zentralisieren, kann das sicher etwas vereinfachen, jedoch bleibt immer noch Redundanz, und die Steuerung der Variante wäre dann immer noch mehrfach über die OCL-Anzeigebedingung vorzunehmen.

    Je länger ich drüber nachdenke, desto mehr habe ich den Eindruck, pro Bericht wieder verschiedene Vorlagen, und die Steuerung welche genommen wird aus dem Berichtscode vorzunehmen, wäre flexibler und könnte sehr mächtige Möglichkeiten bieten.


    zu 3 (Anzeigebedingung auf Listenscripts):

    Ich kann mir ebenso kaum sinnvolle Anzeigebedigungen vorstellen, die auf die einzelnen Einträge der Liste zugriefen und diese auswerten (was wohl performancemässig sehr problematisch wäre). Hingegen sehe ich zwei häufige Anwendungsfälle, wo mir diese Möglichkeit fehlt:

    • Berechtigungssteuerung, dh. Script nur eine bestimmten Person/Gruppe zugänglich machen. Das ginge zwar auch über Benutzgruppen und Objektberechtigungen, nur sind die halt schon deutlich komplexer und damit auch aufwendiger zu troubleshooten.
    • Steuerung, auf welchen Containern im Baum das Script zur Verfügung steht. Aktuell ist das gar nicht möglich, sondern das Script erscheint immer auf allen Containern, die Einträge der entsprechenden Klasse haben
      (Beispiel von uns: Wir haben eine Zusatzklasse für Steuererklärungen, für die wir eine Vielzahl von verschiedenen Auswertungen/Darstellungen/Aspekten haben. Eine davon zeigt beantragte/gewährte Steuerfristen an, und es gibt ein Script, um für alle Einträge einer Liste diese Frist zu setzen. Dieses macht aber nur auf der Liste Sinn, wo tatsächlich die Fristen der Steuererklärungen das Thema sind. Bei allen anderen Auswertungen dieser Klasse ist das nur ein Risiko dass jemand draufklickt und nicht weiss was er tut).

    Wenn die Auswertungsmöglichkeit der Anzeigebedingungen so eingeschränkt wird, dass nur solche globalen Abfragen (zumindest eingeloggter User und aktueller Container im Baum), aber kein Zugriff auf die Einträge möglich sind, dann liesse sich das wohl ohne Performancerisiko umsetzen.

    • Offizieller Beitrag

    Vielen Dank für das wiederum sehr fundierte Feedback!


    zu 1 (mehrere Word-Vorlagen auf Office-Berichten)

    Ich kann die Argument nachvollziehen. Wir werden das im Produktmanagement mal durchdenken. Für uns waren eben die Vorlagen pro Sprache ein Horror, weil kleinste Änderungen eben dann in vielen Vorlange nachvollzogen werden müssen. Ich kann mir kaum vorstellen, dass wir zurück wollen zu obligatorischen Sprachevarianten. Allerdings ist uns auch bewusst, dass z.B. für Word-Vorlagen, die nachher bearbeitet werden müssen (z.B. Angebote) dann u.U. das Word-File gar nicht richtig konfiguriert ist bez. Sprache, Datumsformat etc.


    zu 3 (Anzeigebedingung auf Listenscripts)

    Man könnte sich in der Tat eine Anzeigebedingung auf das angewählte Objekt vorstellen, wie bei den Skripts auf einzelnen Einträgen. Das wäre dann der Ordner / Container und würde die Anforderung im 2. Bulletpoint befriedigen.

    Uns sind seit unserer Einführung auch ein paar Punkte aufgefallen. Die fallen zwar eher in den Bereich der Usability, aber wären trotzdem nice-to-have.


    • Suchen abbrechen.

    Sucht man in einem Ordner egal welcher Art kommt es manchmal leider vor das man durch ungünstige Filter extrem viele Ergebnisse produziert. Aktuell sucht Vertec hier einfach ewig weiter. Mir ist aktuell kein Weg bekannt (außer beenden der Session) diese Suchen abzubrechen. Wäre es denkbar dem User nach einer bestimmten Zeit die Möglichkeit zu geben die Suche abzubrechen?


    • Tab in neues Fenster ziehen

    Die Funktion kennt man vielleicht aus dem Browser. Ein Tab lässt sich per drag & drop einfach in ein neues Fenster ziehen. Über Shift+Enter ist das aktuell ja schon ziemlich schnell in Vertec möglich. Aber vor allem für schon bestehende Tabs wäre des denke ich eine schöne Lösung schnell neue Fenster zu öffnen.


    • Tastenkürzel

    Ich würde mir mehr Möglichkeiten für Tastenkürzel in Vertec wünschen. Aktuell gibt es ja nur die fest definierten. Es wäre z.B. schön Tastenkürzel für eigene Skripts zu definieren. Auch für Standardfunktionen wie Anrufen wäre das durchaus praktisch.


    • Linktypen Bezeichnung über OCL

    Wenn ich in zwei Tabs den Link Rechnungen in unterschiedlichen Projekten öffne habe ich keine Möglichkeit im Namen des Tabs zu erkennen was ich genau geöffnet habe. Mir ist bewusst das das ändern der Bezeichnung über OCL auch nicht die schönste Lösung ist, im Baum würde dann ja vermutlich auch dieser neue Name angezeigt. Ich wollte das nur mal anregen da es Nutzern bei uns häufig aufgefallen ist. Es wäre schön, wenn man das irgendwie verbessern könnte.


    • SQL Ordner gleiche Ergebnisse

    Vielleicht ist das auch eher ein Bug. Aber wenn ich aktuell den gleichen SQL Ordner in zwei Tabs geöffnet habe sind die Ergebnisse immer synchron egal was für Suchbefehle ich in welchem Tab abgebe. Meine Erwartung wäre das ich nach Suche 2 im zweiten Tab immer noch die Ergebnisse der ersten Suche im ersten Tab sehe. Aktuell würde ich aber im ersten Tab dann auch die Ergebnisse der zweiten Suche sehen.

    • Offizieller Beitrag

    Vielen Dank für die detaillierten Beobachtung und Vorschläge! Ich versuche diese einzusortieren und zu bewerten:


    Suchen abbrechen: das hören wir oft, ist aber nahe bei "unmöglich". Das Vertec Objektsystem ist darauf angewiesen, das einzelne Objekte entweder ganz geladen sind oder nicht, und die ganze UI Anbindung (https://www.vertec.com/ch/kb/v…bindung-an-das-ui-modell/) baut darauf auf. Aus diesem Grund kann man das nicht vergleichen mit (z.B.) einer SQL-Abfrage, die einfach nur Resultate liefert.


    Tab in neues Fenster ziehen: In der Web App geht das ja schon, da stellt der Browser das zur Verfügung. In den Windows Apps geht das nicht, wäre aber eine coole Sache, das sehe ich auch so. Es ist aber auch so nicht so weit weg, gibt es diese Option doch auch überall im Rechtsklick Menü:



    Tastenkürzel: die Idee hatten wir auch schon, eine Implementation ist aber immer Wichtigerem / Dringenderem gewichen. Damit wir vielleicht noch etwas Motivation tanken können, um das höher zu priorisieren: was für Skripts sind das? Wie häufig führt man die aus? Man muss dazu auch sagen, dass wir zwar schon sehr auf Tastaturbedienbarkeit achten (z.B. bei der Listenerfassung), viele User aber ausschliesslich mit der Maus arbeiten (auch in Comboboxen, wo eine inkrementelle Suche bedeutend schneller wäre).


    Linktypen Bezeichnung über OCL: Das Problem kennen wir und wird auch in der Kundenzufriedenheitsumfrage immer wieder angemerkt. Bis jetzt haben wir keine Lösung für eine bessere Orientierung wenn man viele Vertec Tabs offen hat, dynamische Bezeichnung von Linktypen sind aber vermutlich nicht die Lösung, weil diese Bezeichnung ja auch im Baum verwendet wird.


    SQL Ordner gleiche Ergebnisse: Bug oder Feature ;) Das erstaunt immer wieder, aber auch Ordner sind "einfache" Vertec Objekte die einfach in verschiedenen Tabs dargestellt werden. Der Inhalt eines Ordners (also was er gerade darstellt) ist auch einfach eine Eigenschaft dieses Objekts, wie z.B. der Code eines Projekts. Insofern ist das "behaves as designed" und es wäre schwierig, für solche Ordner ein anderes Verhalten zu implementieren.

    Ich antworte auch nochmal kurz.


    Suche abbrechen: In dieser Situation wäre es mir aber ja egal ob etwas geladen ist. Ich würde einfach wieder gerne ein nutzbares Vertec Fenster haben. Wenn dann der Ordner wieder in den Urzustand gesetzt wird wäre das ja auch schon eine Besserung. Aber wenn ich Ihre Antwort richtig verstehe ist das dann schon schwierig.


    Tab in neues Fenster ziehen: Ja das stimmt dann ist der Tab aber halt auch noch zusätzlich im alten Fenster geöffnet. Wäre wie sie schon schreiben einfach eine coole Sache um schnell ein neues Fenster zu generieren.


    Tastenkürzel: Wir haben konkret ein Skript über das wir unsere zu versendenden E-Mails generieren. Das wird von den meisten Nutzern mehrmals täglich ausgeführt. Mit der Mausbedienung ist das bei uns vermutlich ähnlich. Tastenkürzel sind ja in den meisten Anwendungen etwas für Power-User die freuen sich dann aber umso mehr. :)


    Linktypen Bezeichnung über OCL: Ja das hatte ich ja auch direkt angemerkt. Eventuell könnte man ein zweites Feld nur für den Namen des Tabs einfügen?


    SQL Ordner gleiche Ergebnisse: Für sie und mich ergibt das sicher so Sinn. Für die meisten Nutzer ist der aktuelle Zustand aber einfach nur mehr als verwirrend. Das verhalten geht ja komplett gegen das was von der Anwendung in dieser Situation erwartet wird. Auch wenn es schwierig wäre denke ich das das Verhalten hier angepasst werden sollte.

    Tab in neues Fenster ziehen fände ich auch super. Allenfalls kann man das Kontextmenu auf dem Tab erweitern ("in neues Fenster verschieben").

    Da ich diese Funktion meist brauche, wenn ich Objekte verknüpfen muss (Korrespondenzadressen, eigene Outlook-Synchronisations-Adresse, etc.) wäre eine gute Variante für mich auch, wenn ich die Zuweisung über den Tab machen könnte (Drag & Drop des Tabs verknüpft die Objekte).