In Bearbeitung Rundungsdifferenzen

[Simone_die_Echte]

Immer wieder ärgere ich mich über von der Wawi produzierte Rundungsdifferenzen.

Das verursacht einfach unnötige Arbeit bei der Buchführung!
Dabei ist es völlig egal, über welche Plattform die Aufträge reinkommen oder welche Zahlart gewählt wurde.
Beispiel:
Shopauftrag über 264,34 EUR -> in der Wawi wird der Auftragswert korrekt angezeigt, exportiert wird jedoch ein Auftragswert von 264,33 EUR

Das passiert jeden Monat mehrfach und bedeutet für diesen blöden Cent eine zusätzliche Buchung, die mich einfach ärgert.

Heute kam ein Auftrag mit dem Wert von 100,35 EUR rein. Bezahlung komplett per paypal. Und was zeigt die Wawi an? -> offener Wert -0,01 EUR.

Bin ich die Einzige, die das doof findet oder lasst brummt ihr das einfach kommentarlos euren Steuerberatern auf und zahlt für die extra Buchungssätze?

 

[deliman]

Du bist nicht allein... Seit dem wir die Wawi einsetzen ist uns das negativ aufgefallen - schon weil in den Standard-Rechnungsvorlagen ja überall dieser unübersehbare Hinweis auf die Rundungsdifferenz erscheint. Bei uns sind es gern auch mal +/- 0,02€ und ich glaube mich erinnern zu können, das wir sogar schon mal +/- 0,03€ Differenz hatten. Das Problem ist wohl schon deutlich länger bekannt allein warum man das noch nicht überarbeitet hat, ist mir ein Rätsel. Es betrifft ja nicht nur einige sondern alle Nutzer!

Es hieß mal, wenn das Refactoring in der Wawi stattfindet, soll dieses Problem mit angegangen werden und dann in einem zukünftigen großen Update mit behoben sein. Bei der 1.2 war es wohl noch nicht so weit...

Warum überhaupt solche Rundungsdifferenzen "programmiert" sind, kann ich nicht nachvollziehen. In den Aufträgen selber stimmen die Nettowerte ja und in anderen Wawi und selbt in unserem alten Shopsystem mit Backoffice-Miniwawi gab es keine Rundungsdifferenzen. In 2017 ist das den Kunden, die darauf drängen, eine stimmige Rechnung zu erhalten, schwer zu vermitteln, das es wegen eines "Systemfehlers" nicht möglich ist. Hier ist JTL in der Pflicht, das schnellstmöglich zu beheben.

Irgendwo habe ich mal gelesen, das man das etwas reduzieren kann, wenn man generell die Preise (auch Versandkosten) mit nur 2 Nachkommastellen kalkuliert.

 

[Peter Schulz]

Servus zusammen,

das Thema gab es ja schon öfter hier im Forum. Ich habe dazu auch ein Ticket bei JTL eröffnet. Der Support hat sich darauf hin auch unser System usw. angeschaut und mir im Anschluss an die Sitzung mitgeteilt, dass dieses nun mit in die Liste der Fehler aufgenommen wurde. Dann habe ich eine weitere Nachricht bekommen, dass das Problem nun behoben wurde und in der 1.3 korrigiert wird. Wann diese kommt weiß ich allerdings nicht.

LG Peter

 

[elcheffe]

Ich glaube jetzt werden hier gerade zwei oder drei ganz unterschiedliche Probleme vermixt.

Einmal die Geschichte mit den Nachkommastellen und der etwas "krummen" Ausgabe auf den Formularen. Hier rechnet die Wawi ja vollkommen richtig.

Das Andere sind die Abweichungen um oft 0,01 EUR bei den Zahlungsbeträgen z.B. bei Paypalzahlungen.

Und dann wir hier von Abweichungen bei Export geschrieben...

 

[Simone_die_Echte]

Ich schätze mal, dass das intern alles zusammen hängt.
Bei uns kommen die Abweichungen soweit ich das überblicken kann immer bei Gewerbetreibenden vor.
Da unsere Bruttopreise auf zwei Nachkommastellen glatt sind, haben die Nettopreise naturgemäß meist vier Nachkommastellen.
Ich würde mal vermuten, dass die Abweichungen (egal ob bei den Zahlungsbeträgen oder beim Export) daher rühren.
Aber das ist definitiv was für die Entwickler von JTL - Ticket ist erstellt...

 

[liquid]

Dieses absolut nervige Problem haben wir ebenfalls seit Urzeiten mit JTL und es wird genau so lange bereits darüber gesprochen. Es ist schon SEHR erstaunlich, dass immer wieder so getan wird, als sei das überhaupt kein Problem.

