Auf und ab ;-) Ich werde wahnsinnig Ceiling oder Round

E

ewc1111

Benutzer
Beiträge
20
Mal wieder eine Anfängerfrage aber diesesmal recht komplex..oder nicht ? Also folgende Aufgabe..es gibt eine Abfrage die einmal die gesamte Rechnung ausweist mit Netto, Brutto, Mwst ...bis hierher kein Problem..alles stimmt...nun kommt die 2. Abfrage..hier werden die Rechnungspositionen nochmal abgefragt ..und auch die mwst. Und hier gibt es Rundungsdifferenzen die genau immer 0.01 cent entsprechen. Beispiel: Summe Mehrwertsteuer aus Gesamt Betrag (19%) 242.16 aus 1274.50
Mehrwertsteuer aus Rechnungspositionen 242.17 . Mir wäre es ja egal, aber unsere Fibu macht da blöd rum. So wenn ich nun mal hingehe und ziehe mir die einzelnen Beträge raus so steht das in der Tabelle was unser ERP System dort reinschreibt:
137.47
29.93
25.94
10.64
38.19
Nun rechne ich mal selbst und ziehe mir die Positionen (Erloes * UST(19%) / 100) so erhalte ich dieses Ergebnis..
137.46500000
29.92500000
25.93500000
10.64000000
38.19000000
Wie schaffe ich es nun auf die o.g korrekten 242.16 zu kommen ? Mit Ceiling oder Round wird ja standard mässig immer um 0.5 aufgerundet oder abgerundet. :confused:
 
Werbung:
ewc1111 schrieb:
Mal wieder eine Anfängerfrage aber diesesmal recht komplex..oder nicht ? Also folgende Aufgabe..es gibt eine Abfrage die einmal die gesamte Rechnung ausweist mit Netto, Brutto, Mwst ...bis hierher kein Problem..alles stimmt...nun kommt die 2. Abfrage..hier werden die Rechnungspositionen nochmal abgefragt ..und auch die mwst. Und hier gibt es Rundungsdifferenzen die genau immer 0.01 cent entsprechen. Beispiel: Summe Mehrwertsteuer aus Gesamt Betrag (19%) 242.16 aus 1274.50
Mehrwertsteuer aus Rechnungspositionen 242.17 . Mir wäre es ja egal, aber unsere Fibu macht da blöd rum. So wenn ich nun mal hingehe und ziehe mir die einzelnen Beträge raus so steht das in der Tabelle was unser ERP System dort reinschreibt:
137.47
29.93
25.94
10.64
38.19
Nun rechne ich mal selbst und ziehe mir die Positionen (Erloes * UST(19%) / 100) so erhalte ich dieses Ergebnis..
137.46500000
29.92500000
25.93500000
10.64000000
38.19000000
Wie schaffe ich es nun auf die o.g korrekten 242.16 zu kommen ? Mit Ceiling oder Round wird ja standard mässig immer um 0.5 aufgerundet oder abgerundet. :confused:
Zum Vergrößern anklicken....


242.16 ist aber auch falsch...

Code: 
test=*# create table ewc (b1 numeric(6,2), b2 numeric(6,3));
CREATE TABLE
Time: 11,685 ms
test=*# copy ewc(b2) from stdin;
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> 137.465
>> 29.925
>> 25.935
>> 10.64
>> 38.19
>> \.
Time: 32110,151 ms
test=*# update ewc set b1 = b2;
UPDATE 5
Time: 0,623 ms
test=*# select * from ewc ;
  b1  |  b2
--------+---------
 137.47 | 137.465
  29.93 |  29.925
  25.94 |  25.935
  10.64 |  10.640
  38.19 |  38.190
(5 rows)

Time: 0,154 ms
test=*# select sum(b1), sum(b2) from ewc ;
  sum  |  sum
--------+---------
 242.17 | 242.155
(1 row)

test=*# select round(sum(b1),2), round(sum(b2),2) from ewc ;
 round  | round
--------+--------
 242.17 | 242.16
(1 row)

Wenn Du es sooo genau brauchst, dann speichere mit einer höheren Genauigkeit. Das kostet weder und tut auch nicht weh.
 
Ich brauch es nicht aber unser Controller ;-) der ERP Hersteller sagt von seiner Seite aus ist alles richtig..wie man aber sieht stimmt das nicht so genau. Der Gesamtbetrag wird ja auch aufgerundet. Ich hab mir die Tabellen nochmal angeschaut. Diese haben das Format decimal 14,2 liegt es daran ?
 
