[php] Afronding en rekenen

[Icheb]

Ik was vandaag bezig met het verwerken van enige betalingen van mijn facturatie systeem Client Exec, waarbij ik een eigen output systeem (.pdf) gemaakt heb. Nu kwam ik iets geks tegen.
Bij sommige facturen (als het aantal centen > 70 is, geloof ik) rond het systeem het verkeerd af. Al zie ik op dit moment niet in hoe dat komt, omdat het allemaal basis functies zijn.

Ik denk persoonlijk niet dat het aan mij ligt meer, maar dat er iets met PHP aan de hand is.

Als voorbeeld heb ik een factuur genomen:
Subtotaal = € 462,50
Iedereen weet dus dat je de btw hiervan kan uitrekenen door subtotaal * 0,19 (19% is btw percentage hier), daar komt dus uit 87,875 op mijn rekenmachine.
PHP daarentegen weet het heel anders te doen; PHP komt namelijk uit op 87,78 (afgerond dmv number_format()).
Wat doe ik hier verkeerd ?
Ik kan ook niet het tarief met 10 cent ophogen, omdat het niet bij iedere factuur zo is.

Mijn code:

PHP:

$tTaxTotal = (($tSubTotal*($tempInvoice->GetTax()/100)));
$tTaxTotal = sprintf("%.2f", $tTaxTotal);
$tTaxTotal = number_format($tTaxTotal, 2, ',', '.');

Hierbij is $tSubTotaal het subtotaal van 462,50. De $tempInvoice variabele vraagt aan ClientExec het BTW percentage aan, doordat dit niet overal hetzelfde is.
Ik moet eerlijk zeggen dat ik het nut van de 2e regel hier niet inzie, maar het resultaat is hetzelfde zonder deze regel.
Ik weet dat ik erg graag haakjes gebruik, maar dat zou geen probleem moeten zijn.

Wat ook gek is, is dat het bedrag wel klopt bij het eind totaal, maar dat komt doordat die het weer direct vanuit de db trekt met de variabele '$tempInvoice->getPrice()'

Wat gaat er hier verkeerd ?
Wie kan mij helpen ?

Het is nogal vervelend hier achter te komen tijdens het bijwerken van het orderboek...

[NMe]

Icheb schreef op 21 juni 2004 @ 14:42:
Als voorbeeld heb ik een factuur genomen:
Subtotaal = € 462,50
Iedereen weet dus dat je de btw hiervan kan uitrekenen door subtotaal * 0,19 (19% is btw percentage hier), daar komt dus uit 87,875 op mijn rekenmachine.
PHP daarentegen weet het heel anders te doen; PHP komt namelijk uit op 87,78 (afgerond dmv number_format()).
Wat doe ik hier verkeerd ?

Niets, want dit getal klopt... 87,875 afronden op 2 decimalen moet naar boven, 87,874 afronden op 2 decimalen zou naar beneden moeten. Wil je per se naar beneden afronden, gebruik dan de functie floor().

[Tjark]

php is niet gemaakt om te rekenen met floating points. Wil soms wel eens onverwachte resultaten geven, niet altijd en ook niet altijd van te voren voorspelbaar (I learned it the hard way).
Tip van mijn kant: hou alle bedragen in centen (dus 46550) en alleen als je ze wil tonen dan gooi je er een komma in (462,50).

[jorritv]

Icheb schreef op 21 juni 2004 @ 14:42:
Iedereen weet dus dat je de btw hiervan kan uitrekenen door subtotaal * 0,19 (19% is btw percentage hier), daar komt dus uit 87,875 op mijn rekenmachine.
PHP daarentegen weet het heel anders te doen; PHP komt namelijk uit op 87,78 (afgerond dmv number_format()).

Zijn de vetgedrukte stukjes een tikfout of het daadwerkelijke probleem? Want als ,875 afgerond wordt op ,78 dan zit er iets erg fout (doh, maar dat wist je al)

[ Voor 24% gewijzigd door jorritv op 21-06-2004 15:02 . Reden: te snel op enter geramd ]

[NMe]

TjarkVerhoeven schreef op 21 juni 2004 @ 14:59:
php is niet gemaakt om te rekenen met floating points. Wil soms wel eens onverwachte resultaten geven, niet altijd en ook niet altijd van te voren voorspelbaar (I learned it the hard way).
Tip van mijn kant: hou alle bedragen in centen (dus 46550) en alleen als je ze wil tonen dan gooi je er een komma in (462,50).

