Currency configuration

Technical Committee
#1

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
jkondrat@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

#2

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ł

···

On Tuesday, May 9, 2017 at 4:03:55 PM UTC+2, jkon...@soldevelo.com wrote:

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

#3

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

···

On Tue, May 9, 2017 at 7:38 AM, Paweł Albecki gidgnulur@gmail.com wrote:

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ł

On Tuesday, May 9, 2017 at 4:03:55 PM UTC+2, jkon...@soldevelo.com wrote:

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

–

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 openlmis-dev@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
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

#4

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ł

···

On Tuesday, May 9, 2017 at 6:48:39 PM UTC+2, djazayer wrote:

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

On Tue, May 9, 2017 at 7:38 AM, Paweł Albecki gidg...@gmail.com wrote:

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ł

On Tuesday, May 9, 2017 at 4:03:55 PM UTC+2, jkon...@soldevelo.com wrote:

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

–

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.

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
Email
djaz...@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

#5

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.

···

From: openlmis-dev@googlegroups.com on behalf of Paweł Albecki gidgnulur@gmail.com

Date: Tuesday, May 9, 2017 at 10:09 AM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Cc: “gidgnulur@gmail.com” gidgnulur@gmail.com

Subject: Re: [openlmis-dev] Re: Currency configuration

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ł

On Tuesday, May 9, 2017 at 6:48:39 PM UTC+2, djazayer wrote:

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

On Tue, May 9, 2017 at 7:38 AM, Paweł Albecki > > gidg...@gmail.com wrote:

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ł

On Tuesday, May 9, 2017 at 4:03:55 PM UTC+2, jkon...@soldevelo.com wrote:

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

–

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.

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
Email
djaz...@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

–

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
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/2a350680-0b9a-4b47-9d0f-095a6432d60b%40googlegroups.com.

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

#6

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.reid@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: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of jkondrat@soldevelo.com jkondrat@soldevelo.com

Sent: Tuesday, May 9, 2017 7:03:55 AM

To: OpenLMIS Dev

Subject: [openlmis-dev] Currency configuration

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

jkondrat@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

–

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
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/41987b86-67d1-4ecf-acd6-f9ca15e50ad3%40googlegroups.com.

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

#7

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

···

Nick Reid | nick.reid@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:
openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of jkondrat@soldevelo.com jkondrat@soldevelo.com

Sent: Tuesday, May 9, 2017 7:03:55 AM

To: OpenLMIS Dev

Subject: [openlmis-dev] Currency configuration

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

jkondrat@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

–

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
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/41987b86-67d1-4ecf-acd6-f9ca15e50ad3%40googlegroups.com.

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

openlmis-dev+unsubscribe@googlegroups.com

openlmis-dev@googlegroups.com

https://groups.google.com/d/msgid/openlmis-dev/MWHPR02MB322930B24259214065F88F8E94EF0%40MWHPR02MB3229.namprd02.prod.outlook.com
https://groups.google.com/d/optout

#8

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

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.

#9

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.reid@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: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

Sent: Wednesday, May 10, 2017 10:10:05 PM

To: OpenLMIS Dev

Subject: Re: [openlmis-dev] Currency configuration

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

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.

–

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
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/8C2F0F17-BDE2-4AC9-B5FC-CDF70FA63851%40villagereach.org.

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