Michael Kabisch

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.

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.

Hallo Lea, danke für das Lob. 😉 Wie Du es auch beschreibst: Größte Herausforderung bei dem Thema ist die Bereitschaft der "Oldies", die eigenen (alten) Entscheidungen in Frage zu stellen und wenn das erkennbar ist, die Beharrlichkeit der "Jungen", die richtigen Fragen zu stellen. Dann klappt es auch mit dem Digitalisieren.

Mein Hinweis bezieht sich eher auf den Ablauf zur Erfassung der Bilder. Warum machen die Kollegen x Fotos von der Ladungssicherung und laden die dann später in die Smap? Warum kann der "Fotograf" diese Bilder nicht gleich in der Smap machen? Dann könnte man es wie @Rolf Thielmannbeschrieben hat lösen, wenn man nicht genau weiss, wie viele Bilder es werden. Folgende Fragen: Werden immer alle gemachten Bilder in die Smap geladen oder muss/kann der Smapinator die noch nach Inhalt/Qualität auswählen? Woher weiß der Smapinator in der Galerie, welche Bilder (meist 8 Bilder) zu welcher Ladung/welchem Fahrzeug die Bilder gehören? Ist es jeweils nur ein Vorgang? Wird die Smap auf dem PC oder einem Handy/Tablet mit den Bildern befüllt? Am PC sieht man die Qualität besser und es können auch mehr Bilder dargestellt werden)

Hallo Max, der Wunsch ist für mich (teilweise) nachvollziehbar. Folgende Frage: Woher kommen die Bilder, die in der "Galerie" liegen und dann in eine Smap eingebunden werden müssen? Können die Bilder nicht gleich bei der Fahrzeug-Foto-Dokumentation vom Nutzer in eine Smap integriert werden?

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?

Hab gerade noch einen Eintrag zum DATUM aus dem Oktober gefunden und schreib das in Kurzform rein

Ein eindeutiges JEIN. Prinzipiell schon, aber ich habe festgestellt, dass ich den DSAB nicht immer im gleichen Abschnitt habe, aber sonst ist es die identische App. In einer ganz anderen App mit DSAB wird der richtige Dateiname verwendet.

Hallo Moritz, @Bülent Erbas,@Manuel Rühl Danke für die Bemühungen und Hilfestellungen. Das mit dem API wird dann etwas zu aufwendig und ist nicht mehr "simple" und eine Schulung für die Anzahl von Nutzern beim Kunden mit dem Thema ..... 🤣 Vielleicht ergibt sich ja was, dass ein Datum aus der DSAB übernommen werden kann oder bei der Zeitraumberechnung ein "definiertes" Datum für die Berechnung im Baustein eingetragen werden kann.

kommt man an der Stelle mit DAYS oder TOTALDAYS weiter???

Genau. Das ist der Ansatz, wenn ich nur 1 x den Turnus addieren müsste.

Danke für den Ansatz. Frage: Kann ich für den Zeitraum den Wert aus dem DSAB (z.B. 14 Tage) verwenden? Wie berechne ich die Anzahl, wie oft ich den Turnus dazu addieren muss? anderer Ansatz In Excel ist das Datum "nur " die Anzeige der Zahl der seit dem 1.1.1900 vergangenen Tage in einem Datumsformat. Man kann also aus dem DSAB das Datum als Zahl in die App holen. Kann man das Bestelldatum als Zahl ermitteln im Baustein "Zeitraumergebnis" (Heute, 01.01.1900) ? Kann man in dem Baustein "Zeitraumergebnis" mir einem "festen Datum" rechnen? (ich bekomme beim Format 01.01.1900 eine Fehlermeldung. Kann man den 01.01.1900 als "festes Datum" in einem anderen Baustein eingeben, um es nicht bei jeder Nutzung der App eingeben zu müssen? ? Ist das Ergebnis des Bausteins "Zeitraumergebnis" als Zahl formatiert, mit der man weiterrechnen könnte? In Excel kommt bei der Berechnung mit den "Zahlen" auch der richtige Wert als "Zahl" raus. oder die Berechnung über einen LOOP machen. Startdatum + 1* Turnus > heute = nein -> Startdatum + 2* Turnus > heute = nein -> Startdatum + 3* Turnus > heute = ja -> Datum Anzeigen

Frage: gibt es diese Problematik nicht auch in anderen Fällen? Wenn irgendetwas regelmäßig geprüft werden muss und es Vorschrift ist, die vor Ablauf der Frist zu erledigen. Dann gibt es ein "Startdatum" für die Prüfung und dann muss vor Ablauf eines Jahres eine erneute Prüfung erfolgen. Dann sollte das Startdatum auch aus einer Datenquelle kommen. Dann wird mir das angezeigt und ich tippe es in der App über einen Baustein ein, damit die App damit rechnen kann?

Hallo, der Kunde möchte für seine MA diese Daten in der App haben. 😉 Aktuell berechnen wir die Turnusdaten in Excel und aktualisieren die Daten (jeweils nur 10 Termine) in der App. Die werden dann alle 10 angezeigt und der Nutzer muss schauen, was als nächstes kommt. Die Berechnung in der App mit dem Startdatum aus dem DSAB wäre "die Lösung" und der Nutzer bekommt nur ein Datum angezeigt und der Pflegeaufwand in der App wäre überschaubarer. Mit der Einführung der Bausteine zur Berechnung von Zeiträumen (Startdatum - Enddatum) hatte ich die Hoffnung, dass es klappt. Wochenenden müssen bei der Berechnung nicht beachtet werden, da der Starttag immer in der Woche liegt -> der nächste Turnustag ist auch nicht an einem WE. Bei den Feiertagen gilt " Mut" zur Lücke (in Absprache mit dem Kunden), da hier auch die unterschiedlichsten Regelungen in den einzelnen Bundesländern gelten, wäre ein "keep it simple" sicher nicht mehr "simple".