[ALG] Prijsmodel excl. btw, presentatie toch bepalend

[mithras]

Hallo allemaal

Ik heb een probleem in een door ons gemaakte webwinkel. Hierin staan producten zonder btw opgeslagen. De btw van de producten kan je gemakkelijk berekenen en kan je dus eenvoudig in de presentatie verwerken. Je kan dan namelijk wel facturen maken waar apart een btw-berekening wordt gemaakt.

De prijzen staan als integers in de database. De btw is gedefiniëerd als een percentage, ook als integer (in Nederland voor de meeste webshops dus 19). Nu is er een probleem met afrondingsfouten in de presentatielaag.

Een klant wil dat €139,95 een prijs is op de website (inclusief BTW). Hiervoor berekent ze de prijs exlusief btw. Dit is €117,6050... Hier ontstaat het probleem: als je €117,60 als prijs invoert komt er een prijs van €139,94 uit. Een productprijs van €117,61 zorgt ervoor dat de bezoeker een prijs ziet van €139,96.

Nu kunnen we gemakkelijk zeggen: jouw prijs van €139,95 kan je dus niet als verkoopprijs hanteren. Toch is het iets te kort door de bocht. Ik neem aan dat anderen hier ook wel eens mee hebben gestoeid. Hoe is dit op te lossen? De meest aangedragen oplossingen maken het systeem namelijk alleen maar slechter: prijzen in floats, een extra kolom voor een incl. btw prijs etc. Zijn er überhaupt oplossingen?

[BtM909]

Welke database gebruik je als backend (MySQL)?

Waarom gebruik je integers voor een currency formaat?

[whoami]

Sla de prijs incl. BTW op, en bereken de prijs excl. BTW indien je die nodig hebt.

[whoami]

BtM909 schreef op vrijdag 09 oktober 2009 @ 22:58:
Waarom gebruik je integers voor een currency formaat?

Volgens mij om 'problemen' met cijfers na de komma te vermijden ... Ik zie er het nut eigenlijk ook niet van in; je kan evengoed een decimal gebruiken.
[small]Ik gebruik echter ook soms wel eens integers om bedragen in op te slaan ( * factor 1000 dan bv), maar dit doe ik enkel in text-files, indien er problemen kunnen zijn met culture-settings.

[SinergyX]

Ligt een beetje aan de doelgroep. Voor bedrijven is het juist 'mooier' afgeronde ex BTW bedragen te hebben (117.50 ex btw), voor particulieren is het inderdaad incls BTW netter. Doe je hoofdzakelijk naar particulier, ga voor de oplossing van whoami

[mithras]

BtM909 schreef op vrijdag 09 oktober 2009 @ 22:58:
Welke database gebruik je als backend (MySQL)?

Waarom gebruik je integers voor een currency formaat?

Ja, MySQL.

Ik heb alles in integers gezet vanwege de problemen met floats. Als je daar wat verder gaat berekenen, krijg je al snel een significante afwijking. Ik heb even wat meer data types opgezocht welke ik kan gebruiken, maar ik zit met een LAMP omgeving. Hierin is denk ik MySQL niet de beperkende factor, maar php.
Ik kan in php alleen floats en integers gebruiken, wat natuurlijk niet zo handig is.

whoami schreef op vrijdag 09 oktober 2009 @ 23:00:
Sla de prijs incl. BTW op, en bereken de prijs excl. BTW indien je die nodig hebt.

Dat is natuurlijk ook een oplossing Een winkelier wil liever in rapportages alles excl doen, omdat je daar nu eenmaal mee rekent. Ik neem het probleem van mijn TS eerder voor lief dan de problemen die je krijgt doordat je alles incl. BTW gaat berekenen.

Want nog een leuk feitje: bepaalde zaken op facturen die je naar het buitenland verstuurt kennen helemaal geen BTW. Beetje zonde om het dan wel mee te nemen

SinergyX schreef op vrijdag 09 oktober 2009 @ 23:04:
Ligt een beetje aan de doelgroep. Voor bedrijven is het juist 'mooier' afgeronde ex BTW bedragen te hebben (117.50 ex btw), voor particulieren is het inderdaad incls BTW netter. Doe je hoofdzakelijk naar particulier, ga voor de oplossing van whoami

