Ga naar inhoud
  • 0

Ingave veld met decimalen


fvlo

Vraag

Hallo, ik heb een ingaveveld in een SQL-tabel (via ODBC) wat in SQL gedefinieerd is als decimal met 4 decimalen.

Ik heb dit veld in een layout opgenomen met in de tag 'Data formatting' 'Format' = 'Decimal' en property 'Fixed Decimal' aangevinkt en ingesteld op 2.

De display van dit veld werkt zoals gewenst. Echter bij ingave laat hij de 4 decimalen zien.

Is dit te wijzigen binnen FM?

Link naar reactie

7 antwoorden op deze vraag

Aanbevolen berichten

  • 0

Ik begrijp je vraag, terwijl die eigenlijk vreemd is.

 

Immers, wanneer je bij het invoeren meer dan 2 decimalen invoert is het logisch dat je op dat moment ook meer dan 2 decimalen te zien krijgt.

Wil je voorkomen dat er meer dan 2 decimalen ingevoerd kunnen worden dan moet je dat regelen met b.v. de validatie van het veld. Helaas wordt een veld normaal gesproken pas gevalideerd nadat het is ingegeven, dus ook dan zul je meer decimalen zien dan is toegestaan, totdat je het veld wilt verlaten. Dan kun je een foutmelding laten zien en het doorvoeren van de ingegeven waarde blokkeren.

 

Wanneer je tijdens het invoeren de extra decimalen wilt blokkeren zul je dat moeten oplossen met een scripttrigger die na elke ingave van een teken het getal controleert en zonodig blokkeert. Een correcte trigger hiervoor maken zal nog niet meevallen, denk b.v. maar aan het correct verwerken van pijltjes toetsen of de backspace e.d.

 

Het vreemde aan jouw vraag is dus dat je niet wilt dat er meer dan twee decimalen worden ingevoerd, terwijl deze al zijn ingevoerd.

 

Een oplossing waar je misschien wat aan hebt is om een extra veld toe te voegen dat automatisch gevuld wordt met het getal met slechts 2 decimalen. Dit definieer je dan in het auto-enter gedeelte van de velddefinitie middels een calculation of look-up. Wanneer je dat veld weer in je SQL tabel wilt hebben zul je dat middels een script trigger (b.v. op de validatie) in het betreffende veld moeten overnemen. Best ingewikkeld allemaal en daardoor foutgevoelig.

 

Een andere benadering is om een script trigger te maken die wordt afgevuurd wanneer je het veld ingaat en dan de waarde naar 2 decimalen zet. Je past dan dus wel de waarde van het veld in de SQL tabel aan. Wanneer dat geen probleem is zou ik denken dat je dan net zo goed vooraf in heel de SQL tabel die waardes zou kunnen aanpassen waardoor heel dit probleem niet speelt. Eventueel via overgang naar een tweede automatisch ingevuld veld.

 

Persoonlijk zou ik al deze moeite niet gauw doen. Uiteindelijk gaat het om de presentatie van de getalletjes en die heb je met de data formatting al prima geregeld.

Link naar reactie
  • 0

Die weergave van 4 decimalen is de wijze waarop het getal in SQL-database is opgeslagen. De weergave-eigenschappen in FileMaker zijn slechts wat de naam zegt.

 

Invoer is een andere toestand dan weergave. en activeer je het veld, dan zie je alleen wat er in is opgeslagen en een trigger zal je niks helpen, je moet het datatype in de SQL-tabel wijzigen.

 

Het algemene commando dat je in de database kan geven is:

ALTER TABLE table_name
ALTER COLUMN column_name NUMERIC(p,s)

waarin "p" de maximale mantisse van het getal is (de maximale lengte inclusief de decimalen, zonder de decimaalpunt)

waarin "s" het aantal decimalen (van de mantisse)

 

Je gebruikt ESS én je hebt schrijftoegang, dus misschien heb je ook wijzigingsrechten op de structuur (is een apart privilege) en dan kan je dit commando uitvoeren met de sciptstap "Execute SQL" (niet te verwarren met de calculatiefuntie "ExecuteSQL()") via dezelfde DSN waarmee je ESS gebruikt.

Link naar reactie
  • 0

Dank Menno.

Ik kan met een redelijk eenvoudig script van alle decimale velden de scale wijzigen. De reden waarom ik dat liever niet wil is dat onderhuids meer cijfers achter de komma wil, tbv afrondingen.

Ik heb op dit forum opmerkingen gezien mbt de afrondingen die m.i. onjuist zijn.

Vooorbeeld: Kolom A regel E,F,G,H zijn willekeurige bedragen. Kolom B regel E,F,G,H 21% van die bedragen. Kolom C regel E,F,G,H de bedragen van kolom B afgerond op 2 decimalen.

Regel K bevat de totalen van de kolommen.

Regel L = 169,19 * 21%

Regel M = bedrag van regel L afgerond op 2 decimalen.

Je ziet dat het resultaat in cel K-C 1 cent minder is dan het resultaat op regel M.

A B C

 

E 100,2 21,042 21,04

F 8,44 1,7724 1,77

G 6,3 0 1,323 1,32

H 54,25 11,3925 11,39

 

K 169,19 35,5299 35,52

L 35,5299

M 35,53

 

Voor de eenvoud wil ik dus elk bedragveld in SQL 4 decimalen houden.

Voor de duidelijkheid nog een voorbeeld van mijn probleem: veld XYZ bevat 26,0000. In FM wordt dit getoond als 26,00 (zoals ik wil). Als ik de waarde wil wijzigen zie je 26,0000.

Link naar reactie
  • 0

Tja over afronden zijn al hele epistels geschreven.

 

