Zeitpunktergebnis / Datum und Zeitauswahl mit aktuellem Datum vorbelegen (als Default)

[Marco Liesegang]

Wir möchten ein Zeitpunktergebnis oder Datumsfeld mit dem aktuellen Datum vorbelegen, so das ein Anwender nur bei einer gewollten  Datumsänderung aktiv werden muss.

[Manuel Rühl]

Das geht meines Wissens nach nur mit einem Zeitstempel-Baustein, den man aktiv drücken muss.

Im Bericht gibt es noch das Datum der Absendung, aber das muss ja nicht zwingend der heutige Tag sein: {{meta.submitted_at}}

[Bülent Erbas]

@Marco Liesegang das habe ich auch bereits als Wunsch geäußert und in einem anderen Post besprochen.

So wie @Manuel Rühl geschrieben hat, gibt es aktuell leider nicht.

[Marco Liesegang]

Dann sollte Smapone das mal als Feature request aufnehmen.

[Moritz]

@Marco Liesegang kannst du mal ein konkretes Beispiel/Szenario beschreiben, damit besser ersichtlich wird, warum der vorhandene Zeitstempel- oder Datumsbaustein nicht ausreicht?

[Marco Liesegang]

Beispiel Arbeitszeiterfassung für den aktuellen Tag:
Mitarbeiter steigt früh morgens in sein Auto und soll dort über die App seine Start und Endzeit (dann am Abend erfassen).
Zusätzlich gibt es ein Datumsfeld (für den Tag).

Aktuell muss der Mitarbeiter immer in das Datusfeld klicken und in dem Dialog dann das (dort heute vorausgewählte) Datum "nur" noch bestätigen.

Aber: Das sind 3 Aktionen nur um das heutige Datum in den Feld zu bekommen.
 

Bei einer Vorbelegung, müsste der Mitarbeiter gar nichts machen.

 

 

[Manuel Rühl]

Mit einem Zeitstempel-Baustein muss man nur einmal drücken.
Ich habe aber immer noch eine Abfrage mit "abweichendes Datum?". Wenn man dann auf ja drückt, kann man noch ein Datum erfassen.
Es wird ja auch immer den Fall geben "Oh Mist, ich hab vergessen heute Morgen die Zeit zu erfassen."

[Bülent Erbas]

Ein Beispiel von uns warum wir das gerne hätten:
wir nutzen einige smaps in der Produktion um diverse Fertigstellungen zu kommunizieren. Das sind am Tag sehr viele Fertigstellungen. Ziel hierbei ist so wenig wie möglich den Benutzer mit der smap interagieren zu lassen, sondern viel vorzugeben bzw den Barcode Scanner zu nutzen.
So würde ich vermeiden, dass jedes Mal der Baustein Zeitstempel genutzt wird, sondern immer das aktuelle Datum automatisch übernommen wird. 

Im Einzelfall klingt ein Zeitstempel-Baustein zu setzen und zu nutzen natürlich nicht dramatisch, doch bei sehr vielen Fertigstellungen ist es für den Benutzer angenehmer.

[metek allgemein User]

@Bülent Erbas das Problem habe ich auch. Hätte es gerne smarter.

 

@Moritz @Johanna Becker ich fände es toll, wenn man Beispielsweise in den Metadaten,  z.b. auf das Erstelldatum bzw. Ausfülldatum der smap zugreifen könnte. 

Oder im Bericht das aktuelle Datum einfügen kann ohne Zeitstempelbaustein.

 

Vielleicht ist das etwas fürs nächste Update?😁

[Michael Pfaff]

Als Ergänzung wäre da noch der Wunsch ein Datum basierend auf einer Formel vorzugeben! Je nach Kritikalität (Niedrig, Mittel, Hoch, z.B. über einen Select-Baustein) soll das Datum vor belegt werden:

• Niedrig -> aktuelles Datum plus 2 Wochen
• Mittel -> aktuelles Datum plus 1 Woche
• Hoch -> aktuelles Datum plus 1 Tag

Der Anwender soll aber jederzeit die Möglichkeit haben von den Vorgaben abzuweichen und das Datum zu überschreiben.

 

[Ina Krüger]

Cool wäre es auch, wenn es eine Funktion gäbe, in der ich von einem angegebenen Datum bis heute die Tage oder Jahre rechnen kann.
Also z.B. automatisch der aktuelle Tag gesetzt wird und ich dann von heute bis zum angegebenen Geburtsdatum zurückrechnen könnte, so das ich mir anzeigen lassen kann wie alt die Person aktuell ist.
 

