Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 3 Jahren, 1 Monat
Letzter Beitrag:
vor 3 Jahren, 1 Monat
Beteiligte Autoren:
Allard, Fabrice Harari, Steven Sitas

4 decimals instead of two in the hyperfile db ( wd 18 )

Startbeitrag von Allard am 07.01.2015 22:18


I have some odd behavior. When I save a record form a table then it sometimes gets saved with 4 digets instead of 2 as it should have . In the table the number has two digets ( currency format , table has mask defined by project)

Ok, when saving the table a lot happens the rows are saved in several tables. Sometimes some calculations are done as well.
For instance if costs are added , specific leger functions specify if vat is to be calculated. Several vat percentages can apply. If Vat does apply a row is added with the calculated amout. For variables in the code I use the currencytype

Should I use integer- or real- for variables instead of the currency type?

It is verry irritating for now my checks ( to see if debet is equal to credit ) fire a fault because
for instance 72,52 is not equal to 72,5189

In the analysis I stated that currency has two digits. In the code I made the variables of the currency type.

My program is an accounting system. It has complete integration of ledger and accoutreceiveble etc. so this is a real showstopper.

Has any of you had this odd behavior or know a solution?




Hi Allard,
what you are seeing is absolutely NORMAL.
The Currency type has ALWAYS a 6 decimal part - just to avoid (common) rounding errors.
Don't confuse this with the mask (display or input) in your Analysis.

So calculations that involve Currency and say Reals or Integers will be done with 6 decimal rounding. Of course depending on where you assign the calculation this COULD end up with say 0 (Zero) decimals, but I think you get the idea.

So you MUST use the Round function to make sure your currency calculations are valid.

Here is a paradigm: (unitprice, quantity, Amount are all of currency type)
unitprice =0.123456 (6 decimals)
quantity = 100000 (0 decimals)
Amount = Round(unitprice * quantity,2)

Although the euro has 2 decimal parts and you cannot sell something for 0.123456 euros, it is absolutely VALID to sell 100000 quantities for 0.123456 euros each.

3 other IMPORTANT things with Accounting:

a) the currency type is a REAL code on 10 bytes (17/6)
b) If you are doing a multiple currency application, there maybe currencies with less (or more) rounding at the END.
c) if you are doing VAT calculations ALWAYS do them at the TOTALs of say the invoice and NOT at each line of the invoice

Steven Sitas

von Steven Sitas - am 08.01.2015 08:37
Hi Allard

To complete Steven message...

You should NEVER use REALs... REAL have a built in flaw that makes them completely unusable for any program where accuracy is important. They cannot record ALL the possible values (by example, 1.2356 could be recorded as 1.2355 instead)...

So stick either with currencies or numerics.

In any cases, I concur with Steven in that this behavior is absolutely normal and that YOU are in charge of rounding where and when it is needed (ie after each and any calculations)

Best regards

von Fabrice Harari - am 08.01.2015 08:42

Thanks Indeed a stupit question. when I read this posting I found out myself that it had to do with the vat calculation. I use indeed the round on the calculation and specify 2 decimals.

Thanks for the rapid response . Yesterday I was strugling with this and this morning I saw the light , Ha ha .

Steven, Yes For invoices I do the vat calc for the total. My issue was when booking an incomming invoice, in invoice from a supplier.



von Allard - am 08.01.2015 09:59
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.