Er zijn meerdere manieren en het is maar net wat je wilt en hoe significant een afronding doorwerkt cq hoe groot de afwijking is die je introduceert. Rondt men een bedrag van 100,001 af naar 100 dan is de afwijking 0,001% (1/100000). Is het een bedrag van 1,001 dat wordt afgerond naar 1 dan is de afwijking al 0,1% en is het gedrag 0,011 dat je afrond op 0,01 dan is de afwijking 10%!

 

Anders gezegd: met 2 cijfers achter de komma extra los je het probleem gewoon niet op, je introduceert een slechts 100-voudige reductie van de fout. Je ontkomt niet aan een fout.

 

Ga je zulke bedragen bij elkaar optellen dan vergoot je de fout evenredig.

 

Wat je voor ogen moet houden is hoe groot is je fout nu werkelijk en hoeveel bedragen je bij elkaar gaat tellen. Neem aan de hand van die gegevens en de eisen van je toepassing een beslissing hoe je er mee omgaat.

 

Neem het berekenen van de BTW op een factuur:

de meest nauwkeurige methode is eerst alle aantallen en prijzen met elkaar te vermenigvuldingen, die resultaten per btw-klasse op te tellen, daarna over die bedragen de btw-percentages toe te passen en op te tellen.

 

Is deze methode dan wél nauwkeurig? .... Ook niet dus, want als je het eindresultaat weer wilt opdelen in net netto-bedrag en de btw, dan heb je vaak weer een afwijking (niet bij 10,00 + 2,10, maar zo mooi passen de getallen vaak niet)

 

Ga je ditzelfde nog een stapje verder toepassen en kijken naar bijvoorbeeld alle facturen die je gedurende een jaar aan je klanten hebt gemaakt.... tel ze allemaal op, bereken de BTW die je had moeten afdragen over het hele bedrag en vergelijk dat met wat je bij elkaar opgeteld op de facturen hebt gezet. Die bedragen komen ook niet overeen en 4 cijfers ipv van 2 achter de komma gaan het probleem niet oplossen, maar slechts verminderen.

 

Het geld dat we allemaal kunnen betalen cq via de bank overmaken, werkt ook slechts met 2 cijfers achter de komma. Kortom hoe belangrijk is de nauwkeurigheid voor jouw toepassing? Dat is de vraag die je jezelf moet stellen en als dat voor jou betekent dat je 4 cijfers achter de komma wilt opslaan, dan zal je ze ook moeten noteren (tegen wil en dank) en zal je ze (soms) bij de invoer ook zien :D

Link naar reactie
  • 0

Dank Menno.

Er is overigens wel een manier om foutloos te werken met decimalen:

Als je op elke regel het verschil tussen het bedrag en de afronding optelt bij het volgende bedrag kom je onderaan altijd 100% correct uit.

Maar ik begrijp dat er geen perfecte oplossing is voor mijn probleem.

Link naar reactie
  • 0

Jouw definitie van 100% correct is dan anders dan die van mij.

 

Ik geef je een voorbeeld ter overweging: Je gaat het hele jaar elke dag met de trein naar je werk en je koopt elke dag op dezelfde plek een kopje koffie om mee te nemen voor 2,70 inclusief 6% BTW en het geluk wil dat je BTW over je koffie kan aftrekken. Je vraagt de koffieverkoper daarom om een BTW-factuurtje. Op dat factuurtje komt keurig de BTW te staan van 0,15 en een nettobedrag van 2,55. 8)

 

De vraag is: heb je de goede keuze gemaakt? Hoeveel BTW krijg je aan het einde van het jaar terug? Dat kan je heel simpel uitrekenen door de bedragen met de 250 dagen van het jaar te vermenigvuldigen en dat komt in jouw geval dus op 37,50. Je hebt echter heel veel geld laten liggen want de op de bonnen vermelde BTW is namelijk 250 keer naar beneden afgerond en dat afrondings-verschil loop je dus mis. Het gaat hier bij om een totaal van 675 euro aan koffie en de BTW daarvan is 675x0,06/1,06=38,2075 wordt afgerond naar 38,21 je loopt dus 0,71 euro mis. 8O

 

Je had dus met jouw koffieverkoper moeten afspreken dat je voor het hele jaar één factuur zou krijgen. Jullie waren dan allebei blij geweest, want hij had daadwerkelijk 71 cent meer omzet gehad, jij had dat meer teruggekregen. Verder zou slechts één boeking in de administratie jullie allebei ook nog tijd en dus geld opleveren en die tijd kan je ook weer besteden aan vakantie of nog meer geld verdienen. :D

 

Dit laatste is natuurlijk onzin voor het dagelijkse koffie, de BTW kan je niet aftrekken en je kan hooguit een strippenkaart oid kopen voor die koffie, maar het principe staat wél: uit hoe meer fragmenten een getal is samengesteld, hoe groter de onnauwkeurigheid ervan kan worden.

 

Nu gaat dit voorbeeld over slechts één artikel met altijd dezelfde prijs, maar je kan je voorstellen dat dit ook met hele verschillende prijzen kan en dat dit zowel positief als negatief uitpakt. De verschillen aan het einde zijn echter zo klein, dat ze toch geen significante verschillen opleveren.

 

Bij hele kleine bedragen moet je echter wél gaan opletten: Als je over prijzen praat van 2 cent oid en je berekent dan de BTW van 21% of zelfs 6% over iedere keer slechts 1 artikel, dan wordt de afwijking te groot als je bijvoorbeeld 1000 items los berekent: 0,02 * 0,21/1,21 = 0,0034710743801 dat is afgerond 0,00 en doe je dat 1000 keer dan loopt de fiscus 3,47 mis

 

Anyway dit was ff lekker zemelen over afronden, succes!

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...