Currency configuration

19 views
Skip to first unread message

jkon...@soldevelo.com

unread,
May 9, 2017, 10:03:55 AM5/9/17
to OpenLMIS Dev
Hello everyone!

The Malawi Team were recently trying to change currency in their implementation. It turned out that it is only configurable at compile time as per Nick's comment on OLMIS-1333. The problem here is that we would have to fork the entire Reference Data repository in order to change the currency. Currently, we got around it by changing the UI configuration and keeping ref data as is, but that may not work for every currency and once we have some calculations based on them.

My question is - wouldn't it be better to specify it in the bootstrap data? I can imagine that other implementations will be also facing this problem. I tried fiddling with the code a bit and the biggest problem with this approach is that Joda Money requires us to specify the currency to store it. Currently, the CURRENCY_CODE constant is used in ProgramOrderable to store pricePerPack.

One approach would be to add another column that holds the currency (like I was trying to get it done on currency-config branch). Perhaps writing a custom JPA attribute converter is also possible?

Thanks,
Jakub

-- 

Jakub Kondrat
Software Developer 
jkon...@soldevelo.com

SolDevelo Sp. z o. o. [LLC] 
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41Al. Zwycięstwa 96/9881-451, Gdynia 
http://www.soldevelo.com

Place of registration: Regional Court for the City of GdanskKRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,Share capital: 60,000.00 PLN

Paweł Albecki

unread,
May 9, 2017, 10:38:37 AM5/9/17
to OpenLMIS Dev
The current approach was not well thought out. In addition to ProgramOrderable in Reference Data we specify currency code in Requisition Service for some fields in RequisitionLineItems. I'm not sure if custom JPA attribute converter that will not require to explicitly serve currency code at compile time (to initialize Joda Money objects) is possible to write. The easiest approach will be to store currency code next to money value in database. The other solution I can see is to give up Joda Money and use BigDecimal again since we manually set all currency properties (such as currency symbol, currency grouping separator, decimal places etc.) anyway.

Best,
Paweł

Darius Jazayeri

unread,
May 9, 2017, 12:48:39 PM5/9/17
to Paweł Albecki, OpenLMIS Dev
For sure someone will eventually have the requirement of supporting multiple currencies (e.g. some prices in the local currently, some prices are in Euro or USD). If we're touching this now, we should take an approach that will support an eventual solution to that problem.

-Darius

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/588e0fe8-7066-4318-8355-2e0e0fbaff0b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

Darius JazayeriPrincipal Architect - Global Health
ThoughtWorks

Paweł Albecki

unread,
May 9, 2017, 1:09:11 PM5/9/17
to OpenLMIS Dev, gidg...@gmail.com
You should take a look at this JIRA ticket and comments. At that time we didn't thought we need multiple currencies in one implementation. But if we will right now make changes to store currency code next to money value in database, I think it will be good starting point to support multiple currencies in future.

Paweł
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

Jake Watson

unread,
May 9, 2017, 1:21:25 PM5/9/17
to Paweł Albecki, OpenLMIS Dev
I absolutely agree that there will be an eventual need to support more than one currency — I’ve seen these requirements in many systems, just as Darius points out. (Also, some currencies use more than two decimal places.)

We do not need to go so far as to keep currency/conversion history when we add support for more than one, but we do need a way to at least support localization of one currency now — without forking.

Nick Reid

unread,
May 9, 2017, 3:23:13 PM5/9/17
to jkon...@soldevelo.com, OpenLMIS Dev

Questions:

- Is the issue with the ReferenceData UI or ReferenceData Service??

- Is there a need to change from handling a single currency to multiple currencies?


I'm a fan of loading currency in from bootstrap settings — but I'm not sure the UI should always ping the ReferenceData Service to figure out how to format numbers....


Nick Reid | nick...@villagereach.org
Friendly Neighborhood Spiderman, Information Systems Group


VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org


From: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of jkon...@soldevelo.com <jkon...@soldevelo.com>
Sent: Tuesday, May 9, 2017 7:03:55 AM
To: OpenLMIS Dev
Subject: [openlmis-dev] Currency configuration
 
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.

Josh Zamor

unread,
May 10, 2017, 3:05:05 AM5/10/17
to Nick Reid, jkon...@soldevelo.com, OpenLMIS Dev
When we made the decision to support only a single currency on an implementation the reasoning that I remember was:

* we only really have the need for tracking the cost of an Orderable so that we may sum the price across line items in something like a Requisition, Order, etc.

* we might compare that cost to some budget level. 

* we don't want the responsibility of needing to convert between currencies. It's more work than what the above is trying to provide: a way for budget owners to see how a Requisition or Order will effect their budget . I wouldn't expect multiple currencies to help this here.

Next when we discussed moving to Joda money and supporting a single currency, the idea was that the currency should be set once, at the beginning of an implementation, and that subsequent changes are fine, though without any implicit conversion- so buyer beware. To me this means it should be some setting in the .env file- there's an ISO standard for what the value should be that Joda money supports. This shouldn't be a compile time setting.

What I believe should be done:

* move the currency setting to an environment variable in .env. Use that when serializing/deserializing.

* an endpoint exposes this ISO setting to the UI.

Does that sound right?

Josh

Brandon Bowersox-Johnson

unread,
May 11, 2017, 1:10:09 AM5/11/17
to OpenLMIS Dev

Josh, I have one suggested tweak to your currency proposal below. Instead of an “endpoint that exposes this ISO setting to the UI”, instead we could just provide the ISO setting value along-side any currency value when we return a currency value from any ReferenceData endpoint.

 

There are a few benefits of this:  

-          Consumers of the API do not need to learn to call our special “ISO setting endpoint”, they simply call our existing endpoints and whenever they see a money value the JSON shows them what currency to interpret that money value as.

-          If we ever decide to support multiple currencies (like a different currency setting on a per-program basis), we would not need to change the API signatures at all. We would just add more logic into the API code but the API RAML would not change and API consumers would not need to change.

-          Plus we save an extra HTTP request back-and-forth.

 

Just a thought.

 

Brandon

 

Nick Reid

unread,
May 11, 2017, 2:49:49 AM5/11/17
to Brandon Bowersox-Johnson, OpenLMIS Dev

I'm a fan of passing the currency type along with the currency value


It does make me wonder if the UI/client would then be responsible for storing every possible format (or any expected format) — but this isn't a huge problem, and possibly something that could be set when the client is built.... I'm not sure we want to expose an endpoint that will describe how to format currencies (ie decimal separators vs commas vs cat-gifs)


Nick Reid | nick...@villagereach.org
Friendly Neighborhood Spiderman, Information Systems Group


VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org


From: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Brandon Bowersox-Johnson <brandon.bowe...@villagereach.org>
Sent: Wednesday, May 10, 2017 10:10:05 PM
To: OpenLMIS Dev
Subject: Re: [openlmis-dev] Currency configuration
 
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages