v3.9.x Rundungsprobleme durch Preise als float

Thema wurde von Anonymous, 15. Mai 2018 erstellt.

  1. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Hallo,

    dies hier schon bekannt?

    (Link nur für registrierte Nutzer sichtbar.)

    VG
     
  2. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Schon bekannt ist gut....

    Die Rundung von Beträgen sind ein Dauerbrenner Thema, seit Jahren, immer wieder, und bei weitem nicht nur bei uns. Wir rechnen in aller Regel mit Floats, mit 4 Stellen nach dem Komma. Andere Systeme wie PayPal, DHL, und wie die alle heissen, rechnen auch gerne mal anders, dafür sind eine Vielzahl von Workarounds im Shop.

    Das wesentliche:
    Es gibt nicht die eine Rechenweise und Genauigkeit, die garantiert für alle passt. Wir können darum auch nicht alles auf einen Standard X umbauen. Dann geht einiges kaputt.
     
  3. Anonymous

    Anonymous Erfahrener Benutzer
    Mitarbeiter

    Registriert seit:
    22. Juni 2011
    Beiträge:
    4.760
    Danke erhalten:
    1.748
    Danke vergeben:
    137
    In PHP ist man bei dem Thema einigermaßen auf der sicheren Seite, sofern man PHP-Funktionen wie number_format() oder round() zum Runden benutzt. Eine blöde Fußangel ist z.B. printf():

    PHP:
    php $b 2.25;
    php > echo number_format($b2);
    2.25
    php 
    > echo number_format($b1);
    2.3
    php 
    printf("%.1f\n"$b);
    2.2
    php 
    printf("%.10f\n"round($b1));
    2.3000000000
    php 
    printf("%.10f\n"round($b1PHP_ROUND_HALF_EVEN));
    2.2000000000
    Ich würde eigentlich auch alles, was mit Geld zu tun hat, so gestalten, dass es Beträge in ganzen Cents speichert und so das ganze Getüddel mit den Fließkommawerten umgeht. Bei den osCommerce-/xt:Commerce-Ablegern wie dem Gambio-Shopsystem werden leider Fließkommawerte verwendet, das werden wir ohne riesigen Aufwand auch nicht mehr los.
     
  4. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Diese Datei hochladen in

    /system/classes/orders/

    und die alte überschreiben, und dann soll es vorbei sein mit abweichenden Beträgen in JTL Wawi und Gambio. Das hat Timo Panitz von Itratos geschrieben. Keine Gewähr/Haftung. (Noch) nicht updatesicher...

    VG
     

    Anhänge:

  5. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Poah, hoffentlich macht dir das nichts kaputt.
     
  6. Christian Mueller

    Christian Mueller Beta-Held

    Registriert seit:
    4. Juli 2011
    Beiträge:
    3.675
    Danke erhalten:
    878
    Danke vergeben:
    288
    Kann mir jemand erklären, wo das greift?
    Erst beim Export oder schon im Checkout?
     
  7. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Das sind die allgemeinen, ziemlich durchgängig verwendeten, Steuerklassen. Daran fummeln ist oberheikel.
     
  8. Christian Mueller

    Christian Mueller Beta-Held

    Registriert seit:
    4. Juli 2011
    Beiträge:
    3.675
    Danke erhalten:
    878
    Danke vergeben:
    288
    Ich probiere das mal ein paar Tage aus
     
  9. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Behalte Bestellabbrüche im Auge. Es kann unter anderem sein, dass der Shop dann anders rechnet als zum Beispiel PayPal und andere Zahlungsanbieter, und du Zahlungsabbrüche bekommst.
     
  10. Christian Mueller

    Christian Mueller Beta-Held

    Registriert seit:
    4. Juli 2011
    Beiträge:
    3.675
    Danke erhalten:
    878
    Danke vergeben:
    288
    Bringt zumindest in Verbindung mit Amicron keine Verbesserung.
    Die Rundungsdifferenzen sind nach wie vor vorhanden.
     
  11. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Das Thema ist riesig, wir haben da auch schon unzählige Stunden mit dem suchen von halben Cents verbraten. Wir binden auch Systeme an, die da nicht homogen sind. Die eine und wahre Siegerlösung gibt es meines erachtens nach nicht.
     
  12. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Christian, ich stecke da auch nicht drin. Hinweise aber noch von Timo:

    Code:
    Behandelt Rundungsfehler in der ot_total.
    Wichtig ist das man die Versandarten/Zahlungsarten bzw. die Gebühren richtig konfiguriert, Du hast z.B. bei Nachnahme 7,56 eingetragen, so kommt gambio auf 8,9964 Euro und nicht auf 9 Euro. Richtig sind hier 7,563 Euro. Das erkennst Du bei allen Bestellungen die mit Nachnahme bestellt wurden oder in meinen ersten Testbestellungen.
    Je weniger Nachkommastellen genutzt werden, desto ungenauer wird der Bruttobetrag. Bei gambio gab es ausschließlich am Ende ein Problem in der Berechnung alle anderen Werte passten, also z.B. die Artikelpreise in der Bestellung - nur bei der letzten Berechnung gab es dann das Problem.
    
    Wenn du möchtest, kannst du dich gerne unverbindlich bei ihm melden, dann würde er sich per Teamviewer mal ansehen, ob das ein ähnliches Problem wie mit JTL ist. info@itratos.de