Über die Frage, warum, wie und wann Rundungsdifferenzen in Rechnungen, etc. auftauchen können, ist ja schon geschrieben worden und dass dies vor allem dann auftritt, wenn mit mehr als 2 Nachkommastellen gearbeitet wird, ist auch klar. Als Argument für die Unabwendbarkeit dieses Umstandes wird aber immer angegeben, dass Vorgang.Positionen.NettopreisGesamt/BruttopreisGesamt eben "by design" mit den rohen Positionsbeträgen mit 4 Nachkommastellen arbeiten würden.
Was ich aber finde, lässt das, meines Erachtens zumindest, in einem anderen Licht erscheinen, und zwar wie folgt...
1. Positions-Einzelbeträge und Positions-Summen kann ich natürlich über eine Formatanweisung oder explizit über Round(Wert,Stellen) runden. Soweit, so klar.
2. Für die Zwischensumme und den Übertrag kann ich aber mit Sum(Round(Auftragspositionen.NettopreisGesamt,2),false) erstaunlicherweise eine Summe aus den individuell auf 2 Nachkommastellen gerundeten Einzelbeträgen errechnen!
3. Vor diesem Hintergrund ist dann aber nicht mehr verständlich, warum das Ganze bei Auftragspositionen.NettopreisGesamt geht, der gleiche Befehl auf Basis von Vorgang.Positionen.NettopreisGesamt, also auf der gleichen Hierarchie-Ebene aber dann doch nur die auf zwei Stellen gerundete Summe der ungerundeten Einzelpreise ausgibt, beim einen der Round() Befehl also beachtet wird, beim anderen aber ignoriert wird.
Das macht wenig Sinn und sieht für mich eher so aus, als ob bei der Implementierung der Summierung für Vorgang.Positionen einfach nur vergessen wurde, ein einschließendes Round() zu beachten und dass das nicht wirklich "by design" ist, denn falls es bei Design wäre, dann dürfte logischerweise auch Auftragspositionen den Round() Befehl nicht beachten.
Vielleicht gibt es ja doch die Möglichkeit, die Berücksichtigung von Round() auch für die Summen über Vorgang.Positionen einzuführen. Schwierig kann das eigentlich nicht sein, weil es ja bei Auftragspositionen.NettopreisGesamt bereits implementiert ist und auch wenn man auf Rundungsdifferenzen hinweisen kann und darf, wäre eine Wawi, die solche Differenzen überhaupt zu vermeiden hilft, natürlich noch viel cooler...
Viele Grüße,
Ingmar
Was ich aber finde, lässt das, meines Erachtens zumindest, in einem anderen Licht erscheinen, und zwar wie folgt...
1. Positions-Einzelbeträge und Positions-Summen kann ich natürlich über eine Formatanweisung oder explizit über Round(Wert,Stellen) runden. Soweit, so klar.
2. Für die Zwischensumme und den Übertrag kann ich aber mit Sum(Round(Auftragspositionen.NettopreisGesamt,2),false) erstaunlicherweise eine Summe aus den individuell auf 2 Nachkommastellen gerundeten Einzelbeträgen errechnen!
3. Vor diesem Hintergrund ist dann aber nicht mehr verständlich, warum das Ganze bei Auftragspositionen.NettopreisGesamt geht, der gleiche Befehl auf Basis von Vorgang.Positionen.NettopreisGesamt, also auf der gleichen Hierarchie-Ebene aber dann doch nur die auf zwei Stellen gerundete Summe der ungerundeten Einzelpreise ausgibt, beim einen der Round() Befehl also beachtet wird, beim anderen aber ignoriert wird.
Das macht wenig Sinn und sieht für mich eher so aus, als ob bei der Implementierung der Summierung für Vorgang.Positionen einfach nur vergessen wurde, ein einschließendes Round() zu beachten und dass das nicht wirklich "by design" ist, denn falls es bei Design wäre, dann dürfte logischerweise auch Auftragspositionen den Round() Befehl nicht beachten.
Vielleicht gibt es ja doch die Möglichkeit, die Berücksichtigung von Round() auch für die Summen über Vorgang.Positionen einzuführen. Schwierig kann das eigentlich nicht sein, weil es ja bei Auftragspositionen.NettopreisGesamt bereits implementiert ist und auch wenn man auf Rundungsdifferenzen hinweisen kann und darf, wäre eine Wawi, die solche Differenzen überhaupt zu vermeiden hilft, natürlich noch viel cooler...
Viele Grüße,
Ingmar