Datum: keine vergangenen Daten auswählbar

[Jeanne Merswolken]

Hi zusammen, 

vielleicht gab es die Frage schon, aber in der schnelle habe ich nichts in der Doku noch im Forum gefunden. 

Gibt es eine Möglichkeit bei dem Datumsbaustein keine vergangenen Daten auswählbar zu machen. Kann das über eine Formel gelöst werden und wenn ja wie sieht diese aus?

Danke euch 🙂 

[Philip Alvermann]

Da man in der smap nicht das aktuelle Datum hat, außer es ist in einem Baustein, ist das nicht möglich.

Es gab dazu schon eine ähnliche Diskussion, vielleicht hilft das ja weiter.

Rechnen mit Zeiten wäre schon ein nettes Feature.

[Bülent Erbas]

Eine Relation auf today{} oder now{} wäre sehr hilfreich, dann hätte man es mit einer Formel gut lösen können.

Anpassungsmöglichkeiten im Datumsbaustein habe ich auch keine gefunden.

[Bülent Erbas]

Hi @Jeanne Merswolken,

hier habe ich was Interessantes gefunden.
Evtl. wäre das ein Ansatz mit einer Art Plausibilitätsprüfung. Bedeutet aber natürlich mehr Bausteine und mehr Klicks  für den Benutzer.

 

[Jeanne Merswolken]

Danke euch, schade das es mich keine  „richtige“ Lösung gibt. 🙂 

[Christian Meixner]

Hallo @Jeanne Merswolken,

späte Antwort, aber hier trotzdem noch eine Ergänzung von mir dazu.

Das Problem an dieser Stelle ist tatsächlich, dass Zeit fließen ist. Das heißt, an welchem Punkt in der Zeit macht man fest, was "in der Vergangenheit" ist. So ist der Zeitpunkt, wann mit Ausfüllen begonnen wurde schon mal ein anderer als der, wann ein Baustein in der Mitte der smap ausgefüllt wurden und wieder ein anderer, wann der Datensatz final abgesendet oder gar an den Server übermittelt wird.

Zwischen diesen verschiedenen Zeitpunkten können nur Sekunden, aber durchaus auch Tage liegen, z.B. wenn man den Datensatz erstmal nur als Entwurf speichert und dann später fertig ausfüllt, oder wenn man offline ist und der Datensatz erst Tage später übermittelt werden kann.
Noch komplexer wird es, wenn der Datensatz als Aufgaben an einen anderen Kollegen weitergegeben wird. Auf welchen Zeitpunkt bezieht man sich beim Ausfüllen des betreffenden Bausteins dann? Und gilt für beide Kollegen, welche diesen Datensatz bearbeiten der gleiche Bezugszeitpunkt beim Ausfüllen der Bausteine?

Wenn man nun sagen würde, es gilt immer "jetzt", also die Zeit, die es eben gerade beim Ausfüllend des Bausteins ist: Was wäre dann, wenn ich den Baustein kurz vorm Absenden nochmal bearbeiten will? Gilt dann wieder "jetzt" oder das "jetzt von vorhin" und ist das "jetzt von vorhin" nicht eigentlich schon Vergangenheit?

Beim Absenden des Datensatzes an die Server der smapOne Dienste wäre es aus dieser Perspektive auch schwer zu validieren, ob die smap vom Nutzer korrekt ausgefüllt wurde, weil dieser dazu den jeweiligen Bezugspunkt kennen müsste.

Von daher: leider gar kein so einfaches Thema, wie es auf den ersten Blick vielleicht erscheint.

[Jeanne Merswolken]

Hallo @Christian Meixner, 

ich verstehe die Erklärung und sie erscheint mir sinnig.

"Jetzt" sehe ich aber immer dann als "jetzt" an, wenn die Person den Baustein befüllt unabhängig ob die smap später weiter befüllt oder ob eine Aufgabe verschickt wird. Schließlich geht es um das jetzt von genau dem Baustein und genau der Person, die die smap befüllt.

Schweres Thema und sicher noch mehr Meinungen. Trotzdem vielen Dank für das Feedback 🙂

[Christian Meixner]

Ok. Bleiben wir mal bei eurem Anwendungsfall. Mal angenommen ich starte heute mit dem Ausfüllen des Formulars, kann es aber aus Gründen nicht mehr beenden und setze das Ausfüllen dann morgen fort.

Jetzt ist morgen und bearbeite ich den gestern schon ausgefüllten Datumsbaustein nochmal. Sollte ich dann das Datum, dass ich gestern an genau diesem Baustein einstellen konnte wieder auswählen können, oder soll ich dann nur noch das Datum von heute und zukünftige auswählen können?

Und mal angenommen, man könnte auch beim erneuten Bearbeiten nur das aktuelle "jetzt" auswählen, wäre die smap dann auch korrekt ausgefüllt, wenn ich das Datumsfeld nicht mehr bearbeitet und das Datum von gestern drin stehen gelassen hätte?