Uiteindelijk wordt dit misschien wel de keus. Helaas moet alles voor ons (== ontwikkelaars) een beetje beheersbaar zijn, dus wil je een configuratie-optie hebben die aangeeft of ingevoerde prijzen inclusief zijn of exclusief. En dat je dus bij het berekenen van een prijs moet gaan bedenken of je incl. of excl. wilt en daarbij dus * 119% of /119% moet gebruiken

Mja, als dit een enige optie is, moeten we maar even afwegen of de tijd die dit kost de extra voordelen kan dekken...

[ Voor 25% gewijzigd door mithras op 09-10-2009 23:09 ]

[SinergyX]

Naja, kort gezegt.. het is niet op te lossen. Een 0.005 versus 0.005, waar je bij ex BTW of BTW bedrag een centje zal moeten aanpassen.

Je kan ook het BTW bedrag apart gaan opnemen voor je prijzen, maar enkel voor deze 'uitzonderingen' de bedragen fixed laten uitlezen, de rest laat je gewoon nog uitrekenen. Dit hebben wij gedaan met prijsafspraken die mooi inclusief BTW moeten worden, artikel regel krijgt een extra vinkje en berekening wordt overgeslagen, in plaats daarvan wordt gewoon de BTW regel uitgelezen. Op de prijzenlijst staat hij met een * aangemerkt, zodat we weten dat daar een aangepast BTW bedrag aan vast zit (bij eventuele prijsverlagingen rekent hij het ook gewoon opnieuw uit).
(mening boekhoudprogramma werkt namelijk ook zo ).

[ Voor 41% gewijzigd door SinergyX op 09-10-2009 23:12 ]

[mithras]

SinergyX schreef op vrijdag 09 oktober 2009 @ 23:09:
mening boekhoudprogramma werkt namelijk ook zo

Dat is iets om ook even naar te kijken. Wel een goede tip. Daar zitten ze natuurlijk ook met dat probleem. Ik vind het zelf namelijk wel weer zo "zonde" om een kolom toe te voegen die waarschijnlijk 99% van de tijd NULL staat te wezen...

[roy-t]

Je kunt natuurlijk een extra veld maken met "rest" dan heb je in 1 kolom gewoon 1995 staan (is €19,95) en dan in een andere kolom de getallen verder achter de komma. Is misschien niet zo super netjes maar dan krijg je wel de precisie die je wilt en het kost je slechts 1 extra rij met intje. (dom idee, sla dan met en zonder btw op)

Het uitrekenen in php zie ik niet zo, tenzij je natuurlijk een stuje code maakt die "afrond op dichste 5 tal" volgens mij kun je dat ook wel legaal doen (Supermarkten doen dat ook) dat kun je even uitzoeken.

[ Voor 4% gewijzigd door roy-t op 10-10-2009 08:31 ]

[gorgi_19]

Wat is het probleem met de centen naar boven af te ronden, zit je sowieso goed. Verder gaat je BTW aangifte afaik toch in gehele getallen.

[Verwijderd]

roy-t schreef op zaterdag 10 oktober 2009 @ 08:30:

tenzij je natuurlijk een stuje code maakt die "afrond op dichste 5 tal" volgens mij kun je dat ook wel legaal doen (Supermarkten doen dat ook)

Dat doen ze alleen om van het gehannes met de 1-cent munten af te zijn. Als je electronisch betaalt, wordt alles wel precies op de cent afgerekend.

OP: als je nou eens je bedragen in tienden van centen in je db opslaat, dan loop je minder snel tegen afrondingsfouten aan.

[pedorus]

mithras schreef op vrijdag 09 oktober 2009 @ 22:56:
Een klant wil dat €139,95 een prijs is op de website (inclusief BTW). Hiervoor berekent ze de prijs exlusief btw. Dit is €117,6050... Hier ontstaat het probleem: als je €117,60 als prijs invoert komt er een prijs van €139,94 uit.