Bullshit. TS neemt een getal op 2 decimalen, dus dan rondt PHP dat getal dus af op 2 decimalen. En afronden doet PHP netjes volgens wiskundige regels. Verder wordt er wel gewoon gerekend met het goede getal, dus wat is überhaupt het probleem?

jorritv schreef op 21 juni 2004 @ 15:00:
Zijn de vetgedrukte stukjes een tikfout of het daadwerkelijke probleem? Want als ,875 afgerond wordt op ,78 dan zit er iets erg fout (doh, maar dat wist je al)

Niet eens gezien. Ik mag toch hopen dat dat een tikfout is.

[ Voor 20% gewijzigd door NMe op 21-06-2004 15:05 ]

[Tjark]

nou, ik heb dus echt een probleem mee gemaakt waarbij het dus fout ging in PHP. Toen opgezocht en op php.net werd gezegd dat 't inderdaad kon gebeuren.

Was toen ook helemaal verbaasd, dat zoiets simpels fout kon gaan.
Er werd toen voorgesteld om de aparte math library te gebruiken.

* Tjark zegt alleen wat hij zelf ervaren heeft.

-- edit --

Kijk hier maar eens hier
http://bugs.php.net/bug.php?id=28536&edit=1

tis geen bug, maar geeft wel aan dat je niet zomaar getallen van elkaar bv kan aftrekken:

Description:
------------
When calculating 90.99 minus 90.00 it returns 0.98999999999999 which is
a bit big for a simple subtraction of two floats that only have 2
decimal numbers.

Reproduce code:
---------------
<?php

$calc = 90.99 - 90.00;
print $calc;

?>

Expected result:
----------------
.99

Actual result:
--------------
0.98999999999999

[26 May 10:06pm CEST] [e-mail]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Welcome to the world of floating point numbers. This is
how it works.

't heeft idd niet met afronden te maken, maar de TS moet wel oppassen met 't rekenen met bedragen.

[ Voor 73% gewijzigd door Tjark op 21-06-2004 15:10 ]

[Martkrui]

Ik heb hier ook al problemen mee gehad.

Afronden doe ik nu zo :

$rounded= floor( ($value*100) + 0.5 ) / 100

( ik weet niet meer of floor( ($value) + 0.005 ) ook
goed werkte)

[RwD]

Ik heb zelf ook problemen met floating point getallen vooral als je prijzen wilt vergelijken. Daarom heb ik ook alles in centen, en kan het aanraden, het werkt best goed!

edit:
Icheb schreef op 21 juni 2004 @ 14:42:
Ik kan ook niet het tarief met 10 cent ophogen, omdat het niet bij iedere factuur zo is.

Ik denk niet dat de TS een typefout heeft gemaakt gezien deze opmerking....

[ Voor 68% gewijzigd door RwD op 21-06-2004 15:19 ]

[Tjark]

precies, anders moet je overal van die trukjes als Dr.DNA gebruikt toepassen, en daar wordt je niet blij van

[Icheb]

Sorry dat het zo lang duurde, ik was even weg...

Het is geen typefout, PHP zit er gewoonweg 10 cent naast.

TjarkVerhoeven schreef op 21 juni 2004 @ 14:59:
Wil soms wel eens onverwachte resultaten geven, niet altijd en ook niet altijd van te voren voorspelbaar (I learned it the hard way).
Tip van mijn kant: hou alle bedragen in centen (dus 46550) en alleen als je ze wil tonen dan gooi je er een komma in (462,50).

Ik wou dat dit kon, maar het probleem is eigenlijk dat het programma wat ik gebruik hier geen rekening mee houdt, en de source code niet te bewerken is (IonCube voor de kenners )

jorritv schreef op 21 juni 2004 @ 15:00:
[...]


Zijn de vetgedrukte stukjes een tikfout of het daadwerkelijke probleem? Want als ,875 afgerond wordt op ,78 dan zit er iets erg fout (doh, maar dat wist je al)

Dat is dus het probleem...

TjarkVerhoeven schreef op 21 juni 2004 @ 15:15:
precies, anders moet je overal van die trukjes als Dr.DNA gebruikt toepassen, en daar wordt je niet blij van

Daar zit inderdaad ook wel iets in...

Ik programmeer nu al in verschillende talen sinds '96 ofzo, maar dit is de eerste keer dat ik meemaak dat bij een simpele berekening een getal niet uitkomt.
Ik sta echt op het punt plat achterover te vallen hiervan....
Anders maar eens kijken of ik het nog op andere manieren uit kan rekenen, ik begin medelijden te krijgen met al die mensen die ik tot nu toe heb geholpen met simpele PHP scripts met rekensommen erin, gewoon het idee dat het niet uit komt...