[Bülent Erbas]

vor 21 Minuten schrieb Ina Krüger:

Cool wäre es auch, wenn es eine Funktion gäbe, in der ich von einem angegebenen Datum bis heute die Tage oder Jahre rechnen kann.
Also z.B. automatisch der aktuelle Tag gesetzt wird und ich dann von heute bis zum angegebenen Geburtsdatum zurückrechnen könnte, so das ich mir anzeigen lassen kann wie alt die Person aktuell ist.

Hallo @Ina Krüger,
das kannst du tatsächlich schon berechnen lassen, mit der Funktion SUB_DATE.

So sieht das dann aus:

Die Ausgabe ist in Tagen. Wenn du es noch als Jahr ausgegeben haben möchtest:

[Steffen Haußmann]

Am 13.9.2023 um 10:34 schrieb Bülent Erbas:

Die Ausgabe ist in Tagen. Wenn du es noch als Jahr ausgegeben haben möchtest:

Man habe ich da auf dem Schlauch gestanden... Beim Inventurprotokoll wollte ich den Zeitraum in Monaten angeben, bin aber echt nicht drauf gekommen, einfach die Division zu nutzen bei den Tagen. 🙈 In der finalen Version ist die Angabe jetzt in Tagen. In der Entwicklungsversion habe ich da alles mögliche veranstaltet. Habe die Tage,  Monate und Jahre getrennt. Dann einzeln berechnet. Dann wenn der Tag der letzten Inventur höher war, wurde bei der Monatszahl einer abgezogen. Funktioniert hat es auch, aber wenn ich jetzt drüber nachdenke, wie einfach es gewesen wäre, muss ich schon schmunzeln. Danke für den Blickwechsel.

[Bülent Erbas]

@Steffen Haußmann bei den Datums- und Zeitthemen muss ich auch oft überlegen.. manchmal habe ich einen Wollknäuel im Kopf 🤣

[Annemarie]

Hallo in die fröhliche Zeitbausteine-Diskussionsrunde!

@Marco Liesegang Dein Wunsch der Datumsvorbelegung für Fälle, wo der meist gewünschte Wert schon vorher absehbar ist, ist nachvollziehbar. Das einzuführen, haben wir zwar für die nächste Zeit nicht auf dem Plan, aber auf lange Sicht halten wir es für eine sinnvolle Funktion. Wir haben es als interessante Erweiterung bei uns erfasst, zusammen mit eurem Input.
In dem Zusammenhang danke für die Erläuterungen deines Szenarios, auch an @Bülent Erbas, der sich gleich mit angeschlossen hat! Das hilft immer sehr beim Verstehen.

Ich fasse noch einmal zusammen, was ich mir aus dieser Runde mitnehme:

• Featureidee 1: Ihr wünscht euch Vorbelegung des Bausteins, um Eingabeschritte zu sparen, und häufig geltende Werte schon einzutragen (gern auch mithilfe von Formeln abhängig von vorherigen Eingaben).
• Featureidee 2: Daneben sehe ich noch einen weiteren Wunsch in eurer Diskussion mehrfach auftauchen, nämlich den aktuellen Zeitpunkt, oder zumindest das heutige Datum, in der smap verwenden zu können. Dafür schweben mir zwei mögliche Ansätze vor: 1. Es könnte als Wert ähnlich der Metadaten in Formeln zur Verfügung stehen, oder 2. wir könnten dafür sorgen, dass es in einem Baustein erfasst wird, ohne dass Nutzer erst etwas drücken müssen. Beide Varianten würden dafür sorgen, dass auch @Ina Krügers Altersprüfungsidee mit der SUB_Date-Funktion wie von @Bülent Erbas gezeigt realiserbar wäre, ohne das "Heute" erst auswählen zu müssen.

Wenn ihr noch weitere Szenarien dazu habt, die ihr uns dazu mitgeben möchtet, oder besonders zu Featureidee 2 eure Fantasie spielen lassen wollt, dann immer raus damit!

[Bülent Erbas]

Guten Morgen @Annemarie

für die Berichte gibt es ja den Platzhalter {{meta.doc_created}}.

So ähnlich wie dort könnte ich mir eine weitere Metainformation {smap:created} vorstellen.
Dann könnte man Formeln wie GETDATE() oder TODAY() anwenden. Dafür bräuchte man auch keinen weiteren Baustein.

Aber das das aktuelle Datum erfasst wird ohne Bestätigung klingt auch sehr gut.

 

