[Release v1.123 - Kategorien für smaps [Update 2]]

vor einer Stunde schrieb Manuel Rühl:

Danke, ist mir gestern auch schon aufgefallen, wollte aber nicht gleich wieder meckern. 😉

Das ist kein Meckern, das ist das gewünschte Feedback 🙂.

[Release v1.123 - Kategorien für smaps [Update 2]]

Schön wäre wenn man in der Ansicht "Alle smaps" erkennen könnte, ob eine smap schon in einer Kategorie ist und wenn ja in welcher. 

[Die neue Web-App von smapOne]

Ich hoffe man kann später an der smap einstellen das man diese nicht mit der Web-App benutzen kann.
Außer die Verlinkung in Mails, Aufgaben etc. und smap's über QR-Code zu öffnen, sehe ich da keinen so großen Mehrwert.

Für uns war die Offlinefähigkeit der Clients eins der wichtigsten Punkte bei der Entscheidung für smapOne.

[Farbe/Design im Kopf]

https://platform.smapone.com/Documentation/de/Topic/Reports#berichte-individualisieren

[Alternative zu Wiederholungsgruppe in Wiederholungsgruppe gesucht]

Warum nicht den DSAB mehrfach verwenden?

https://faq.smapone.com/kb/guide/de/was-muss-ich-beachten-wenn-ich-einen-dsab-mehrmals-einbinden-mochte-fYDOWG69Y8/Steps/1560034

[Gruppierung von Smaps]

Am 13.12.2023 um 14:24 schrieb Sandra Wecke:

Ich freue mich auf euer Feedback und eure Fragen dazu 🙂

Gibt es diese Kategorien dann auch auf den Endgeräten?

[Nicht editierbare Eingabefelder]

Am 15.12.2023 um 14:27 schrieb Annemarie:

Ihr findet die Idee jetzt auch auf unserem Board als "Schreibschutz für einzelne Bausteine nach Aufgaben-Weitergabe", damit sie dort separat betrachtet und kommentiert werden kann.

Tausend Dank, das freut mich.

[Nicht editierbare Eingabefelder]

Am 14.11.2023 um 16:50 schrieb Annemarie:

Würde das dein Szenario abdecken? Was würdest du noch brauchen? 

 

Am 15.11.2023 um 08:44 schrieb Philip Alvermann:

Fast richtig, einige Felder die durch die Rest-Api befüllt werden sind auch nur Vorschläge und können sich unter Umständen auch bei der Bearbeitung der Aufgabe ändern.

Ich schiebe das mal wieder an. Fast ein Monat ist um und im Feature-Board habe ich dazu leider noch nichts passendes gefunden.

@Annemarie du wolltest Beispiele, die hatte ich geliefert. Leider ist mir nicht klar ob diese dir ausreichen.

["Können wir da nicht einfach eine Smap machen?"]

intern nur innerhalb des Unternehmens.

Extern außerhalb des Unternehmens:

z.B. Serviceaufträge jemand der nicht zum Unternehmen gehört muss unterschreiben, AGB's bestätigen, bekommt automatisch einen Report zugesandt. Also alles wo Personen die nicht zu deinem Unternehmen Anspruch auf die erfasste Daten haben. 

Subunternehmen können für dich Daten erfassen z.B. wegen Gebäudeenergiegesetzes (GEG) 

["Können wir da nicht einfach eine Smap machen?"]

vor 18 Minuten schrieb Manuel Rühl:

Ich werde also das Canvas erstmal als Gesprächsgrundlage nutzen. Das hilft mir gezielt Fragen zu stellen und schreckt dann auch niemanden ab.

Finde ich deine Vorlage super und hätte da noch Vorschläge 🙂.

Eventuell noch zwei Checkboxen:

• Nutzung intern
• Nutzung extern

Es kann auch beides Ausgewählt werden

Eine Checkbox "CI für Report verwenden" würde bei der Aufwandschätzung auch helfen.

[Übernahme von Zahlenwerten in separates Zahlenfeld ohne Funktion]

Ja:

CONCAT(TEXT({Number}),IF(NOTEMPTY({Number_2}),"_",""),TEXT({Number_2}),IF(NOTEMPTY({Number_3}),"_",""),TEXT({Number_3}))

[Smap-Überblick ?!]

vor einer Stunde schrieb Steffen Haußmann:

Ein Nachteil gibt habe ich dabei allerdings auch. Bei nötigen Änderungen an der smap muss man dann entweder jedes mal die bisherige smap löschen lassen und eine neue verteilen, die man dann wieder erhalten hat, oder man baut mit dem Hauptaccount die Änderungen ein.

Oder über die Rest-Api:

mit 1. holst du dir das aus der Quelle, mit 2. bekommst du einen Wert revision den du dann mit 3. verwendest.

Bei DSAB's musst du natürlich aufpassen, die solltest du dann entsprechend  kennen und und im json anpassen.

 

