berekend veld geeft veel te veel decimalen, hoewel ingesteld op 2 decimalen

[hoingkatleen]

Bekijk bijlage BIJSCHOLING.zip

Hoi,
maar meteen de dbase toegevoegd want het zal m in de details zitten vermoed ik.
Dus: open het formulier. Vul bvb in CBBDIR en voer query uit.
Het gaat om het laatste veld. Als er in 'prijs per medewerker' iets achter de komma staat, dan wordt mijn prijsberekening een erg lang getal.
Wat zie ik over het hoofd?

Alvast dank!

 

[hoingkatleen]

ah, na nog wat googelen iets gevonden: in tabel bijwonen cursus heb ik nu veld 'prijs per medewerker' ingesteld als valuta. Nu heb ik het probleem niet meer.

Hm, te vroeg gejuicht. Het werkt enkel als %budgetcode 1 is. Als ik 'prijs per medewerker' vermenigvuldig met een kommagetal, resulteert dit nog steeds in teveel digits na komma :-(

 

[hoingkatleen]

ah, berekend veld in query ook op valuta gezet. problem solved! Bedankt aan mezelf en sorry om jullie ermee te belasten; Ik laat het maar staan voor andere mensen die zich dezelfde vragen stellen :-D.

 

[OctaFish]

Als je met decimalen gaat werken, en je berekening gaat daardoor de teil in (goed overigens dat je zelf al hebt uitgevogeld dat je geldbedragen altijd als valuta moet gebruiken ) dan moet je ook in je berekening al een afronding meenemen. Dan krijg je dus dit:

Prijsberekening: IIf([BUDGETCODE1]=[Formulieren]![Invulformulier budgetcode voor stavaza budget]![Keuzelijst8];Round([%BUDGETCODE1]*[Bijwonen Cursus]![PRIJS PER MEDEWERKER];2);
IIf([BUDGETCODE2]=[Formulieren]![Invulformulier budgetcode voor stavaza budget]![Keuzelijst8];Round([%BUDGETCODE2]*[Bijwonen Cursus]![PRIJS PER MEDEWERKER];2);"probleem"))

En ik zou het veld [Prijsberekening] dan ook opmaken als EURO.

 

[hoingkatleen]

OctaFish, is het niet raar om iets af te ronden voor je er verdere berekeningen mee maakt?
Mijn leraar wiskunde trok ons punten af vroeger als we dat deden .

Mijn probleem leek opgelost door die valuta-instellingen. Voorzie jij dat er toch nog onjuistheden zouden opduiken als ik je afrondingssuggestie niet zou toepassen? Of waarom moet dat nog toegevoegd worden?

 

[OctaFish]

Je rondt niet af voordat je de berekening maakt: Round([%BUDGETCODE1]*[Bijwonen Cursus]![PRIJS PER MEDEWERKER];2). Je wiskundeleraar heeft je vast verteld dat berekeningen altijd van binnen naar buiten worden uitgevoerd, dus eerst krijg je de berekening [%BUDGETCODE1]*[Bijwonen Cursus]![PRIJS PER MEDEWERKER] en daarna wordt het resultaat afgerond. Een veld op Valuta zetten bij de veldeigenschappen is op zich prima omdat het veld zelf dan de juiste decimalen krijgt, en omdat je Enkele precisie had ingesteld kreeg je dus soms een hele rare waarde te zien. Daar ben je vanaf met een Valutaveld. Alleen de notatie van een veld aanpassen doet niks (nuttigs) omdat je daarmee alleen het uiterlijk van een veld verandert, niet de inhoud. Je ziet in dat geval dus iets anders als dat er staat. Een doorgaans onwenselijke situatie, zeker in een database of een spreadsheet.

Berekeningen kunnen natuurlijk zelf ook weer worden gebruikt in een vervolgberekening. Het is maar de vraag of en wanneer je dan moet afronden. Een artikel waar je korting op krijgt levert een andere prijs op dan als je op een artikel geen korting krijgt. In beide gevallen rolt er een prijs uit, en in beide gevallen moet er daarna bijvoorbeeld BTW worden berekend. Je krijgt andere bedragen als je de prijs met korting afrondt, vervolgens de BTW berekent en dat bedrag ook weer afrondt t.o.v. prijs met korting berekenen, vervolgens de BTW berekenen en dat bedrag dan als laatste afronden. Wat is wijsheid? Geen idee; ik ben geen boekhouder .

 

[hoingkatleen]

Ahja, je rondt het nadien af, had ik niet goed gezien.

Of het onwenselijk is dat het uiterlijk van het veld verandert en niet de inhoud, daar ben ik niet over uit.
Als ik bvb een bedrag krijg met veel digits na de komma, dan is het goed dat ik er maar 2 zie als ik een betaling wil uitvoeren. Maar als er nadien verder iets berekend moet worden, dan heb ik toch graag dat het volledige getal nog voorhanden is om dat te gaan doen om afrondingsfouten te voorkomen.

Wat ik vooral gek vond, was dat ik na de komma allerlei getalletjes kreeg die gewoon fout waren. Maar dat lag dan eerder aan de enkele precisie vs valuta he?