ewc1111 schrieb:
Ich brauch es nicht aber unser Controller ;-) der ERP Hersteller sagt von seiner Seite aus ist alles richtig..wie man aber sieht stimmt das nicht so genau. Der Gesamtbetrag wird ja auch aufgerundet. Ich hab mir die Tabellen nochmal angeschaut. Diese haben das Format decimal 14,2 liegt es daran ?
Zum Vergrößern anklicken....

Schau Dir doch einfach mein Beispiel an ...
 
hmm schon etwas spät...ich müsste wenn ich das richtig verstehe die Mwst Tabelle ändern auf 14.3 ? Würde aber bedeuten das dies eigentlich der ERP Hersteller machen müsste...? Ich teste das mal in der Testumgebung.
 
ewc1111 schrieb:
hmm schon etwas spät...ich müsste wenn ich das richtig verstehe die Mwst Tabelle ändern auf 14.3 ?
Zum Vergrößern anklicken....

Jupps. Aber Vorsicht: für Ausgaben ist das dann eher schlecht, wer will schon einen Betrag mit N,xyz auf der Rechnung sehen?

Würde aber bedeuten das dies eigentlich der ERP Hersteller machen müsste...? Ich teste das mal in der Testumgebung.
Zum Vergrößern anklicken....

Ist halt zu klären, wo und wie gerundet werden soll. Das zu entscheiden ist nicht mein Ding, ich schau nur, warum es so passiert.
 
Ok ich werde die mal kontaktieren morgen. Das kann es ja auch nicht sein das ich hier das ganze noch richtig rechnen muss. Ich müsste sonst als Alternative in meinem SSIS Paket auch nochmal alles umrechnen. Also vielen Dank erstmal für die schnelle Hilfe..wie immer Top hier ;-)
 
Ich würde exakt den selben Rechenweg gehen wie das ERP System und an den selben Stellen Runden. Wenn du nur eine bereits gerundete MwSt Summe hast wird es schwer immer den richtigen Erlös zu bestimmen ohne den Rechenweg des ERP exakt zu kennen.
 
Es gibt wohl auch ein Summenerhaltendes Runden laut Wikipedia: "Beim summenerhaltenden Runden werden die Teilbeträge so gerundet, dass die Summe der gerundeten Teilbeträge der Summe der ursprünglichen Beträge entspricht." Aber das soll mal der ERP Hersteller lösen.
 
Klingt interessant aber ich muss der Buchhaltung beipflichten: Eine Differenz von nur einem Cent, egal ob im Brutto, Netto oder sonstwo geht gar nicht. Insofern sollte man es rechnen wie im ERP, selbst wenn der Cent dort falsch gerundet wird. Oder man muss die Berechnung im ERP anpassen.
 
