Using non-ISO 4217 currencies

Does anybody use currencies that are not included in ISO 4217 and, therefore, not available through the java.util.Currency class?
We are looking into removing the hard-coded 2-digit rounding moqui is doing for calculating OrderPart and OrderHeader totals, for which we would use the formatCurrency methods of the L10nFacade.
However, this would result in an IllegalArgumentException when using any currency that is not available in the java.util.Currency class. This would happen
While we could add the currencies at the JVM level, we are considering the solution of adding the capability of registering new currencies at the L10nFacade, specifying aspects such as the symbol, fraction digits and others that are normally available throught the java.util.Currency class. Would this make sense to anybody else?
I see there is a BTC currency definition which would have the same issues we are facing now.

The problem we are facing is that in Chile we seem to be very creative when it comes to currencies. We do have 2 currencies (really one currency, CLP, and one fund code, CLF) that are included in the ISO 4217 definition, but we need to add two more that are regularly used in contracts and orders. They are translated into CLP when issuing an invoice, but need to be handled in orders and workEffort costs.

1 Like

It might be interesting to use the moqui.basic.Uom entity instead of the java.util.Currency class, adding fields as needed (like decimal digits and symbol) to handle output formatting and perhaps elsewhere too. Is that what you had in mind, and is that something you have already started working on?

1 Like

Yes, I do have a working solution but it would be nice to extend it to a general solution. Adding the symbol and decimal digits in Uom or in a currency-specific entity with uomId as PK would allow us to manage any currency, and if this is not defined, we would fall back to either the java.util.Currency definition if available or a default.

What we would also need in moqui would be a method in L10nFacade and an attribute like ‘hide-symbol’ in the screen’s display tag to use along with the currency-unit-field attribute to not display the currency symbol. This would allow us to replace the hard-coded format ‘#,##0.00’ used in screens to format currency values to a currency-dependent format. This, because the ‘#,##0.00’ format used for currency amounts is essentially the format for en_US Locale and USD currency but without clogging the screen with the currency symbol in every field.
I could prepare a merge request implementing this.

1 Like

It would be very helpful to have a better general pattern for currency amount output with no currency symbol, though on most screens having a symbol wouldn’t be a bad thing (though on some reports and screens with more dense data the currency symbol does make it more difficult to read).

IMO would be best to just add fields to the Uom entity, no need for a separate entity and the overhead and inconvenience it would add. Uom doesn’t have a lot of fields, not a very wide table, and it’s a config table so relatively few rows too.

I like the idea of falling back to java.util.Currency if no Uom currency record is found, will save us considerable effort in adding and maintaining currency data we don’t care so much about or where Java defaults are adequate, while supporting override with a database record.

Thanks for your effort on this, will be a considerable improvement for localization.

1 Like

I’m surprised that’s not how it already works. This change would be great. Jens if you want help or a review of the PR just send me a message or get in touch.

There is a pull request available for review, including changes for moqui-framework (Currency by jenshp · Pull Request #614 · moqui/moqui-framework · GitHub), moqui-runtime (Currency by jenshp · Pull Request #217 · moqui/moqui-runtime · GitHub) and mantle-usl (Currency by jenshp · Pull Request #199 · moqui/mantle-usl · GitHub).

This adds some fields to moqui.basic.Uom which enables defining custom currencies not available in java.util.Currency or to override symbol and amount of digits to use for rounding and formatting. Also adds an attribute to the display tag so in screens a numeric value can be formatted according to currency + locale settings without the currency symbol.
The symbol field in moqui.basic.Uom is set to be localizable to enable the possibility to use different symbols according to the locale (as with java.util.Currency), for e.g. use the currency code instead of currency symbol according to the locale.

1 Like

Awesome work, exactly what we needed, thank you @jenshp and everyone for looking into this

1 Like

Hello everyone. In the following recent commit Currency by jenshp · Pull Request #199 · moqui/mantle-usl · GitHub there was a new line introduced to get the currencyUomId from orderHeader (which is supposed to hold order header info) but it wasn’t queried in the first place; and because of that we are getting a null pointer exception every time mantle.order.OrderServices.update#OrderPartTotal service runs. This’s the exception…

Error running groovy script (java.lang.NullPointerException: Cannot get property 'currencyUomId' on null object): 

I hope that was clear. It is apprenticed if this issue is looked into and fixed, thank you.

1 Like

This appears to happen when the currencyUomId for the OrderHeader is not defined, I will submit a fix to assume ‘USD’ in that case.

Thanks for addressing the issue @jenshp … but if you look at the service, it doesn’t even query orderHeader to get its currencyUomId, so even if you set the currencyUomId on the order, it will never get it unless the order is queried

1 Like

You are right, there was a missing line in the commit, sorry about that!

1 Like

Pull request at Currency by jenshp · Pull Request #200 · moqui/mantle-usl · GitHub with the fix.

1 Like

Thanks @jenshp!

1 Like