Improve currencies

[metasikander]

It would be great to be able to set the currency yourself. I love beansbooks, but its hard to use in norway since i cant set the local currency or any other currency that i would pay or get payed in (like SEK or BTC).
It would also be great to set different currencies for each sale/product/service.

Is this feasible?

[funnylookinhat]

Hi @metasikander -

Handling multiple currencies is near impossible as the exchange rates for those change each day. Realistically, businesses work and report within a single currency - if they're accepting payments in another currency they will usually convert it over on the day of the transaction and record it in their working currency.

We're working on improving currency support ( to include non-decimal currencies and to broaden the number of currencies that are frequently used ). We'll make sure to add SEK to the list.

BTC is a bit more difficult to implement as you can have an exceedingly higher precision in your decimals ( i.e. BTC 0.19512 is a value that can be traded ) - and our reports and database are all designed to presume two decimals at maximum.

[metasikander]

NOK and DKK would be great to, so all of scandinavia is represented :)

I see. That is too bad. And it might not be practical to count in satoshis?

[funnylookinhat]

Ah - I'm not that familiar with BTC and didn't know about Satoshis.

From: http://bitcoin.stackexchange.com/questions/114/what-is-a-satoshi

A Satoshi is the smallest fraction of a Bitcoin that can currently be sent: 0.00000001 BTC, that is, a hundredth of a millionth BTC. In the future, however, the protocol may be updated to allow further subdivisions, should they be needed.

So - BTC could technically be implemented on that scale - but my concern is that they state "the protocol may be updated to allow further subdivisions." I suppose support could be built around some smaller unit than that - but I wouldn't be the one to determine where that should be. :)

[metasikander]

shure. but it might be a while before that happens.
and you could maybe make a script that converted the current value for a satoshi to whatever it will be in the future, by adding zeros to every current satoshi in the database?

[cdp1337]

@funnylookinhat , I have another instance where the 2-decimal point precision is biting me in the a.. Products that are purchased in bulk, such as resistors. Their price is often times > $0.01, so precision above 2 is required for me.

As a side-note, (as usual with features I end up needing out of this product), I'm going to see what I can do about adding support for 4-digit precision in my fork of the project. I'll report back if I have any success.

[cdp1337]

OK, short answer, it is possible :)

Slightly longer answer: eVAL-Agency@9c85927

This isn't implemented throughout the system, just more of a proof of concept, (although it does seem to be working on expenses).

[MrJamesEllis]

FWIW The ECB has a fairly good list of major currencies accessible in XML format, if required for on-the-fly exchange rate estimates:

http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml

[funnylookinhat]

@cdp1337 Yeah - so the change would have to move everything to start tracking to the fourth decimal point throughout the system ( inputs, reports, etc. ) - which could take quite a bit of time to tweak ( esp. with the CSS ).

Would you round actual dollar-values up when paying bills? You can't cut a check for $0.001 - but it could be a value. Does that value round up or down? Do different vendors have different rules?

I think the broad goal should be to get BeansBooks code completely off DECIMAL/FLOAT types. That would solve a lot of the need to call $this->_beans_round($value) over and over again in the code. It would also allow the code to scale between varying points of accuracy for different companies and currencies more easily.

[cdp1337]

You're correct, you can't cash a check for $0.001. My use case of the precision change was sometimes we buy tiny pieces in bulk of 100. Each piece is cost $0.005, which when multiplied up leaves a line total of $0.50. All line totals in my commit still have 2-point precision; just the individual quantity allows for 4-point. I still wanted to record that we ordered 100 pieces so our inventory software has the correct stock qty, [ ooh yeah, we're building that too ;) ]

---

True, I know Stripe does all calculations in cents, (which wouldn't entirely fix my issue, but...). That could also be a solution for BTC/LTC, where the lowest point value is considered 1, and the system can recognize that if [input < 0.00001 ], display in BTC instead of Satoshi. (Yeah, this starts getting into a REAL pain because we'd need dedicated currency formatters for each different currency supported. Then the issue of what happens when the algorithm dictates that the precision of the currency be increased due to inflation in 20 years.... blegh :/

BUT yeah, ditching the precision altogether is something I did with another project that I helped develop; where all input values are round( *100), and then /100 before the output is returned.

[cdp1337]

As an amendment to my previous comment about how Stripe handles currencies, a quote from their API:

A positive integer in the smallest currency unit (e.g 100 cents to charge $1.00, or 1 to charge ¥1, a 0-decimal currency) representing how much to charge the card...