Derzeit ist im Abfrageeditor nur möglich im "Select-Teil" des Statements eine Quell Tabelle und ein Quellfeld auszuwählen.

Ganz frei kann lediglich der Teil nach dem "WHERE" geschrieben werden.

Wenn es aus Sicherheitsgründen nicht möglich sein sollte, dass komplette Statement frei eintragen zu dürfen, so wäre es sehr nützlich in dem Abfrageeditor typische SQL Funktionen zu ermöglichen.

z.b. count(), max(), last(), unique() etc.

Diese könnten dann ja ebenfalls per Dropdown ausgewählt werden und dem "Select-Feld" zugeordnet werden können.

Dann wäre es endlich möglich im Workflow z.B. eine solche Abfrage zu machen:

SELECT count(rechnungsnummer) AS anzahl_rechnungen FROM rechnungen

oder:

SELECT max(betrag) AS hoechster_betrag FROM Ausgangsrechnungen

...

Somit ergeben sich durch eine kleine Erweiterung im SQL Editor sehr viele Möglichkeiten.

Dies wäre eine Alternative zum komplett freien SQL.

Als Benutzer mit Controller-Funktion (z. B. Buchhaltung) kommt es oft vor, dass man Dokumente über das Archiv sucht und sich dann die Workflow-Historie anschaut. Hier kommt man oft an den Punkt, die Workflow-Aufgabe öffnen zu müssen um diese bearbeiten zu können.
Zurzeit muss man hierzu dann wieder die Controller-Funktion anwählen, den richtigen Workflow, die richtige Workflow-Version und die richtige Aufgabe wählen, was bei mehreren hundert oder mehreren tausend Aufgaben nicht ganz so einfach ist.

Schön wäre es, wenn man (insofern man die entspr. Berechtigung besitzt) in der Historie auf einen Button drücken könnte und sich die Workflow-Aufgabe dann im Controller-View öffnet.

Im WF-Manager in DW 6.7 habe ich zwar die Möglichkeit externe Daten abzufragen, bin aber auf TABLES und rein auf die WHERE-Klausel beschränkt.
Wenn ich einen VIEW nutzen könnte, dann wäre das Problem schon gelöst, da ich ein case select brauchen würde.
Das Thema mit der Where-Klausel könnte man im übrigen auch auf alle anderen Bereiche in Docuware ausweiten - nur die Where-Klausel nutzen zu können beschränkt einen sehr (bei den Auswahllisten kann ja noch ein Subselect machen) In diesem Fall will ich keine AWL sondern für einen zeitkritischen Prozess brauche ich automatisch gefüllt zu diesem Dokument ganz bestimmte Werte und Wenn-Dann Bedingungen um Werte zu verändern um damit dann neue Prozesse "sofort" starten zu lassen. AIX mit Polling ist da nicht schnell genug, bzw. bremst das System zu sehr.

Moin,

derzeit kann man Fälligkeiten / Überfälligkeiten nur starr mithilfe "Anzahl Tage" definieren.
Mein Wunsch wäre, dass man diese Eskalationsstufen auch mit einer GV variabel definieren kann (Dezimalzahl).
neben einer variablen Zahl sollte zusätzlich ein Datumsfeld bzw. Datum&Uhrzeit-Feld genutzt werden können, um die Überfälligkeit zu definieren -das kombiniert mit einer Neuzuweisung wäre sehr mächtig: Damit könnte man eine Wiedervorlage so gestalten, dass z.B. der Admin die Aufgaben solange bekommt, bis das gewünschte Wiedervorlagedatum erreicht ist, dann weist der WF-Manager das Dokument dem richtigen Bearbeiter zu und er bekommt darüber auch gleich noch eine E-Mail..
Voilà: Wiedervorlage ohne umständliche Konstrukte mit zwei Workflows und Autoindex-Workarounds

Dieser Wunsch ist übrigens ähnlich:
https://docuware.uservoice.com/forums/230574-konfiguration-deutsch/suggestions/31339582--zeit-box-in-den-wf-manager-einbauen