nou, ik heb dus echt een probleem mee gemaakt waarbij het dus fout ging in PHP. Toen opgezocht en op php.net werd gezegd dat 't inderdaad kon gebeuren.

Was toen ook helemaal verbaasd, dat zoiets simpels fout kon gaan.
Er werd toen voorgesteld om de aparte math library te gebruiken.

Aparte math lib ?
Waar kan ik die precies vinden ?

[slm]

Afrondingsverschillen op de btw in facturen is niet te voorkomen.

Voorbeeld:

code:

Factuur blaat

Product              BTW 19%      (Sub)Totaal
1 x blaat á 0,50        0,10              0,60
1 x bleet á 0,50        0,10              0,60
1 x bloot á 0,50        0,10              0,60
1 x bluut á 0,50        0,10              0,60
1 x blyyt á 0,50        0,10              0,60
       ---------      ----------        --------
            2,50        0,50              3,00

echter:
0,19 * 2,50 = 0,48 (eigenlijke btw bedrag)
1,19 * 2,50 = 2,98 (eigenlijke totaalbedrag)

Je zou even met de boekhouder moeten overleggen wat hiermee wordt gedaan (if anything), maar volgens mij kan je in principe gewoon uitgaan van de eerste berekening en dus mét de afrondingsverschillen.

[Gomez12]

slm schreef op 21 juni 2004 @ 21:30:
Afrondingsverschillen op de btw in facturen is niet te voorkomen.

Voorbeeld:

code:

Factuur blaat

Product              BTW 19%      (Sub)Totaal
1 x blaat á 0,50        0,10              0,60
1 x bleet á 0,50        0,10              0,60
1 x bloot á 0,50        0,10              0,60
1 x bluut á 0,50        0,10              0,60
1 x blyyt á 0,50        0,10              0,60
       ---------      ----------        --------
            2,50        0,50              3,00

echter:
0,19 * 2,50 = 0,48 (eigenlijke btw bedrag)
1,19 * 2,50 = 2,98 (eigenlijke totaalbedrag)

Je zou even met de boekhouder moeten overleggen wat hiermee wordt gedaan (if anything), maar volgens mij kan je in principe gewoon uitgaan van de eerste berekening en dus mét de afrondingsverschillen.

AFAIK moet je de btw nog steeds berekenen over het totaal te betalen bedrag van de artikelen die in 1 btw groep liggen. (BTW 19% is alleen het hoge btw percentage hier 6 % is het lage percentage ).

Dus niet per artikel en dan optellen, maar in bovenstaand voorbeeld 1,19 * 2,50. Een bedrijf betaalt namelijk ook geen btw per artikel, maar per bedrag verdiend per maand / 3-maanden / halfjaar / jaar. Dus volgens mij is iedere persoon die btw per regel berekent en dit optelt gewoon een oplichter, want dit is extra winst voor de ondernemer.

[slm]

Gomez12 schreef op 21 juni 2004 @ 21:39:
[...]


AFAIK moet je de btw nog steeds berekenen over het totaal te betalen bedrag van de artikelen die in 1 btw groep liggen. (BTW 19% is alleen het hoge btw percentage hier 6 % is het lage percentage ).

Dus niet per artikel en dan optellen, maar in bovenstaand voorbeeld 1,19 * 2,50. Een bedrijf betaalt namelijk ook geen btw per artikel, maar per bedrag verdiend per maand / 3-maanden / halfjaar / jaar. Dus volgens mij is iedere persoon die btw per regel berekent en dit optelt gewoon een oplichter, want dit is extra winst voor de ondernemer.

Als je dat wilt doen, prima, maar dan moet je je facturen niet specificeren zolang dat mogelijk is. Zodra je een factureringsprogramma gebruikt zal volgens mij dezelfde afronding geschieden. Maar zoals ik al zei: laat de TS eens contact met zijn boekhouder opnemen.

[stekkel]

slm schreef op 21 juni 2004 @ 21:56:
[...]


Als je dat wilt doen, prima, maar dan moet je je facturen niet specificeren zolang dat mogelijk is. Zodra je een factureringsprogramma gebruikt zal volgens mij dezelfde afronding geschieden. Maar zoals ik al zei: laat de TS eens contact met zijn boekhouder opnemen.

En zo gebeurd het in de praktijk
BTW wordt altijd over het totaal berekend. nooit per sub item.

[flat]

