Datamodel voor webshop met zowel incl. als excl. BTW orders

[B-Man]

Beste mede-forumleden,

Ik ben bezig met het datamodel voor een webshop waar zowel b2c als b2b klanten op kunnen bestellen.
Nu loop ik wat vast in het volgende, waar ik graag feedback/input op krijg.
Ik heb ruime ervaring met b2c-only en b2b-only projecten, en kom nu voor het eerst een gemengd project tegen.

Het project begon als een b2c project, waardoor we per orderregel een bedrag incl btw opslaan, het btw tarief en tenslotte het btw bedrag. So far, so good. Op basis van deze info is netjes een overzicht van de order te tonen met daaronder een btw specificatie.

Vervolgens kwam het verzoek of er ook b2b klanten en orders afgehandeld kunnen worden.
Hiervoor is het (uiteraard) nodig om prijzen excl btw te tonen, regeltotalen ex btw, een ordertotaal ex btw, dan de btw specificatie en tenslotten een ordertotaal incl btw.

Ik voorzie op dit moment twee oplossingen:
1) een flag op de order (b2b of b2c), bedragen zijn resp. excl of incl btw;
2) bedragen zowel excl als incl btw opslaan (stuksprijs, regeltotaal, ordertotaal)

Ik ben echter niet zo'n fan van (1) omdat je de getallen dan niet zomaar kunt vergelijken of optellen, vanuit de database bezien. Dit is echter vanuit code op te lossen door een interface te implementeren zodat je een B2BOrder en B2COrder krijgt die deze details intern afhandelen.

(2) heeft als nadeel dat je afrondingsverschillen krijgt. Je gaat dan immers de btw per product als basis nemen, en die vermenigvuldigen ipv werken met btw op basis van het regeltotaal.

Hoe zouden jullie dit modelleren?

[twiekert]

Ik zou op orderregel niveau bedragen altijd excl. btw opslaan met btw tarief in percentage. Op orderniveau BTW berekenen per BTW tarief.

[NMe]

Op orderniveau BTW berekenen gaat alleen als je geen verschillende tarieven hebt binnen je bedrijf en het ook héél onwaarschijnlijk is dat je die ooit gaat krijgen. Als je wél dingen aan kan bieden via het nultarief of hoog-/laagtarief, dan moet je het BTW-percentage opslaan per orderregel.

Overigens kun je in dat geval ook redundant beide bedragen opslaan om veelvuldig rekenwerk te voorkomen.

[ Voor 15% gewijzigd door NMe op 01-11-2014 12:10 ]

[Verwijderd]

Drie kolommen per orderregel: unit_price, amount en tax_amount. BTW code aan je product koppelen, en een aparte entiteit voor een prijslijst. Dan neem je de amount over van je prijslijst en maak je een soort "tax engine" om de btw kolom te vullen/berekenen.

Eigenlijk zou je van orderregel nog de stap moeten maken naar factuurregel. Als je dan evt voor distributies kiest, zou ik het bedrag (ex) en btw opslaan in twee afzonderlijke regels. Ligt er een beetje aan hoever je wilt gaan :-).

[NMe]

BTW-code? Waarom zou je de BTW in een andere tabel opslaan en daarnaar verwijzen? Sla gewoon het BTW-percentage op als double (of desnoods het promillage als integer). Je moet facturen sowieso altijd in de originele vorm opnieuw kunnen uitdraaien (belastingregels ) dus verwijzen naar een veldje dat je makkelijk kan updaten is aardig uit den boze. Afgezien van dat gemak is een eigen entiteit maken voor BTW alleen maar overhead (een int maken als foreign key die verwijst naar een double/int in een andere tabel en verder niks lijkt me nogal onhandig).

[Verwijderd]

Wat doe je dan als het BTW-tarief wijzigt.
Wij slaan de tariefcode op en per tariefcode/land het bijbehorende percentage per ingangsdatum.

Op basis van de huidige of gekozen datum en de tariefcode is dan het juiste percentage te berekenen.

Idem voor inkoop- en verkoopprijzen, die zijn ook datumafhankelijk en voor inkoop mogelijk zelfs leveranciersafhankelijk. Voor de B2B-klanten zou je dat op klant kunnen aangeven en daarmee een andere layout voor de factuur tonen.

[NMe]

Gewoon de huidige BTW-tarieven ergens opslaan in je config of database en alsnog de percentages opslaan per order of orderregel afhankelijk van je business.

[B-Man]

Bedankt voor jullie reacties, maar de essentie van mijn vraag blijft staan:

- per orderregel het regeltotaal ex btw, btw percentage en btw bedrag opslaan is het probleem niet, dan kunnen we het regeltotaal incl en excl btw tonen
- per orderregel het bedrag per stuk ex btw en incl btw tonen is een ander verhaal

Orderregels bevatten een aantal, dus bijvoorbeeld 3x een prullenbak. Op dit moment laten we in de orderhistorie en orderbevestiging dat aantal, de stuksprijs en het regeltotaal zien.
En daar zit het probleem: de stuksprijs.

Als we als basis alles ex btw opslaan, en per orderregel de btw over die regel, dan is het geen probleem om een stuksprijs ex btw te tonen (die slaan we immers op, of kunnen we berekenen door het regeltotaal ex btw door het aantal te delen).
We kunnen echter, vanwege afrondingsverschillen, niet altijd een correcte stuksprijs incl btw tonen.
De enige correcte manier om die te berekenen is dan namelijk "(regeltotaal ex BTW + regelbedrag BTW) / aantal", en dat kan een afronding vereisen.

Bijvoorbeeld: het product kost 8,30 ex BTW tegen 21% BTW.
Een klant bestelt dit product 3x, dus 3 x 8,30 = 24,90 ex BTW
21% BTW over 24,90 is (afgerond naar twee decimalen) 5,23

Het regeltotaal incl BTW is nu 24,90 + 5,23 = 30,13

De stuksprijs ex BTW is nog steeds 8,30
De stuksprijs incl BTW is nu 30,13 / 3 = 10,04 (afgerond naar twee decimalen)

Dan ziet de klant (b2c) dus:

2x Product X (10,04) = 30,13

En dat klopt niet vanwege het afrondingsverschil (3 x 10,04 = 30,12).

Daarbij speelt dan ook nog mee dat we op de b2c website de klant stuksprijzen incl BTW moeten tonen, die we dus ook moeten berekenen. En dat betekent dus: btw berekenen over de stuksprijzen.

Het btw bedrag van een orderregel wordt dan: "aantal x (stuksprijs incl btw - stuksprijs excl btw)".
Daarvan meen ik me echter te herinneren dat albert heijn dat ooit gedaan heeft en op de vingers getikt is.

[croxz]

Kijk even hoe facturering/boekhoudpakketten hiermee om gaan:
https://www.moneybird.nl/...de-afronding-in-moneybird
http://nl.visma.com/klant...rschillen-in-facturering/

Afrondingsverschillen ga je altijd krijgen. De belangrijke vraag hier is welke eisen de belastingdienst stelt aan een factuur. In mijn herinnering gaat het op regelniveau op totaalbedrag op 2 decimalen. Je berekent dus het totaalbedrag (dit kan in- of exclusief BTW zijn) voor een regel op 2 decimalen en berekent vervolgens het bijbehorende BTW bedrag en rond het af op 2 decimalen.

Dan de kwestie of je prijzen in- of exclusief BTW op moet slaan. Hou hierbij in je achterhoofd dat bij prijzen excl. BTW niet alle mooie verkooprijzen incl. BTW te realiseren zijn. 10,- euro is bijvoorbeeld niet te maken, namelijk: 8,26 ex BTW is 9,99 incl BTW en 8,27 ex BTW is 10,01 incl. BTW.

[B-Man]

croxz: dank je! Moneybird laat zien dat zij per factuurregel de gebruiker laat kiezen of de bedragen inclusief of exclusief BTW zijn.

Dat zit dus in de hoek van de door mij voorgestelde oplossing (1): met een flag aangeven of de bedrag incl of excl btw zijn.
Na er nog eens goed over nagedacht te hebben is dat volgens mij ook de enige manier om dit op te lossen.

[Xiphalon]