Let op. Je mag bij ?.??5 niet afronden naar beneden als het over belasting gaat. Hier is volgens de regels BTW 22.3449 euro=22.34, dus bedrag moet 117.61 zijn.

Een productprijs van €117,61 zorgt ervoor dat de bezoeker een prijs ziet van €139,96.

De oplossing is dan ook de prijs incl btw per product opslaan bij een consumentensite, en dan per product afronden, of over het geheel om de btw te berekenen. Als je de prijzen een beetje handig kiest, dan rond je per artikel af en weet je de belasting ietsje te drukken.

prijzen in floats

Word niet meer exact, niet doen dus!

[ Voor 13% gewijzigd door pedorus op 10-10-2009 12:35 . Reden: foute link... ]

[wizzkizz]

En als je, zoals ook al aangegeven door jointm1k je prijzen in de database nauwkeuriger gaat opslaan? Dus ipv op de centen, op 4 decimalen (dat kun je ook prima opslaan als integer natuurlijk). Dan ben je volgens mij van een heleboel afrondingsverschillen af (omdat het dan gaat over afronden op 100e centen wat je in je presentatie toch niet ziet).

In de webshops die ik ontwikkel/onderhoud werk ik (sinds een tijdje) ook met prijzen met 4 decimalen om afrondingsverschillen te voorkomen. Je kunt dan als prijs gewoon EUR 117,6050 opslaan.

[ Voor 4% gewijzigd door wizzkizz op 10-10-2009 12:26 ]

[Sefyu]

__Ongelukje__

[ Voor 99% gewijzigd door Sefyu op 10-10-2009 12:27 ]

[ixi]

Kun je niet beide prijzen (dus excl en incl BTW) opslaan in de database? Bij de normale gang van zaken laat je de incl-prijs automatisch berekenen (dus alleen als de excl-prijs wordt aangepast), maar je bied de klant de mogelijkheid om deze te overrulen en zelf een bedrag in te vullen.

[Canaria]

mithras schreef op vrijdag 09 oktober 2009 @ 22:56:
De btw is gedefiniëerd als een percentage, ook als integer (in Nederland voor de meeste webshops dus 19).

Wat doe je als de btw naar 19,5% zou gaan?

[Soultaker]

Waarom sla je de bedragen niet in tienden (of desnoods honderdsten) van centen op? Afronden moet je toch, maar je kunt dan bijvoorbeeld de prijs ex btw opslaan als 117,6050 euro, en presenteren als 117,61 cent inclusief btw, en 139.95 exclusief btw.

Canaria schreef op zondag 11 oktober 2009 @ 00:22:
Wat doe je als de btw naar 19,5% zou gaan?

Ook een goed punt inderdaad. Je kunt de representatie natuurlijk makkelijk aanpassen naar een breuk als je floating-point getallen wil vermijden. Het is niet erg waarschijnlijk dat ooit een irrationeel btw-tarief ingevoerd wordt.

[ Voor 49% gewijzigd door Soultaker op 11-10-2009 00:45 ]

[mithras]

ixi schreef op zondag 11 oktober 2009 @ 00:14:
Kun je niet beide prijzen (dus excl en incl BTW) opslaan in de database? Bij de normale gang van zaken laat je de incl-prijs automatisch berekenen (dus alleen als de excl-prijs wordt aangepast), maar je bied de klant de mogelijkheid om deze te overrulen en zelf een bedrag in te vullen.

Het is sowieso niet wenselijk om alle producten een incl. en excl. prijs mee te geven. Dat zou je dan wat verder moeten normaliseren. Maar als je toch 99% van de prijzen kan berekenen, ga je dat natuurlijk niet allemaal opslaan.

Canaria schreef op zondag 11 oktober 2009 @ 00:22:
[...]

Wat doe je als de btw naar 19,5% zou gaan?

True, maar dat is niet heel moeilijk om te veranderen. En ik denk dat het gebruik van integers vs iets anders (of btw in promille-integers) niet uitmaakt voor de fouten in de afronding. Je zal dan waarschijnlijk net op een iets andere plaats een afrondingsfout krijgen.

