In Bearbeitung Rundungsdifferenzen

wawi-dl

Sehr aktives Mitglied
29. April 2008
5.948
569
Wir haben diese Probleme alle 2 Tage, siehe Bild!

Kunde bestellt zB teilbaren Artikel, oder etwas mit Rabatt, es entstehen ungerade Beträge.
Im Auftrag wird "abgerundet", warum auch immer.

In der Auftragsübersicht wird "aufgerundet", der Kunde bezahlt aber den "abgerundeten" Betrag zB per PayPal im JTL- Shop.

2020-11-12 12_37_09-Window.png
 
  • Gefällt mir
Reaktionen: Julimed

Wissenssammler

Sehr aktives Mitglied
27. März 2016
442
77
Kottenheim
Wir machen es mitlerweile wie folgt: Beispiel bei fiktiven 1000€ Rechnungsbetrag mit 8 Cent Rundungsdifferenz.

Ich trage die Bankzahlung ein 999,92€
Dann Trage ich 0,08€ als Rundungsdifferenz ein (Habe extra dafür eine Zahlungsart eingerichtet um die Rechnungen aus zu gleichen.)
und verbuchen tue ich es nach Rücksprache mit dem Steuerberater als gewährtes Skonto.
 

b-tool.ch

Aktives Mitglied
14. Juni 2018
75
13
Beim Einrichten des Zahlungsabgleichs per csv-Import ist das Rundungsproblem auch bei uns akut geworden.
Eine Option "Beim Zahlungsabgleich Differenzen bis ... ignorieren" (oder auf ein eigenes Konto buchen, falls dies für die Buchhaltung notwendig ist) würde uns reichen. Der Löwenanteil der (immer auf 5 Rappen gerundeten) Zahlungseingänge würde dann automatisch mit den (ungeraden) Bruttobeträgen der Aufträge abgeglichen. Das würde uns viel Arbeit ersparen.
Mit Grüßen aus der Schweiz, Daniel
 

golvreven

Gut bekanntes Mitglied
1. Oktober 2020
218
18
Hallo zusammen,

ich möchte im Zusammenhang mit Rundungen noch einen anderen Aspekt hervorheben: Es gibt häufig 1-Cent-Abweichungen zwischen der Darstellung des Preises im Frontend und der Darstellung des Preises im Produktfeed für Exporte an Plattformen und Google Shopping. Im Google Merchant Center werden Artikel abgelehnt, sobald es zu solchen Preisabweichungen kommt. Jedes Mal muss ich deshalb bei abgelehnten Artikeln an den Nachkommastellen herumschrauben, damit im Feed derselbe Preis gerundet wird wie im Frontend. Wozu braucht man vier Nachkommastellen bei Preisangaben? Ich sehe den Sinn darin nicht, weil mir niemand 0,0001 c bezahlen kann.

Viele Grüße
g.
 

golvreven

Gut bekanntes Mitglied
1. Oktober 2020
218
18
Hallo en001,

danke für den Hinweis. Dazu müssten die Markups sauber sein. Und zweitens treten im Markup "price" dieselben Rundungsprobleme auf wie bei der Berechnung des Gesamtpreises für den Feed! Insofern habe ich an drei Stellen zu kämpfen: im Frontend (1.), im Feed (2.) und im Markup (3.). Sobald der Gesamtpreis durch eine Formel ausgegeben wird, kann es zu dem Rundungsproblem kommen:

1. angezeigter Gesamtpreis im Shop (für Nutzer):
Std. VK-Brutto * Mindestabnahme = Gesamtpreis -> angezeigter Gesamtpreis wird gerundet
19,9 € * 19,45 m² = 387,055 € -> angezeigter Gesamtpreis: 387,06 €

2. Gesamtpreis im Feed (für Google Shopping):
Std. VK-Netto * Mindestabnahme * Mehrwertsteuer = Gesamtpreis
16,7227 * 19,45 * 1,19 = 387,0553 -> Gesamtpreis im Feed nach Rundung: 387,05 €

3. Gesamtpreis im Markup (für Google):
Std. VK-Brutto * Mindestabnahme = Gesamtpreis -> angezeigter Gesamtpreis wird gerundet
19,9 € * 19,45 m² = 387,0550 € -> angezeigter Gesamtpreis nach Rundung: 387,05 €

Würde bei der Berechnung von 2. und 3. mit 5 als Nachkommastelle korrekt aufgerundet, wäre das alles kein Problem. Tatsächlich wird aber nicht aufgerundet. Was ist das anderes als ein Bug?

Ich kann die Abweichnung von 0,01 c im Feed nur dadurch umgehen, indem ich den Std. VK-Brutto manuell höher setze oder niedriger setze, sodass die Rundung aufgeht. Leider kann ich auf diese Weise nicht in die Berechnung des Gesamtpreises im Markup "price" eingreifen. Ich müsste die Formel kennen, mit der der angezeigte Gesamtpreis berechnet und gerundet wird. Dann würde ich diese für das Markup "price" nachbauen. Aktuell nutze ich:

($Artikel->fMindestbestellmenge*$Artikel->Preise->fVKBrutto)|string_format:"%.2f"

Dies führt aber zu den genannten Abweichungen vom angezeigten Gesamtpreis bei Nachkommastellen mit 5.

Außerdem kann ich nicht beeinflussen, welchen Wert Google Merchant Center abgreift: Einmal wird dort behauptet, der Preis auf der Website sei 387,06. Dann bezieht sich die Angabe auf den angezeigten Gesamtpreis. Am nächsten Tag kommt Google Merchant Center auf die Idee, zu behaupten, dass der Preis auf der Website 387,05 sei. Und dann ist das Markup ausschlaggebend. Ein absurdes Theater.

Viele Grüße
g.
 
Zuletzt bearbeitet:

Manuel Pietzsch

JTL-Wawi
Mitarbeiter
2. Januar 2012
2.851
1.017
Hückelhoven
  • Gefällt mir
Reaktionen: recent.digital

csaeum

Sehr aktives Mitglied
23. Juli 2011
1.295
141
Küps
Hi,

am besten ein Ticket im Support aufmachen und einen Screenshot vom Auftrag, bzw. der Rechnung aus der JTL-Wawi mitgeben.
Häufig ist es ne Frage der Layouteinstellung, Verwendung der Nachkommastellen.

Gruß

Manuel
Das ist alles Standard von euch.

Ich habe mal geschaut es wird die Variable "Report.TotalGrossPrice" genommen und die liefert den Wert schon von 167,80€ aber das passt ja nicht weil es dort ja schon falls drin steht.

Hier ein Screen vom Auftrag auch dort ist es falsch:

1643222150284.png
 
  • Gefällt mir
Reaktionen: kutti und golvreven

csaeum

Sehr aktives Mitglied
23. Juli 2011
1.295
141
Küps