Rundungsproblem bei Kleinartikeln

[mxnet]

Hallo Forum,

wir haben bei einem unserer Kunden ein Problem mit dem Bonausdruck, wenn dieser viele Kleinstartikel an seine Privatkunden (B2C) verkauft. Da er Spirituosen in 10 ml-Schritten verkauft (Abfüllung) kommt oft eine größere Stückzahl raus. z.B. 50x10ml für eine 500ml-Flasche mi Rum.

Es geht hier um einen 0,44 EUR Artikel (Netto = 0,3697 EUR). LS-POS rechnet bei 50x 0,44 EUR = 22 EUR - richtig. Wenn jetzt ein Artikel mehr genommen wird ... also 51x oder mehr ... steht dort 22,43 EUR (oder mehr!). Das kann natürlich keiner erklären ... ich jedenfalls nicht. Und der Kunde findet es überhaupt nicht komisch.

Wir haben den Vorgang auch direkt in JTL-Wawi nachgestellt. Dort rechnet das System bei 51x 0,44 EUR auch 22,44 EUR

Den Vorgang haben wir als Anlagen angefügt.

Hat jemand eine Idee?

Gruß
mx-net solutions - Goslar

 

[Shopworker.de]

AW: Rundungsproblem bei Kleinartikeln

In der Wawi wird intern mit 4 Nachkommastellen gerechnet, dadurch kommt die leichte Rundungsdifferenz .... gibts aber auch schon einige Threads zu ...

 

[mxnet]

AW: Rundungsproblem bei Kleinartikeln

Hallo Shopworker,

das Problem ist auch nicht in Wawi, sondern in LS-POS!

uns geht es ja um den BON-Ausdruck. Vielleicht gibt es da ein Workaround. Die Mathematik wollen wir ja nicht anzweifeln ... deshalb auch der neue Thread!

Gruß
mxnet

 

[reneromann]

AW: Rundungsproblem bei Kleinartikeln

Was habt ihr denn für Preise in der Wawi hinterlegt?
Brutto oder Netto?
Sind noch Rabatte aktiv?

Und was heißt "dann steht dort 22,43 (oder mehr)"?
Was steht denn genau dort?

Insbesondere bei Brutto-Netto-Umrechnung plus Rabatten kommt ihr schnell in den Bereich, wo "Grütze" passiert, weil aufgrund des Rechnens mit 4 Nachkommastellen dann halt schnell mal doch der eine oder andere Cent verloren geht.

Und zu deinem Beispiel:
Solltet ihr statt dem Bruttopreis von 0,44 EUR den Nettopreis von 0,3697 EUR eingegeben haben, so ergibt das einen Bruttopreis von 0,439943 EUR, von dem die Wawi jedoch nur die ersten 4 Stellen verwendet.
Sieht auf den ersten Blick gut aus, ist aber bei deinem 51x-Beispiel fatal. Denn statt 0,44 oder 0,439943 wird mit 0,4399 gerechnet. Und jetzt kommt das Problem: 0,4399 * 51 => 22,4349, gerundet auf volle Cent-Beträge also 22,43 EUR statt 22,44 EUR (0,439943 bzw. 0,44).

Deshalb bitte nochmal prüfen, ob ihr in der Wawi den Netto- oder den Bruttopreis hinterlegt. Sollte der Nettopreis hinterlegt sein, so werdet ihr das Problem immer wieder bei Bruttopreisen haben, während bei Eingabe des Bruttopreises ähnliche Probleme bei den Nettopreisen passieren. Insbesondere im Endkundengeschäft sollte daher IMMER der Brutto- und nicht der Nettopreis hinterlegt werden. Und nachdem der Bruttopreis hinterlegt wurde, auf keinen Fall in das Eingabefeld des Nettopreises klicken, da die Wawi ansonsten statt dem Brutto- auf einmal den Nettopreis verwendet!

 

[mxnet]

AW: Rundungsproblem bei Kleinartikeln

Hallo reneromann,

wir haben beide Preise in Wawi stehen. Dort steht unter Brutto auch 0,44 EUR. Bei der Eingabe der Produkte wurde aber nur der Bruttopreis eingegeben und der Nettopreis wird dann errechnet ... oder stehe ich total im Nebel?.


XXXXXXX
wegen 22,43 EUR (oder mehr): ich meinte mit "oder mehr", dass ein höherer abweichender Preis bei einer höheren Stückzahl dargestellt wird. --> verstanden? ))
XXXXXXX

Gruß
mx-net

 

[reneromann]

AW: Rundungsproblem bei Kleinartikeln