ukulele schrieb:
Ich würde exakt den selben Rechenweg gehen wie das ERP System und an den selben Stellen Runden. Wenn du nur eine bereits gerundete MwSt Summe hast wird es schwer immer den richtigen Erlös zu bestimmen ohne den Rechenweg des ERP exakt zu kennen.
Zum Vergrößern anklicken....
Nu denn, der ERP Hersteller macht laut seiner Aussage alles richtig. Das bringt mich aber nicht wirklich weiter. Ich habe nun einiges versucht doch ab einer gewissen Anzahl Datensätze wird das Ergebnis wieder verfälscht mit der Rundung. In einem amerikanischen Forum hab ich das hier entdeckt, nennt sich Bankers Rounding als function. Ich selbst bin aber nun zu blöd das irgendwo einzubauen ;-( Die schreiben das wenn man dies so einsetzt aus den Zahlen 137.465 die 137.47 wird und aus der 29.925 die 29.92 So würde es eigentlich passen oder ?. Nur wie ruf ich diese Function dann auf so das mir diese die Mwst in der Tabellenspalte rechnet ?

ALTER Function [dbo].[BankersRound](@Val Decimal(32,16), @Digits Int)
Returns Decimal(32,16)
AS
Begin
Return Case When Abs(@Val - Round(@Val, @Digits, 1)) * Power(10, @Digits+1) = 5
Then Round(@Val, @Digits, Case When Convert(int, Round(abs(@Val) * power(10,@Digits), 0, 1)) % 2 = 1 Then 0 Else 1 End)
Else Round(@Val, @Digits)
End
End
 
ukulele schrieb:
Zu Deutsch nennt man das kaufmännisches Runden.

Nochmal genau, welche Werte hast du und was willst du errechnen?
Zum Vergrößern anklicken....
Hallo ukulele,
habe heute festgestellt das dies auch nicht die Lösung bringt. Bei o.g Beispiel würde mir diese Function natürlich auch den Betrag von 25.935 runden auf 25.93 was das Ergebnis wieder verfälscht. Seltsamerweise ist es auch so, wenn ich die UST so wie weiter oben beschrieben von akretschmer mit mehr Genaugkeit zuerst addiere und dann ein round nehme, kommen diese Rundungsdifferenzen trotzdem irgendwo zustande. Also nun eine andere Lösungsidee (auch von unserer Buha) ...nur da fehlen mir einfach die Kenntnisse..Beispiel aus dem ersten Post...ganz oben UST =242.16 aus 1274.50 ...und dann wenn die einzelnen Positionen einen UST Wert haben von 242.17 dann ziehe von der letzten oder ersten Position 0.01 cent ab oder dazu. Könnte man dies nicht über einen Trigger lösen oder ein Proc. ?
 
ewc1111 schrieb:
Hallo ukulele,
habe heute festgestellt das dies auch nicht die Lösung bringt. Bei o.g Beispiel würde mir diese Function natürlich auch den Betrag von 25.935 runden auf 25.93 was das Ergebnis wieder verfälscht. Seltsamerweise ist es auch so, wenn ich die UST so wie weiter oben beschrieben von akretschmer mit mehr Genaugkeit zuerst addiere und dann ein round nehme, kommen diese Rundungsdifferenzen trotzdem irgendwo zustande. Also nun eine andere Lösungsidee (auch von unserer Buha) ...nur da fehlen mir einfach die Kenntnisse..Beispiel aus dem ersten Post...ganz oben UST =242.16 aus 1274.50 ...und dann wenn die einzelnen Positionen einen UST Wert haben von 242.17 dann ziehe von der letzten oder ersten Position 0.01 cent ab oder dazu. Könnte man dies nicht über einen Trigger lösen oder ein Proc. ?
Zum Vergrößern anklicken....

Also ich werd nicht schlau. In der Schule hab ich gelernt: ab der 5 rundet man auf. Aber, das ist lange, sehr lange her. Vielleicht verwechsle ich ja auch was. Und dann sollte man das so nach dieser Regel bei jedem Betrag und jeder Rechnung machen, und dann stimmt alles.

Wie man das dann umsetzt, das kommt später. Andere Baustelle. Erst einmal gilt: wenn man was umsetzen will, sollte man zuerst wissen, was man umsetzen will. Nicht einfach was machen und dann definieren, was es sein soll.
 
Werbung:
ewc1111 schrieb:
Bei o.g Beispiel würde mir diese Function natürlich auch den Betrag von 25.935 runden auf 25.93 was das Ergebnis wieder verfälscht.
Zum Vergrößern anklicken....
Das ist nicht richtig. Ein 0,005 wird auf auf 0,01 gerundet also hättest du 25,94 und das wäre korrekt kaufmännisch gerundet. So wie es hier in der Schule gängig gemacht wird und im Finanzwesen auch durchaus gängig ist, aber nicht überall und immer und nicht verpflichtend!
Bei steuerlichen Dingen wird z.B. i.d.R. zu gunsten des Steuerpflichtigen gerundet. Wenn also deine Werbungskosten 0,01 Cent betragen kannst du das in deiner Steuererklärung auf 1,00 Euro aufrunden.

ewc1111 schrieb:
..Beispiel aus dem ersten Post...ganz oben UST =242.16 aus 1274.50 ...und dann wenn die einzelnen Positionen einen UST Wert haben von 242.17 dann ziehe von der letzten oder ersten Position 0.01 cent ab oder dazu.
Zum Vergrößern anklicken....
Also wenn eure ERP Software hier auf 242,17 kommt ist das FALSCH. Richtig ist 242,16 und das spuckt z.B. auch Excel aus wenn man die normale RUNDEN(1274,5/119*100;2) Funktion bemüht. So dürfte auch SQL im Normallfall runden.

Schwer wird es nur wenn du mehr als 2 Teilbeträge errechnest (also z.B. mehrere Rechnungspositionen einzeln) und diese dann in Summe einen Wert ergeben müssen. Darum nochmal meine Frage nach den Ausgangswerten, was genau hast du und was willst du errechnen? Wenn es nur Brutto zu Netto oder umgekehrt ist muss das immer richtig gehen.

Brutto - Steuern (19%) = Netto

Brutto / 119 * 100 = Netto

Netto * 119 / 100 = Brutto
 
Zurück
Oben