Icheb schreef op 21 juni 2004 @ 17:49:
Aparte math lib ?
Waar kan ik die precies vinden ?

Je zou eens naar BCmath kunnen kijken, dat zit standaard bij PHP.
Overigens werkt jouw code hier wel goed, met PHP 4.3.7 en 4.2.3:

root@aapje:~# php calc.php
87,88

[Icheb]

flat schreef op 21 juni 2004 @ 22:11:
[...]

Je zou eens naar BCmath kunnen kijken, dat zit standaard bij PHP.
Overigens werkt jouw code hier wel goed, met PHP 4.3.7 en 4.2.3:

root@aapje:~# php calc.php
87,88

Los werkt het hier ook goed, maar bij elkaar nog steeds niet.
Ik denk persoonlijk dat het aan de Zend Optimizer ligt, of aan pdflib. Dat zijn de enige gekke dingen die actief zijn. Ik ga vannacht (tis een webhosting server) dat Optimizer er eens uit slopen. Kijken of dat een beetje effect heeft...


Ik kan wel contact opnemen met mijn boekhouder, maar die was al erg blij met de overgang van handmatig factureren naar een programma. De bedoeling was dat het programma 'aangepast'/ingesteld aan ons systeem zou worden, maar nee, programma pakte het eerste factuurnummer niet, programma kan geen orderboek weergeven, programma zit vol met bugs. Op die manier had ik het net zo goed zelf kunnen schrijven (beetje depri vanavond )

[slm]

stekkel schreef op 21 juni 2004 @ 22:05:
[...]


En zo gebeurd het in de praktijk
BTW wordt altijd over het totaal berekend. nooit per sub item.

Daar kun je helemaal gelijk in hebben, alhoewel het volgens mij inmiddels al mogelijk was om via de kassabon methode te factureren waardoor je je als ondernemer een heel stuk kan besparen (door dan ipv normaal af te ronden, af te ronden naar beneden - per product!) of in ieder geval liep hier een testproces oid over. Vandaar dat ik ook aangaf om met de boekhouder even te praten.

[NMe]

slm schreef op 21 juni 2004 @ 22:32:
[...]


Daar kun je helemaal gelijk in hebben, alhoewel het volgens mij inmiddels al mogelijk was om via de kassabon methode te factureren waardoor je je als ondernemer een heel stuk kan besparen (door dan ipv normaal af te ronden, af te ronden naar beneden - per product!) of in ieder geval liep hier een testproces oid over. Vandaar dat ik ook aangaf om met de boekhouder even te praten.

Een ondernemer mag niet besparen op de manier van BTW rekenen... BTW = belasting -> gaat naar de overheid. Dit moet geen inkomstenbron zijn voor de verkoper, en is volgens mij zelfs onwettig wanneer het verkeerd berekend wordt.

[RobIII]

Ik denk dat er gebruik wordt gemaakt van Bankers Rounding. Dit is een redelijk veelvoorkomende vraag op rounding in de meeste programmeertalen. Dat verklaart waarom 7.775 wordt afgerond naar 7.78 (naar boven) en 7.765 wordt afgerond naar 7.76 (naar beneden)

1 tip: Reken OF alles in 2 decimalen en tel die uiteindelijk op, OF tel de BTW pas op het eind op en rond dan af. Alle tussenvormen leveren altijd verschil op.

Hoewel ik in combinatie met PHP niet erg veel hierover kon vinden, is er toch nog wel wat te vinden met google. Verdiep je er eens in

Op Wisfaq.nl kon ik wel nog een nederlandstalig artikel hierover vinden.

offtopic:
@ flat : Mijn icoon ja

[ Voor 28% gewijzigd door RobIII op 22-06-2004 03:28 ]

[slm]

NMe84 schreef op 21 juni 2004 @ 22:54:
[...]

Een ondernemer mag niet besparen op de manier van BTW rekenen... BTW = belasting -> gaat naar de overheid. Dit moet geen inkomstenbron zijn voor de verkoper, en is volgens mij zelfs onwettig wanneer het verkeerd berekend wordt.

Bij belastingen is het normaal dat je decimalen naar beneden afrondt (in jouw voordeel en niet die van de belastingdienst).

[RwD]

RobIII schreef op 21 juni 2004 @ 23:57:
Ik denk dat er gebruik wordt gemaakt van Bankers Rounding. Dit is een redelijk veelvoorkomende vraag op rounding in de meeste programmeertalen. Dat verklaart waarom 7.775 wordt afgerond naar 7.78 (naar boven) en 7.765 wordt afgerond naar 7.76 (naar beneden)

