Fehlertext "Sachkontenlänge" bei fehl. Re.Datum / erst Pflichtfelder - dann Rest aufklappen...

[#1]

Wir möchten solche unsinnigen Fehlermeldungen hier vermeiden:

- erweiterte Erfassung, Eingangsrechnung, Periode zugeordnet

- Re.Datum z.B. nicht durch OCR erkannt oder aus anderen Gründen (noch) leer

- Erfassung eines beliebigen Sachkontos

- Hinweis auf Kontrolle der Sachkontenlänge in den Stammdaten (die natürlich richtig hinterlegt ist)

M.E. wieder ein Fall für Stellenausschreibung: UX Designer für Datev UO in Nürnberg gesucht 

Vorschlag 1: In solchen Fällen bitte die Fehlermeldung ändern in "bitte erfassen Sie zuerst ein Rechnungsdatum"

Vorschlag 2: Um den Anwender gar nicht erst in solche "Fallen" laufen zu lassen sollte die Erfassungsmaske sich erst dann "aufklappen" und solche Felder wieder "Sachkonto" erweitern, wenn zuvor die Pflichtfelder gefüllt wurden.

Mit freundlichen Grüßen
Marco Hüwe

[#2]

Hallo @marcohüwe, 

Oh 😲 Danke für den Hinweis, dass die Fehlermeldung am Feld Sachkonto und die zugeordnete Periode trotz fehlendem Belegdatum nicht richtig ist. Ich habe die Punkte an die entsprechenden Kollegen weitergeleitet und werde Sie via Ideas über den weiteren Verlauf informieren. 

[#3]

Hallo Community, 

bezüglich des ersten Sachverhaltes (in der Bearbeitungsform Erweitert wird dem Beleg eine Periode zugeordnet, obwohl das Belegdatum fehlt) habe ich eine Frage an Sie: War die Erwartungshaltung, dass die Periode auf <Keine> steht oder wäre es sinnvoll den aktuellen Monat als Vorbelegung heranzunehmen? 

Herzlichen Dank. 

[#4]

Hallo Frau @Nina_Naßler,

auch wenn ich nicht mit dem Programm arbeite, möchte ich dennoch meine Einschätzung abgeben.

Da DUO vom Konzept her eine zeitnahe Bearbeitung vorsieht, ist es aus meiner Sicht erwartungskonformer, wenn die Periode immer den aktuellen Monat widerspiegelt. Eine Überschneidung der Perioden ist dann nur i. d. R. in der ersten Woche gegeben. Dagegen sind die letzten 3 Wochen i. d. R. periodengerecht erfasst. Das bedeutet, dass nur in 1/4 aller Fälle manuelle Eingriffen notwendig wären. Zu beachten ist, dass das Periodenfeld immer als Startpunkt selektiert wird, damit mit wenig Interaktionen die Periodenzuordnung erfolgen kann.

Auch wäre es sinnvoll, eine Hinweismeldung auszugeben, wenn aus dem Feld Belegdatum abgesprungen wird (LostFocus) und kein gültiger Wert (= auch Leereingaben) erfasst werden.

Werden die Felder mit der Maus selektiert und dabei das Belegdatum übersprungen, sollte die Prüfung eines gültigen Belegdatums beim Abspeichern erfolgen.

Gruß Achilleus

[#5]

Hallo Frau @Nina_Naßler ,

zunächst in Bild 1 unten der Hinweis auf die DATEV-Hilfe zur Periode - dies stimmt grade nicht (siehe Bild 2). In meinem Testfall wurde Januar vorgeschlagen obwohl nirgendwo ein Datum zu erkennen war.

In Bild 3 unten passt sich die Periode dann richtig an, nachdem ich das Datum manuell ergänzt habe.

Da wir derzeit die "OCR anpreisen" sehe ich auf Mandanten-/Anwenderseite folgende Erwartungshaltung:

• OCR erkennt gar kein Datum: Periode frei lassen
• OCR erkennt unsicher: Periode = Datum
• OCR erkennt sicher: Periode = Datum

Den aktuellen Monat würde ich hier nicht als Vorbelegung vorschlagen.

Mit freundlichen Grüßen
Marco Hüwe

[#6]

ich schließe mich @marcohüwe an, das wäre aus meiner Sicht die beste Unterscheidung, um Fehler zu vermeiden.

[#7]

ich schließe mich ebenfalls @marcohüwe an, das wäre eine gute Unterscheidung, um Fehler zu vermeiden.

[#8]

Hallo zusammen, 

vielen Dank, dass Sie sich die Zeit genommen haben, auf meine Frage zu antworten 😊

Wodurch sehen Sie genau Fehler auftreten, wenn die aktuellen Periode vorbelegt wird?

Das Feld Periode wird durch die Eingabe des Datums getriggert, was bedeutet, dass sich die Periode richtig anpasst, nachdem das Datum manuell ergänzt wird. 

[#9]

Hallo in die Runde, 

ich habe ein Update zu dieser Idee: ist das Erfassungsfeld für das "Rechnungsdatum" nicht vorbelegt, das Sachkonto wird aber historisch wiedererkannt, so erscheint kein Hinweis auf Kontrolle der Sachkontenlänge in den Stammdaten mehr. 

[#10]

Wir haben den Fehler ausgebaut. Der Hinweis wird nicht mehr ausgegeben 🙂