Ich weiß, die Fragen klingen spitzfindig, aber das sind tatsächlich genau die Fragen, die wir uns stellen, wenn wir das Verhalten von Bausteinen festlegen - natürlich immer mit dem Ziel möglichst viele Einsatzszenarien abzudecken.

 

Aber: Ich hätte hier noch einen anderen, einfacheren Lösungsvorschlag für dich, als den weiter oben vorgeschlagen.

Mit einem "Zeitstempel"-Baustein als Pflichtfeld am Anfang der smap, könntest du dein eigenes "jetzt" festlegen und dich in nachfolgenden Berechnungen darauf beziehen. Mittels der Formel  kann dann die Differenz zwischen "jetzt" und der Datumseingabe berechnet werden. Dieses Ergebnis kann man dann wieder wiederum benutzen, um einen Texthinweis in der smap anzuzeigen, z.B. wenn der Unterschied mehr als einen tag in der Vergangenheit liegt.

Die Aktivierungsregel für diesem Texthinweis kann dann z.B. so aussehen: 

Der nachfolgende Screenshot zeigt das ganze Konstrukt im Designer und in der smapOne App (für Testzwecke ist hier die ausgerechnete Differenz in der App sichtbar).

[Bülent Erbas]

@Christian Meixner kennt der smapifier etwa schon Formeln die noch nicht freigeschaltet sind? 

Interessant das TODAY() verwendet wird 🤣🤣

[Christian Meixner]

Nein, leider nicht. 😄

Leider ist ja das eine der größeren Herausforderungen von faktenbasierter KI, dass es zuweilen nicht ganz einfach ist, ihr das "Halluzinieren" abzugewöhnen. So erfinden KI Modelle leider immer wieder eigene "Fakten", die so nicht existieren. In der Berichterstattung hatte man ja einiges dazu, gelesen, wie ChatGPT z.B. ganze Bücher, Essays oder Biographien erfunden hat, aber der festen Überzeugung war, dass diese so existieren.

Hier fantasiert sich die KI dann leider eine nicht exsitierenen "Today()" funktion zusammen.

 

Übrigens ist es nicht so, dass wir nicht auch schon über eine solche Funktion nachgedacht haben. Allerdings gelten dabei die gleichen Überlegungen, die ich weiter oben schon genannt hatte. Die Formelfunktion würde, abhängig davon, wann sie ausgeführt wird, unterschiedliche Ergebnisse liefern. So könnte es z.B. sein, dass das Ergebnis "wahr" (true) ist, während der Nutzer den Datensatz ausfüllt, aber später, z.B. wenn der Server den Datensatz auf Gültigkeit überprüft "falsch" (false) herauskommt und die Daten sich somit verändern würden.

Ein definiertes "jetzt", z.B. mit dem Zeitstempelbaustein, wie in meinem Beispiel oben, ist daher unumgänglich, wenn man einen unveränderlichen, jederzeit überprüfbaren Datensatz garantieren möchte.

[Bülent Erbas]

Da gebe ich dir recht, das Thema ist echt kniffelig.

Die Grundproblematik ist ja, so wie du es oben super beschrieben hast, das der Datensatz in dem Moment offen und dynamisch ist.

Vielleicht wäre es eine Überlegung, so wie beim Bericht der Platzhalter {meta.doc_created}, ein internes Datum beim Beginn des Formulars zu setzen {formular.created}. So spart man sich zumindest ein Baustein.
Benötigt man das tatsächliche "jetzt", kann man den Baustein ja optional einsetzen.

Somit hätte man aber die Flexibilität die zeitliche Relation selbst zu bestimmen.

[Philip Alvermann]

vor einer Stunde schrieb Bülent Erbas:

beim Beginn des Formulars zu setzen {formular.created}. 

Wie gehst du dann mit Aufgaben um, die für Wochen im voraus erstellt werden?

[Bülent Erbas]

vor 1 Stunde schrieb Philip Alvermann:

Wie gehst du dann mit Aufgaben um, die für Wochen im voraus erstellt werden?

Dafür gibt es doch jetzt den Zeitpunktergebnisbaustein und die Formeln ADD_PERIOD und SUB_PERIOD und weiterhin die bisherigen Zeitstempel- bzw. Datum und Zeitauswahlbausteine. Die haben ja schon ihren Berechtigungsdasein.
Die obige Überlegung ist ja kein Ersatz, sondern wäre als eine weitere Unterstützung zu sehen.

Als Anwendungsbeispiel nutzen wir smaps in der Produktion um diverse Fertigstellungen zu kommunizieren. Das sind am Tag sehr, sehr viele Fertigstellungen. So würde ich vermeiden, dass jedes Mal der Baustein Zeitstempel genutzt wird, sondern immer das intern generierte Formulardatum automatisch übernommen wird. 
In einem Einzelfall klingt ein Baustein setzen und nutzen natürlich nicht dramatisch. Aber wenn es doch in zwei- bis dreistelligen Bereich geht, wird es für den Nutzer einfach nervig.
 

Bearbeitet 11. August 2023 von Bülent Erbas