Magento und PayPal Rundungsfehler Analyse und “Lösung”

Viele Magento Betreiber dürften das Problem kennen, wenn Kunden eine Zahlung mit Paypal tätigen kommt es manchmal zu Rundungsfehlern. Dieser Fehler sorgt dafür das ein Cent zu wenig von Paypal berechnet wird, was den Kunden evtl. noch freut (ich würde mich als Kunde darüber eher wundern) ist für den Shopbetreiber meist ein echtes Problem.

Diesem Problem bin ich auf den Grund gegangen und werde meine Erfahrungen hier schildern. Alle Angaben beziehen sich auf Magento 1.6.1, wobei Magento angepasst wurde um mit vier Nachkommastellen zu arbeiten.

Eine Lösung…

Nachdem diese Thematik in der Zwischenzeit sogar den Einen oder Anderen “Verzeifelten” auf meinen Blog gespült hat möchte ich gleich zu Anfang eine Lösung anbieten.

1. Rundung in Magento

Dazu gibt es von mir ein Plugin, dass die Anzahl der Stellen nach dem Komma bei Rundungungen überschreibt. Durch den Einsatz einer Extension bleibt der Shop upgradefähig
Weiter sollten keine Anpassungen nötig sein….

Extension AB_FixRounding herunterladen

In der Datei app/code/local/AB/FixRounding/Model/Store.php in Zeile 5 kann die Anzahl der Nachkommstellen beim Runden eingestellt werden, momentan 3.

Die Extension muss heruntergeladen und anschließend in das Verzeichnis der Magento Installation entpackt werden. Ein Backup kann vorher nicht schaden.

2. Cronjob

Die Datei in dem Zip-File herunterladen, entpacken und auf den Server parallel zur Magentoinstallation kopieren und dann regelmässig als Cron-Job ausführen, z.B. so:

Alle fünf Minuten: */5 * * * *

Das Problem – wozu das Ganze ?

Kurz gesagt: Paypal akzeptiert nicht genug Nachkommastellen über die API, was zu einem Rundungsfehler, damit zu einem Cent Verlust und schließlich zu “hängenden” Bestellungen führt.

Wer es jetzt genauer wissen möchte kann weiter lesen…

Ein Beispiel

  1. Ein Produkt für 71,94 € + 4,80 € Versandkosten wird im Shop gekauft. Der Bruttogesamtwert beträgt somit 76,74 €. Das entspricht einem Nettobetrag von 64,4874
  2. Magento überträgt die auf zwei Stellen gerundeten Nettowerte von 60.45 € und die Versandkosten von 4,03 € an Paypal.
  3. Paypal errechnet einen Bruttowert von 60,45 + 4,03 € = 64,48 * 1,19 = 76,7312. Das ergibt einen Brutto-Gesamtbetrag von 76,73 €
  4. Paypal liefert den falschen, wenn auch richtig berechneten Betrag zurück
  5. Magento erkennt einen Cent Differenz und setzt den Status nicht auf “processing” sondern auf “suspected fraud”
  6. Wir haben einen Cent verloren und eine bezahlte Bestellung in einem “falschen” Zustand

Wo liegt das Problem ?

Die Ursache ist einfach. Die von Magento angesprochene Paypal-Schnittstelle erwartet Nettowerte und akzeptiert dabei nur zwei Nachkommastellen. Mit den übertragenen Nettowert(en) errechnet Paypal den Bruttogesamtwert. Dabei kann es zu Rundungsfehlern kommen weil zwei Nachommastellen einfach nicht ausreichend sind.

Hier ein Auszug aus dem Protokoll:

Es wurden zwei Produkte gekauft: 12.58 + 47.87 = 60,45 €
zusätzlich werden 4,03 € Versand berechnet. Das Problem bleibt das gleiche.

Der Nettowarenwert von 64,49 € wird von Magento geliefert aber von Paypal offensichtlich nicht interpretiert. Die interpretierten Daten sind leider nicht genau genug. Versucht man mehr Nachkommastellen zu übertragen werden die Werte von Paypal nicht akzeptiert und die Schnittstelle liefert einen Fehler.

Aus Sicht von Paypal ist alles in Ordnung und entsprechend sieht auch die Antwort aus:

Der verlorene Cent und der dabei entstandene Kundeneindruck ist schon ärgerlich genug. Noch problematischer ist allerdings das der von Paypal zurückgelieferte Betrag nicht dem von Magento erwarteteten Betrag entspricht. Das führt dazu das Magento die Zahlung als Betrugsversuch “Suspected Fraud” erkennt und den Status der Bestellung entsprechend setzt.