Wenn der Bruttopreis eingegeben wird, wird auch dieser in die DB geschrieben.
Wichtig ist nur, dass in das Eingabefeld Nettopreis nicht mehr geklickt wird, weil ansonsten der (vorher errechnete und gerundete) Nettopreis geschrieben wird...

By the way: 0,44 gibt im Binärsystem eine periodische Zahl, wird also in der Datenbank als irgendwas bei 0,4399 gespeichert.
Wenn man damit weiterrechnet ergibt sich natürlich wieder das (oben bereits aufgezeigte) Problem mit dem Runden...

 

[mxnet]

AW: Rundungsproblem bei Kleinartikeln

Hallo,

wir haben die Datenbank geprüft. Dort steht in der Brutto-Spalte 0,44 EUR und in der Netto 0,3697478991596639 EUR. Somit sollte das System doch richtig rechnen! Auch der Hinweis von Luwosoft (1. Wawi-Update auf die aktuelle Version und 2. MSSQL-Update von 2005 auf 2012) haben wir gemacht, konnten uns den Grund aber nicht erklären. Denn: Dieses Problem dürfte es doch nicht geben.

Nochmals zur Erinnerung: 0,44 x 51 = 22,44 EUR und nicht 22,43 EUR

XXXXXXXXXXXX

Jetzt zu diesem Thema Binärsystem! Binärsystem hin oder her, rechnerisch ist das auch bestimmt korrekt, dass 0,44 x 51 = 22,43 sind, aber ...

1. wenn wir uns nicht komplett irren, rechnen wir in Deutschland nach dem Dezimalsystem und da sind nun mal 0,44 x 51 = 22,44
2. wie sollen wir das nur unserem Kunden erklären bzw. unser Kunde seinen Kunden? Da machen sich beide Parteien doch lächerlich, wenn wir mit dem Binärsystem kommen.
3. wie haben denn die anderen tausend LS-POS-Kunden (lt. Luwosoft wurde das Produkt über 3500x verkauft) das Problem gelöst?
4. Warum rechnet Wawi z.B. beim Sofortauftrag richtig und die Kasse LS-POS leider nicht! (siehe angehängte Screenshots oben)

Das sind nur einige Überlegungen, die wir in den letzten 10 Minuten hatten.

Wir haben auf jeden Fall einen klaren Auftrag von unserem Kunden für die nächsten 3 Wochen mitbekommen:
Aussage: Er (unser Kunde) hat ein funktionsfähiges Kassensystem erworben, das auch richtig rechnen sollte. Wenn wir das bis Mitte März nicht geregelt bekommen, wird er sich entsprechende Maßnahmen überlegen (die Gedanken sind hier frei).

Seit ihr alle Vertriebler, die dieses Produkt verkaufen? Wenn ja, wie regelt ihr das?

PS: 0,45 x 51 sind nach Binärsystem 22,96 und nicht 22,95! Dann schlagen wir unserem Kunden vor dem Preis anzupassen, um seine Kunden zu "bescheißen"

Gruß
mx-net

PSS: Genial ist auch ein Bonausdruck von unserem Kunden. Dort werden zwei Produkte ausgewiesen zu jeweils 50 x 0,44 EUR mit einem Produktpreis von jeweils 22 EUR! Der Gesamtbetrag auf dem Bon ist aber 43,99 EUR... ratlos!

 

[reneromann]

AW: Rundungsproblem bei Kleinartikeln

Zu deinen 4 Gedanken zum Binärsystem:
1. Ja, Menschen(!) rechnen nach dem Dezimalsystem... Interessanterweise gerade weil der Mensch nämlich 10 Finger hat (und man damit dann schön schnell abzählen kann).
Das hat aber nichts mit Deutschland zu tun - immerhin haben z.B. selbst die Römer vor knapp 2000 Jahren schon mit dem Dezimalsystem gearbeitet...