Wij* slaan beide bedragen op. Voor het bedrag wordt het Money datatype gebruikt (in Microsoft SQL Server) dat heeft 4 decimalen achter de komma, dan kan je je bron kolom opslaan met 2 decimalen (dat afronden moet je dus in je software doen) en de berekende kolom met 4 decimalen. Je kan dan altijd terugrekenen. Uiteraard wordt er per regel een vlaggetje bijgehouden of de inc of ex prijs leidend is.

Trouwens sowieso per regel een BTW code vastleggen, er zijn verschillende vormen van BTW (verlegd, 0%, hoog, laag)

Let op: bij meerdere stuks, eerst afronden, dan vermenigvuldigen. Een artikel wat (berekend) 0,021 per stuk kost inc btw wordt dus als je er 100 van koopt 2,00 euro

*) Ik werk bij een bedrijf wat kassasoftware maakt

[B-Man]

darkmage: ik neem aan dat je bedoelt dat jullie het regeltotaal excl en incl btw opslaan?

Je overigen opmerkingen zijn me reeds bekend (we bouwen hier al jaren relatief grote e-commerce websites), maar het zal een ander die zoekt naar btw-gerelateerde onderwerpen zeker helpen

[Verwijderd]

NMe schreef op zondag 02 november 2014 @ 14:24:
BTW-code? Waarom zou je de BTW in een andere tabel opslaan en daarnaar verwijzen? Sla gewoon het BTW-percentage op als double (of desnoods het promillage als integer). Je moet facturen sowieso altijd in de originele vorm opnieuw kunnen uitdraaien (belastingregels ) dus verwijzen naar een veldje dat je makkelijk kan updaten is aardig uit den boze. Afgezien van dat gemak is een eigen entiteit maken voor BTW alleen maar overhead (een int maken als foreign key die verwijst naar een double/int in een andere tabel en verder niks lijkt me nogal onhandig).

Je hebt het over belastingregels, en wilt dan alleen het BTW percentage opslaan?

Dat het waarschijnlijk is dat het beter performed zonder extra tabel kan iedereen bedenken.

[The Eagle]

Waarom zo moeilijk doen? Sla de boel op ex btw, en maak een of meerdere views die de bedragen inclusief btw tonen. Afhankelijk van b2b of b2c gebruik je de juiste view.

[sjroorda]

Absoluut exclusief btw opslaan, plus een btw-percentage of -code. Zoals hierboven al gezegd heb je te maken met verschillende percentages (0%, 6% en 21%) en veranderende percentages (zoals we onlangs van 19% naar 21% zijn gegaan). Mocht je over de grens gaan verkopen, houd er dan rekening mee dat per 1 januari volgend jaar het btw-percentage dat je buitenlandse particulieren (binnen de EU) in rekening brengt niet meer de Nederlandse 21% is, maar het percentage dat hoort bij het betreffende land. Je komt dan met veel verschillende percentages te zitten.

[kwaakvaak_v2]

The Eagle schreef op zondag 09 november 2014 @ 11:57:
Waarom zo moeilijk doen? Sla de boel op ex btw, en maak een of meerdere views die de bedragen inclusief btw tonen. Afhankelijk van b2b of b2c gebruik je de juiste view.

Dat dus... BTW hoort in een view, en of dit nu een HTML, PDF of watdanook (tm) view is. In je DB hoort enkel een referentie te staan naar welk BTW tarief telde op het moment dat de order regel is aangemaakt.

(anders krijg je idd van die lollige zaken dat een factuur uit het verleden ineens met 21% in de boekhouding staat ipv 19%)

[_Moe_]

kwaakvaak_v2 schreef op maandag 10 november 2014 @ 12:26:
[...]


Dat dus... BTW hoort in een view, en of dit nu een HTML, PDF of watdanook (tm) view is. In je DB hoort enkel een referentie te staan naar welk BTW tarief telde op het moment dat de order regel is aangemaakt.

(anders krijg je idd van die lollige zaken dat een factuur uit het verleden ineens met 21% in de boekhouding staat ipv 19%)

Bij ons wordt het bedrag met BTW enkel opgeslagen van zodra het daadwerkelijk besteld is.

[Sircuri]

