Ga naar inhoud
  • 0

decimalen - truncate - afronden


Gem

Vraag

Hallo

 

Weeral een afrondingsvraag maar ik geraak er niet meer uit...

 

Totaal	btw 21%        afronden	             truncate (2)
107,73	 22,6233 €	      22,62	             22,62
 52,6	 11,0460 €         11,05	             11,04
 25,5	  5,3550 €	       5,36                 5,35

185,83    39,0243 €	      39,03	             39,01

 

 

Drie werkbonnen samengeteld kom je aan 185,83. Reken daar 21% btw op dan heb je 39,0243 aan btw op de factuur.

Wanneer elke werkbon afzonderlijk betaald wordt en je de btw per bon afrondt, dan heb je in totaal een verschil van 1 cent. Kap je de getallen af met truncate dan heb je nog steeds een verschil van 1 cent.

Dan dacht ik maar de precisie op 4 cijfers na de komma te laten maar wanneer je in FM16A de gegevensopmaak, vast aantal decimalen, op 2 zet dan geraak je er blijkbaar ook niet.

 

 

Weet iemand hoe je de totalen kan doen matchen ?

Link naar reactie

18 antwoorden op deze vraag

Aanbevolen berichten

  • 0

Als we een factuur maken geeft FM ons de te facturen bonnen in een portaal weer met bovenaan de portaal totalen.

Bij het maken van de factuur, maken we factuurregels in een factuurlayout door middel van een portaal, Een voorbeeld van enkele factuurregels zou kunnen zijn:

goederen 102€

diensten 30€

verzending 15€

enz...

Voor detail wordt dan naar de bonnen verwezen.

 

De factuurregels worden eveneens getotaliseerd in de factuurlayout en pas wanneer de totalen van de factuurregels gelijk zijn met de totalen van de te factureren bonnen kunnen de bonnen via een script afgepunt worden als zijnde gefactureerd.

 

En daar wringt nu het schoentje...

Als we de totalen van de bonnen overnemen zonder die te berekenen op de factuur dan kan iemand wel eens een factuurregel vergeten boeken waardoor het totaal van de factuur niet gelijk loopt met het totaal van de bonnen.

 

Hoe zou jij dan die controle aanpakken ?

Link naar reactie
  • 0

Bedankt alvast voor het meedenken.

 

ik heb inderdaad een portaal met bonnen en een totaal van de bonnen (excl. btw = MVH)

Dit totaal wordt vergeleken met het totaal van de factuur om zeker te zijn dat alles gefactureerd werd. Dit werkt goed.

... maar ik denk dat je in de portaal van de bonnen altijd het totaal van de

bonnen moet hebben (ex btw) zodat je dat kunt vergelijken met het totaal van de factuur, en dan daarna de btw over het factuur bedrag berekenen.

 

Dit is nu juist het probleem. Wanneer je btw over het factuur bedrag berekent is dit niet altijd gelijk aan de som van de btw bedragen van de bonnen die onder deze factuur vallen.

En omdat de bonnen betaald worden via bankcontact en het te betalen saldo op de factuur vermeld staat krijg ik geregeld een factuur met een te betalen saldo van 0.01euro daar waar alle bonnen eigenlijk correct betaald werden en dus de factuur ook op 0€ zou moeten staan.

 

Nu heb ik zelf een idee waar ik mogelijks iets mee kan doen:

Ik maak een script dat via een scripttrigger op het omschrijvingsveld van de factuur een evaluatie uitvoert (if statement). Het script evalueert of de totalen excl btw gelijk zijn en indien affirmatief neem het totaal van de btw op de bonnen over in het veld "btw factuur".

Als de MVH niet gelijk is tussen beiden dan wordt het btw bedrag nul en is het totaal inclusief btw van de factuur dus ook niet gelijk met het totaal inclusief btw op de bonnen.

En wanneer beide bedrag inclusief btw niet gelijk zijn kan ik de factuur (script) niet afsluiten.

 

Ik denk dat dit moet lukken.. Wat denk je, nog een beter idee ?

 

Bedankt alvast.

Link naar reactie
  • 0