Das tut aber nichts zur Sache, weil Rechentechnik i.d.R. im Binärsystem arbeitet. Der Computer kann nämlich nur "0" oder "1" und nichts anderes.
Für finanztechnische Berechnungen gibt es neben dem Binärsystem (für das alle Mikroprozessoren optimiert sind) noch das BCD-System (Binary Coded Decimals) - jedoch ist das BCD-System bei weitem nicht so verbreitet (u.a. wegen dem größeren Speicherbedarf, da pro Halb-Byte nur eine Ziffer gespeichert wird - bei BCD-Darstellung gehen pro Byte zwei Dezimalstellen, bei Binärdarstellung das ~2,5-fache desselben. Weiterhin ist das BCD-System auch aufgrund der komplizierteren Regeln bei arithmetischen Berechnungen auch langsamer bei Berechnungen).
MSSQL unterstützt BCD, jedoch müsste der Kern der Wawi komplett auf BCD umgeschrieben werden, damit BCD genutzt werden kann und solche "Probleme" nicht mehr auftreten - das ist aber auch schonmal vor mehr als einem Jahr hier im Forum ein Thema gewesen. Solange jedoch nicht auf BCD umgestellt wird, geht gar nichts und es wird immer wieder zu solchen Rundungsproblemen kommen. Übrigens sind diese Probleme beim Finanzamt "bekannt" - insbesondere dass durch Rundungen dort dann Veränderungen im Centbereich entstehen.

Zu 2.:
Tja, das ist "euer" Problem
Nein, im Ernst - anderer Preis, der im Binärsystem "vernünftig" darstellbar ist, reicht aus. Generell gilt hierbei, dass alle Potenzen von 2 (also 1/2, 1/4, 1/8, 1/16 usw.) und die Summe/Differenz dergleichen ohne Probleme funktionieren.
Heißt also bspw. 0,25; 0,50; 0,75...

Zu 3.:
Wenn man "vernünftige" Preise benutzt und nicht mit solchen Mengen arbeitet, sondern stattdessen z.B. mit Stücklisten arbeitet.
Bei den angebotenen Mengen (also bspw. 100 ml-Flasche, 250ml-Flasche, 500ml-Flasche, ...), wären entsprechende Stücklistenartikel (also 500ml-Flasche => Stückliste mit 50x 10ml vom Basisprodukt) viel besser als die 50x Basisprodukt.
Zumal dann auch beim Stücklistenprodukt viel einfacher ein "Mengenrabatt" möglich ist.

Zu 4.:
Gute Frage...
Es könnte sein, dass das Problem ggfs. sogar noch verschärft wird, je nachdem ob mit Netto- oder Bruttopreisen gearbeitet wird.

Übrigens: Die 0,44 / 1,19 sind in der Wawi aufgrund der 23 (binären) Nachkommastellen [Gleitkommazahl einfacher Genauigkeit, IEEE 754] zur Speicherung nicht etwa 0,36974789915966386554621848739496 sondern 0,3697478771209716796875. Mehr als 7-8 (dezimale) Nachkommastellen gehen da (leider) nicht...

 

[mxnet]

AW: Rundungsproblem bei Kleinartikeln

vorab erst mal Danke für deine Mühe und Ausführung. Ich bin ja froh das wir überhaupt Gehör finden. Ich möchte auch nicht in Frage stellen das dies mathematisch nicht korrekt ist. Aber mal das technische mal ganz ausgeblendet (sofern das geht):

a) ich soll den Kunden jetzt sagen das er "vernünftige" Preise benutzen soll oder das bestimmte Preise nicht funktionieren

b) das das "Problem" ist rein mathematischer Natur - bedeutet wenn ich morgen bei Aldi, Rewe ein Artikel finden (0,44€) den 51 mal kaufe tritt das selbe auf. - oder haben die das BCD-System?

verstehe mich nicht falsch, sicherlich bist du dafür nicht verantwortlich - willst ja nur helfen, erklären - aber ich kann mir nicht vorstellen das dies bei allen Kassensystemen auftritt.

Also Fazit:

1) mit Einstellungen im WaWi kommen wir nicht weiter
2) Einstellungen im LS-POS gibt es dazu auch nicht
3) Soll die Kasse vernünftige BONs drucken ist LS-POS ungeeignet - heißt: Wir müssen das System wechseln

Danke für deine/eure Tipps!

Gruß
mxnet


PS: bin mal gespannt wie die das machen: reBuy ? 400.000 Artikel je 44 Cent (zzgl. 3,99? Versand) » Haus, Garten und Freizeit

 

[mxnet]

AW: Rundungsproblem bei Kleinartikeln

passend zum Thema Kasse ist auch dieser Link --> EC Cash Rollen online kaufen ab 44 Cent netto/Rolle

gibt mal 51 Artikel ein ...

Gruß
mx-net

 

[reneromann]

AW: Rundungsproblem bei Kleinartikeln

Das Problem ist mathematischer Natur... In dem Moment, wo bei Berechnungen (aufgrund von Systembeschränkungen) Teile abgeschnitten werden, kommt es immer zu den Ungenauigkeiten.
Ob das Problem bei Aldi/Rewe/woanders auch auftritt, hängt von deren verwendeter Software ab. Solange dort aber nicht mit BCD sondern im Binärsystem gearbeitet wird, wird das Problem auch dort auftreten.
Jedoch muss es dort nicht zwingend bei 0,44 EUR * 51 auftreten, sondern kann je nach Design der Software auch erst bei anderen Größenordnungen auftreten...

