In Bearbeitung Rundungsdifferenzen

Markus Hütz

Moderator
Mitarbeiter
4. März 2014
402
189
Mittelfristig wenn man sieht das Mittelfristige Tickets schon seit 2013 betehen erwarte ich nicht viel.

Habe das Projekt mit der Kundin neu gestartet mit Shopware und Vario7 da Rechnungen mit Rundungsfehlern ihr bei Rewe, Edeka usw nicht akzeptabel sind.
Hey,

ich kann deine Enttäuschung nachvollziehen. Das ist leider kein einfaches Thema. Vor allem wenn man die einzelnen Ausgabestellen und -möglichkeiten betrachtet.

Ich kann hier leider nur sagen, dass wir das Thema intern gerade aufarbeiten.

Gruß,
Markus
 

ergowebshop

Gut bekanntes Mitglied
14. Januar 2022
117
24
Ich berichte mal von der kürzlich aus der Beta zur offiziellen Version gewordenen Wawi 1.6.38.2.

Artikel sind mit Brutto Preisen eingepflegt worden, ein kürzliches Angebot (bei Auftrag ist es genauso) zeigt in Positionen den errechneten Netto gerundet auf 2 Nachkommastellen, also 264,71:


1655108303409.png


Aber das Angebot geöffnet hat den aus 315 brutto errechneten Netto 264,7059, wäre ja intern auch okay:


1655108373438.png


Aber der Gesamt Netto den wir hier sehen der wird dann aus dem Gesamt Brutto errechnet. Daraus wird in der Dokumentvorlage halt ebenfalls:


1655108456517.png


Jetzt guckt der Kunde blöd drauf, greift kurz zum Taschenrechner, ruft an und meint "hey 14 * 264,71 ist doch 3.705,94 und nicht 3.705,88".

Man kann also bei größeren Aufträgen auch locker mal 0,06€ Unterschied haben. Und da haben wir noch nicht mal Rabattierung drin.

---

Nachtrag.
Wir haben uns jetzt beholfen zumindest die Ausgabe im Dokument anders darzustellen. Statt:

SalesQuotationPosition.TotalNetPrice

Dann selber Anzahl multipliziert mit dem gerundeten Netto Einzelpreis:

SalesQuotationPosition.Quantity * Round(SalesQuotationPosition.NetPricePerUnit,2)

In der Positionstabelle ergibt sich somit beim Gesamtpreis der Position:

LocCurrL$ (SalesQuotationPosition.Quantity*Round(SalesQuotationPosition.NetPricePerUnit,2), JTL_GetCulture(Report.CountryISO, Report.LanguageISO, Report.CurrencyISO))

(soweit für Angebot, bei Auftrag entsprechend mit SalesOrderPosition u.s.w.)

Dann ist da aber wieder der Gesamt Block der nicht mit spielt:

1655113032377.png

Und am Ende weicht es wohl eh wieder zu dem ab was in der Bestellbestätigungs-Mail steht, die ja vom z.B. JTL Shop versendet wird.

----------------------

Hey. Wir sind noch dran. Sind leider einige Prozesse die überprüft werden müssen. Leider bekommen wir die Preise je nach Plattform mal gerundet, mal ungerundet, mal nur den Netto, mal nur den Brutto. Das macht es für die Weiterverarbeitung nicht unbedingt einfacher.

In unserem 14 Jahre alten Strato ePages Shop gab es dazu eine kleine Einstellung und gut war es, für die meisten Bedürfnisse abgedeckt. Wäre das nicht was?


1655109728665.png
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: pannscheck und kutti

CheckerChris

Gut bekanntes Mitglied
17. Januar 2017
119
15
@Manuel Pietzsch

Hallo Manuel,
wir nuten die WaWi 1.6 schon lange als Betatester, doch ich kann nicht bestätigen, dass das Problem gelöst sei.
Ärgere mich heute schon wieder, dass viele Gutschriften von Amazon mit einem Rundungsfehler in der WaWi landen.
Da ist echt noch Luft nach oben.
Der Fehler kommt tatsächlich wieder zustande, weil das Brutto aus Netto + MwSt errechnet wurde.

Ist der Fehler nur bei mir?

LG
Chris Welter
 
  • Gefällt mir
Reaktionen: SHAAN und csaeum

SHAAN

Sehr aktives Mitglied
26. August 2020
598
165
@CheckerChris

Das kann ich nur bestätigen. Da läuft irgendetwas nicht rund. Das Problem zieht sich schon lange oder wird durch die stetige Programmierung immer wieder neu verursacht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: csaeum

golvreven

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

an dem Ticket gab es kürzlich eine Aktualisierung. Was hatte sie zu bedeuten? Kann man das irgendwo sehen? Ich bin dort nicht angemeldet.

Viele Grüße
g.
 

wawi-dl

Sehr aktives Mitglied
29. April 2008
5.959
574
wir hatten dazu mit JTL gesprochen, es ist nicht so einfach umzusetzen, diese Änderung muss komplett über alle Bereiche hinweg vollzogen werden

zudem kommen noch andere Themen wie Anzahl Nachkommestellen grundsätzlich dazu, dann müssen Tabellen in DBs angepasst werden, und und und ...
 

deliman

Sehr aktives Mitglied
13. Februar 2016
961
116
Und das ist der Grund, warum man das seit Jahren nicht angeht und uns Nutzer bzw. Kunden die Diskussionen mit den Kunden überlässt? Erst letzte Woche hatte ich da eine halböffentliche Stelle, die sich partout geweigert hat, die Systemrechnung mit der Rundungsdifferenz zu akzeptieren. Das es andere können, zeigt mir, das es prinzipiell kein Hexenwerk ist auch wenn man über saubere Programmierung sicher streiten kann. Aber das kann man ja dann für Laien auch immer gut heranziehen, da die ja keine Ahnung davon haben. Stimmt, ich persönlich bin da raus was Programmieren betrifft aber es gibt Leute die sich damit auskennen und die kennen möglicherweise auch die JTL Anwender und haben sich z.B. die Programmierung der Datenbanken mal angeschaut...

Grundsätzlich sollte/muss ein Warenbwirtschaftsystem, mit dem auch Rechnungen erzeugt werden, buchhalterisch richtig runden und wenn das seit Jahren nicht hinhaut zeigt das ja nur, das am Anfang Murks gemacht wurde (warum auch immer) und man nun schon soviel drumrum programmiert hat, das man es jetzt nur noch schwer auflösen oder ändern kann ohne das einem das ganze Konstrukt auf die Füsse fällt.

Wenn ich mich richtig erinnere, hieß es mal, dass das mit Rechnung 2.0 geändert wird aber wann kommt Rechnung 2.0??? JTL wollte da ja offener und besser kommunizieren (in Zukunft)...
 

recent.digital

Offizieller Servicepartner
SPBanner
8. Juli 2015
1.524
459
Wuppertal
Grundsätzlich sollte/muss ein Warenbwirtschaftsystem, mit dem auch Rechnungen erzeugt werden, buchhalterisch richtig runden und wenn das seit Jahren nicht hinhaut zeigt das ja nur, das am Anfang Murks gemacht wurde (warum auch immer) und man nun schon soviel drumrum programmiert hat, das man es jetzt nur noch schwer auflösen oder ändern kann ohne das einem das ganze Konstrukt auf die Füsse fällt.

Ja, so ziemlich nah an Tag 1 muss es gewesen sein wahrscheinlich. Der Fehler sitzt dermaßen tief, dass man zuerst alles andere umbauen muss. Wir hatten die Thematik mal sehr ausführlich und herzlich diskutiert mit den Kollegen von JTL.

Wenn es einfach wäre -> es würde umgehend gelöst.