Neu Netto-Rechnungen und fehlerhafte WaWi-Rundung -> Tool zur externen Rundung

[Eiko]

Hallo zusammen,

wir sind bei uns im Unternehmen frisch auf die JTL-WaWi umgestiegen, weil unser altes GS-Auftrag nicht mehr so das Gelbe vom Ei ist. Aktuell verwenden wir die WaWi auch noch rein als Warenwirtschaft, Shop soll evtl. später dazukommen. Wir erstellen Aufträge und Rechnungen sowohl für Endkunden mit Bruttobeträgen, als auch für Firmenkunden als reine Nettorechnung. Beim Erstellen der Vorlagen ist uns dann aufgefallen, dass in der Wawi eklatante Rundungsfehler auftreten. Eine Nettorechnung kann über die Positionen nicht vernünftig addiert werden, außer man zeigt die Preise in der Positionsliste mit 4 Nachkommastellen an. Und das sieht bescheiden aus und ist auch nicht wirklich üblich.

Alles rumprobieren und Vorlagen ändern hilft nichts, auf einer Nettorechnung stehen falsche Summen. Der Fehler resultiert daraus, dass ein Artikel Datenbank-Intern mit dem Nettobetrag und dem MwSt-Satz gespeichert wird. Aus 109,95€ wird dann bei 19% MwSt ein Betrag von 92,39495798319328€ hinterlegt. Dieser wird dann für sämtliche Rechnereien in der Positionsliste als Dezimalwert mit 4 Nachkommastellen genommen. Die Summenbildung und die Standardanzeige in der Positionsliste zeigen aber nur 2 Nachkommastellen. So werden dann aus 10 Einheiten eines Artikels, welcher intern Netto 5,105€ kostet, als Gesamtsumme 51,05€ angezeigt. Die Einzelposition steht mit 5,10€ da. Spätestens hier steigt mir die Buchhaltung des Rechnungsempfängers aufs Dach.

4 Nachkommastellen anzeigen ist wie gesagt keine Option, auch hier kann es zu Rundungsfehlern kommen. Als einzige Option bleibt nur, dem Firmenkunden einen individuellen, auf 2 Nachkommastellen gerundeten Nettopreis zu hinterlegen. Aus dem Beispiel oben wird dann aus 109,95€ über 4 Stellen 92,3950€ und dann 92,40€ als Nettopreis für Firmenkunden. Dass aus 92,40€ keine 109,95€ sondern 109,96€ werden, spielt dabei keine Rolle, da ich meinen Firmenkunden ja eh immer nur Nettopreise kommuniziere. Ebensowenig ist es relevant, dass die Firmenkunden dadurch einen anderen Gesamtbruttopreis bezahlen.

Da wir mehrere Mitarbeiter im Unternehmen sind, ist es sehr wahrscheinlich, dass das Setzen des individuellen Preises für Firmenkunden irgendwann vergessen wird. Daher musste ich das zwangsläufig automatisieren. Herausgekommen ist ein Kommandozeilentool, welches sich wunderbar in Verbindung mit der Ameise in einem Skript unterbringen lässt. Per Workflow wird beim Anlegen eines Artikels ein Ameisenexport gestartet, welcher die Preise in eine .csv packt, von dem Tool runden lässt und dann wieder per Ameise importiert. Das Tool kann mehrere Spalten für unterschiedliche Kundengruppen verarbeiten, behält bei Bedarf bereits vergebene Individualpreise, kann den letzten Artikel direkt aus der Datenbank lesen, schreibt eine Logdatei bei Bedarf etc.

Eine Anleitung und das Tool selber gibt es hier:
http://www.digitalcelluloid.de/b2b-netto-runder/

Über Anregungen und Kritiken würde ich mich sehr freuen.

 

[gutberle]

Hallo @Eiko,

erst einmal vielen Dank dafür, dass Du nicht rumjammerst, sondern das Problem benennst und auch gleich eine Lösung präsentierst!

Ich muß Dir allerdings bei Deiner Bewertung der Situation deutlich widersprechen, denn erstens sind das keine "Rundungsfehler", weil die Wawi kaufmännisch korrekt rundet, sondern "Rundungsdifferenzen", zweitens sind die in der Geschäftswelt absolut üblich und drittens fallen Deine Beispiele auch in den üblichen Rahmen der erlaubten/tolerierten Rundungsdifferenzen.

