Built in datatype for handling money values?

[OvermindDL1]

@CharlesO

If you are responsible for a system that will only ever have 2 decimal point numbers and the operations involved are simply addition, subtraction , hardly ever multiplication or division, I still feel there might be some simplifications that may be obtained by not taking on a dependency.

Except it is way trivial to accidentally handle, say, a remainder on a division then, that’s the major issue.

You should never use a basic number as a money type, ever ever I would assert.

Whether you use ex_money or make your own, never allow the base monetary value to be altered directly.

@mudasobwa

One should not try to build malformed partial implementations in any case, but even if all the currencies were having 2 decimals, the money unlike numbers require an ability to split 0.33 into two shares, than join them back and get 0.33 . Otherwise the first audit would dismiss the whole business. That is impossible without very careful implementation, that is IMHO harder than anything else in the field.

+1

[CharlesO]

I have since written this project using Decimal Library …, I just shake my head when i look at the source… it really looks like over-kill

I get where you are coming from, what happens if we have > 2-decimals for ANY reason … for example splitting 0.33

[Qqwy]

I agree with what other people have already said. The problem with a concept like ‘money’ is that it is a very vague one: What exactly you need really depends on your application:

• Do you need to handle multiple currencies, or only one currency?
• What rules for decimal places and rounding (half up, half even?) do these currency(/ies) follow?
• What kind of operations make sense for your domain? Usually it is non-sensical to multiply two monetary values together, but maybe it’s not in your domain?
• If your domain is about accruing small rewards over a long period of time, you very well might need more decimals inside your calculations before converting to a result with less precision at the very end.

If I’d find myself in this situation, I would probably create a custom struct wrapping a fixed-point number, and indeed implemented Numbers’ add, sub abs and to_float, as well as mult and div where one of the two operands (in the div case: the divisor) is expected to be an integer or float; passing two money-values to these will raise.

[OvermindDL1]

@Qqwy

What rules for decimal places and rounding (half up, half even?) do these currency(/ies) follow?

You don’t round money, you get back a result of the operation and the leftovers so you have to handle them somehow. This is one of the big no-no’s of money systems. You Don’t Round Money.

[CharlesO]

@OvermindDL1

You Don’t Round Money.

So how do you split 0.33 two ways and record that in a system that has cents (2-decimal) as its smallest REAL currency?

[samgranieri]

Just use cents or the smallest currency item as an integer and go from there.

So, store $10.50 in your db as 1050.

[OvermindDL1]

@CharlesO

So how do you split 0.33 two ways and record that in a system that has cents (2-decimal) as its smallest REAL currency?

Say you want to divide it in half, then your only option is to return two 0.16’s and 1 0.01. Then you’d probably just add the 0.01 to one of them to make it 0.16 and 0.17, or put it somewhere else.

@samgranieri

Just use cents or the smallest currency item as an integer and go from there.

So, store $10.50 in your db as 1050.

Yeah I’d always store it as an integer of the smallest representable monetary amount too.

[kip]

Money is complicated. Splitting an amount of money is a good case. And indeed there are cases for rounding as well.

1. The current exchange rate today for USD -> JPY is 111.869. I have USD 24.39 and when converted I end up with JPY 2728.9971

2. This is a totally valid accounting value (I understand most fintech systems require at least 7 digits of precision but I can’t site a reference for that). But of course eventually we have to put an amount in a customer account that is a settlement value that is a cash amount. Rounding JPY means no decimal digits so the result would be (using the default “half-even” or “bankers rounding” is JPY 2729.

3. Online services can charge at fractional cents. For example AWS charges $0.192 per Hour for a m5.xlarge instance. Rounding is required prior to billing

4. Splitting definitely has its own challenges. Splitting a money amount and rounding to the appropriate digits for a currency can leave a balance that shouldn’t be lost. I treat this in ex_money by returning the split amount and the remainder:

iex> Money.split(Money.new!(:USD, "12.43"), 3)
{#Money<:USD, 4.14>, #Money<:USD, 0.01>}

In short, there are valid reasons why a money amount may have more precision that the currency’s definition since intermediate results can create such scenarios. Currency conversion is one good example, interest rate calculations is another, stock trading another one. Eventually to settle accounts rounding will be required and management of the remainder will then also become important.

[mudasobwa]

@OvermindDL1

Yeah I’d always store it as an integer of the smallest representable monetary amount too.

Except that 20 years ago the maximal number of decimals was 5 and now (thanks to ₿) it’s 8. I could not imagine the horror uglier than updating the existing codebase to support bitcoins now.

[OvermindDL1]

@mudasobwa

I could not imagine the horror uglier than updating the existing codebase to support bitcoins now.

Each monetary value would have a different base amount regardless when storing it in a database, just shift the decimal to equal the base-most amount that can reasonably be handled, which I’d put at a lot more than 8 for bitcoin all things considering.