Soultaker schreef op zondag 11 oktober 2009 @ 00:29:
Waarom sla je de bedragen niet in tienden (of desnoods honderdsten) van centen op? Afronden moet je toch, maar je kunt dan bijvoorbeeld de prijs ex btw opslaan als 117,6050 euro, en presenteren als 117,61 cent inclusief btw, en 139.95 exclusief btw.

Is dat niet voor mensen veel moeilijker te beheren? Al die extra getallen achter de komma... dan zou ik liever een aparte incl. btw kolom opnemen die bij de uitzonderingen de btw fixed kan uitgeven, in plaats van de automatische manier.

[Erkens]

mithras schreef op zondag 11 oktober 2009 @ 10:50:
Is dat niet voor mensen veel moeilijker te beheren? Al die extra getallen achter de komma... dan zou ik liever een aparte incl. btw kolom opnemen die bij de uitzonderingen de btw fixed kan uitgeven, in plaats van de automatische manier.

Als je die mogelijkheid aanbied dan krijg je vroeg of laat problemen. Wat je wel kan doen is de prijs opslaan zonder btw, zoals het hoort imo, en in de interface de prijs incl btw laten invullen. Op die manier is het voor de shopowner niet "ingewikkeld" met beheren en wordt het toch goed opgeslagen.

[Hobbles]

Is het globale probleem niet gewoon dat je per 5 cent wil afronden?

[ta_chi79]

Canaria schreef op zondag 11 oktober 2009 @ 00:22:
[...]

Wat doe je als de btw naar 19,5% zou gaan?

Of dat je klant ineens een product wil verkopen die in de 6% BTW categorie zit?

[whoami]

ta_chi79 schreef op zondag 11 oktober 2009 @ 17:54:
[...]


Of dat je klant ineens een product wil verkopen die in de 6% BTW categorie zit?

En wat is het probleem dan ?
Dan verander je gewoon de btw categorie voor dat product; no big deal ...

[ Voor 13% gewijzigd door whoami op 11-10-2009 23:17 ]

[mithras]

whoami schreef op zondag 11 oktober 2009 @ 23:16:
[...]

En wat is het probleem dan ?
Dan verander je gewoon de btw categorie voor dat product; no big deal ...

Ja inderdaad. Het was een opmerking adhv mijn statement dat ik het btw tarief als integer van procenten heb ingesteld (dus 19 voor 19%). Dan kan je dus niet zomaar switchen naar 19.5%, mocht dat ooit het geval zijn. Toch heb ik niet het idee dat het wenselijk is om zó flexibel te zijn met je systeem. Het is uiteindelijk niet zo groot en een kleine moeite om het om te schrijven als het een keer voorkomt.

Erkens schreef op zondag 11 oktober 2009 @ 10:55:
[...]

Als je die mogelijkheid aanbied dan krijg je vroeg of laat problemen. Wat je wel kan doen is de prijs opslaan zonder btw, zoals het hoort imo, en in de interface de prijs incl btw laten invullen. Op die manier is het voor de shopowner niet "ingewikkeld" met beheren en wordt het toch goed opgeslagen.

Dit is denk ik dan wel de beste oplossing. Ik vond eerder ook al dat de extra kolom dan de mooiste van de oplossingen was, maar het blijft niet zo netjes. Jouw methode kan je achter de schermen zelf de significantie bepalen. Dit zal niet meteen worden geïmplementeerd, toch houd ik dit idee in mijn achterhoofd om het ooit te kunnen omschrijven.

[pedorus]

mithras schreef op zondag 11 oktober 2009 @ 23:39:
Toch heb ik niet het idee dat het wenselijk is om zó flexibel te zijn met je systeem. Het is uiteindelijk niet zo groot en een kleine moeite om het om te schrijven als het een keer voorkomt.

Inderdaad, YAGNI.

