Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009013Openbravo ERP01. General setuppublic2009-05-13 10:322010-07-20 11:45
ReporterRenateNieuwkoop 
Assigned Tormorley 
PrioritynormalSeveritytrivialReproducibilityalways
StatusnewResolutionopen 
PlatformOS5OS Version
Product Version2.50 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0009013: Multi-currency: conversion rates setup
DescriptionWhen using multi-currency, you are required to setup a conversion rate.
I was testing to add a Purchase Invoice for dollars instead of Euros. I had setup the conversion rate of EUR to DOLLAR, yet when I wanted to complete the Purchase Invoice, I had an error message that the conversion rate from DOLLAR to EURO had not been created.

As soon as you set up the conversion rate EUR to DOLLAR the relation is defined and calculations can be made, so the system should not require that you also setup the conversion rate of DOLLAR to EURO, it can get the calculation for the exchange rate from the EURO to DOLLAR setup.
Steps To Reproduce- General Setup || Application || Currency || Currency:
making sure that the currency you will use is set up in Openbravo

- General Setup || Application || Conversion Rates || Conversion Rate
Setup the conversion from the foreign currency to the system currency

- Master Data Management || Pricing || Price List || Price List
Create a Purchase Price list in the foreign currency with the products that you will buy in that currency and the prices in that currency

- Procurement Management || Transactions || Purchase Invoice || Header
Here you select the foreign price list and the currency related to that pricelist will be defaulted. When you enter the lines you will notice that only products that are on that foreign pricelist can be selected.
Proposed Solution2 approaches to be research on:
a)
The easiest way to approach it as this is something lit bit complex is to remove the field "Divided Rate by". This field is just confusing things because it is not use in the system (that is the reason why you realized about the issue reported) and besides it is true that conversion rate from $ to eur could not be the same as eur to $.

Therefore OB user will have to enter 2 conversion rates:
from € to $ (by using "Multiple Rate by" field)
and from $ to € (by using "Multiple Rate by" field) as well.

b) the system should allow the definition of an exchange rate of X between two currencies, for example from A * X = B. The system should automatically determine that the reverse exchange rate is the inverse of X, for example B * 1/X = A.
Conversely the system should also allow the exchange rate to be defined as an inverse, meaning that the user should be able to define B * 1/X = A. The system should then automatically determine the reverse rate as A * X = B.

This should not result in rounding differences as long as X is defined in only one direction (i.e., the system always determines the reverse rate.
The user should never need to manually enter the reverse rate.
Additional Information
TagsNo tags attached.
Relationships
related to feature request 00021812.50 closed rafaroda Currency in reports - non accounting reports 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-05-13 10:32RenateNieuwkoopNew Issue
2009-05-13 10:32RenateNieuwkoopAssigned To => rafaroda
2009-05-14 13:40rafarodaAssigned Torafaroda => pjuvara
2009-05-20 11:21rafarodaRelationship addedrelated to 0002181
2009-05-20 11:22rafarodaNote Added: 0016495
2009-05-21 07:28pjuvaraAssigned Topjuvara => rmorley
2009-05-21 07:36pjuvaraNote Added: 0016546
2009-08-05 12:08RenateNieuwkoopNote Added: 0018838
2010-07-20 09:17psanjuanProposed Solution updated
2010-07-20 11:45rafarodaIssue Monitored: rafaroda

Notes
(0016495)
rafaroda   
2009-05-20 11:22   
Multi Currency Reports test cases: http://wiki.openbravo.com/wiki/QA_test_plan_2.50/Multi_Currency_Reports [^]
(0016546)
pjuvara   
2009-05-21 07:36   
Please notice that this is not related to multi currency reporting but to multi currency data entry.

The issue is that if you enter the conversion rate from EUR to USD, that rate should also apply for conversions from USD to EUR.

At the moment the system requires you to enter this information twice (once for EUR to USD and once from USD to EUR).

There are two approaches to solve this issue:
1) whenever EUR to USD is created / updated, also create / update the reciprocal conversion rate
2) whenever you retrieve a currency conversion, check for the existence of the conversion that you need and if that is not available check for the existence of the opposite one.

That said:
A) I am not sure how big of an issue this is in practice. A company has a base currency (let's say EUR) and it only really needs to enter conversions **to** that currency. So they only really need USD to EUR.
This problem is only relevant for companies that have two legal entities in two different currency areas that transact with each other. In other words, this problem is only relevant for companies with subsidiaries in both the Euro zone and the US.
B) Even in that case, I am not sure it is functionally correct to apply the same exchange rate in both directions. There could be different costs and fees involved that require a different exchange rate.

Richard: can you please comment?
(0018838)
RenateNieuwkoop   
2009-08-05 12:08   
Adding in the email conversation between Paolo and Richard on this subject from May 22, 2009:

OK, thanks for this.
Regards
Richard

Paolo Juvara wrote:
> Richard,
>
> thanks for the analysis. I then suggest to add two tasks to the Finance engineering team backlog:
> 1) Analysis of the solution to this problem. Expected outcome is a solution design and a risk analysis
> 2) Implementation of the solution. Based on the risk analysis, we will decide whether this can be done as part of maintenance or need to wait for the next release.
>
> It's up to you to determine the priority of these two tasks.
>
> Thanks,
>
> Paolo
>
> On Thu, May 21, 2009 at 10:47 AM, Richard Morley <richard.morley@openbravo.com> wrote:
>
> Hi Paolo,
> I see this as a serious issue. Sort of along the lines of negative transactions.... :)
>
> The system currently requires the rates for EUR > DOLLAR to be be defined seperately from the DOLLAR > EUR rate, whereas they should be defined as a single rate (normally from the system base currency to the foreign currency) and the inverse automatically derived.
>
> The main problem is that the current setup introduces significant risk of transactional error if the system is configured / maintained by someone who doesn't understand pure maths!
> The reason is that the system might be setup (for example) so that the EUR > DOLLAR rate = 0.7242 and the DOLLAR > EUR rate = 1.3808
> On the face of it that would appear to be correct, but it is actually very wrong.
>
> How it should be set up to correctly manage rounding errors and ensure transactional integrity is for the EUR > DOLLAR rate = 0.7242 and the DOLLAR > EUR rate = 1 / 0.7242
> The system does support this convention, but it is:
> a) a huge pain in the ass to maintain
> b) a source of significant risk of transactional error and rounding differences (which themselves are incredibly difficult to resolve)
> c) completely unnecessary!
>
> The correct solution is to only allow one exchange rate to be defined for each currency pair and the system automatically derives the inverse. Normally this would be the exchange rate for the system base currency to the foreign currency.
>
> I would recommend that this should be treated as a bug and fixed ASAP (if at all possible).
> However......from a code perspective we should also acknowledge that changing the system behaviour for such critical algorithm carries some risk, so your comments on how best to resolve this would be appreciated.
> Regards
> Richard