LS Rundungsproblem

[BMT216A]

Hallo,
ich steh jetzt grad aufm Schlauch. Wenn ich mit den Beträgen in den Feldern netto1 = 57,50 und mit 19% rechne bekomme ich einen Rundungsfehler in meinem Script. Dieses sieht wie folgt aus.

*************************************************************
' Routine zum Berechnen der Steuer  über einen Button
'
' Versionskontrolle:
*************************************************************     
   
   Dim netto1_str, netto2_str, netto3_str As String
   Dim netto1, netto2, netto3 As Double
   Dim gesnetto As Double
   Dim Endbetrag As Double
   Dim  Zins As String
   Dim Zinsbetrag As Double
   Dim uiws As New NotesUIWorkspace
   Dim uidoc As NotesUIDocument
   Dim MWSt_str As String
      
   Set uidoc = uiws.CurrentDocument   

   netto1_str = Trim (uidoc.FieldGetText ("netto1"))
   If netto1_str = "" Then
      netto1 = 0
   Elseif Not Isnumeric (netto1) Then
      netto1 = 0
   Else
      netto1 = Cdbl (netto1_str)
   End If
   
für netto2 und netto 3 siehe oben

   Print "Netto1: " & netto1 & " Ausgelesen: " & netto1_str
   Print "Netto2: " & netto2 & " Ausgelesen: " & netto2_str
   Print "Netto3: " & netto3 & " Ausgelesen: " & netto3_str
   
   gesnetto = netto1 + netto2 + netto3
   
   MWSt_str = (uidoc.FieldGetText ("MWSt"))
   
   zins = MWSt_str
   
   ' Neuer Absatz für Steuerfreie Berechnung
   If MWSt_Str = "Steuerfrei" Then
      zins = 0
   End If
   ' Ende neuer Absatz für Steuerfreie Berechnung
   
   Zinsbetrag = gesnetto * zins / 100
   
   Zinsbetrag = Round(Zinsbetrag,2)
   
   Endbetrag = gesnetto + Zinsbetrag
   
   Print "Zins in Prozent " & zins & " Zins in EUR " & Zinsbetrag
   
   Call uidoc.FieldSetText ("Zinssatz", Cstr (Zinsbetrag))
   Call uidoc.FieldSetText ("gesnetto", Cstr (gesnetto))
   Call uidoc.FieldSetText ("Endbetrag", Cstr (Endbetrag))
   
   Call uidoc.Refresh
   

Was mache ich hier falsch - bzw. zu umständlich.

Vielen Dank für Eure Hilfe

Christian

[Axel]

Das Problem ist kein LS-spezifiesches Problem, sondern das tritt in allen Sprachen auf.

Die Lösung: Addiere zu deinem Nettobetrag einfach 0,005 hinzu. Dann sollte es passen.


Axel

[koehlerbv]

Verzichten sollte man auch auf blödsinnige Typkonvertierungen, die man unkontrolliert der Software überlässt bzw. aufzwingt. Die Variable Zins als String zu deklarieren, muss schon als sträflich bezeichnet werden.

Bernhard

[BMT216A]

Hallo Axel,

die Antwort verstehe ich nicht ganz. Das Feld ist doch von meinem User zu füllen und kann daher immer verschiedene WErt beinhalten.
Bekomme ich denn dann bei anderen Beträgen nicht ein Rundungsproblem?
Ich kann zwar in meinem Code immer 0,005 hinzurechnen - aber ich weiß nicht wie das immer so ist. Bei mir müssen die Beträge genau passen, da ich Notesler in einer Bank bin.

Danke

[DerAndre]

Hier wird Dir geholfen

Rundungsproblem

[Thomas Schulte]

Was bekommst du denn konkret für ein Ergebnis raus?

[Axel]

Danke Andre für den Link. Ich war auch gerade auf dem Weg dorthin.

Die Lösung: Addiere zu deinem Nettobetrag einfach 0,005 hinzu. Dann sollte es passen.

Sorry, war nicht ganz korrekt. Wenn man was nur alle Schaltjahre einmal braucht, sollte man vorher doch mal genau nachdenken.  


Axel

[BMT216A]

Hallo an alle,
erstmal Danke für die schnelle Hilfe.
Ich werde es ähnlich der Methode mit den 0,005 dazuzählen machen. Nur zähle ich 0,000001 dazu - das findet unser Mensch aus dem Rechnungswesen für unbedenklicher wegen eventuellen Fehlern.

@kohlerbv
die Variable Zins habe ich als String deklariert, weil sonst meine Berechnung bei der Auswahl steuerfrei nicht funktioniert hat. Vorher war die Variable eine double Variable.
Wenn Du eine besser Lösung hast, würde ich mich über eine Erklärung darüber freuen.
Danke


PS: Das hab ich im Internet noch zur Rundung gefunden.
IEEE 754 unterscheidet zunächst zwischen binären Rundungen und binär-dezimalen Rundungen, bei denen geringere Qualitätsforderungen gelten.
Bei binären Rundungen muss zur nächstgelegenen darstellbaren Zahl gerundet werden. Wenn diese nicht eindeutig definiert ist (genau in der Mitte zwischen zwei darstellbaren Zahlen) muss in Richtung zur nächstgelegenen geraden Zahl gerundet werden. Damit wird die von Knuth beschriebene statistische Drift in längeren Rechnungen vermieden.
Eine zu IEEE 754 konforme Implementierung muss drei weitere vom Programmierer einstellbare Rundungen bereitstellen: Rundung gegen +Unendlich (immer aufrunden), Rundung gegen −Unendlich (immer abrunden) und Rundung gegen 0 (Ergebnis immer betragsmäßig verkleinern).

[Axel]

PS: Das hab ich im Internet noch zur Rundung gefunden.
IEEE 754 unterscheidet zunächst zwischen binären Rundungen und binär-dezimalen Rundungen, bei denen geringere Qualitätsforderungen gelten.
Bei binären Rundungen muss zur nächstgelegenen darstellbaren Zahl gerundet werden. Wenn diese nicht eindeutig definiert ist (genau in der Mitte zwischen zwei darstellbaren Zahlen) muss in Richtung zur nächstgelegenen geraden Zahl gerundet werden. Damit wird die von Knuth beschriebene statistische Drift in längeren Rechnungen vermieden.
Eine zu IEEE 754 konforme Implementierung muss drei weitere vom Programmierer einstellbare Rundungen bereitstellen: Rundung gegen +Unendlich (immer aufrunden), Rundung gegen −Unendlich (immer abrunden) und Rundung gegen 0 (Ergebnis immer betragsmäßig verkleinern).

Man kann's auch übertreiben.



Ich hatte mit der 0,005er Lösung noch nie Ärger.
 
Axel

[BMT216A]

Hallo Axel,

mir würde die Lösung mit 0.005 auch reichen - aber Du kennst leider oder besser gesagt zum Glück unser Rechnungswesen nicht.

In diesem Sinne

schönes Wochenende