Dit is denk ik dan wel de beste oplossing. Ik vond eerder ook al dat de extra kolom dan de mooiste van de oplossingen was, maar het blijft niet zo netjes. Jouw methode kan je achter de schermen zelf de significantie bepalen. Dit zal niet meteen worden geïmplementeerd, toch houd ik dit idee in mijn achterhoofd om het ooit te kunnen omschrijven.

Ik snap deze oplossing niet helemaal, want wat is dan de significantie achter de schermen? Als je veel niet 100%-exacte bedragen optelt, dan kun je alsnog vreemde 1-cent-verschillen krijgen. Dan moet je dus heel nauwkeurig 139.95/1.19 op gaan slaan, terwijl gewoon 139.95 opslaan natuurlijk veel makkelijker is. Ook is het zeer onwaarschijnlijk dat iemand die 139.95 invoert, bij een BTW-wijziging naar 20% een bedrag van 141.1261 wil hebben (Nu! bestel er 2 en krijg 1 cent korting! ).

Ik snap eigenlijk het probleem niet met whoami's oplossing. Als je voor andere berekeningen excl. btw-bedragen wil hebben, dan kun je gewoon een view gebruiken die die bedragen automatisch berekend. Afronden per artikel mag gewoon, maar per bonnetje of in totaal is ook prima te implementeren. Bij 1 incl. btw-bedrag hoort altijd maar 1 excl. btw-bedrag, andersom niet. Dus als je excl. btw-bedragen hebt kun je de mist in gaan, maar bij bedragen incl. btw zie ik geen problemen (zolang je niet gaat adverteren met excl. btw-bedragen natuurlijk, dan is de andere aanpak logischer ).

[mithras]

Ik wil, omdat het gewoon in de totale bedrijfsvoering eenmaal makkelijker is, prijzen exclusief btw in de database opslaan. Als je kijkt naar invoer/uitvoer, koppelingen met externe applicaties (ook mogelijk in de toekomst) en misschien wel meer, is dat allemaal exclusief. Wanneer je prijzen inclusief btw gaat opslaan in je database, verplaats je volgens mij gewoon het probleem.

Soms wil de klant een speciale incl btw prijs die niet via een "excl * btw percentage" te berekenen is (zoals met de €139,95). Dit komt omdat a) je producten invoert exclusief btw en b) productprijzen in centen (integers) worden opgeslagen.
Wanneer je significante verhoogt (bijvoorbeeld in tienden van centen je prijs opslaat) kan je dit probleem voorkomen. Klant voert €139,95 in, systeem berekent dat je prijs exclusief btw dan €117,605 moet zijn. Dat staat dan als 117605 in de database en kan je in je verdere presentatie afronden naar een prijs van €117,61 (wat juist is volgens het eerder aangehaalde arrest van Ahold).

Dit heeft als voordeel dat je a) wel prijzen exclusief btw in de database hebt staan en b) de klant kan laten kiezen welke methode hij/zij wil gebruiken om prijzen in te voeren. Die eerste omrekenstap is namelijk eenvoudig aan- of uit te zetten via een configuratie.

[ Voor 4% gewijzigd door mithras op 12-10-2009 00:40 ]

[pedorus]

mithras schreef op maandag 12 oktober 2009 @ 00:39:
Ik wil, omdat het gewoon in de totale bedrijfsvoering eenmaal makkelijker is, prijzen exclusief btw in de database opslaan. Als je kijkt naar invoer/uitvoer, koppelingen met externe applicaties (ook mogelijk in de toekomst) en misschien wel meer, is dat allemaal exclusief. Wanneer je prijzen inclusief btw gaat opslaan in je database, verplaats je volgens mij gewoon het probleem.

Wat is het probleem om die andere bedrijfstoepassingen met een view te laten werken? Zelfs als ze rechtstreeks met de database willen praten, dan nog kent bijna iedere db-engine gewoon views hiervoor.

Wanneer je significante verhoogt (bijvoorbeeld in tienden van centen je prijs opslaat) kan je dit probleem voorkomen. Klant voert €139,95 in, systeem berekent dat je prijs exclusief btw dan €117,605 moet zijn. Dat staat dan als 117605 in de database en kan je in je verdere presentatie afronden naar een prijs van €117,61 (wat juist is volgens het eerder aangehaalde arrest van Ahold).