Dabei ist die Lösung so einfach: Man verbaut einen Abfragebutton im System, ob kaufmännisch gerundet auf Einzelpreisebene gerechnet werden soll. Dann werden in der Datenbank neben den mathematischen Preisen (diverse Nachkommastellen) zusätzlich je ein Netto- und ein Bruttofeld eingefügt, die die jeweils gerundeten Preise auf zwei Nachkommastellen beinhalten (Einzelpreis). Ist im System eingestellt, dass mit kaufmännischen Preisen gerechnet werden soll, dann werden diese Felder für die Berechnungen abgegriffen, sonst die Standardpreisfelder mit x-Nachkommastellen. Jetzt kenne ich den Source nicht im Detail und das würde meine Kenntnisse auch übersteigen, aber mit dieser Grundlogik ist das problemlos umsetzbar. So machen es andere Anbieter ja auch. Lei Lexware beispielsweise passen die Summen von Netto und Brutto IMMER, da gibt es nie auch nur einen Cent Differenz in der Summierung.

 

[Rico Giesler]

Wir haben das Thema intern auf dem Schirm. Leider ist es nicht ganz so einfach umzusetzen, da verschiedenste Dinge beachtet werden müssen.
PS: auch ein Kaufmännisches Runden ist nicht immer 100% genau.

 

[Simone_die_Echte]

Schups, schieb, push...

Auftragswert: 44,46 EUR

Gesamtbetrag auf der Rechnung: 44,45 EUR


Leute, dass verursacht echt viel unnötige Arbeit

 

[Rico Giesler]

Hey Simone. Mach dazu mal bitte ein Ticket auf. Du bist ja mit der neusten Version unterwegs und die Kollegen schauen dann mal drüber.

 

[gutberle]

@Rico Giesler - Come on, darüber wird schon seit vielen, vielen Jahren immer wieder hier im Forum gejammert, dazu müssen doch schon Dutzende gelbe Postits mit Erinnerungen daran, das endlich zu fixen, an allen möglichen Entwickler-Whiteboards kleben. Und dann ist das Ganze auch noch so dermaßen offensichtlich und schon beim flüchtigen Draufschauen überall präsent, da muss doch einfach jemand dransitzen ...

 

[css-umsetzung]

So ist es leider und dabei geht es nicht nur um einen Cent.

 

[Adellmour]

Nur mal so als Info, das Problem ist sogar noch in der Version 1.4.25.1...
Wir sind erst relativ spät darauf gekommen...
Wir arbeiten fast ausschließlich mit nur 2 Nachkommastellen und die Aufträge werden auch nur händisch eingegeben...
Im Auftrag selbst stimmen die Zahlen, im Ausdruck oder in der Übersicht nicht, haben mehrere Cent unterschied

Heute z.B. einer mit 7 Cent
Auftragswert Brutto in echt: 1077,40
Auftragswert Brutto in der Übersicht und am Beleg: 1077,33

 

[Wissenssammler]

Guten Morgen, bis wann ist mit einer Lösung zu rechnen, Aktuell habe ich den Fall bei einer JTL- Shop Bestellung mit Rabatt wieder.

Es sieht einfach unschön auf der Rechnung aus und macht zusätzlichen Buchungsaufwand.

Kaufbetrag laut Shop und Shop-Bestätigungsmail 301,00€
Laut Wawi dann 301,02€
Differenz 2 Cent, ist nicht viel, aber ist auch nicht schön.

Ich habe bewusst den Shop bei JTL, weil meine Hoffung ist, dass JTL intresse daran hat das zumindest innerhalb JTL alles 100%ig richtig läuft.

Würde mich über eine Antwort freuen.

 

[Rico Giesler]

Das sollte das passende Ticket dazu sein. https://issues.jtl-software.de/issues/WAWI-18568
Votet alle mal kräftig dafür, damit die Prio hier steigt und da endlich eine Lösung für euch kommt.

 

[mitlaser]

1.5.24.1 - gleiches Problem.
Langsam vermute ich bei JTL bewusstes ignorieren, weil doch andere Dinge viel angenehmer zu programmieren sind und in der Aussendarstellung besser ankommen. Ein Wawi-Programm, was nicht richtig rechnet (oder das richtig gerechnete Erbegnis nicht richtig darstellen kann) ist wohl nich so schick zu vermarkten..

 

[microline]

Das mit den Rundungsdifferenzen ist bei Staffelpreisen noch viel schlimmer.
Wenn man dann noch einen Kundengruppenrabatt gibt, z.B. 3%, dann wird das Ganze unbrauchbar.