Damit “hängt” die Order erstmal im System und kann z.B. von externen Systemen nicht automatisiert verarbeitet werden. Das bedeutet der Status muss erst “per Hand” angepasst werden was Zeit und Nerven kostet, ganz abgesehen von dem verlorenen Cent, sich “wundernden” Kunden und evtl. Fragen vom Steuerberater…

Lösungsansätze

  • Paypal habe ich das Problem geschildert. Dort hat man die Ursache auf Magento geschoben und das Problem offensichtlich nicht verstanden oder verstehen wollen. :(
  • Den Fraud-Check einfach auszustellen stellte sich als aufwändiger als erwartet heraus da die Funktionalität leider sehr verstreut ist.
  • Man kann den Status in der Datenbank ändern, das ist aber per Hand recht mühsam und auch keine dauerhafte Lösung.
  • Meine momentane Lösung setzt per Cron alle mit Paypal bezahlten Bestellungen die auf “suspected fraud” stehen und sich nur um einen Cent unterscheiden auf status und state “processing”.

 Cronjob zur Zustandskorrektur bei Bestellungen mit Rundungsfehlern

 

 

 

Nachtrag:

Wenn Magento den Zustand auf “processing” setzt wird (in meinem Shop) auch die Rechnung erzeugt. Dieser Teil fehlt in dem Skript. Wenn jemand diesen Aufruf “parat” hat, bitte posten dann passe ich das im Skript noch an wenn es funktioniert.

Dieser Beitrag wurde unter Magento abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

30 Antworten auf Magento und PayPal Rundungsfehler Analyse und “Lösung”

  1. Johannes Tümmers sagt:

    Hallo Herr Krüger,

    …sehr fundierter und informativer Beitrag – herzlichen Dank!! Zwei Nachfragen:

    a) Ich vermute, der o.a. Cronjob erledigt genau das, was auch eine entsprechende manuelle Änderung in der Administration (Backend) von Magento bewirkt, wenn ?

    b) An welche Adresse von PayPal haben Sie Ihre Schilderung gesendet? Es könnte ja auch von anderen Betroffenen an die gleiche Stelle eine entsprechende Nachfrage gestellt werden, damit sich evtl. dort doch einmal etwas bewegt!

    MfG,
    JT

    • fabian sagt:

      Hallo Johannes,

      Danke für den Lob.
      zu a) Der Cronjob setzt alle Bestellungen die sich um bis zu 1,4 Cent unterscheiden und deshalb auf “Fraud” stehen auf “processing”. Der Cron hat bestimmt noch Verbesserungspotential.
      zu b) ppmts@paypal.com (Paypal Merchant Technical Support)

      Hier die Antwort nach der ca. 8. Antwort – nach der ich aufgegeben habe – es wurde offensitchtlich nicht verstanden… :

      Sehr geehrter Herr Krüger,
      Vielen Dank für ihre Antwort.

      Nochmals, wir übernehmen die Beträge so wie sie von Magento an uns übergeben werden. Auf unserer Seite werden die Beträge dann einfach nur zusammenaddiert. Bei uns gibt es auch keine Brutto oder Nettobeträge, was immer ihr Shop an uns sendet werden wir auch darstellen bzw. abrechnen. Wie ich Ihnen ja bereits gezeigt hatte sendet Ihr Shop folgende Beträge an uns:

      Diese Werte zusammengerechnet unterscheiden sich um genau 1 cent von dem was ihr Shop anzeigt. Das heißt das Magento hier einen falschen Wert an uns schickt und wir deshalb auch einen Cent unterschied abrechnen. So gerne ich Ihnen hier noch weiterhelfen würde aber leider können wir von unserer Seite hier nichts machen da wie erwähnt die Beträge so von Magento an uns gesendet werden. Sie müssten sich hier wirklich mit Magento direkt auseinandersetzen. Ich bin mir ziemlich sicher das Megento bereits ein update hat da dieses Problem sicher nicht nur bei Ihnen auftritt.

      Ich habe das Internet mal durchsucht und noch weitere Posts mit diesem Problem gefunden:

      [Ich habe auch viele Beiträge gefunden, aber keiner konnte (mir) helfen, wie auch...]

      Wie sie dort sehen können handelöt es sich hier wirklich um ein Problem in MAgento selbst. Daher würde ich raten Magento direkt zu kontaktieren.

      Ich hoffe dies hilft Ihnen weiter und wenn sie weitere Fragen haben so lassen sie es mich bitte wissen.

      mit freundlichen Grüßen

      XXXX
      PayPal MTS

      • Johannes Tümmers sagt:

        Hi Fabian!

        Herzlichen Dank für die erneut ausführliche Antwort! Ich werde diesen Cron auch einmal ausprobieren; offenbar wird dieser Streit zwischen Huhn und Ei noch auf unbestimmte Zeit weitergehen und darauf zu warten können wir uns gegenüber den Kunden nicht wirklich erlauben.

        Verstehe ich es richtig, daß im o.a. Cron-Code mit der Angabe von $isCustomerNotified=false; die Benachrichtigung des Kunden NICHT gesetzt wird?

        Das wäre ja auch wünschenswert so, damit die Kunden nicht unnötig verunsichert werden.

        Hinsichtlich der ‘Umstellung’ von Magento auf die Rundung mit 4 stat 2 Nachkommastellen habe ich inzwischen folgende Dateien angefaßt:

        app/code/core/Mage/Core/Model/store.php

        app/code/core/Mage/Paypal/Model/Cart.php

        app/code/core/Mage/Paypal/Model/Payflowpro.php

        app/design/adminhtml/default/default/template/catalog/product/edit/price/tier.phtml

        app/code/core/Mage/Adminhtml/Block/Catalog/Product/Helper/Form/Price.php

        app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit/Tab/Options/Option.php

        Habe ich da noch was übersehen? :-)

        • fabian sagt:

          Hallo Johannes,
          ich hoffe du hast das Problem schon beheben können ?
          Ansonsten versuch es mit der Extension, die hindert Magento daran nach zwei Kommastellen sbzuschneiden. In den Templates passt das, soweit ich mich erinnere ;)

  2. Marcus sagt:

    Danke für diesen Artikel. Ich habe allerdings das Problem, daß Paypal Nettopreise anzeigt, ich aber gerne Bruttopreise dort hätte. Kann man das irgendwo einstellen?

    Grüße,
    Marcus

  3. Weiser sagt:

    Hallo und vielen Dank für diesen Lösungsansatz. In welche Datei muss der o.a. Code gesetzt werden???

    Vielen Dank im voraus :-)

    • fabian sagt:

      Hi Weiser,
      der Code muss etwas angepasst werden, so dass in $magentoDir der Pfad ui Magento steht. Dann st egal wo du die datei ablegst.
      cheers

  4. Arnaud sagt:

    Hallo,

    ich würde gerne den PHP Script benutzen, weiß aber leider nicht wie… Kann das Script auch durch den Linux Cron dienst ausgeführt werden oder muss Magento benutzt werden? Habe leider keinerlei PHP-Kenntnisse, würde mich aber freuen wenn mit jemand weiterhelfen könnte

    Danke und Grüße,
    Arnaud

  5. ska sagt:

    vielen Dank, der Cronjob ist sehr hilfreich

  6. Robert sagt:

    Vielen Dank für Dein Script. Es funktioniert mit 1.7.0.2 gut außer zwei Sachen:
    1) Die Bestätigungsmail enthält template path hints. Bei normalen Bestellungen z.B. auf Kreditkarte ist die Bestätigungsmail sauber.
    2) Die Rechnung wird zwar automatisch erstellt aber nicht dem Kunden gesendet. Manuell klappt es aber.
    Hast Du einen Tipp?

    • fabian sagt:

      Hi,
      1) die “path hints” dürften an nicht aufgelösten Einträgen in deinem Order-Coment Mail-Template liegen ?
      2) Du meinst “$order->sendNewOrderEmail();” wird nicht ausgeführt ? Dann habe ich keine Idee, check mal die logs. Oder wird sonst 8durch eine andere Extension) die Rechnung als PDF angehängt ?

      Tut mir leid das ich da kaum helfen kann..

  7. dakira sagt:

    Hi, danke für den cronjob. Das mit den Rechnungen sollte klappen, wenn du
    $invoice->pay();
    nutzt statt
    $invoice->capture()->save();

  8. dakira sagt:

    Also bei mir läuft der cronjob so nicht. Der php cli braucht ein höheres memory_limit und ich bekomme exceptions, dass ich nicht die rechte habe auf die Daten zuzugreifen.

    Ich habe das ganze mal so modifiziert, dass ein SOAP-API user benutzt wird, der die entspr. Rechte hat. Damit geht es bei mir. Die Rechnungen wie gesagt gehen bei mir nun auch. Ich hab das mal hier in ein Gist gepackt:
    https://gist.github.com/6308663

  9. Daniel Meyer sagt:

    Wir haben das Skript auch eingesetzt, nur funktioniert es meiner Meinung nicht bei mehreren Stores/Storeviews:

    Fatal error: Uncaught exception ‘Mage_Core_Model_Store_Exception’ in /html/magento/app/code/core/Mage/Core/Model/App.php:1357
    Stack trace:
    #0 /html/magento/app/code/core/Mage/Core/Model/App.php(842): Mage_Core_Model_App->throwStoreException()
    #1 /html/magento/app/code/core/Mage/Core/Model/App.php(491): Mage_Core_Model_App->getStore()
    #2 /html/magento/app/code/core/Mage/Core/Model/App.php(274): Mage_Core_Model_App->_initCurrentStore(‘default’, ‘store’)
    #3 /html/magento/app/Mage.php(615): Mage_Core_Model_App->init(‘default’, ‘store’, Array)
    #4 /html/magento/paypal-fraud.php(5): Mage::app(‘default’)
    #5 {main}
    thrown in /html/magento/app/code/core/Mage/Core/Model/App.php on line 1357

    Das habe ich nun bei zwei Magento-Installationen beobachtet. Hat jemand eine Idee?

    Viele Grüße
    Daniel

  10. Thomas sagt:

    Schön das die Lösung funktioniert, allerdings kann ich den Kommentaren nicht so recht folgen.

    Die E-Mail sagt doch alles aus, worum es scheinbar geht. PayPal übernimmt die Beträge wie Magento liefert.

    Das Problem ist bei dem Workaround, ja denn es ist keineswegs eine Lösung, das es nicht die Ursache behebt. Denn so gehen einem Shop jedesmal 1,4 Cent flöten (überspitzt formuliert) was bei ~10.000 Bestellungen in Summe 140€ Verlust bedeuten.

    Es sollte daher nur als temporärer Hotfix genutzt werden. Das Problem liegt in der Berechnung des Zahlenwertes, der an PayPal übergeben wird.

    Bei der Berechnung der zu übergebenen Summe sollte demnach angepasst, bzw überarbeitet werden. Der Grund hierfür ist die oftmals hochgelobte Lösung der “Rundungsfehler” durch erhöhen der Nachkommastellen auf 4 Stellen. So ist es völlig ausreichend bei der Berechnung der Übergabewerte an PayPal einen simplen Abgleich der Gesamtsummen zum base_grand_total der order zu machen. Etwaige Differenzen kann man dann gleichmäßig auf die enthaltenen Positionen verteilen und alles ist gut.

    Denn Grundsätzlich ist es keine Gute Idee das Dateien zum Einen php Values anpassen, zum Anderen mit require_once $magentoDir.”/app/Mage.php” arbeiten. Das System hat für eben solche Dinge einen Workflow, der auch Cronjonjobs steuern kann.

    Und all jene die es nicht hinbekommen diesen Fehler zu beheben, sollten ggf darüber nachdenken doch das Geld für einen Entwickler auszugeben.

  11. nikl sagt:

    Version 1.8 soll das endlich beheben…

  12. Andreas sagt:

    Hallo,

    Ich habe inzwischen an paar Stellen einen Kommentar hinterlassen:
    http://magento.stackexchange.com/questions/829/what-is-the-status-of-rounding-issues-in-1-7/8097#8097
    http://www.webguys.de/magento/magento-1-5-und-die-steuern-eine-losung/#comment-166677

    Es hat nicht 100%ig etwas mit dem PayPal zu tun. Ist eher allgemein.
    Was ist maßgeblich incl. oder excl. ?
    In den USA wird der Preis immer exkl. angegeben. In Cent und nicht in 10tel oder 100tel Cent!
    Die Mengen f(x) = round(a*x, b) sind nicht bijektiv! und es existiert keine Umkehrfunktion.
    Bsp bei 19% Steuern:
    incl: 19.95 => excl. 16,76 => Steueranteil 3.18 => 1 Centfehler
    excl. 16.76 => incl. !19.94!
    excl. 16.77 => incl 19.96!

    In Amerika existiert der Preis incl. 19.95 bei 19% nicht!
    Das sind 2 verschiedene Systeme.
    Wichtig ist zu wissen, WAS MAßGEBLICH ist – incl. oder exkl.
    Nehmen wir an in unserem System ist incl. maßgeblich,
    dann sollte der zu dieser Zeit erhobene Steuersatz mit gespeichert werden. Alle Rabatte, Steuern… beinhalten dann diesen “Bruch”.
    Wenn Sie runden ist das nicht einfach. Sie produzieren oft einen Fehler, den sie mit einplanen müssen und nicht unbedacht weitergeben können.
    Deshalb gibt es in diesem Fall m.E. keine allg. Lösung, wie Änderung einer Funktion oder Präzision. Grenzen bestimmen, Eingaben validieren und bestenfalls Steuersatz mitspeichern, eventuell Präzision erhöhen wären besser.
    Ich warne aber vor den einfachen Lösungen, falsch gehandhabt bewirkt es nichts. Auch wenn sie nur einen Fehler von 10⁻5 haben – vll wird die Schraube 1 Million mal gekauft. Klingt kleinlich, der Fehler ist aber letztlich nicht erkannt, wird aufgeschoben und mit der Rangehensweise auch beim nächsten Fix nicht behoben.
    Da das alles in meinen Augen kompliziert ist, würde ich einfach den amerikanischen Weg gehen und dort konsequent sein und die Eingaben validieren.
    So Preise wie 19,95 existieren dann einfach nicht! Oder die Eingabe incl. ganz verbieten.

    • fabian sagt:

      Hallo,

      “Wichtig ist zu wissen, WAS MAßGEBLICH ist – incl. oder exkl.”

      wenn ich Deinen Kommentar richtig verstehe, ist “Exkl.” maßgeblich.

      “In Amerika existiert der Preis incl. 19.95 bei 19% nicht!”

      Weshalb denn nicht ? Die MwSt. (VAT) zahlt der Amerikaner (theoretisch) auf den Nettobetrag in deinem Shop. Die Höhe ist – in den USA – vom Bundesstaat abhängig, aber wenn die 19% betragen würde… in den USA zahlt man die VAT am Ende “einfach so”, das heisst der Bruttobetrag ist erst auf der Rechnung zu sehen. Die Probleme sind aber die Gleichen ?!

      “Da das alles in meinen Augen kompliziert ist, würde ich einfach den amerikanischen Weg gehen und dort konsequent sein und die Eingaben validieren.
      So Preise wie 19,95 existieren dann einfach nicht! Oder die Eingabe incl. ganz verbieten.”

      Ja, das ist kompliziert. Aber das (hier beschriebene) Problem liegt hier einfach an der unterschiedlichen Berechnung der Werte aufgrund unterschiedlicher Genauigkeit, die dann zu Problemen führt. Das wäre durch eine größere Genauigkeit der übertragenen Werte zu vermeiden. Zwei Nachkommastellen langen nicht. Das ist in den USA aber auch so.
      Oder einfach alle Mehrwertesteuern abschaffen :)

  13. Sergio sagt:

    Hallo,
    ich habe folgendes Problem:
    Nachdem der Cron durchgelaufen ist, schickt wird die Email an den Kunden verschickt (funktioniert), das Problem dabei ist aber, dass dieser eine Millionenrechnung erhält. Alle aufgelisteten Beträge sind um 7 Kommastellen verschoben. Wenn man aus dem Backend aber ne mail versendet an der Kunden stimmen die Beträge wieder genauso wie im Backend. Woran kann das liegen?

    Gruß, Sergio

  14. Oliver sagt:

    Hey, wenn die Bestellungen in Magento auf “Frauf” gesetzt werden, wird das Geld dann überhaupt aufs Händlerkonto überwiesen? Ich nehme es, sonst würde die automatisierte Umstellung der Bestellung auf “Processing” nichts bringen, wenn das Geld von PayPal “on hold” wäre, oder?

    • fabian sagt:

      Hi Oliver,

      ja “das” Geld wurde überwiesen, nur leider ein Cent zu wenig (zu viel?).
      Somit “hängt” die Bestellung und du darfst dich drum kümmern, während die Kundin wartet.

  15. Pingback: Magento, Paypal und der Betrugsverdacht (Suspected Fraud) :: Fleno GmbH | ihre Agentur in Flensburg | Software, E-Commerce & Consulting

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


sechs × 6 =

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">