Neu Bei PayPal Zahlungen wird falsch gerundet z.B. -0,01 Zahlung offen

[Janine]

Nach dem gestern der Fehler mit der PHP/Modul Version behoben wurde läuft der Shop.
Nach den ersten Bestellungen zeigt sich das bei PayPal Zahlungen oft falsch gerundet wird.
Unter "Ist bezahlt" steht dann z.B. Anz. /0,02 oder auch Ja / -0,01.
Ist das ein Bug oder eine Einstellungsfrage des Shops/Plugin?

 

[JulianG]

Wichtig wäre hier die exakten Daten zu wissen:
- Stimmt der PayPal-Betrag überein mit der Shop-Bestellbestätigung - Sprich: Weicht nur JTL-Wawi ab?
- Wie exakt sah die Bestellung preislich aus im Shop und in JTL-Wawi?
- Wie exakt sind die Brutto UND Nettowerte der Produkte in JTL-Wawi?

 

[Janine]

Beispiel
Auftrag in der Wawi Netto 107,59 Brutto 124,80
PayPal Zahlung 124,81
Ich habe es mal im Shop nachgestellt, dort wird für den Einkauf/die Waren auch 124,80 angezeigt.
In der Shop Übersicht steht der Auftrag so drin:

So hat der Kunde einen Cent zu viel bezahlt

 

[JulianG]

Kannst du bitte einmal die genauen Brutto/Nettowerte von allem posten, mit möglichst allen Nachkommastellen:
- Artikelpostiionen (Angabe aus der Wawi Artikelverwaltung)
- Versandkosten (Angabe aus der Versandart im JTL- Shop Backend und ob netto oder brutto Berechnung)
- ggf. zusätzliches (nicht aus dem Auftrag, sondern aus der Preis-Einstellung)

Dann können wir versuchen es nachzustellen.

 

[Janine]

So, ich habe das ja über den Support gemeldet. Ticket#2020102010002377
Offensichtlich ein bekanntes Problem.
https://issues.jtl-software.de/issues/SHOP-3140
https://issues.jtl-software.de/issues/SHOP-2395
Ich muss nun jeden Preis (Brutto) erneut in das Produkt eingeben, dann wird ein neuer Netto Preis berechnet.
Wo dann die Probleme weg sind?
Das es da nicht etwas Automatisches gibt, das man über die Wawi laufen lassen kann?
Jedes Produkt aufrufen und das machen?
Beispiel Spannschraube Brutto
VK Brutto im Artikel hinterlegt 7,79€ Netto 6,7143
Im Auftrag steht VK Brutto 7,7886 Netto 6,7143
Wenn ich jetzt in der Artikel Maske die 7,79 lösche und neu eingebe ändert sich plötzlich das hinterlegte Netto zu 6,7155
Das ist doch Wahnsinn, da muss es doch eine 1 Knopf Update Lösung geben um das zu korrigieren.
Was soll denn da der Kunde denken wenn zwischen Rechnung und bezahlter Summe die Zahlen nicht stimmen?
Von den letzten 5 Aufträgen stimmte einmal die bezahlte Summe. 2 "zu viel" und 2 "zu wenig" bezahlt. Bzw Richtige Summe bezahlt aber falsche Summen im Auftrag/ Shop angezeigt.
Ich bitte um eine Lösung, wo ich nicht jeden Artikel einzeln anfassen muss.
Danke

 

[JulianG]

Um preise schneller anzupassen kannst du zum einen die Preisglättung benutzen (vorher Sichern): https://guide.jtl-software.de/jtl-w...wi-durchfuehren/#registerkarte-preisglaettung
oder via Ameise exportieren, mit Excelfunktionen anpassen und reimportieren.

Bei den bekannten Problemen sollte das Problem allerdings recht selten auftreten (außer es sind sehr beliebte Produkte betroffen, die ständig und insbesondere bei hoher Stückzahl gekauft werden). Es kann jedoch sein, dass das Problem mit 16% USt. häufiger auftritt als mit 19% USt.
Ist von den beschriebenen Problemen denn etwas der Fall? Sonst würde ich erneut um ein konkretes Beispiel mit allen notwendigen Informationen zum Nachstellen bitten.

 

[wawi-dl]

Wir haben das Problem seit Jahren, vor allem bei Artikeln mit Staffelpreisen, ab 10/25/50/100 Stück gibt es Rabatte in Prozente, zack ist Einzelpreis ein Preis mit vielen Nachkommastellen.

Öffnet man den Auftrag steht unten 30,13€ (genau gerechnet aber wohl 30,1345€) und wurde auch so bezahlt, in der Auftragsübersicht steht aber 30,14€ als Beispiel, es fehlt also "scheinbar" 1 Cent und Auftrag ist unbezahlt.
Wir müssen im Auftrag dann 1 Artikel bei Nachkommastelle so runden, dass es passt.

Die Rundung im Auftrag und Auftragsübersicht muss identisch sein!

 

[microline]

Das Problem ist schon ewig bekannt und tritt nicht "recht selten" auf. Es gibt momentan keine Lösung, auch nicht mit Preisglättung o.ä.
Die Senkung der Mwst. verstärkt den Bug nur noch und ist nicht der Auslöser.

Ich verkaufe viel mit Rabattstaffeln, das ist ein ewiger Krampf. Zig Tickets an JTL haben nur eine Antwort ergeben: Momentan (seit Jahren) keine Lösung in Sicht.

 

[JulianG]