[Michael Kabisch]

Am 13.10.2023 um 15:24 schrieb Annemarie:

Hallo in die fröhliche Zeitbausteine-Diskussionsrunde!

@Marco Liesegang Dein Wunsch der Datumsvorbelegung für Fälle, wo der meist gewünschte Wert schon vorher absehbar ist, ist nachvollziehbar. Das einzuführen, haben wir zwar für die nächste Zeit nicht auf dem Plan, aber auf lange Sicht halten wir es für eine sinnvolle Funktion. Wir haben es als interessante Erweiterung bei uns erfasst, zusammen mit eurem Input.
In dem Zusammenhang danke für die Erläuterungen deines Szenarios, auch an @Bülent Erbas, der sich gleich mit angeschlossen hat! Das hilft immer sehr beim Verstehen.

Ich fasse noch einmal zusammen, was ich mir aus dieser Runde mitnehme:

• Featureidee 1: Ihr wünscht euch Vorbelegung des Bausteins, um Eingabeschritte zu sparen, und häufig geltende Werte schon einzutragen (gern auch mithilfe von Formeln abhängig von vorherigen Eingaben).
• Featureidee 2: Daneben sehe ich noch einen weiteren Wunsch in eurer Diskussion mehrfach auftauchen, nämlich den aktuellen Zeitpunkt, oder zumindest das heutige Datum, in der smap verwenden zu können. Dafür schweben mir zwei mögliche Ansätze vor: 1. Es könnte als Wert ähnlich der Metadaten in Formeln zur Verfügung stehen, oder 2. wir könnten dafür sorgen, dass es in einem Baustein erfasst wird, ohne dass Nutzer erst etwas drücken müssen. Beide Varianten würden dafür sorgen, dass auch @Ina Krügers Altersprüfungsidee mit der SUB_Date-Funktion wie von @Bülent Erbas gezeigt realiserbar wäre, ohne das "Heute" erst auswählen zu müssen.

Wenn ihr noch weitere Szenarien dazu habt, die ihr uns dazu mitgeben möchtet, oder besonders zu Featureidee 2 eure Fantasie spielen lassen wollt, dann immer raus damit!

Hallo,

ich hatte leider diesen Eintrag überlesen mit meiner aktuellen Anfrage zum Thema DATUM. 

Datum aus DSAB als Datum übernehmen und nicht als Text

Das ist eine ähnliche Konstellation. Die Smap kann aus einem DSAB kein Datum übernehmen, dass ich zur Berechnung benötige.

Wenn das Datum als ZAHL in die Smap übernommen wird, kann man die nicht mit einem DATUM (z.B. Heute) zur weiteren Berechnung heranziehen.

Die Idee 2 würde ich noch erweitern, dass man bei der Vorbelegung ein festes Datum verwenden kann (oder dass es aus einem DSAB kommt)

PS: wo ist das technische Problem, dass aus einem DSAB aktuell nur Zahlen bzw. Text übernommen werden kann und kein Datum?

 

[Annemarie]

@Michael Kabisch Stimmt, das ist ein ähnliches Szenario. Um mit einem Datums- oder Zeitwert aus einem DSAB weiter rechnen und ihn in den Zeitformeln verwenden zu können, müsste er auch vom Typ Datum / Zeit sein, oder dahin umgewandelt werden können. Aktuell wird für DSAB-Daten nur zwischen den Typen Text und Zahl unterschieden. Ein Zeit-Datentyp wäre eine sinnvolle Erweiterung.

Hier öffnen wir dann allerdings auch die Büchse der Pandora, die "Zeitzonen" heißt. Hat jemand von euch Fälle, die sich nicht nur innerhalb einer Zeitzone abspielen, und hat schon ein Wunschverhalten für den Umgang mit DSAB-Zeitwerten identifiziert, oder Ideen dazu? Das würde mich interessieren. Beispiele: Kombinationen aus Datum und Uhrzeit im DSAB könnten grundsätzlich als UTC gehandhabt werden. Oder: Sie werden gar nicht in andere Zeitzonen umgerechnet, sondern immer gleich beibehalten, wie Werte von Datums- und Zeitauswahlbausteinen aktuell auch.

[Bülent Erbas]

@Annemarie
zum Thema UTC ist mir direkt folgender Beitrag eingefallen:

Das könnte durchaus ein Szenario sein, worüber man stolpern könnte.

[Steffen Haußmann]

Hallo @Annemarie,

Beim Thema Zeitzonen bin ich bei dir. Das kann es wirklich schnell kompliziert werden lassen und für einige wird es in der Nutzung der smaps auch schwierig. 