Keine meiner B2B Kunden beschweren sich oder kennen das anders und nicht einmal das Finanzamt würde über Deine Beispiele stolpern, sondern einfach nur erwarten, dass man in der Fibu ein Konto "Rundungsdifferenzen" hat, das diese Differenzwerte abbildet. Insgesamt macht die Wawi es also tatsächlich ~so~ richtig, wie es nur geht.

Das Problem ist also nicht die Wawi und ihre Programmierung, sondern die unausweichliche Tatsache, dass Du entweder glatte/runde Brutto- oder glatte Netto-Preise haben kannst, beides geht nicht, siehe auch hier. Und dass dann aus den glatten Nettopreisen für B2B Kunden wieder krumme Bruttopreise entstehen ist ja auch klar und zeigt nur die Unmöglichkeit, beides gleichzeitig hinzubiegen.

Und wenn Du in der Einzelpreisspalte von den der Berechnung zugrundeliegenden Preisen aus ästhetischen Gründen nur die ersten beiden Nachkommastellen anzeigen willst, dann aber erwartest, dass beim Gesamtpreis "was Passendes" rauskommt, naja, dann ist das ehrlich gesagt eher Dein Problem und nicht das der Wawi.

Dass Dich das trotzdem nervt kann ich natürlich verstehen und dass Du jetzt eine Lösung dafür erstellt hast und die auch noch öffentlich machst, ist cool, danke dafür!

Feature-Vorschlag:

Was ich aber eigentlich aus Deinem Post mitnehme ist, dass das ein guter Feature-Vorschlag für das Menü "Kunden > Kundengruppen" wäre, wo unter "Allgemein" nur noch eine weitere Zeile mit "Nachkommastellen der Nettopreise festlegen:" eingefügt werden müsste, z.B. mit einem DropDown und der Auswahlmöglichkeit zwischen "2" und "4".

Das hätte dann den Vorteil, dass das Ganze eine zentrale Eigenschaft der Kundengruppe ist, hierarchisch gleichauf mit "Nettopreise anzeigen" und dass das auch dann funktioniert, wenn man für einen Artikel keine spezifischen Kundengruppenpreise für die B2B Kunden angelegt hat. Der Kunde muß dann nur noch zu einer Kundegruppe gehören, für die das gilt und gut ist...

Was hältst Du davon, wäre das nicht eine elegante Lösung?

Gruß,
Ingmar

 

[Eiko]

Hallo @Eiko,

erst einmal vielen Dank dafür, dass Du nicht rumjammerst, sondern das Problem benennst und auch gleich eine Lösung präsentierst!

Ich muß Dir allerdings bei Deiner Bewertung der Situation deutlich widersprechen, denn erstens sind das keine "Rundungsfehler", weil die Wawi kaufmännisch korrekt rundet, sondern "Rundungsdifferenzen", zweitens sind die in der Geschäftswelt absolut üblich und drittens fallen Deine Beispiele auch in den üblichen Rahmen der erlaubten/tolerierten Rundungsdifferenzen.

Wir hatten Rechnungen, da lag der Wert von meinetwegen "Vorgang.Positionen.NettopreisGesamt" drei, vier Cent neben dem, was beim Durchrechnen mit dem Taschenrechner rauskam. Das akzeptiert doch keiner mehr als Rundungsdifferenz? Das alte GS-Auftrag von Anfang der 90er, welches wir eingesetzt hatten, rechnet generell mit 2 Nachkommastellen, da gabs dann halt lediglich das Problem, dass wenn man dem Firmenkunden einen Bruttopreis genannt hat, man bei einer Nettorechnung diesen einen Cent Differenz teilweise hatte. Das hat auch jeder akzeptiert.

Das Problem ist also nicht die Wawi und ihre Programmierung, sondern die unausweichliche Tatsache, dass Du entweder glatte/runde Brutto- oder glatte Netto-Preise haben kannst, beides geht nicht, siehe auch hier. Und dass dann aus den glatten Nettopreisen für B2B Kunden wieder krumme Bruttopreise entstehen ist ja auch klar und zeigt nur die Unmöglichkeit, beides gleichzeitig hinzubiegen.

Ich habe kein Problem damit, wenn der Firmenkunde krumme Bruttopreise erhält. Mich macht halt diese Inkonsequenz bei der Rechnung mit 4 und dann wieder mit 2 Nachkommastellen ein bißchen stutzig. Ich habe Stunden darauf verbracht, die Vorlagen anzupassen, dass die Nettorechnungen korrekt sind, indem ich entsprechende Rundungen eingebaut habe. Das Ende vom Lied war, dass der Fehler dann in den Listenansichten und in den offenen Posten auftaucht. Inkonsequent ist es in meinen Augen nämlich, die ganze Zeit mit 4 Stellen nach dem Komma zu rechnen, sämtliche Listen und Anzeigen (selbst beim Anlegen eines Auftrages, wo mir Brutto/Nettobetrag und Gewinn angezeigt werden) aber nur zweistellig darzustellen.

Feature-Vorschlag:

Was ich aber eigentlich aus Deinem Post mitnehme ist, dass das ein guter Feature-Vorschlag für das Menü "Kunden > Kundengruppen" wäre, wo unter "Allgemein" nur noch eine weitere Zeile mit "Nachkommastellen der Nettopreise festlegen:" eingefügt werden müsste, z.B. mit einem DropDown und der Auswahlmöglichkeit zwischen "2" und "4".

Das hätte dann den Vorteil, dass das Ganze eine zentrale Eigenschaft der Kundengruppe ist, hierarchisch gleichauf mit "Nettopreise anzeigen" und dass das auch dann funktioniert, wenn man für einen Artikel keine spezifischen Kundengruppenpreise für die B2B Kunden angelegt hat. Der Kunde muß dann nur noch zu einer Kundegruppe gehören, für die das gilt und gut ist...

Was hältst Du davon, wäre das nicht eine elegante Lösung?

Gruß,
Ingmar

Das wäre auf jeden Fall eine gute, und mindestens für uns hilfreiche Verbesserung.

Grüße,

Eiko

 

[gutberle]

Hallo Eiko,

ok, trennen wir hier mal, um die Sache klarer zu machen ...

1. Da die Wawi intern mit 4 Nachkommastellen rechnet, kann die Rundungsdifferenz pro Positionszeile maximal 0,005€ betragen.
> Das gilt z.B. für Deine 5,105€ netto von oben, denn die stellen kaufmännisch betrachtet den "Worst Case" dar, weil das kaufmännlisch gerundet 5,11€ wären, die Differenz ungerundet/gerundet auf 2 Realstellen bezogen also maximal ist.

2. Da jede Positionszeile eine solche Maximaldifferenz von 0,005€ aufweisen kann und darf, ist die Gesamt-Rundungsdifferenz nur durch die Anzahl der Positionszeilen begrenzt.
> Wenn Du einen Auftrag mit 126 Zeilen mit je 1x Deinem 5,105€ Artikel anlegst, gibt Dir jede JTL Standardvorlage ein Gesamtnetto vo 643,23€ aus, 126x (vermeintliche, weil angezeigte) 5,11€ ergäben aber 643,86€ eine Differenz von 0,63€ !!

3. All das ist rechtlich einwandfrei, aber klar ist auch, dass spätestens jetzt jeder, ob Geschäftskunde oder Finanzamt, "ääähhh" sagen und den Taschenrechner zücken würde.
> Die Differenz fällt zu Gunsten des Kunden aus, also wird der Kunde oder bezogen auf die USt auch das FA zufrieden sein
> Bei einem Netto-Einzelpreis von 5,104€ und gleichem Beispiel mit 126x 1 Stück @ 5,104€ ist die Differenz aber -0,504€ zu Lasten des Kunden/FA! - Ob da Freude aufkommt?

4. Inkonsistenzen in der Anzeige kenne ich eigentlich nur an zwei Stellen:
> Einmal in der Artikelauswahl, z.B. für einen Auftrag, in der konsequent Netto und Brutto mit 2 NK-Stellen angezeigt werden.
> In dem Dialog, der bei der initialen Aufragseingabe aufgerufen wird, wird das Nettogesamt mit 2 Stellen angezeigt. Rufst Du die (vermeintlich) gleiche Auftrags-Maske noch einmal auf, sind es 4 Stellen, denn das sind 2 verschiedene Dialoge.
> An allen anderen Stellen, z.B. Auftragsliste werden die rein rechnerisch korrekten Beträge angezeigt, dass die dann aber von Deinen Beträgen abweichen, wenn Du die Vorlagen von "rechnerisch korrekt" auf "sichtbar korrekt" abänderst, ist klar.

Fazit: Das Ganze ist und bleibt immer das selbe Problem, dass man nicht immer gleichzeitig glatte 2 Nachkommastellen-Nettobeträge und -Bruttobeträge haben kann. Damit man all diese zwar korrekten, aber echt unschön sichtbaren Inkonsistenzen vermeiden kann ist es schlicht der einzige Weg, dafür zu sorgen, dass die Nettopreise auf 2 NK-Stellen glatt sind, denn ist das der Fall, dann gibt es weder auf Positions-Nettoebene, noch auf Gesamt-Nettoebene Rundungsdifferenzen. Und letztlich ist es ja genau das, was Dein Tool schön automatisierbar macht.

Aber, das heißt natürlich noch lange nicht, dass es am Ende des Tages nicht doch Rundungsdifferenzen geben kann. In meinem Beitrag im anderen Thread hatte ich geschrieben, dass der JTL Shop nach der vertikalen Methode arbeiten würde und wenn das so ist (wäre, s.u.), dann bedeutet das, dass die Mehrwertsteuer pro Zeile berechnet und noch dort auf zwei Stellen gerundet wird. Diese gerundeten MwSt-Werte werden dann bei der vertikalen Methode saldiert, so dass es bei vielen Positionszeilen jetzt plötzlich bei der Mehrwertsteuer zu der oben beschriebenen Kumulation von Rundungsdifferenzen kommen, was natürlich auf den Bruttobetrag durchschlägt.

Jetzt bin ich aber stutzig geworden, weil mir die MwSt-Beträge in meinen Test-Aufträgen von oben "komisch" vorkamen und siehe da, die Wawi selbst rechnet NICHT nach der vertikalen sondern nach der horizontalen Methode - bei der die Positions-Nettosummen erst saldiert und darauf dann erst die MwSt berechnet und auf 2 NK-Stellen gerundet wird - und so ist das auch in allen List & Label Vorlagen umgesetzt! Damit kann es auch bei vielen Positionszeilen und bei glatt 2-NK-stelligen Einzelbeträgen nur zu einer Rundungsdifferenz von maximal 1 ct kommen.

Jetzt war ich aber natürlich alarmiert, denn wenn die Wawi horizontal, der Shop aber vertikal rechnen würde, dann hätten wir ein Problem. - Also habe ich das Ganze gerade noch einmal im aktuellen JTL Shop 4.05.3 durchgespielt und siehe da, der (aktuelle) JTL Shop rechnet auch horizontal. Das widerspricht allerdings meiner Aussage im anderen Thread und da ich mich gut daran erinnern kann, das damals genau wie Heute im Shop und in der Wawi ausführlich getestet zu haben, bin ich jetzt verwirrt. Entweder hatte ich damals einen Aussetzer, oder aber JTL hat die Berechnungsmethode hier wie dort in der Zwischenzeit geändert oder vereinheitlicht und ich habe das nicht mitbekommen, hmmmm ...

Fakt ist aber für jetzt und Heute, 9.7.2017, dass sowohl der JTL Shop 4.05.3, wie auch die JTL Wawi 1.2.3.4 beide die Mehrwertsteuer nach der horizontalen Methode berechnen. Bei Verwendung von glatt 2-NK-Stellen bei Deinen Nettopreisen wirst Du also maximal 1 ct Rundungsdifferenzen erleben.

Gruß,
Ingmar

 

[Eiko]

Danke für deine ausführliche Antwort.

Mit Inkonsequenzen meinte ich, dass im Reiter F6-Verkauf in jeglichen Listen alles nur mit zwei Nachkommastellen dasteht. Selbst die Auftragspositionen, während sie im Auftrag selber aber mit 4 Stellen stehen. Dadurch kommt es mMn ja schon bei der Anzeige zu Differenzen.

In den von dir verlinkten Beitrag ist ja die Lösung auch die, welche ich in meiner Methode angewandt habe. Ich hatte im Vorfeld auch schon einiges im Forum gelesen, andere haben das "Problem" ja scheinbar teilweise auch, u.a. auch mit LS-POS, wo die Kasse dann unterschiedliche Werte anzeigt, wegen dieser internen 4-Stellen-Rechnerei.

Ich werde mal sehen, wie es sich mit meiner Lösung leben lässt. Vielleicht kommt ja irgendwann das von dir beschriebene Feature, dann kann ich auf externe Lösungen verzichten.