Was hier aber ggfs. helfen würde, wäre klar zu definieren, wann gerundet wird...
Denn bei dem 2 * 50 Stk. à 0,44 EUR => 43,99 EUR deutet darauf hin, dass dort zwischendurch nicht korrekt auf 22,00 EUR gerundet wurde, sondern mit ~21,995 EUR weitergerechnet wurde...
Hier könnte man ggfs. bei LS-POS und der Wawi nochmal angreifen und schauen, wann auf wieviele Stellen nach dem Komma gerundet wird - bei Endkunden müssen ja die Bruttopreise stimmen, während bei Firmen die Nettopreise stimmen müssen (wobei es für letzteren Punkt eine Einstellung in der LS-POS gibt).

Zu 3)
Du kannst der LS-POS auch beibringen, dass statt dem LSPOS-Bin die Wawi-Rechnung gedruckt werden soll.
Problem an der Sache ist nur, dass dort dann natürlich im Beispiel 44,00 EUR ausgewiesen werden, während die Kasse im Kassenprotokoll nur 43,99 EUR buchen würde...

Zu deinem Link:
Hier kommt die gleiche Diskrepanz zum Tragen: Für Endkunden gelten Bruttopreise - die 0,44 EUR netto entsprechen dabei 0,44 * 1,19 => 0,5236 EUR, also 0,52 EUR. 51 x 0,52 EUR brutto (also für den Endkunden korrekt berechnet) ergibt 26,52 EUR, ausgewiesen werden aber (nach Nettopreisrechnung für Unternehmen korrekte) 26,70 EUR... Hier sind's je nach Rundung dann sogar 18 ct Unterschied zwischen Brutto- und Nettopreisrechnung.
Letzten Endes gleiches Problem, nur diesmal deutlicher ersichtlich, sofern die Artikelanzahl größer wird.

 

[mxnet]

AW: Rundungsproblem bei Kleinartikeln

Wie gesagt ich glaube dir das alles. Was ich leider nicht verstehe, oder besser nicht glauben kann:

Über 3500 Installationen in 9 Nationen setzen ein klares Signal. <--- von der LS-POS Webseite:

alle diese Kunden verkaufen keine 0,44Cent Produkte - oder ggf. ähnliche Preise mit dem "Fehler" (hast es ja oben beschrieben welche das sein könnten)

Wie schon mehrfach erwähnt bin ich dir für deine Antworten dankbar. Leider habe ich trotzdem keine pragmatische Lösung die ich dem Kunden erklären kann... bis auf ändere deine Preise, doch ehrlich, das würdest du doch auch keinen erklären. Gerade im Einzelhandel geht es doch um die Cent-Beträge. Und was wir wollen ist ja nur einen plausiblen BON.

Gruß
mxnet

 

[reneromann]

AW: Rundungsproblem bei Kleinartikeln

Ich glaube das Problem liegt weniger an den 0,44 als viel mehr an der verhältnismäßig großen Menge (mit 50x des Produkts).
Als "Abhilfe" würde ich hier auf Stücklisten mit 10, 25, 50 mit jeweils entsprechenden Fixpreisen setzen - dann gibt's halt nicht 50x 10ml, sondern 5x 100 ml oder 1x 500 ml.
Immerhin wird bei Stücklisten der "originale" Artikel dann auch um die korrekte Menge reduziert - und es reduziert dem Verkäufer das "manuelle" Ausrechnen der korrekten Stückzahl (ok - bei 50x 10ml sollte das noch jeder können, aber was ist, wenn ein anderes Produkt auf einmal in 15 ml oder 25 ml Schritten ist?).

Schau doch mal auf den Kassenbon bei Rewe, wenn du einen Bierkasten kaufst - da steht auch nicht 20x 1 Flasche Bier, sondern 1 Kasten Bier [wo dann intern die Kasse trotzdem natürlich von den Flaschen als Lagerbestand jeweils 20 abzieht, wenn 1 Kasten verkauft wird - zumal der Preis für 1 Kasten teilweise auch günstiger ist als der für 20x 1 Flasche]. Genau so funktionieren ja auch Stücklisten in der Wawi (und natürlich in LS-POS & dem JTL- Shop). Das der Lagerbestand dann intern auf einen anderen Artikel mit Faktor verweist, sieht und merkt der Kunde nicht, während in der Wawi nur ein Lagerbestand für beide Artikel verwaltet wird (im Bierkasten-Bsp. dann die Einzelflasche).

 

[Janusch]

AW: Rundungsproblem bei Kleinartikeln

In der Wawi wird intern mit 4 Nachkommastellen gerechnet, dadurch kommt die leichte Rundungsdifferenz...

Nein, die Wawi rechnet intern mit allen Nachkommastellen. Es werden nur 4 in der GUI angezeigt. Das erklärt den Unterschied.

 

[ralph_1]

AW: Rundungsproblem bei Kleinartikeln

Ich vermute den Fehler, den ich gerade in 1.7.0.1 nachgestellt habe, bei LS-POS.

51*0,4399=22,4349
aber JTL-Wawi rechnet 51*0,4399xxxxxxx=22,4371

JTL-Wawi kommt zum Ergebnis 22,44. LS-POS kommt auf 22,43.

Hier der Auftrag in JTL-Wawi:


Mathematik hin oder her, ich da ganz bei mxnet: Der auf dem Bon erscheinende Bruttoendpreis muss (aus Sicht des Kunden) "stimmen". Und 51*0,44 ist eben nicht 22,43.

@mxnet: Rundungsfehler sind immer wieder mal Thema im Forum, vor allem im Zusammenhang von Rabatten oder Teilmengen. Teilweise wurden sie auch behoben, in diesem Fall von Luwosoft: http://forum.jtl-software.de/fragen-rund-um-ls-pos/59059-rundungsfehler-rabatt.html#post356003
Bei mir treten sie extrem selten auf, und leider kann ich nichts zur Lösung beitragen.

--
wawi099923,lspos1.701

Edit: Kleine Episode am Rande:
Oben genannter Bon, für den in JTL-Wawi eine Rechnung über 22,44 EUR angelegt wurde, habe ich in LS-POS storniert. Die daraufhin in JTL-Wawi erstellte Rechnungskorrektur zeigt 22,43 EUR an.

 

[Janusch]

AW: Rundungsproblem bei Kleinartikeln

Das ist korrekt, Rechnungskorrektur erechnet nicht die Preise der Artikel neu, sondern nimmt die Werte der Rechnung die übergeben wurden.

 

[mxnet]

AW: Rundungsproblem bei Kleinartikeln

Danke für die Hinweise.. schlussendlich werden wir wohl versuchen den Kunden Richtung reneromann`s Hinweis zu bekommen. Den Hinweis mit der Veringerung der Stückzahl empfinde ich als machbar aber es bleibt ein Workaround... Für uns als Dienstleister hat das natürlich ein ziemlich faden Beigeschmack. Auch wenn wir nicht die Kassenspezialisten sind haben wir grundlegend die normalen Sachen geprüft. - gängige Datenbank, welches OS darunter, Backup möglich, Design.. etc... Aber wer prüft schon ob die BON`s bei bestimmten Preisen passen.

Wir haben derzeit noch die ein oder andere Anfrage in dieser Richtung und hätten uns gern auch auf diese Produktkombination eingestellt. So wird das aber leider nichts... Ich will hier nicht wie ein nörgelnder Abo-Kunde klingen, so nach dem Motto: "Wenn ihr es nicht günstiger Macht gehe ich woanders hin". Aber so kann ich das Gesamtkonstrukt leider nicht an den Kunden bringen. Auch die Hinweise seitens des Herstellers sind hier nicht wirklich ausreichend oder überhaupt vorhanden. Ich würde mir sogar eine Fehlbedienung oder Konfiguration vorwerfen lassen - nur um das Thema endlich von Tisch zu bekommen. Schade!

Und ralph_1 : BESTEN DANK, ich wollte heute schon die neue Version runterladen und in einer Testumgebung nachstellen. Die Arbeit hast mir hiermit abgenommen - ich gebe dir symbolisch ein Bier oder Kamillentee aus !

Gruß
mxnet

 

[Buinger]

AW: Rundungsproblem bei Kleinartikeln

Wie schaut es eigentlich mit der Emailvorlage für die Rechnungskorrektur aus, kann man dort die Anzahl der Nachkommastellen ändern? Während es im angehängten Rechnungsformular korrekt mit 2 Nachkommastellen angezeigt wird haben wir es in der Emailvorlage (mit den Variablen {{Vorgang.Positionen.BruttopreisGesamt05}} {{Vorgang.Rechnung.Auftrag.Währung}} ) oft mit Werten wie 297,999997558564 EUR anstelle von 298,00 EUR zu tun.