Egal wie oft man an den vier Stellen hinter dem Komma schraubt, im Shop kommt nie der richtige Staffelpreis an.

Zumindest wird jetzt über ein Feature nachgedacht, Staffelpreise optional auf 2 Nachkommastellen kürzen zu können.

https://issues.jtl-software.de/issues/WAWI-47342

 

[Manuel Pietzsch]

Hi Freunde,

tatsächlich haben wir das Problem in der 1.6 gelöst.
Problem ist, dass die Wawi aus dem Brutto den Netto neu berechnet und diesen letztlich als Berechnungsgrundlage nutzt.

Wir speichern ab der 1.6 den Brutto so wie wir ihn bekommen und berechnen ihn erst neu wenn der Auftrag manuell verändert wird. So ist es auch egal wenn andere Systeme anders runden.

Gruß

Manuel

 

[Forsernam]

Hallo Manuel,

für die B2B-Kunden passt die Berechnung von JTL-WaWi aber generell nicht, da z.B. bei den Artikelpreisen von Netto-Beträgen ausgegangen wird und bei den Versandkosten von Brutto-Beträgen. Somit bekommt man eben regelmäßig die 1-Cent-Differenzen im Rechnungsendbetrag.

Wirklich stimmig wäre die Berechnung für B2B-Kunden nur dann, wenn man bei den Versandkosten ebenfalls von Netto-Beträgen ausgehen würde. Es sollte also bei der Anlage der Versandkosten die Möglichkeit bestehen, diese entweder als Netto- oder Bruttobetrag zu kennzeichnen. Alternativ könnte man natürlich auch zulassen, dass die Versandkosten mit 4 Nachkommastellen statt nur 2 Nachkommastellen angelegt werden können, wenn denn schon unbedingt die Versandkosten als Bruttobeträge hinterlegt werden müssen.

Nachfolgend einmal ein Beispiel was passiert, wenn man von gewünschten 7,90 Euro Netto-Versandkosten ausgeht. Hinterlegen lässt sich bei den Versandkosten durch die aktuellen Vorgaben der WaWi nur ein Bruttobetrag von 9,16 Euro (statt korrekt 9,1640 Euro).

Bei der automatischen Berechnung durch die WaWi kommt dann ein Rechnungsendbetrag von 16,73 Euro heraus, was laut dem Beleg für den Kunden nach einem Additionsfehler aussieht.

Setzt man im Auftrag aber manuell den korrekten Netto-Versandkostenbetrag von 7,90 Euro ein, stimmt der Rechnungsendbetrag über 16,74 Euro.

Frage:
Wäre es mit einem Workflow möglich, nachträglich die korrekten Netto-Versandkosten in die Aufträge zu schreiben, um zumindest an dieser Stelle die Rundungsdifferenzen zu vermeiden?

 

[Wissenssammler]

Ich warte ja schon lage darauf, dass die Versandkosten über die Wawi für den Shop (ähnlich wie ein Variations Kombinationsartikel) angelegt und verwaltet werden könn, damit könnte man das Problem doch umgehen, da man dann einen Preis optional für jede Kundengruppe hinterlegen kann. So bekommt der B2B Kunde Runde Netto-Preise und der B2C Kunde runde Bruttopreise angezeigt.

 

[Julimed]

Hi Freunde,

tatsächlich haben wir das Problem in der 1.6 gelöst.
Problem ist, dass die Wawi aus dem Brutto den Netto neu berechnet und diesen letztlich als Berechnungsgrundlage nutzt.

Wir speichern ab der 1.6 den Brutto so wie wir ihn bekommen und berechnen ihn erst neu wenn der Auftrag manuell verändert wird. So ist es auch egal wenn andere Systeme anders runden.

Gruß

Manuel

Hallo Manuel,

noch arbeiten wir nicht mit der 1.6 Version, aber kannst du bitte einen Workflow zeigen, den wir zwischenzeitlich nutzen können?

Zumindest das man per Mail informiert wird, wenn die Auftragssumme im Vorgang, von der Gesamtsumme abweicht? Durch die Mehrwertsteuerumstellung, haben wir plötzlich in den Artikeln und Versandkosten, so viele Nachkommastellen, dass es uns auch passiert, dass Aufträge wegen 1Cent hängen bleiben und leider zu spät bemerkt werden. Im Auftrag steht die Summe 50,00€, gezahlt ist genau dieser Wert, aber in der Übersicht (BruttoVK) hat er plötzlich 50,01 und setzt somit den Vorgang als unbezahlt.

Das wäre richtig super und würde uns zumindest auf die Aufträge hinweisen, die wir manuell ändern müssen.

Vielen Dank für deine Hilfe.

Julimed