[smapOne PowerAutomate Connector verfügbar]

Super Sache 👍.

[Nicht editierbare Eingabefelder]

vor 15 Stunden schrieb Annemarie:

Unabhänig von einer konkreten Lösungsidee verstehe ich dich so, dass in deinem Prozess Aufgaben per API erstellt werden, und dort Bausteine befüllt werden, die in weiteren Schritten nicht verändert werden sollen.

Fast richtig, einige Felder die durch die Rest-Api befüllt werden sind auch nur Vorschläge und können sich unter Umständen auch bei der Bearbeitung der Aufgabe ändern.

Hier mal ein Beispiel was es eventuell deutlicher macht:

Ein Techniker fährt zu einem Service und hat dazu eine Aufgabe erhalten. Diese Aufgabe enthält unter anderem die Adresse, Kundennummer und Auftragsnummer, da diese auf dem Bericht angedruckt werden sollen ist das ein Baustein (Text, Zahl, etc.) der angedruckt werden kann.
Wenn der Techniker nun die Auftragsnummer ändert, kann dieser Bericht nicht mehr korrekt in unserem CRM System zugeordnet werden, auch der Kunde könnte das nicht mehr zuordnen da der bisherige Schriftverkehr ja über eine ganz andere Auftragsnummer lief.

So gibt es noch einige andere Felder wie z.B. Checkboxen für eine Anfahrtspauschale als Vorgabe aus dem CRM, welche angedruckt werden muss aber auch nicht verändert werden darf.

In anderen Fällen sollen Felder der Vorgabe durchaus angepasst werden können, wie zum Beispiel die Kilometer für die Anfahrt.

Die Rücklaufenden Werte, wie z.B. Anfahrt, Arbeitszeit, Material werden bei uns in das CRM zurückgespielt und dienen im Anschluss als Vorgabe für die Erstellung der Rechnung. 

Also ein alles oder nichts, wie bei eurer Featureidee würde uns nicht weiterhelfen.

[Ideenboard und Feature-Voting]

vor 26 Minuten schrieb Annemarie:

@Philip Alvermann Und kein Überschreiben von Werten, die in früheren Schritten gesetzt wurden.

Ist auch schön so, aber mir geht es um etwas ganz simples.

vor 6 Stunden schrieb Gregor:

Wir bruchen ein Häkchen für "Nicht editierbar".

Das soll dann auch über die Rest-Api gesetzt werden können und der Baustein soll trotzdem auf dem Bericht angedruckt werden können.

[Mehrere Aufgaben gleichzeitig löschen?]

State "incomplete" sollte die Tasks löschen, also wenn du alle Aufgaben einer bestimmten Version entfernen willst wäre das eine Möglichkeit.

[Ideenboard und Feature-Voting]

vor 23 Stunden schrieb Marika Karl:

Darunter sehe ich deinen Request der nicht editierbaren Eingabefelder. Fehlt dir hier was?

Entweder bin ich blind oder kann das nicht interpretieren, ich sehe hier nichts von nicht editieren Eingabefeldern (Text/Zahl).

 

Zitat

Gewünscht ist eine Funktion die verhindert das ein Feld vom Anwender bearbeitet werden kann.
In einer Aufgabe wird ein Feld, Text oder Zahlenwert, vorbelegt und soll natürlich auch so mit dem Inhalt, auf dem Report erscheinen. Der Anwender soll keine Möglichkeit haben den Wert zu ändern.

[Anzeige Bausteine über REST-API befüllen]

Am 7.11.2023 um 18:26 schrieb Grzegorz Wiktorowicz:

Es gibt einige Angaben wie Kundennummer, Auftragsnummer etc., welche von dem App Benutzer nicht manipuliert werden dürfen.

Klingt nach meinem Feature Wunsch 🙂, eventuell gibt es ja sowas mal.

 

[Ideenboard und Feature-Voting]

Am 26.10.2023 um 11:16 schrieb Marika Karl:

stimmt. Lass mich das noch mal gegenchecken und nachholen 🙂

Kann ich immer noch nicht finden. Gehe ich nun davon aus, dass es nicht wird mit dem Feature?

[Ideenboard und Feature-Voting]

Kann man das Portal eventuell hier verlinken?

[Ideenboard und Feature-Voting]

Sehr cool, das gibt mir wieder Hoffnung 🙂, leider vermisse ich meinen Wunsch Nicht editierbare Eingabefelder.

Ein paar Votings habe ich schon abgegeben. 

[Daten per Scan einlesen]

Ich denke eher, das dort der RFID-Chip ausgelesen wurde.

[Nicht editierbare Eingabefelder]

Gibt es hier schon etwas neues, ist was in der Planung?

[Datum: keine vergangenen Daten auswählbar]

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?

[smapLight: Release v1.121]

@Daniel Gilbert Sehr schön aber, ist das noch nicht aktiv?

Ansonsten vielen Dank für das Update.