Format Nettopreise bei Varianten (nur 2 Stellen nach dem Komma)

[Claudiocool]

Hallo Freunde,

 

die Suche gab hier nichts her, darum mal kurz hier die Frage:

 

Wenn ich einem Artikel Varianten zuweise, die sich dann auch preislich auswirken, kann ich ja den Netto- oder den Bruttopreis angeben, so wie bei den Preisen grundsätzlich ja auch.

 

Der Unterschied bei beiden ist, dass der Artikelpreis selbst die Nettopreisform 6-stellig hinter dem Komma ist, so dass letztendlich kaum Rundungsfehler auftreten bei Kunden, die Bruttopreise bezahlen, bei den Varianten ist es aber beim Nettopreis so, dass nur 2 Stellen hinter dem Komma auftauchen, was dann schnell zu Rundungsfehlern führt, wenn man gleich mehrere Produkte im Wagen liegen hat  und bei der Anlage des Preises den Nettopüreis gesetzt hatte.

 

Jetzt bin ich auf der Suche, wo das Preisformat geändert werden muss.

 

Hier das beim Normalpreis:

 

Und jetzt bei den Varainten:

 

Gibt man es Brutto ein, wird es in der Datenbank mit den 6 Stellen gespeichert, das ist also mathematisch korrekt, aber ich kriege nach dem Speichern im BO nur den gerundeten Nettopreis gezeigt, weiß dann also nicht, ob der glatt ist oder eben ab der 3. Stelle noch was kommt. Lustig ist, dass man es bei der Anlage eines Bruttopreises sieht, wie er das netto berechnet, aber wenn man später drübergeht, eben nur 2 Stellen sieht.

[rictools]

Ich würde generell den wichtigeren Preis (normalerweise also den Preis inkl. MwSt.) eintragen und den Preis ohne MwSt. daraus berechnen lassen.

[Scully]

Spannend. Eben mal in der Datenbank nachgesehen:

 

Produkte Preis = Dezimal 20,6

Produkte-Variante = Dezimal 17,2

 

Sinn macht das eigentlich ja kaum. Ich vermute aber, dass es mit einer Änderung alleine in der Datenbank nicht getan ist. Ich würde price.js und / oder attribute.js als Kandidaten sehen, wo das Thema dann auch noch zu fixen wäre.

 

z.B. in attribute.js

    Line 56:         $('#attribute_price, #attribute_priceTEReal, #attribute_priceTI').val('0.00');
    Line 152:                 new_elem = create_attribute_row(elem.getAttribute('name'), elem.parentNode.getAttribute('name'), elem.value, '0.00', '0.00');

Edited September 3, 2017 by Scully (see edit history)

[Claudiocool]

In der DB wird der Nettopreis dann richtig eingetragen, wenn man ihn Brutto ins intere Feld (inkl. Mwst) einträgt, aber eben nur dann. Richtig wäre aber, dass er anhand des Nettopreises einen Bruttowert berechnet (falls der nicht ohnehin als Bruttopreis eingetragen wird) und dann den Bruttopreis geradesetzt, also ohne versteckte weitere Stellen hinter der 2. Kommastelle und dann quasi daraus dann den Nettopreis bildet. Klingt jettt kompliziert, aber nur so wird man Rundungsfehler bei den Bruttopreisen wegbekommen.

 

Im Einzelnen muss es so sein, dass es 2 Fälle gibt:

 

1. Ich verkaufe was für 20 EUR brutto und gebe das so ein, dann muss der Nettopreis daraus Netto=Brutto/(1+Steuersatz/100) gerechnte werden

2. Ich trage z.B. 12,20 Netto ein, dann sagt er, Brutto sind das 14,52 EUR, jetzt sollte er aber daraus 12,201681 Netto machen, ansonsten läuft irgendwann bei genügend Artikeln der Bruttopreis davon, weil der den aus dem Nettopreis errechnet. Bei 10 Stück wären es dann Brutto 145,18 statt 145,20, also schon 2 Cent zuwenig.

 

Eigentlich müsste der Shop mit Netto_N für Geschäfte ohne Umsatzsteuer arbeiten, da dann der glatte Satz mit nur 2 Nachkommastellen und dann eben noch mit Netto_B für die Geschäfte mit Umsatzsteuer, dann würde es in beiden Fällen glatt laufen und die Rundungsfehler würden nicht auftauchen. Weil egal, wie man es dreht und wendet, es wird irgendwann immer aus dem Ruder laufen, wenn die Stückzahlen hoch genug sind.

 

PS: Gerade bei den Preisen selbst probiert, da ist es auch so, wenn man den Nettopreis glatt eingibt und da dann sofort auf Speichern geht. Also muss man bei den Preisen selbst auch darauf achten, dass man da nicht speichert, sondern weiter mit Tab geht, bis man unten ist.

 

Blöde Sache

Edited September 3, 2017 by Claudiocool (see edit history)