[ASP.Net/C#] SQL money afronden

[T-Blizzard]

Ik heb momenteel een probleem met afronden:

Producten tabel:

ID [int]	Price [money]	Tax[decimal(18,4)]
1	210.0756	0.1900

Als ik dan de producten opvraag geef ik de totaalprijs terug in een calculated column Price + (Price * Tax). Deze berekening gaat dus met de 4 decimalen (is nodig voor sommige producten om er voor te zorgen dat het bedrag inclusief B.T.W. op een afgerond bedrag uitkomen). In dit geval dus € 249,99.

Wat er nu dus mis gaat is dat in de ASP.NET C# frontend het bedrag zonder b.t.w. (met 2 decimalen) getoond wordt als € 210,08.

Als de gebruiker het daar dus na rekend:

€ 210,08 * 19% = € 249,9952 (€ 250,- dus)

Terwijl uit de database het volgende komt (en wat ook als totaal bedrag gebruikt wordt):

€ 210.0756 * 19% = € 249,989964

Ik kan moeilijk mijn bedragen in de frontend gaan tonen met 4 decimalen

[NMe]

Wat wou je eraan doen als je zelf al aangeeft dat je moeilijk alle drcimalen weer kan gaan geven?

Bovendien Zit je hier fout: Waar hoort mijn topic?

[storeman]

Je kunt in je query het tussenbedrag toch afronden?

Niet erg netjes, maar ik denk dat het dergelijke fouten wel kan voorkomen.

[ Voor 43% gewijzigd door storeman op 21-07-2010 08:54 ]

[lier]

T-Blizzard schreef op woensdag 21 juli 2010 @ 08:43:
is nodig voor sommige producten om er voor te zorgen dat het bedrag inclusief B.T.W. op een afgerond bedrag uitkomen

Vraag jezelf eens af of het "echt" noodzakelijk is.
Blijkbaar wil je je klanten een bruto prijs (in ieder geval ex BTW) presenteren. Wat is het nut om tot een afgerond bedrag netto te komen ? Is het voor jou niet veel logischer/eenvoudiger/mooier om "afgeronde" bruto bedragen te krijgen ?

[ Voor 38% gewijzigd door lier op 21-07-2010 09:07 . Reden: voortschrijdend inzicht ]

[T-Blizzard]

lier schreef op woensdag 21 juli 2010 @ 09:04:
[...]

Waarom niet ?

[...]

Vraag jezelf eens af of het "echt" noodzakelijk is.

Jammer genoeg is dit de wens van een klant

[Paul]

Dan moet je de klant uitleggen dat hij 2 opties heeft: Accepteren dat er zoiets als afrondingsverschillen bestaat, of alle prijzen in 4 decimalen laten tonen

Je kunt wel afkappen in plaats van afronden, maar dan zijn er weer andere bedragen te verzinnen waarbij het niet klopt.

[YopY]

is nodig voor sommige producten om er voor te zorgen dat het bedrag inclusief B.T.W. op een afgerond bedrag uitkomen

Euh. Eerst bedrag + BTW uitrekenen, dan pas afronden indien nodig? In dit geval zie ik maar een paar oplossingen:

* Prijs van het product altijd op 2 decimalen instellen. Ik zie zo geen reden om het met meerdere decimalen af te ronden, tenzij het echt bulkgoederen zijn (zoals olie e.d.)
* Prijs met 2 decimalen weergeven. Dit als optie #1 niet kan.
* Altijd totaalprijs weergeven, dus bedrag + BTW
* Het laten zoals het is, één of twee cent op 250 euri zal niemand echt veel boeien en kun je afschuiven op afrondingsfouten ivm de prijs met 4 decimalen.

[Korben]

Misschien is het simpelweg handiger om prijzen inclusief BTW in de database te zetten, en aan de front-end het bedrag ex. BTW te bereken aan de hand van het BTW-percentage.

C#:

decimal withTax = 249.99M;
decimal tax = 0.19M;

decimal withoutTax = withTax / (1 + tax);
// withoutTax = 210.07563025210084033613445378M

[T-Blizzard]

YopY schreef op woensdag 21 juli 2010 @ 09:19:
[...]


Euh. Eerst bedrag + BTW uitrekenen, dan pas afronden indien nodig? In dit geval zie ik maar een paar oplossingen:

* Prijs van het product altijd op 2 decimalen instellen. Ik zie zo geen reden om het met meerdere decimalen af te ronden, tenzij het echt bulkgoederen zijn (zoals olie e.d.)
* Prijs met 2 decimalen weergeven. Dit als optie #1 niet kan.
* Altijd totaalprijs weergeven, dus bedrag + BTW
* Het laten zoals het is, één of twee cent op 250 euri zal niemand echt veel boeien en kun je afschuiven op afrondingsfouten ivm de prijs met 4 decimalen.

Gezien het feit dat het de ene keer B2B is (wil mooie bruto bedragen) en andere keren particulier (mooie netto bedragen) denk ik dat optie 4 de beste oplossing is. Dan de afrondingsfouten maar voor lief te nemen.

[Amras]

T-Blizzard schreef op woensdag 21 juli 2010 @ 09:58:
[...]
Gezien het feit dat het de ene keer B2B is (wil mooie bruto bedragen) en andere keren particulier (mooie netto bedragen) denk ik dat optie 4 de beste oplossing is. Dan de afrondingsfouten maar voor lief te nemen.

Ik zou de klant de opties voor leggen en die de knoop door laten hakken, dat scheelt je een hoop gezeik achteraf.

[T-Blizzard]

Amras schreef op woensdag 21 juli 2010 @ 10:01:
[...]

Ik zou de klant de opties voor leggen en die de knoop door laten hakken, dat scheelt je een hoop gezeik achteraf.

Jammer genoeg zijn er meerdere klanten

[Face_-_LeSS]

Ik zou kiezen voor optie 4 en dan in de frontend een help-tekst plaatsen met de reden waarom het totaal-bedrag kan afwijken en met een eenvoudige voorbeeld berekening erbij.

[Korben]

Of optie 5: Beide bedragen in de database opslaan (dit is een probleem waarbij redundancy toegestaan is lijkt me), en in de back-end de optie geven om als leidende prijs bruto of netto in te voeren.

[ Voor 0% gewijzigd door Korben op 21-07-2010 11:31 . Reden: Typo ]

[YopY]

Korben schreef op woensdag 21 juli 2010 @ 11:31:
Of optie 5: Beide bedragen in de database opslaan (dit is een probleem waarbij redundancy toegestaan is lijkt me), en in de back-end de optie geven om als leidende prijs bruto of netto in te voeren.

Dat zou je ook kunnen doen. Wat je daarmee kunt doen is het 'vriendelijke' bedrag weergeven, met verborgen (als de gebruiker met de muis over een vraagteken oid gaat) het precieze bedrag en de berekening weergeven.

[NMe]

T-Blizzard schreef op woensdag 21 juli 2010 @ 10:03:
[...]

Jammer genoeg zijn er meerdere klanten

Waarom negeer je mijn vraag nou?

Wat is nu precies het probleem? Je applicatie geeft 2 decimalen weer. Jij wil 2 decimalen weergeven, zoals je zelf zegt. Meldinkje "door afronding kunnen brutoprijzen afwijken van de werkelijkheid", klaar.

[T-Blizzard]

NMe schreef op woensdag 21 juli 2010 @ 12:31:
[...]

Waarom negeer je mijn vraag nou?

Wat is nu precies het probleem? Je applicatie geeft 2 decimalen weer. Jij wil 2 decimalen weergeven, zoals je zelf zegt. Meldinkje "door afronding kunnen brutoprijzen afwijken van de werkelijkheid", klaar.

Probleem was dat er geen consequente manier van werken was (meerdere ontwikkelaars). Wat ik nu heb aangepast is dat alle berekeningen in de SP's op 4 decimalen gedaan wordt. Uitkomst wordt aan de applicatie terug gegeven afgerond op 2 decimalen.

Die melding is nu precies wat ik gedaan heb

[Verwijderd]

Je doet toch gewoon Math.Round(double d) of snap ik de vraagstelling niet?