Auftragswesen next rundet ungewollt Mengen im Lieferschein

[#1]

Hallo zusammen,

wir arbeiten in einem unserer Unternehmenszweige mit Auftragswesen next (kenne aber auch das Auftragswesen online).

Ich erstelle regelmäßig Lieferscheine und nun fällt auf: Sobald ich auf "Speichern" gehe, rundet mir das System ungefragt einfach meine Liefermengen auf volle Kilogramm auf oder ab. Muss jedes Mal nochmals händisch nachbessern, bis es dann stehen bleibt.

Das verursacht doppelt und dreifach Arbeit und ist absolut unschön. 

Kennt noch jemand das Problem? Oder ist es gar Fehler40 und liegt an mir (irgendeine Einstellung verbockt?)?

Grüße

Carolin Huck

[#2]

Immerhin scheinst Du nicht das Problem von @Schloss zu haben: rechnung wird verarbeitet

Tipp 💡: DUO mal im InPrivate / Inkognito-Modus probieren: https://duo.datev.de Passt dann alles, sind veraltete Cache und Cookies dran Schuld. Tritt das Problem dort auch auf, scheint es ein Programmfehler zu sein. Dass Auftragswesen next aber nicht mehr als 2 Nachkommastellen kann, ist Dir bekannt? Nicht, dass Du 1,4578kg hast. 

[#3]

Ich habe es getestet. Passiert bei mir auch und ich habe in meinem Testbestand noch nie vorher einen Lieferschein erstellt. 

1,75 kg hat er auf 2 eingestellt. Beim korrigieren mit Speichern ist es nun so geblieben. 

[#4]

@metalposaunist Danke für die schnelle Hilfe.

Habe beides ausprobiert- inkognito Modus und mal Cache und Cookies komplett gelöscht/geleert. Das Problem ist leider nach wie vor präsent.

Was kann man jetzt tun? Das ist echt super aufwendig so. Überlege tatsächlich, alles auf Gramm umzustellen, dann hab ich das Thema vorerst umgangen. Aber Sinn der Sache ist das natürlich nicht.

[#5]

wow, das ist ein Supergau, geht gaaar nicht.

Stell Dir vor, das Unternehmen verkauft Safran und rundet sämtliche bestellte Mengen auf volle Kilogramm auf😅

Abrunden wird die Software wohl nicht, denn sonst käme öfters mal die Menge 0 kg heraus 😅

Nachtrag:

... wäre interessant zu wissen, ob intern mit der korrekten Zahl gerechnet wird,

ob es also ein reines Anzeige-Format-Problem ist oder ein Dyskalkulie-Problem 😅

[#6]

---

@CHuck schrieb:

Was kann man jetzt tun?

---

Auf DATEV warten. DATEV Auftragswesen next - wir bessern nach

@Eva_Hartwich: Wird hier auch nachgebessert? So langsam denke ich, dass eine Ab- und Anzahlungsfunktion ein sehr frommer Wunsch ist, wenn die Basics nicht stimmen. 

---

@CHuck schrieb:

Überlege tatsächlich, alles auf Gramm umzustellen, dann hab ich das Thema vorerst umgangen.

---

Ich denke, meine Gedanken können hier alle lesen 😇. Da braucht es nicht mal die Glaskugel von @MikeWHerbs 😅. Wenn nicht, gern eine PN an mich. Wenn man die Dinge 1x anfasst, dann bitte gleich richtig. Wer weiß, was bei der Umstellung auf g passiert 😶. 

Auf IT muss man sich verlassen. Immer. Auf DATEV? Hm.  

[#7]

@vogtsburger doch, das System rundet auch fröhlich auf 0 ab wie in der Schule gelernt: <0,5 auf 0, >=0,5 auf 1 hoch

[#8]

... wie gesagt: wenn die Software wenigstens richtig rechnet und speichert, ist das schon 'die halbe Miete' und 'die halbe Blamage'

... denn Optik spielt ja wie im wahren Leben meist keine Rolle , oder ? 😂

[#9]

@vogtsburger Bin normal echt ein Fan von Galgenhumor- nur heute irgendwie nicht. Das ist schon wirklich extrem bitter. War bisher nicht unbedingt unzufrieden mit dem Auftragswesen next. Aber wir sind auch nur ein wirklich kleiner Laden. Aber wenn es an solchen elementaren Sachen scheitert, frage ich mich, wieso man Neukunden ausschließlich das next zur Verfügung stellt. Hätte kein Thema mit gehabt, auch im neuen Zweig noch das online zu nutzen. Da funktioniert wenigstens das.

[#10]

---

@CHuck schrieb:

@vogtsburger doch, das System rundet auch fröhlich auf 0 ab wie in der Schule gelernt: <0,5 auf 0, >=0,5 auf 1 hoch

---

Na dann wirst Du mit der Einheit auf g auch keinen Erfolg haben bzw. musst Du dann ja beim Erstellen des Belegs mitrechnen, damit am Ende mit DATEV das rauskommt, was Du Dir gewünscht hast. Das ja nun keine Lösung 👎.  

Dann bin ich schneller, wenn ich Stift und Papier mit einer Rechenmaschine nehme 😶. 

---

@CHuck schrieb:

War bisher nicht unbedingt unzufrieden mit dem Auftragswesen next. Aber wir sind auch nur ein wirklich kleiner Laden.

---

Wie gern ich Dir andere Vorteile zeigen würde 🙌 😍.

[#11]

Danke dir! Auch, wenn das jetzt nicht unbedingt das war, was ich hören wollte.

Umstellung auf Gramm wird nicht passieren- da drehe ich ja durch. Aber ja nun- so drehe ich halt regelmäßig durch wenn ich alles doppelt eintragen und speichern muss, bis AW next kapiert, was ich will. Bitter.

[#12]

Ich bin sicher, dass @d_brusch das ruck-zuck testen kann, ob die Software wenigstens mit den eingegebenen Zahlen rechnet und nur dummerweise falsch darstellt.

Dann wäre das Problem deutlich kleiner, denn ein Anzeigeformat ist (normalerweise) schnell geändert 

[#13]

---

@vogtsburger schrieb:

ob die Software wenigstens mit den eingegebenen Zahlen rechnet und nur dummerweise falsch darstellt.

---

So schnell kommen wir auf die E-Rechnung: E-Rechnung und ZUGFeRD: Sollen Menschen XML und PDF vergleichen – srsly?

Dann steht in der XML was anderes als in der PDF. So entsteht der Unterschied also. Ich verstehe. Danke @vogtsburger!  

[#14]

ich habe vor kurzem bei einem 'fremden' Warenwirtschaftssystem solche Fehler entdeckt.

Intern wurde korrekt gerechnet und gebucht, aber auf dem Rechnungsbeleg wurde der Rechnungsbetrag auf andere Weise ermittelt und somit hatte man fast in jeder Buchung eine Differenz beim Rechnungsbetrag (zwischen dem (korrekten) Buchungssatz und dem  (falschen) Rechnungsbeleg

... zur Fehlerursache:

die Bruttopreise der einzelnen Artikel wurden auf Nettopreise+USt. umgerechnet, dann jeweils gerundet, mit der jeweiligen Anzahl multipliziert, aufsummiert und am Ende der Rechnungsbetrag wieder mit Nettobetrag+USt. ermittelt 😉

.. ergo, ein Problem mit den Rundungen, wie so oft im wahren Leben 😎

[#15]

ich habe es nun wirklich noch einmal weiter getestet.

Es ist ein Anzeigefehler. 

Ich habe folgendes eingegeben im LS:

Bei Klick auf Fertigstellen wandelt er diese Zeilen entsprechend in 2 und 1 um. Jedoch nur für diesen Moment. 

Das Dokument öffnet sich aber mit den richtigen Werten und zeigt das Dokument trotz der falschen Anzeige wieder mit dem richtigen Mengen an. 

Weiterführung in die Rechnung ist auch alles i.o.

[#16]

@d_brusch Besten Dank fürs Austesten! Soweit hab ich mich in der Tat nicht getraut- denn festgeschrieben ist festgeschrieben. 

Dann ist das zumindest "nur" ein optischer Fehler und ich spare mir das doppelt eintragen. Das ist schonmal gut. Werde trotzdem ein Auge drauf haben. Und vielleicht findet DATEV ja Zeit, diesen unschönen Anzeigefehler zügig zu beheben. Denn das irritiert wirklich sehr.

Danke euch!

[#17]

WYSINWYG 🤓 total irre - liegt bestimmt an Cookies 🍪. 

[#18]

Vielen Dank für die Information.

Wir können dies intern nachstellen und werden es betrachten. 

[#19]

---

@Kristina_Bluhm schrieb:

und werden es betrachten

---

Aber nicht wie bei Schalke bitte: nur angucken, nicht anfassen ist in diesem Fall keine Lösung 😉. 

[#20]

... jetzt bin ich mal richtig gespannt, wie lange es dauert, bis diese "Unannehmlichkeit" von der Datev aus der Datev-Welt geschaffen wird

Marcel Reich-Ranicky würde jetzt vielleicht lispeln ... ähm ... sagen: ...

ich nehme diese Unannehmlichkeit nicht an !

Ich selbst nehme nämlich an, dass die Behebung dieses Fehlers technisch (hoffentlich) 'nur' eine Kleinigkeit ist, z.B. nur die Korrektur eines falsch definierten Zahlenformats für die Anzeige. 

Nachtrag:

... jetzt könnte man ja die Vorteile einer reinen Online-Anwendung voll ausspielen, da ja diese Online-Anwendung nur an 1 Stelle geändert werden muss und dann allen Anwendern sofort zur Verfügung steht 😉

... so jedenfalls die (naive) Theorie 😎

[#21]

---

@vogtsburger  schrieb:

... jetzt bin ich mal richtig gespannt, wie lange es dauert, bis diese "Unannehmlichkeit" von der Datev aus der Datev-Welt geschaffen wird

Marcel Reich-Ranicky würde jetzt vielleicht lispeln ... ähm ... sagen: ...

ich nehme diese Unannehmlichkeit nicht an !

Ich selbst nehme nämlich an, dass die Behebung dieses Fehlers technisch (hoffentlich) 'nur' eine Kleinigkeit ist, z.B. nur die Korrektur eines falsch definierten Zahlenformats für die Anzeige. 

Nachtrag:

... jetzt könnte man ja die Vorteile einer reinen Online-Anwendung voll ausspielen, da ja diese Online-Anwendung nur an 1 Stelle geändert werden muss und dann allen Anwendern sofort zur Verfügung steht 😉

... so jedenfalls die (naive) Theorie 😎

---

Challenge accepted. Das Ticket ist im aktuellen Sprint.

Mit freundlichen Grüßen aus Nürnberg

Thorsten Jedlitzke
DATEV Auftragswesen next | DATEV eG

[#22]

@Thorsten_Jedlitzke ,

wow, eine gute Nachricht.

Jetzt können wir mal (fast) live die Datev-Höchstgeschwindigkeit beim 'Sprinten' erleben 😊

Ich stehe schon an der Ziellinie, mit der Stoppuhr in der Hand 😅

[#23]

Japp, Best Of des Abends... "betrachten"...

Einfach mal beobachten... Vielleicht ändert sich der Sachverhalt einfach von alleine. Prost!

[#24]

Nachtrag:

... ich weiß natürlich, dass sich Software-Entwicklung in großen Teams grundlegend unterscheidet von den Tätigkeiten eines einzelnen, autarken Programmierers 'im stillen Kämmerlein'.

... trotzdem würde mich interessieren, ob in Datev-Entwicklungsteams tatsächlich jedes 'Entwicklungsprojekt' grundsätzlich den vollen 'Dienstweg' bzw den vollen Scrum-Prozess einer 'agilen Softwareentwicklung' durchlaufen muss, und sei es auch noch so klein.

Falls ja, wäre ein Ergebnis nach 1 Woche schon ungewöhnlich schnell, oder ?

[#25]

Der Fehler mit der falschen gerundeten Anzeige ist behoben und auf Produktion ausgeliefert.

Aber: Wir haben im Kontext des Mengen-, Stückzahlen und Preisfeldes noch ein anderes Problem. Insbesondere bei der Neuanlage eines Belegs wird der neu eingegebene Wert nicht gespeichert, wenn der Cursor nach einer Änderung noch im Feld steht und Sie direkt auf Speichern klicken. Dann wird der gerade eingegebene Wert nicht gespeichert. Aktuell muss noch vor dem Speichern aus dem Feld herausgeklickt werden. Der Fehler ist auch schon behoben, muss aber noch bei uns durch die Qualitätssicherung. Das wird voraussichtlich Anfang / Mitte der kommenden Woche sein.

@vogtsburger Damit sind wir dann bei Ihrer Frage nach dem "wie arbeiten agile Entwicklungsteams bei der DATEV." Die wenigsten Teams arbeiten streng nach Scrum. Es gibt zwar Sprints (oft 14 Tage, wie bei Auftragswesen next), in denen ein im Team festgelegter zusammen akzeptierter Umfang an Tickets / Themen umgesetzt wird. Der Sprint ist aber nicht "heilig", so dass nach Bedarf auch Tickets nachgezogen und priorisiert bearbeitet werden. So wie in diesem Fall geschehen.

Die beiden Fehler sind auf unsere Fastlane gewandert, woran ich nicht ganz unschuldig war. Sorry, Team! Ein solches Fastlane Ticket bringt Unruhe in den Entwicklungsprozess. Andere Themen müssen kurzfristig gestoppt werden und der Fokus geht verloren. Das sollte deshalb auch die Ausnahme bleiben.

Ihre Annahme "eine Woche ist dann wohl schnell" trifft eher die Realität. Einen solchen Fehler, für den es einen Workaround gibt, nehmen wir normalerweise zeitnah in den zwei-Wochen-Zyklus mit auf und planen ihn ein. Irgendwo zwischen zwei und acht Wochen liegt normalerweise die Realität zwischen Aufnahme des Fehlers in einem Fehlerticket, Entwicklung, Qualitätssicherung und Auslieferung in Produktion. Je nach Priorität.

Bevor der Einwand zurecht kommt. Leider erfüllen wir in Auftragswesen next nicht immer diese Lieferzusage. Wir arbeiten aber daran, besser zu werden.

Was ausgeliefert wird dokumentieren wir übrigens in DATEV MyUpdates.

Mit freundlichen Grüßen aus Nürnberg

Thorsten Jedlitzke
DATEV Auftragswesen next | DATEV eG

[#26]

---

@Thorsten_Jedlitzke schrieb:

Die beiden Fehler sind auf unsere Fastlane gewandert,

---

Vielleicht sollte DATEV das "öffentlich" machen? Aus der Sicht Eurer Nutzer ist die Liste der FastLane echt krass lang. DATEV sortiert's aber teilweise als "nice to have" ein, was aber oftmals essentielle Wünsche sind, damit IT Spaß macht und sich nicht wie digitalisiertes Analogarbeiten anfühlt. Vielleicht wäre das auch zusammen mit DATEV Ideas nochmal eine Überlegung wert @Annekathrin_Bels, auch wenn es da schon den Status "Umsetzung unwahrscheinlich" gibt. So kann man sich dann besser auf Alternativen fokussieren, wenn's DATEV nicht via FastLane liefert. Ich weiß, will @Christian_Buggisch nicht gern lesen aber heute geht IT-technisch eigentlich alles. Nur "geht nicht" ist nicht mein Anspruch. 

---

@Thorsten_Jedlitzke schrieb:

Was ausgeliefert wird dokumentieren wir übrigens in DATEV MyUpdates.

---

Und dann muss man sich erstmal durchklicken und einen Filter bauen und dann bekommt man aber keine Benachrichtigung und 1 Link "aktuelle Version von" gibt's auch nicht, weil der Filter keine eigene URL hat, tbc ... @Melisa_Begovic: Ein Fall von FastLane oder ein Fall für manuell. Danke Manuel 👨. Und weil man nicht weiß, wann DATEV dort nach dem 21.02 einen Eintrag veröffentlicht, klickt man sich immer wieder durch diesen Prozess? Viel Aufwand für wenig Ziel. 

Ich hab's gern eindeutig, wenig Aufwand für mein Gegenüber und am liebsten so zielgerichtet wie nur möglich. 

Dennoch danke @Thorsten_Jedlitzke für die ausführliche Darstellung! Gerne mehr davon auch wenn sich der Mehrwert in meinen Augen in Grenzen hält. Dass sich Mitarbeiter bei DATEV langweilen, glaube ich ja eher weniger. 

[#27]

@Thorsten_Jedlitzke ,

ich hatte nicht damit gerechnet, dass die Datev auch mal auf der 'fast lane' 'rechts überholen' kann, wenn es brennt 

Danke !

... auf der (Daten-)Autobahn wird ja nicht immer eine Rettungsgasse freigehalten, wenn die Feuerwehr und der Notarzt kommt

(sorry für diese Analogie in diesem digitalen Thema 😎 )

Apropos,

@CHuck und @d_brusch könnten vielleicht testen, ob bzw. wann die Änderungen sichtbar sind  

[#28]

Nachtrag:

mir geht es in diesem Fall eigentlich nicht speziell um genau dieses Problem in dieser speziellen Online-Anwendung "Auftragswesen Next", sondern ganz allgemein um die Schnelligkeit und Flexibilität, mit der die Datev-Entwickler auf neu erkannte, relevante Software-Fehler reagieren können bzw. bei Bedarf auch tatsächlich reagieren.

Die Anwendung "Auftragswesen Next" gehört für mich nämlich zur Zeit (noch) nicht zu den Anwendungen, die ich 'guten Gewissens' im Mandantenkreis empfehlen würde. Das muss aber nicht so bleiben, denn diese Anwendung kann sich ja noch von der unscheinbaren 'Raupe' zum strahlend schönen 'Schmetterling' entwickeln .... theoretisch ...😉

... und die Datev-Entwickler haben diese Challenge mit Bravour bestanden. 

... das lässt hoffen ... 😊

[#29]

---

@LS4B  schrieb:

Einfach mal beobachten... Vielleicht ändert sich der Sachverhalt einfach von alleine. Prost!

---

Funktioniert in der Politik und Verwaltung doch auch. 😉

[#30]

Der Fehler mit dem runden der Beträge ist behoben. 

Allerdings wurde bei mir die Zahl nicht gespeichert, wenn ich mit dem Cursor im Mengenfeld stehe und auf Speichern klicke.

Das System ist von der eingegebenen 3,35 nach dem Speichern zurück auf die 1 gegangen.