Ok. Enkel nu bestellen we 123 producten, en is er alsnog een verschil van 1 cent ontstaan.. Sowieso is het gevaarlijk om de opslag in integers te doen en posities op te laten schuiven, als je dat ergens vergeet zit je er opeens een factor 10 naast... (gebruik dan decimal)

[B-Man]

Ik loop momenteel tegen een vergelijkbaar vraagstuk aan. Ik krijg in mijn applicatie een productfeed binnen met prijzen inclusief BTW.

Nu zal het in eerste instantie zo zijn dat de orderbevestiging naar de klant (het betreft een webshop) incl BTW zal zijn, met specificatie van BTW onderop (dat is dus totaal / 1,19 * 0,19).
In de toekomst zullen er echter ook zakelijke accounts komen, wat betekent dat er orderbevestigingen en facturen ex BTW verstuurd moeten gaan worden.
Als ik enkel prijzen incl BTW + het BTW tarief opsla, dan zal ik tegen afrondingsverschillen aan gaan lopen. Er zullen immers verschillen (kunnen) optreden bij de som van de berekende ex BTW bedragen per regel vs het berekende totaalbedrag ex BTW.

Een vereiste is dat de "mooie" bedragen incl BTW behouden blijven; Uiteraard is het ook een vereiste dat de ex BTW berekeningen ook kloppen. Wat is in dit geval wijsheid?
Waar vang ik de afrondingsverschillen op? Ik zal per orderregel een ex BTW bedrag moeten berekenen (en afronden voor de presentatie).

Edit: dit probleem dus. Uit die link is af te leiden dat het toegestaan is om per regel af te ronden; Als ik geen eis had dat het totaalbedrag incl BTW moet kloppen was ik nu klaar geweest

[ Voor 10% gewijzigd door B-Man op 26-11-2009 14:54 ]

[B-Man]

Ik heb nog wat info gevonden:
http://drupal.org/node/587654 (drupal cart met hetzelfde issue)
http://navtechapac.spaces...5CE4F07FC65F8C9!150.entry (hoe Navision hiermee omgaat)

Uiteraard nog veel meer info, maar het merendeel is niet van toepassing of volledig.

Het lijkt erop dat (afgaande op bovenstaande info) ik dus een afgerond ex BTW bedrag kan berekenen, en de BTW dan incl - excl is. In het voorbeeld van Drupal (zie hier) zou dit betekenen dat een product met een incl prijs van 2,85 bij 20% BTW uitkomt op 0,47 BTW ipv een wiskundig correcte 0,48 BTW?

[mocean]

Ik beheer een backofficepakket waar ook gemengde facturen voorkomen (Dus producten met 6 en 19 procent op 1 factuur). Per product (en orderregel) wordt de Incl-prijs opgeslagen en de BTW (+ percentage). Bij de invoer van de producten kan gekozen worden voor mooie incl- of mooie excl. prijzen. En bij een btw-wijziging staan natuurlijk je order-regels vast. Over deze werkwijze heeft nog geen accountant geklaagd!

[B-Man]

mocean schreef op donderdag 26 november 2009 @ 19:02:
Ik beheer een backofficepakket waar ook gemengde facturen voorkomen (Dus producten met 6 en 19 procent op 1 factuur). Per product (en orderregel) wordt de Incl-prijs opgeslagen en de BTW (+ percentage). Bij de invoer van de producten kan gekozen worden voor mooie incl- of mooie excl. prijzen. En bij een btw-wijziging staan natuurlijk je order-regels vast. Over deze werkwijze heeft nog geen accountant geklaagd!

Ok, goed om te weten.
Dit betekent wel dat bij jullie facturen het totaal BTW bedrag niet per se overeen hoeft te komen met percentage * totaal ex BTW? Dat is ook precies wat ik her en der las: Als je de BTW per regel berekent kan de factuur niet "kloppen" vergeleken met het handmatig berekenen van de BTW over de gehele factuur ivm afrondingsverschillen.