Zoals toch al vaker aangegeven is een bedrag inclusief BTW een afgeleide waarde. Namelijk bedrag + btw-tarief ==> Bedrag inclusief BTW. Dat soort informatie hoort in principe niet thuis in een database model. Enkel niet af te leiden gegevens sla je op. Bedrag inclusief BTW is dus eenvoudig te reconstrueren op basis van bedrag en btw tarief.

Tevens loop je de kans op data inconsistentie tussen je bedragen inclusief en exclusief BTW.

[Xiphalon]

Oh, jij slaat geen voorraad op in je database? Arme performance

(want: voorraad = inkoop - verkoop + correcties, dus afgeleid)

[raptorix]

darkmage schreef op woensdag 12 november 2014 @ 10:10:
Oh, jij slaat geen voorraad op in je database? Arme performance

(want: voorraad = inkoop - verkoop + correcties, dus afgeleid)

Lang niet elk bedrijf dat producten verkoopt houden een voorraad aan.

[B-Man]

Dank voor alle reacties; Echter speelt natuurlijk ook mee dat er voor B2C ook mooie ronde bedragen getoond moeten kunnen worden; Dan moet je per definitie al iets gaan doen met het opslaan van bedragen incl BTW, en dat als basis gebruiken om je BTW bedrag te berekenen.

Ik heb momenteel een vraag uitstaan bij mijn accountant om vanuit een betrouwbare bron een correct antwoord te krijgen. Het blijkt lastiger dan ik dacht om mensen uit te leggen waarom dit een lastig issue is. Dat gaat makkelijker face to face met een kladblaadje erbij

[kwaakvaak_v2]

B-Man schreef op woensdag 12 november 2014 @ 22:33:
Dank voor alle reacties; Echter speelt natuurlijk ook mee dat er voor B2C ook mooie ronde bedragen getoond moeten kunnen worden; Dan moet je per definitie al iets gaan doen met het opslaan van bedragen incl BTW, en dat als basis gebruiken om je BTW bedrag te berekenen.

Want???? Je kunt niet afronden in je presentatie laag?

[croxz]

kwaakvaak_v2 schreef op donderdag 13 november 2014 @ 09:13:
[...]
Want???? Je kunt niet afronden in je presentatie laag?

Ik quote mezelf:

Dan de kwestie of je prijzen in- of exclusief BTW op moet slaan. Hou hierbij in je achterhoofd dat bij prijzen excl. BTW niet alle mooie verkooprijzen incl. BTW te realiseren zijn. 10,- euro is bijvoorbeeld niet te maken, namelijk: 8,26 ex BTW is 9,99 incl BTW en 8,27 ex BTW is 10,01 incl. BTW.

[kwaakvaak_v2]

Hoezo? centen zijn nog steeds een wettig geldig betaal middel, en het is een keuze of je die als leverancier wil accepteren. Maar voor de belastingdienst is volgens mij het BTW bedrag voor 8,26 nog steeds 8,26 * 0,21 = 1,73. Dat je die ene cent naar boven afrond is jouw keuze. Stel dat jij 10.000 van die producten verkoopt, reken maar dat de belastingdienst die 10.000 * 0,01 cent graag terug ziet in je opgave

Dat je voor de consument afrond naar boven of beneden is je eigen keuze, en dat is iets wat je prima in je presentatie laag kan doen.

code:

if cijfer.last < 4 then floor(cijfer) elseif cijfer.last > 6 then ceil(cijfer)

maar dan misschien eerst * 100 doen om de centen weg te werken

[Sircuri]

Voor de BTW aangifte moet je elke BTW tarief apart berekenen en dan pas afronden. Niet per factuurregel. Anders krijg je een hoop verschillen.

@darkmage: natuurlijk zijn er momenten dat je data redundant opslaat. Inderdaad is voorraad er 1 van. Ik ken ook scenario's waarin op een factuurregel zowel de BTW percentage als waarde wordt opgeslagen naast een referentie naar de BTW tarief regel in een BTW tabel. Het is maar net hoeveel vertrouwen je legt in een goed datamodel. Mensen zijn gauw geneigd om zo veel mogelijk data redundant op te slaan, want de data zou maar eens veranderd kunnen worden door iemand zodat alle foreign key relaties mee veranderen.
Het is een kwestie van een goed data model en goede programmatuur.