Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
| ID | ||||||||||||
| 0009013 | ||||||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
| feature request | [Openbravo ERP] 01. General setup | trivial | always | 2009-05-13 10:32 | 2010-07-20 11:45 | |||||||
| Reporter | RenateNieuwkoop | View Status | public | |||||||||
| Assigned To | rmorley | |||||||||||
| Priority | normal | Resolution | open | Fixed in Version | ||||||||
| Status | new | Fix in branch | Fixed in SCM revision | |||||||||
| Projection | none | ETA | none | Target Version | ||||||||
| OS | Any | Database | PostgreSQL | Java version | ||||||||
| OS Version | Database version | Ant version | ||||||||||
| Product Version | 2.50 | SCM revision | ||||||||||
| Review Assigned To | ||||||||||||
| Web browser | ||||||||||||
| Modules | Core | |||||||||||
| Regression level | ||||||||||||
| Regression date | ||||||||||||
| Regression introduced in release | ||||||||||||
| Regression introduced by commit | ||||||||||||
| Triggers an Emergency Pack | No | |||||||||||
| Summary | 0009013: Multi-currency: conversion rates setup | |||||||||||
| Description | When 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 Solution | 2 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. | |||||||||||
| Tags | No tags attached. | |||||||||||
| Attached Files | ||||||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
||||||||
|
||||||||
 Relationships |
|
Notes |
|
|
(0016495) rafaroda (developer) 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 (reporter) 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 (reporter) 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 |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2009-05-13 10:32 | RenateNieuwkoop | New Issue | |
| 2009-05-13 10:32 | RenateNieuwkoop | Assigned To | => rafaroda |
| 2009-05-14 13:40 | rafaroda | Assigned To | rafaroda => pjuvara |
| 2009-05-20 11:21 | rafaroda | Relationship added | related to 0002181 |
| 2009-05-20 11:22 | rafaroda | Note Added: 0016495 | |
| 2009-05-21 07:28 | pjuvara | Assigned To | pjuvara => rmorley |
| 2009-05-21 07:36 | pjuvara | Note Added: 0016546 | |
| 2009-08-05 12:08 | RenateNieuwkoop | Note Added: 0018838 | |
| 2010-07-20 09:17 | psanjuan | Proposed Solution updated | |
| 2010-07-20 11:45 | rafaroda | Issue Monitored: rafaroda | |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |