More decimal places needed in part price

[pfranquesa]

Two decimal places for unit price are not enough (Ex. 0,003 EUR for 0603 SMT resistor)

[Drachenkaetzchen]

Very good point. I have no good idea how to solve this, I don't think that simply extending the decimal places to 3 decimals is the way to go - especially with all the different currencies out there.

Do you have any idea how to solve this in a generic matter?

[pfranquesa]

Maybe a global preference or a user preference defaulting to 3 ? Then, when defining the "numberfield" add the attribute "decimalPrecision : 3" or whatever defined in the user or global preference. Anyway 3 (maybe 4 if you are averaging stock price) decimals are a must when working with cheap parts almost in every "popular" currency, as this small numbers are usually a fraction of the corresponding monetary unit.

[scrupeus]

Storage needs to be expanded from the current DECIMAL(5,2) to DECIMAL(12,4) or similar. Some currencies will have parts costing in the millions, while, as per the OP, it is common for parts to require more than 2 decimals in many currencies. Note: Apparently some languages have problems with an odd number of decimal places (Delphi 7 being one I saw mentioned), so it would be best to use 4 or 6 decimals in the database.

Otherwise, just use double. It's unlikely anyone needs their stock value to more precision than provided by double. 32-bit float can be a problem summing a lot of low-price items, e.g. 15000 resistors at 0.0012 each, but double should be okay for users of PartKeepr.

Regardless of the backend storage, a user preference should be provided to set the display format.

[Drachenkaetzchen]

I'm not a very big fan of floating point values, decimal in the database is just fine (something like 12,4 or even more).

An example why floating point won't be the way to go: Simply paste the following line in your browser.

javascript:{{alert(0.1+0.2);}}

Here's a discussion regarding decimals in JavaScript: http://stackoverflow.com/questions/3454965/javascript-decimal-values

As decimal(12,4) means that we can store a maximum of 99999999.9999 - which would yield in a maximum of 999999999999 when we agree not to use floating point, but whole numbers and adjust the precision on these.

I admit that I haven't got too much experience with floats - probably we can also use toFixed() in combination with the user setting:

javascript:{{alert((0.1+0.2).toFixed(4));}}

[Drachenkaetzchen]

This should be fixed now. I've added the new CurrencyField as well as the new currency formatter, while scrupeus has increased the decumal range. Aside from a probably missed currency field somewhere, this should now be done.

[tenaciousRas]

Why would decimal place support be defined at the user-level? What happens if two users with different settings edit the same product at different times? Does the team or business using PartKeepr suddenly experience mysterious rounding errors or differing quotes/estimates depending on who generates a report? This feature should be system-wide or defined at a higher level (than that of 'user'). My installation only has two decimal places. Did the CurrencyField addition fix this and if so is it there for me already, or do I need to do something special to use it?

[tenaciousRas]

wait...how am I supposed to use currency field?

wait...Partkeepr should store the whole price, up to 6 decimals places (!), and do no rounding when the data is entered. This discussion about how many decimal places is only with respect to the cost displayed on the screen after entry, not the one stored in the database, right?!

[Drachenkaetzchen]

PartKeepr stores the whole price. Calculations are done with maximum precision. Only the final, displayed values are formatted - that's why there's a formatter.

[tenaciousRas]

Great! I hadn't checked the raw data to be sure.