Hallo,

ich möchte gerne einen Vorschlag zum Thema DocuWare Forms einreichen. Es geht darum, dass es möglich seine sollte Parameter im Rahmen der URL Ansprache beim Öffnen eines Formulars angeben zu können um so vorhandene Felder bereits auszufüllen.

Beispiel:
In einem Workflow wird der User über die "Link" Funktion aufgefordert ein Formular auszufüllen. Der Workflow hat vorher verschiedene bestehende Indexeinträge in Variablen gespeichert und gibt diese als Parameter im Link an (ähnlich wie bei Splitbooking damit das richtige Dokument gebucht werden kann) um den User das aufzurufende Formular bereits vorauszufüllen (z.B. mit Name, Personalnummer, etc.).

Beispiel für einen solchen Link:
http://dwserver/Docuware/Platform/WebClient/Forms/Formular?orgID=1&Name=Mustermann&Personalnr=12345&Datum=02.07.2018

AutoIndex kann zwar in SQL-Tabellen auch Werte zurückschreiben, dass aber nur wenn es insgesamt keine "sonderbaren" Tabellenspalten gibt, selbst wenn diese augenscheinlich gar nicht verwendet werden! Dies ist by-design so...
Wenn man nun statt Tabelle eine Sicht/View vorauswählt, verschwindet komplett die Wizard Seite mit der Möglichkeit des Updates!
Sicher... Es gibt Definitionen von SQL-Sichten, worüber dann kein Update funktioniert (siehe Limitations zu Oracle, My und MS SQL zu update über eine Sicht). Aber für 99% der Anwendungsfälle mit DocuWare Autoindex reicht eine "normale Sicht" vollkommen und würde massive Vorteile bieten!

-- Ich kann damit alle unnötige Spalten der Tabelle einfach weglassen
-- Ich kann die Spalten in anderer Reihenfolge für bessere Lesbarkeit umsortieren
-- Ich kann auch mit AS jeden gewünschten Spaltennamen "umtaufen", damit alles im AdminTool für den DW Admin verständlicher angezeigt wird.
-- Ich kann mit WHERE schon komplett und exakt so vor-filtern wie ich möchte (,und muss dann diese "Filter-Spalten erst garnicht als Spalten zum DocuWare sichtbar schalten... bspw. im WHERE der VIEW steht DokTyp=Rechnung... dann erspare ich mir, die Spalte DokTyp auch im SELECT angeben zumüssen, um daraufhin im AutoIndex Filter auf Rechnung einzuschränken!)
-- Ich umgehe o. g. Bug vollkommen mit "problematischen Daten-/Spaltentypen", weil ich sie erst garnicht im SELECT der VIEW angebe! Also aus DW Sicht gibt es diese unnötigen Spalten dann garnicht!
-- ich kann sogar sehr individuell mit Cast und Convert und CASE hantieren, und damit a) Datentypen konvertieren, eben damit ein DW Integer in ein SQL VarChar zusammen passt! Und b) Daten umformatieren oder Übersetzen!

Sie sehen also, es gibt sehr Weitreichenden Benefit einer View, wenn DW AutoIndex ein Update per View ermöglichen würde.

Wir setzten bereits fasst IMMER von Beginn an bei LESENDEN Autoindex eine SQL View dazwischen, --selbst wenn wir eigentlich gar keine bräuchten(!)-- ...Wir definieren diese zunächst ohne Manipulation, also 1zu1 mit "SELECT * FROM table", ...aber um eben jederzeit darin Anpassungen vornehmen zu können zukünftig ...denn auch ein ERP-System wird auch mal geupdated und eine Tabellenstruktur ändert sich plötzlich!

Nur fehlt diese Möglichkeit wenn es um die Richtung des Zurückschreibens geht.
Sehr schade eigentlich...

Beste Grüße, Danke für Beachtung,
Tobias Nagel, Firma Ricoh