Die bekannten Probleme sind leider nur schwer zu lösen, das ist richtig. Im ersten Post klang es jedoch so, als wäre hier Bestellabschluss und Wawi-Auftrag identisch und nur PayPal wäre abweichend, daher weiterhin mein Interesse an einem konkreten Beispiel.

 

[wawi-dl]

Für mich ist das Problem eher nur in der Wawi, weil es den Preisunterschied innerhalb des Auftrages zur Auftragsübersicht gibt.

Sobald wir den Fall haben, geben wir gerne Bescheid.

 

[Nico.W]

Hallo,
warum wird sowieso in der WAWI mit so vielen Nachkommastellen gerechnet und nicht nur mit 2. Ich kann doch ee nicht mit weniger als Cent bezahlen. Das nächste Problem ist auch, dass man nicht einstellen kann welche Abmessungen man hat. Hinterlegt ist leider fest im Shop Template cm, musste es per Hand abändern. Das geht allerdings nur wenn man mm Ware hat wie bei uns.

 

[wawi-dl]

Das ist schon korrekt so, dass einzelne Artikel mit Nachkommastellen berechnet werden, nur der Gesamtbetrag muss korrekt in der Wawi gerundet werden, analog zum Shop.

Aber schon innerhalb der Wawi gibt es Rundungsunterschiede und wurde oft gemeldet.

 

[koiandreas]

Die bekannten Probleme sind leider nur schwer zu lösen, das ist richtig. Im ersten Post klang es jedoch so, als wäre hier Bestellabschluss und Wawi-Auftrag identisch und nur PayPal wäre abweichend, daher weiterhin mein Interesse an einem konkreten Beispiel.

Hallo Julian,

bei uns ist genau das der Fall. Gibt es dazu eine Lösung? Bestellabschluss in Woocommerce Warenkorb ist bspw. 85,50 und in der Wawi ebenfalls 85,50 jedoch hat Paypal laut Woocommerce erst einen Validierungsfehler mit 85,49 und demnach wird der Auftrag in der Wawi nicht freigegeben, da 1 cent zu wenig gezahlt wurde.
Würde mich über postive NAchrichten freuen

 

[bibo]

Seit dem Update auf 2.0.1 haben wir exakt dieses Problem, eine Lösung kann ich nicht finden ? Hat jemand einen Tipp ?
Kaufpreis in Bestellbestätigung 229,59 in Wawi 229,60 und PayPal 229,59

Der Auftrag wird dadurch nicht als bezahlt gesetzt und erscheint nicht im Versand.

 

[NoOne]

Shop 5.6? Da gibts das hier: https://issues.jtl-software.de/issues/SHOP-9358
In dem Fall kann es helfen in der /includes/src/Cart/Cart.php die Zeilen 1094, 1144 und 1171 von

$total = \round(\round($total, 3), 2);

in

$total = \round(\round($total, 4), 2);

zu ändern.

 

[Elsterhund]

Hallo,

wir haben auch wieder vermehrt die Probleme. Es ist auch kein Zufalle. Nach der Umstellung auf die aktuellste Wawi Version und aktuellste Shop Version haben wir gestern 12 Bestellungen mit diesem Rundungsfehler. 12 Bestellungen die in der Wawi angefasst werden müssen damit diese ausgeliefert werden und die Zahlung stimmt. Auch in Klarna muss man aufgrund dieses Rundungsfehlers die Bestellung bzw. diese 0,01 Position erfassen, sonst bekommt man das Geld nicht.

Wieso macht JTL das nicht ($total = \round(\round($total, 4), 2) Hat das eventuell Auswirkungen an anderer Stelle?

Theoretisch klingt das doch ganz plausibel von 3 auf 4 anzupassen, weil die Wawi ja auch mit 4 stellen arbeitet.

Besten Dank!
Sven

 

[wawi-dl]

nach der Anpassung ist bei uns ruhe

 

[Elsterhund]

nach der Anpassung ist bei uns ruhe

welche Anpassung?

Die:

$total = \round(\round($total, 3), 2);

in

$total = \round(\round($total, 4), 2);

 

[Elsterhund]

Hallo,

angeblich soll das ja am Preis in der Wawi liegen.
Alte Preise stehen ja zum Beispiel noch mit ein oder 2 stellen nach dem Komma.

In der Datenbank sieht das dann zum Beispiel so aus (Wawi):
SELECT
a.cArtNr,
a.fVKNetto,
CONVERT(DECIMAL(20,10), a.fVKNetto) AS NettoExakt
FROM dbo.tArtikel a
WHERE a.cArtNr = '2025OS1789';


cArtNr fVKNetto NettoExakt
2025OS1789 3.7300000000000 3.7300000000

Ich hatte immer gelesen, das es nicht per Import angepasst werden kann. Kann es doch! Wenn man es per Brutto importiert, wird Netto von der Wawi neu berrechnet.

Ameise-Export: Artikelnummer + Brutto-VK
Ameise-Import: dieselbe Datei als Preis-Import (Standardpreis brutto) zurückspielen

Das wars.

Dann sieht es in der Datenbank so aus:
cArtNr fVKNetto NettoExakt
2025OS1789 3.7289719626168 3.7289719626

Auch in der Wawi sieht es dann so aus, als wenn man es manuell machen würde.

Mal schauen ob es sich dann erledigt hat oder ob das Problem immer noch auftritt.

Vielleicht hilft es jemanden!

Liebe Grüße
Sven