Wenn würde ich diesen gern ohne Umrechnung haben wollen. Wenn diese dann nötig ist, kann man es dann entweder vorab für den DSAB machen, oder hinterher etwas aufwendiger in der smap. 

[Michael Kabisch]

Hallo,

erweitert bitte meinen Horizont. Vielleicht denke ich zu einfach beim Datum (Zeitzonen) oder andere zu kompliziert? (Anm: ich benötige "nur" das Datum)

Die folgenden Fragen habe ich beim Thema DATUM (und Zeitzone?) bei einer Smap.

In welchen Fällen ist die Zeitzone beim Datum eine Herausforderung in einer Smap? 

Wenn jemand in einer anderen Zeitzone eine Smap bedient und einen Zeitstempel setzt, steht auch die lokale Zeit vom Ausfüllort drin? Oder eine andere?

Mit welcher Zeit wird der Datensatz in der App gespeichert? Mit der Zeit, wo sie versendet wurde oder wann Sie am Server angekommen ist? In den Datensätzen habe ich ja beide Angaben? Welchen Einfluss hat es, wenn z.B. der Datensatz vor dem Empfangszeitpunkt erstellt wurde? Fehlermeldung?

Gibt es schon Apps, bei denen Vorgänge in verschiedenen Zeitzonen laufen und die unterschiedlichen Zeitzonen eine Rolle spielen oder ist das eher theoretischer Natur?

Für meinen Anwendungsfall findet alles in der selben Zeitzone statt.

Für Rückinfos, bei welchen Anwendungsfällen die Zeitzone ein Herausforderung darstellt wäre ich dankbar.

 

[Annemarie]

Die Zeitzonenfrage stellt sich für mich eher, wenn es um Datums- und Zeitwerte zusammen geht, also konkrete Zeitpunkte. 
@Michael Kabisch Wenn du nur das Datum brauchst, wäre das ein unkomplizierter Fall. 
Ich kann mir allerdings vorstellen, dass es nicht allen so geht.

Generell etwas Hintergrund zum Verhalten mit Zeitzonen in smaps:
Für Datensätze wird sowohl der Zeitpunkt des Absendens beim smap-Nutzer erfasst, als auch des Eintreffens der Daten. Für beide Ereignisse wird die jeweilige Zeitzone (genau genommen der Unterschied von UTC in Stunden) mit aufgenommen. Das ermöglicht das Anzeigen beider Werte in der Zielzeitzone des Betrachters.
Genauso wird für Zeitpunkte, die mit Zeitstempel-Bausteinen erfasst werden, die Zeitzone berücksichtigt und der Wert umgerechnet angezeigt, wenn er an anderen Stellen ausgegeben wird. Da das "Jetzt" des Erfassers ja nicht dem "Jetzt" des Empfängers entspricht. Das betrifft z.B. die Anzeige der eingegangenen Daten für Creatoren, oder die Anzeige für Aufgabenempfänger. 
Anders ist das Verhalten beim Baustein zur Datums- und Zeitauswahl: Mit ihm wird nicht zwangsläufig der aktuelle Zeitpunkt bezogen auf den Erfasser ermittelt, sondern kann ein beliebiger Wert gesetzt werden, der unterschiedlich gemeint sein kann. Außerdem kann wahlweise ja auch nur ein Datum oder nur eine Uhrzeit erfasst werden, wo Umrechnung wenig Sinn ergeben würde. Daher werden für alle Werte, die dieser Baustein erfasst, keine Zeitzoneninfos mit aufgenommen, und die Werte werden unabhängig von möglichen Zeitzonenunterschieden zwischen Erfasser und anzeigender Person immer gleich angezeigt.
 
Befinden sich alle Beteiligten in Deutschland, fällt bei Zeitpunkten, die die Zeitzone berücksichtigen, nichts weiter auf. Aber verreist z.B. ein smap-Nutzer oder arbeitet dauerhaft an einem anderen Ort als beispielsweise Aufgabenempfänger oder Creatoren, dann beginnt es, eine Rolle zu spielen. Wir haben Fälle, wo smaps in ganz anderen Teilen der Welt genutzt werden und auch an sich ändernden Orten, zum Beispiel in der Logistik-Branche. Und auch in diesen Fällen soll alles zuverlässig sein. Daher sollen die Zeitzonenproblematiken nicht unberücksichtigt bleiben, sobald Zeitpunkte ins Spiel kommen.

