Rundungsprobleme beim Beleg-Export

Allgemeines zur Rundung

In fast allen Systemen (JTL, Magento, Gambio, …) werden die Preise in den Belegpositionen als „float“ Variablen abgelegt. Dies führt zwangsweise zu Problemen bei der Berechnung der Summe eines Belegs.

Hier 2 Links zu diesem Thema:
Wikipedia Gleitkommazahlen
Wikipedia Maschinengenauigkeit

Viel Theorie, aber was bedeutet dies in der Praxis:

Ein Beispiel: Folgender Preis soll in der Datenbank abgelegt werden 4,455 Euro.
Je nach Genauigkeit der der „float“-Variable wird daraus in der Datenbank:

  • Fall 1: 4,455000000
  • Fall 2: 4,454999998
  • Fall 3: 4,455000001

Ich habe das Beispiel so gewählt, weil es je nach Rundungsmethode zu Problemen führen kann.

Man muss jetzt auch noch zwischen der Mathematischen Rundung und der Kaufmännischen Rundung unterscheiden.
Die Mathematische Rundung sollte eigentlich in keinem System angewandt werden.

Wikipedia Rundung

Wenn das System nun mit allen Nachkommastellen arbeitet, werden aus unseren ursprünglich 4,455 Euro in der Datenbank abgelegten Zahl folgendes:

Mathematische Rundung

  • Fall 1: 4,45
  • Fall 2: 4,45
  • Fall 3: 4,46

Kaufmännische Rundung

  • Fall 1: 4,46
  • Fall 2: 4,45
  • Fall 3: 4,46

Man sieht, die Berechnung mit allen Nachkommstellen birgt definitiv ein Problem.

Wie geht unsere Fibu-Schnittstelle vor:

In der Schnittstelle ist z.B. eine Genauigkeit von 6 Nachkommastellen eingestellt.

Schritt 1: Multiplikation mit 10^6

  • Fall 1: 4455000,000
  • Fall 2: 4454999,998
  • Fall 3: 4455000,001

Schritt 2: Kaufmännisches Runden und Umwandlung in eine „integer“-Variable (ohne Nachkommastellen)

  • Fall 1: 4455000
  • Fall 2: 4455000
  • Fall 3: 4455000

Schritt 3: Übergabe in die Fibu mit 2 Nachkommastellen durch Kaufmännisches Runden der „integer“-Variable.

  • Fall 1: 4,46
  • Fall 2: 4,46
  • Fall 3: 4,46

Wie man sieht, wird aus allen möglichen Eintragungen in der Datenbank das korrekte Ergebnis berechnet.

Problem: Meist wird die Berechnung in den unterschiedlichen Systemen nicht in dieser Form durchgeführt.
Dies kann dann zu Abweichungen führen.

Gesamtbelegsumme zu Einzelpositionen

Brutto Berechung (ein B2C Kunde)

Unter einem Beleg steht immer eine Gesamtsumme. Doch schon dies birgt Probleme.

Konstruieren wir ein einfaches Beispiel

Artikel6 Nachkommastellen2 Nachkommastellen
Artikel 1 12,002000 Euro12,00 Euro
Artikel 2 13,004000 Euro13,00 Euro
Zwischensumme25,006000 Euro25,00 Euro
Summe gerundet25,01 Euro25,00 Euro

Gerundet 25,01 Euro

Die Finanzbuchhaltung möchte nun aber diese beiden Belegpositionen auf unterschiedlichen Sachkonten oder Kostenstellen verbuchen.
Bei der Verbuchung auf Einzelpositionen ergibt sich eine Belegsumme von nur 25,00 Euro.

Da der Beleg meist auch nur mit 2 Nachkommastellen zu Papier gebracht wird, sähe dies bei der Variante mit 6 Nachkommastellen so aus:

Artikel6 Nachkommastellen (2 auf dem Papier)
Artikel 1 12,00 Euro
Artikel 2 13,00 Euro
Summe25,01 Euro

(Diese Belege kommen nicht sehr häufig vor, aber es gibt sie. Es sind schon einige durch meine Hände gelaufen.)

Netto Berechnung (ein B2B Kunde)

Bei dem Bruttopreisen haben wir in der Regel nur 2 Nachkommastellen. Werden aus den Bruttopreisen Nettopreise erzeugt, entstehen in der Regel Zahen, mit vielen Nachkommastellen. Hier ist die Wahrscheinlichkeit, dass es zu einem Problem kommt höher.

Résumé

Ziele:

  • Egal, ob ein Beleg mit einer Buchung oder mit fünf Buchungen in der Finanzbuchhaltung abgebildet wird, die Summe aller Buchungen muss mit der Summe, die auf dem Beleg ausgegeben wird, identisch sein.
  • Egal, ob in der Datenbank 4,455000000001 oder 4,45499999999997 steht, die Berechnung muss 4,46 ergeben.

Sinnvoll wäre, wenn alle Systeme die Summe der Belegpositionen mit einer Kaufmännischer Rundung auf 2 Nachkommastellen ermitteln würden.
Zusätzlich müsste die Berechnung, um ganz sicher zu gehen, mit „integer“-Variablen durchgeführt werden. (siehe oben)
Dies ist aber in der Regel nicht der Fall, deshalb kann man in unseren Schnittstelle die Nachkommastellen konfigurieren.
Leider ist aber trotzdem nicht möglich, eine 100,000000001 % Lösung hiermit zu erzielen.
(Ups, die 100 % wurden wohl in einer Datenbank abgelegt.)

Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information