Er zijn principieel 2 methoden waarop je de BTW kan berekenen en cumuleren (en dus afronden). De belastingdienst verwacht van jou dat je je aan slechts één methode houdt bij het berekenen van al je facturen. Zie: https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/btw/btw_berekenen_aan_uw_klanten/btw_berekenen/rekenvoorbeeld_btw_berekenen wat zij bedoelen.

 

Je op een factuur de BTW per line-item berekenen en dan bij elkaar optellen, maar je kan ook eerst alle line-item bij elkaar tellen en dan de BTW berekenen. Zoals gezegd, de belastingdienst accepteert beide methoden, maar verwacht van je dat je consequent van één methode gebruikt maakt.

 

In een notendop gaat het eigenlijk om het afronden. Werk je zoals gebruikelijk met 2 cijfers achter de komma, dan bepaalt het derde cijfer of je het getal afkapt op cijfers of dat je het 2e getal achter de komma met 1 verhoogt. Is het een 5 of hoger, dan rond je af naar boven en anders niet.

 

Methode 1: Per BTW-klasse over een factuur de BTW berekenen.

Dit is de meest nauwkeurige manier, je telt hierbij alle line-item waarover 21% moet worden berekend eerst bij elkaar op, bepaalt dan wat daarvan 21% is, dat rond je af volgens de regels en dat tel je bij het totaal van de line-item. Heb je op die factuur ook line-item waarover 6% moet worden berekend, dan bereken je dat apart en tel je er ook bij op.

 

Methode 2: Per line-item de BTW berekenen en het totaal van de resultaten bij elkaar optellen

Potentieel is deze methode iets minder nauwkeurig, de maximale afwijking kan in centen precies de helft van het aantal line-items positief of negatief zijn, maar is meestal minder. Hier vermenigvuldig je eerst het aantal artikelen met de prijs per stuk en daarna bereken je de BTW. Tenslotte tel je op de factuur eerst de netto bedragen bij elkaar en vervolgens de berekende (en afgeronde) BTW per factuur-regel (line-item).

 

Helaas heb je met het kiezen van methode 1 of methode 2 nog steeds je probleem niet helemaal opgelost, vooral met het inboeken van inkopen in je administratiekan je tegen nóg een verschil in de rekenmethode oplopen. In het bedrijfsleven (B2B) zijn we gewend om altijd te rekenen met netto bedragen en dat is zonder BTW. In de consumentenwereld, rekenen we met bruto bedragen en dus inclusief BTW.

 

Dit gaat helemaal probleemloos wanneer het artikel netto 100 euro kost, want bruto is dat 121 euro bij 21% BTW. Het maakt niet uit hoe we dan de BTW berekenen: over het 100 levert dezelfde uitkomsten als van het 100:

100 + 0,21*100 = 121 en 121/1,21 = 100

 

Maar wanneer het brutobedrag 100 euro is, dan krijgen we ineens wél verschillen: 100 euro bruto is bij 21% BTW namelijk netto 82,64. De 21% BTW over 82,64 is in B2B namelijk 17,35 (0,21 x 82,64) en dat is bij elkaar opgeteld 99,99. Terwijl wanneer je de 21% BTW van 100 uitrekent dan krijg je 17,36 (100 - 100/1,21).

 

Ik heb in diverse systemen gezien dat de ontwikkelaar en/of de gebruikers dit oplossen door altijd met 4 cijfers achter de komma te werken en pas aan het einde op 2 cijfers af te ronden. De weergave doen ze dan wel altijd met 2 cijfers, want dat kan je ook laten afronden. Gaat iemand dan met de zakjapanner de getallen optellen dan komen er soms toch afwijkingen van enkele centen naar boven. Dus onderhuids met 4 cijfers werken is meestal geen goed idee.

 

Één van mijn klanten werkt met zowel bedrijven als met particulieren en dan heb je een nog mooiere uitdaging dit goed te krijgen. Je moet je namelijk ook bedenken dat je de facturen ook in de boekhouding moet zetten en daar moet ook alles kloppen. Wat je boekt zijn dan de bedragen die op de facturen staan.

 