87,875 werd afgerond naar 87,78.
En dat was ook het probleem.....

[Icheb]

RwD schreef op 22 juni 2004 @ 10:15:
[...]

87,875 werd afgerond naar 87,78.
En dat was ook het probleem.....

Dat klopt inderdaad.

Ik heb even hier zitten proberen, Zend Optimizer staat inmiddels uit, maar nog steeds hetzelfde resultaat.
Persoonlijk denk ik nu dat het of inderdaad in PHP een probleem, een probleem in ClientExec of in pdflib is.

Met BC Math kom ik er ook niet uit, aangezien een bepaalde functie verkeerde waarden teruggeeft... bcmul() geeft 0.00 als waarde terug van die keersom, terwijl dit toch echt niet klopt... (Ik ga daar nog even mee experimenteren hier)

Alleen het oplossen ervan wordt erg leuk.

Dit moet geen inkomstenbron zijn voor de verkoper, en is volgens mij zelfs onwettig wanneer het verkeerd berekend wordt.

Heerlijk zeg, ik overhandig de broncode anders wel aan de belastingdienst, om te laten zien dat de formules wel goed zijn .

offtopic:
P&W ging toch over scripting, toch niet over BTW berekeningen op zich ?

[Banpei]

Misschien een heel erg domme vraag:
reken je toevallig ook het getal uit met de komma in het getal?

Als je namelijk de komma in het getal laat staan geeft ie idd bij mij ,78 en als ik er een punt van maak (zoals het in ieder programmeertaal hoort!) maakt ie er netjes ,88 van.

Edit: zal dan waarschijnlijk aan het parsen van een getal uit een string te maken hebben.

Edit2: Idd het parsen van een getal:

PHP:

$tSubTotal = "462,50";
echo floatval($tSubTotal)."<br>";
$tSubTotal = "462.50";
echo floatval($tSubTotal)."<br>";

Als je 462 * 0,19 doet kom je idd uit op 87,78 en niet op 87,88.

[ Voor 39% gewijzigd door Banpei op 22-06-2004 16:23 ]

[Icheb]

Banpei schreef op 22 juni 2004 @ 16:14:
Misschien een heel erg domme vraag:
reken je toevallig ook het getal uit met de komma in het getal?

Als je namelijk de komma in het getal laat staan geeft ie idd bij mij ,78 en als ik er een punt van maak (zoals het in ieder programmeertaal hoort!) maakt ie er netjes ,88 van.

Edit: zal dan waarschijnlijk aan het parsen van een getal uit een string te maken hebben.

Edit2: Idd het parsen van een getal:

PHP:

$tSubTotal = "462,50";
echo floatval($tSubTotal)."<br>";
$tSubTotal = "462.50";
echo floatval($tSubTotal)."<br>";

Als je 462 * 0,19 doet kom je idd uit op 87,78 en niet op 87,88.

Absoluut geen domme vraag, want ik heb geen idee hoe dit programma het precies doorgeeft. Nu heb ik de results eens allemaal in een test pdf laten "echo'en", en je hebt volkomen gelijk.
Op een bepaald moment bij het uit het beveiligde deel halen van gegevens (dus daarbij kan ik niet zien wat er gebeurt) komt er een comma getal uit. Nu heb ik er met wat truukjes een contructie om gebouwd inmiddels die het getal handmatig zelf uitrekent vanuit de db. En nu kan PHP weer afronden

Bedankt voor deze tip.
Dat ik zoiets stoms ben vergeten, de output van dat stuk nakijken op . en ,'s...

[NMe]

Icheb schreef op 22 juni 2004 @ 22:17:
[...]


Absoluut geen domme vraag, want ik heb geen idee hoe dit programma het precies doorgeeft. Nu heb ik de results eens allemaal in een test pdf laten "echo'en", en je hebt volkomen gelijk.
Op een bepaald moment bij het uit het beveiligde deel halen van gegevens (dus daarbij kan ik niet zien wat er gebeurt) komt er een comma getal uit. Nu heb ik er met wat truukjes een contructie om gebouwd inmiddels die het getal handmatig zelf uitrekent vanuit de db. En nu kan PHP weer afronden

Bedankt voor deze tip.
Dat ik zoiets stoms ben vergeten, de output van dat stuk nakijken op . en ,'s...

Als je graag vanuit die pdf wil blijven werken, dan kun je ook gewoon die getallen met komma's ophalen. Als je wat met setlocale speelt mag je geloof ik ook komma's gebruiken als decimaalteken.