Wenn jemand konkrete Beispiele für Szenarien mit Zeitzonen teilen möchte, bin ich sehr neugierig darauf, was ihr berichtet!

Bearbeitet 8. Februar von Annemarie

[Christian Spratte]

Hallo,

Vielleicht als Ergänzung zur Frage nach dem aktuellen Datum, das für die interne Verarbeitung in der Smap zur Verfügung steht:
Ich würde gerne eine Smap für unsere Übergaben auf dem Schiff erstellen. Es gibt eine Datenbank mit der Information wer auf welcher Reise an Bord sein wird. Ich würde nun gerne das Feld des Ausfüllenden gerne vorbelegen mit dem Namen der Person, die als Schiffsführung im aktuellen Zeitraum aktiv ist und für eine eMail zur Übergabe automatisch aus der Datenbank die Adresse der nachfolgenden Person einsetzen. Dadurch könnte man bei der Übergabe einfach nur die relevanten Werte erfassen und auf absenden drücken und durch eine direkte Mail die nachfolgende Crew informieren.

Dadurch könnten wir Zentralisierung reduzieren und unseren Schiffsführer*innen helfen, sich direkt bilateral über den Zustand des Schiffs zu informieren.

Herzliche Grüße
Christian

[Michael Kabisch]

Am 1.2.2024 um 16:34 schrieb Annemarie:

Die Zeitzonenfrage stellt sich für mich eher, wenn es um Datums- und Zeitwerte zusammen geht, also konkrete Zeitpunkte. 
@Michael Kabisch Wenn du nur das Datum brauchst, wäre das ein unkomplizierter Fall. 
Ich kann mir allerdings vorstellen, dass es nicht allen so geht.

Generell etwas Hintergrund zum Verhalten mit Zeitzonen in smaps:
Für Datensätze wird sowohl der Zeitpunkt des Absendens beim smap-Nutzer erfasst, als auch des Eintreffens der Daten. Für beide Ereignisse wird die jeweilige Zeitzone (genau genommen der Unterschied von UTC in Stunden) mit aufgenommen. Das ermöglicht das Anzeigen beider Werte in der Zielzeitzone des Betrachters.
Genauso wird für Zeitpunkte, die mit Zeitstempel-Bausteinen erfasst werden, die Zeitzone berücksichtigt und der Wert umgerechnet angezeigt, wenn er an anderen Stellen ausgegeben wird. Da das "Jetzt" des Erfassers ja nicht dem "Jetzt" des Empfängers entspricht. Das betrifft z.B. die Anzeige der eingegangenen Daten für Creatoren, oder die Anzeige für Aufgabenempfänger. 
Anders ist das Verhalten beim Baustein zur Datums- und Zeitauswahl: Mit ihm wird nicht zwangsläufig der aktuelle Zeitpunkt bezogen auf den Erfasser ermittelt, sondern kann ein beliebiger Wert gesetzt werden, der unterschiedlich gemeint sein kann. Außerdem kann wahlweise ja auch nur ein Datum oder nur eine Uhrzeit erfasst werden, wo Umrechnung wenig Sinn ergeben würde. Daher werden für alle Werte, die dieser Baustein erfasst, keine Zeitzoneninfos mit aufgenommen, und die Werte werden unabhängig von möglichen Zeitzonenunterschieden zwischen Erfasser und anzeigender Person immer gleich angezeigt.
 
Befinden sich alle Beteiligten in Deutschland, fällt bei Zeitpunkten, die die Zeitzone berücksichtigen, nichts weiter auf. Aber verreist z.B. ein smap-Nutzer oder arbeitet dauerhaft an einem anderen Ort als beispielsweise Aufgabenempfänger oder Creatoren, dann beginnt es, eine Rolle zu spielen. Wir haben Fälle, wo smaps in ganz anderen Teilen der Welt genutzt werden und auch an sich ändernden Orten, zum Beispiel in der Logistik-Branche. Und auch in diesen Fällen soll alles zuverlässig sein. Daher sollen die Zeitzonenproblematiken nicht unberücksichtigt bleiben, sobald Zeitpunkte ins Spiel kommen.

Wenn jemand konkrete Beispiele für Szenarien mit Zeitzonen teilen möchte, bin ich sehr neugierig darauf, was ihr berichtet!

Danke für die ausführlichen Erläuterungen.

Vielleicht wäre ein Ansatz, dass man bei einem Berechnungsbaustein mit Datum/Zeit darauf hinweist. dass dies z.B. nur in einer Zeitzone gemacht werden kann.