In het bijgevoegde voorbeeld wordt de BTW altijd per line-item/factuur-regel berekend. Bij het maken van een factuur kan worden gekozen voor Bruto_b = 1 voor prijzen inclusief BTW bij levering aan particulieren of voor Bruto_b ≠ 1 bij levering aan bedrijven. Dit voorbeeld zou je dus als basis kunnen gebruiken, wanneer je zowel met particulieren als met bedrijven te maken hebt.

Facturen.fmp12

Link naar reactie
  • 0

Een mooie verhandeling Menno. Dank.

 

Maar moet dit altijd zo? Ik vraag het mij af. Om te beginnen interesseert de belastingdienst zich absoluut niet in dit marginale verschil in centen. Gemiddeld zal het immers niet heel veel uitmaken, dan kom je weer een cent te kort, dan heb je weer een cent over.

 

De mensen die de som van de afgeronde bedragen per line item gaan vergelijken met de getotaliseerde bedragen behoren doorgaans niet tot de groep van financiële professionals zoals boekhouders, belastingambtenaren of accountants. Het is hooguit een argwanende klant die zich ernstig benadeeld voelt wanneer de BTW 2 cent te hoog is uitgevallen.

 

Mijn tactiek is in het algemeen heel simpel; FM presenteert alleen de uitgesplitste BTW bedragen over het totaal van een factuur, ook al zijn de line items alleen incl BTW vermeld of ook wanneer ieder line item al het BTW bedrag vermeldt.

 

Ik heb hier nog nooit problemen meer gehad, niet met accountants noch met de belastingdienst. Ik hou het daarom ook lekker eenvoudig.

Mocht zo'n klant toch op zijn strepen staan dan worden die 2 centen gewoon gecrediteerd. Dat is echter nog nooit voorgekomen :)

Link naar reactie
  • 0

bedankt ieder voor jullie denkwerk. :idea:

 

Het gaat hier niet om enkele centen waar mijn klanten noch ikzelf van wakker liggen maar om de structuur en opbouw van een programma die op een wijze automatiseert dat de gebruiker er vertrouwen kan in hebben steeds correct gehandeld te hebben.

Om vergissingen en vergetelheden tegen te gaan wordt zo weinig mogelijk input verwacht en zoveel mogelijk geautomatiseerd. Een factuur aanmaken die enkele tientallen bonnen en betalingen omvat is in mijn geval slecht een druk op een knop. Doordat er weinig input vereist is slinkt ook de kans op foutieve input waardoor er meer vertrouwen gegenereerd wordt. Dat is mijn doel.

 

Ik ben volkomen eens met uw visie Banach maar die luttele centjes kunnen het verdraaid moeilijk maken om een vergelijking in een script naar behoren te doen functioneren.

Voor mijn evaluatie bij de betalingen heb ik dan ook een mouw gepast:

 

Case(
     FactuurType="FA"  and (AlgTot FA - Bon_Tot Betaald_MEM)<,03;0;   //factuur
     FactuurType="CN";0;            //creditnota
     (AlgTot FA - Bon_Tot Betaald_MEM)
)

 

Wanneer ik voortaan een verschil heb dat kleiner is dan 3 cent, tussen de reeds betaalde bonnen en het totaal van de dus reeds betaalde maar nog te maken factuur; dan zet ik het te betalen saldo van de factuur op nul. Zo voorkom ik dat mijn klanten een factuur te betalen krijgen met een restwaarde van enkele centen daar waar alles eigenlijk al betaald werd via het bonnensysteem.

Link naar reactie
  • 0

Laat FM de btw uitrekenen. Rond dit af op hele centen. Laat het calculatieresultaat ook afgerond op 2 decimalen zijn, dus niet de decimalen laten staan en er twee weergeven.

 

Vervolgens: netto + btw = bruto

 

Voorbeeld:

 

Netto bedrag 180,78

Btw 0,21 x 180,78 = 37,9638 -> afronden op 37,96

Bruto is dan 180,78 + 37,96 = 218,74

 

Nooit meer totaal-verschillen

Link naar reactie
  • 0

BON 1 / week 1

Netto bedrag 180,78
Btw 0,21 x 180,78 = 37,9638 -> afronden op 37,96
Bruto is dan 180,78 + 37,96 = 218,74

klant betaalt 218,74 met bankcontact

 

BON 2 / week 2

Netto bedrag 180,78
Btw 0,21 x 180,78 = 37,9638 -> afronden op 37,96
Bruto is dan 180,78 + 37,96 = 218,74

klant betaalt 218,74 met bankcontact

 

BON 3 / week 3

Netto bedrag 180,78
Btw 0,21 x 180,78 = 37,9638 -> afronden op 37,96
Bruto is dan 180,78 + 37,96 = 218,74

klant betaalt 218,74 met bankcontact

 

 

maandfactuur

 

netto 180,78 x 3 bonnen = 542,34

btw 0,21 x 542,34 = 113,89

bruto = 542,34 + 113,89 = 656,23

 

klant heeft betaald = 3 x 218,74 = 656,22

 

FM berekent het verschll tussen het bruto bedrag van de factuur en het reeds betaald bedrag en maakt een factuur op met de vermelding hoeveel er nog betaald moet worden. Niettegenstaande de klant al zijn bonnen betaald heeft moet hij volgens FM nog een saldo van 0.01€ betalen.

 

Het probleem zit hem dus in het berekenen van de btw op net netto bedrag van de factuur. Wanneer ik gewoon alle btw bedragen van de bonnen optel dan zou ik dit probleem niet hebben.

Ik denk dat er een beetje gefoefel nodig is om dit te doen kloppen want anders komen we er niet uit.

Link naar reactie
  • 0

Als de klant 3 bonnen in één keer betaalt, dan betaalt hij een bedrag dat is samengesteld uit 3 bedragen waarover afzonderlijk de BTW is berekend.

 

DUS moet jij nog steeds die 3 BTW-bedragen afzonderlijk boeken en niet eerst de netto-bedragen bij elkaar vegen en dan de BTW erover berekenen. Net zoals je de afzonderlijke wekelijkse bonnen hebt berekend.

Link naar reactie
  • 0

 

maandfactuur

 

netto 180,78 x 3 bonnen = 542,34

btw 0,21 x 542,34 = 113,89

bruto = 542,34 + 113,89 = 656,23

 

klant heeft betaald = 3 x 218,74 = 656,22

 

FM berekent het verschll tussen het bruto bedrag van de factuur en het reeds betaald bedrag en maakt een factuur op met de vermelding hoeveel er nog betaald moet worden. Niettegenstaande de klant al zijn bonnen betaald heeft moet hij volgens FM nog een saldo van 0.01€ betalen.

 

Het probleem zit hem dus in het berekenen van de btw op net netto bedrag van de factuur. Wanneer ik gewoon alle btw bedragen van de bonnen optel dan zou ik dit probleem niet hebben.

Ik denk dat er een beetje gefoefel nodig is om dit te doen kloppen want anders komen we er niet uit.

btw = totaal van de btw-velden, dus 3 x 37,96 = 113,88

Link naar reactie
  • 0

En dat Menno en hbrendel het juist hebben mag misschien ook blijken uit het volgend voorbeeldje vanuit een totaal andere hoek.

 

Ik koop in de supermarkt 3 pakken melk à 72 cent per pak. Ik moet afrekenen 3 X 0,72 = 2,16. Ik ga niet pinnen want wanneer ik contant betaal neemt de kassière genoegen met 2,15. Toch betaal ik dan nog 5 cent teveel. Want wanneer ik 3 X 1 pak zou kopen reken ik telkens 70 cent af met een totaal van 2,10.

 

Het is mij nog nooit gelukt om die 3 pakken in één keer voor 2,10 mee te krijgen :D

Link naar reactie
  • 0

Het produceren van 1 en 2 eurocent-stukken is veel duurder dan dat beide muntstukken waard zijn. Vandaar dat onder andere Nederland in de wet heeft vastgelegd, dat contante aankopen op 0,05 euro nauwkeurig mogen worden afgerond (mits door de winkelier duidelijk aangegeven met bijv. een raamsticker).

Link naar reactie

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Beantwoord deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...