Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0010574
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] 00. Application dictionarymajoralways2009-09-11 18:092009-11-11 12:28
ReporternetworkbView Statuspublic 
Assigned Toharikrishnan 
PriorityurgentResolutionfixedFixed in Version2.50MP9
StatusclosedFix in branchpiFixed in SCM revisionb41bbb3be75a
ProjectionnoneETAnoneTarget Version2.40MP10
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product Version2.40MP8SCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0010574: The converion rate table has to save the rates with more decimals

DescriptionThe converion rate table has to save the rates with more decimals, because in other case the accounting is not correct.
The accounting process works well but the problem is that the multiplier rate and divide rate use only two decimals when they have to use 5, that is how
the conversions are defined.
Steps To ReproduceSee the attached document but the problem is not the process, but only the definition of the conversions.
TagsNo tags attached.
Attached Files? file icon steps_to_reproduce.odt [^] (745,071 bytes) 2009-09-11 18:09

- Relationships [ Relation Graph ] [ Dependency Graph ]
depends on backport 00106082.40MP10 closedjeneivemalarkodi The converion rate table has to save the rates with more decimals 
has duplicate feature request 0011028 closedrafaroda Currency Exchange Rate 
has duplicate defect 0011183 closedrafaroda Currency Exchange Rate 
related to feature request 0010887 newiciordia Numeric references should declare its own format (from format.xml) instead of being hardcoded in WAD 
related to defect 0010941 closedharikrishnan API check build 171 fails - part2 
related to defect 00116402.50MP10 closedrafaroda In some tables the columns MultiplyRate and DivideRate are Number 

-  Notes
(0020327)
harikrishnan (reporter)
2009-09-24 07:01

 To increase the decimal points we have to follow the steps.
Step 1.
Edit Format.xml(openbravocodebase/config/Format.xml)
   Change decimal point in formatOutput and formatInternal attribute of euroEdition.
      <Number name="euroEdition" decimal="." grouping=","
      formatOutput="#0.0000000"formatInternal="#0.0000000" />
Step 2.

Run Ant task

   ant compile.complete

Hence if now look in to conversion rate the field displays seven decimal point.
(0020355)
networkb (developer)
2009-09-25 08:48

 The solution changes the number of decimals that are euro fiels,
what is not correct because the invoices in spain has to be presented
with only two decimals, by law.
Besides although in the conversion rates is possible to save more decimals
there is a callout that round both values so the value saved have only two decimals.

Other problem in 2.50 is that the core mustn't be modified so how to implement this change using modularity?

A proposal solution could be to create a new reference in order to use more decimals to be assigned only to this two fields.
(0020357)
rafaroda (developer)
2009-09-25 10:03

 1) You are right, the solution proposed is not valid since it changes all the euroEdition formatted fields.

2) Forget about the callout, this is not the problem:
* Type in Multiplier Rate field: 0.666666667 This value is rounded to 0.67

3) The code that makes this rounding starts in line 187 of WADNumber.java https://code.openbravo.com/erp/devel/main/file/600c52248c85/src-wad/src/org/openbravo/wad/controls/WADNumber.java#l187 [^] Decimal numbers are rounded based on euroEdition field of Format.xml file, which does not seems very correct.

Issue passed to Platform in order that they decide if a new entry has to be added into Format.xml file for decimal numbers.
(0020574)
rafaroda (developer)
2009-09-30 07:59

 Current Format.xml.template file https://code.openbravo.com/erp/devel/pi/file/7d24f94b2a5e/config/Format.xml.template [^]
(0020602)
rafaroda (developer)
2009-09-30 16:27

 The new solution proposed is to change the reference to GeneralQuantity (ad_reference_id = '800019') for these 2 columns. This way, the format taken from Format.xml will be generalQtyRelation and generalQtyEdition. If this is set to the number of decimals that we want, it will work.

I have some doubts:

1) Number (ad_reference_id = '22') seems the correct Reference for these 2 columns: why change it to GeneralQuantity?

SELECT t.name AS TABLE_NAME, c.name AS COLUMN_NAME, r.name AS REFERENCE_NAME
FROM ad_table t, ad_column c, ad_reference r
WHERE r.ad_reference_id IN ('22')
AND c.ad_table_id = t.ad_table_id
AND r.ad_reference_id = c.ad_reference_id
ORDER BY r.name, t.name, c.name;

2) Currently there are no columns defined with reference GeneralQuantity in Openbravo ERP.

SELECT t.name AS TABLE_NAME, c.name AS COLUMN_NAME, r.name AS REFERENCE_NAME
FROM ad_table t, ad_column c, ad_reference r
WHERE r.ad_reference_id IN ('800019')
AND c.ad_table_id = t.ad_table_id
AND r.ad_reference_id = c.ad_reference_id
ORDER BY r.name, t.name, c.name;

I keep thinking that the problem is in the Format.xml. See wadUtility.java https://code.openbravo.com/erp/devel/pi/file/c6b4fe83c065/src-wad/src/org/openbravo/wad/WadUtility.java#l2120 [^]

Why both Amount (ad_reference_id = '12') and Number (ad_reference_id = '22') are considered decimal numbers in the same way? Normally one wants amounts to be formatted in a currency style which differs many times to the style that we want for decimal numbers (multipliers with several decimals).

I think that a better solution would be:

1) In WadUtility.java, change:
public static boolean isDecimalNumber(String reference) {
    if (reference == null || reference.equals(""))
      return false;
    return (reference.equals("12") || reference.equals("22"));
  }

by

public static boolean isAmountNumber(String reference) {
    if (reference == null || reference.equals(""))
      return false;
    return (reference.equals("12"));
  }

public static boolean isDecimalNumber(String reference) {
    if (reference == null || reference.equals(""))
      return false;
    return (reference.equals("22"));
  }

2) In WADNumber.java, change:
 if (WadUtility.isDecimalNumber(getData("AD_Reference_ID"))) {
      xmlDocument.setParameter("columnFormat", "euroEdition");
      xmlDocument.setParameter("outputFormat", "euroEdition");
    }

by

 if (WadUtility.isAmountNumber(getData("AD_Reference_ID"))) {
      xmlDocument.setParameter("columnFormat", "euroEdition");
      xmlDocument.setParameter("outputFormat", "euroEdition");
    } else if (WadUtility.isDecimalNumber(getData("AD_Reference_ID"))) {
      xmlDocument.setParameter("columnFormat", "decimalEdition");
      xmlDocument.setParameter("outputFormat", "decimalEdition");
    }

3) In Format.xml.template file, add:
 <Number name="decimalRelation"
       decimal="." grouping="," formatOutput="#,##0.00" formatInternal="#0.000000" />
   <Number name="decimalEdition"
       decimal="." grouping="," formatOutput="#0.00" formatInternal="#0.000000" />
   <Number name="decimalExcel"
       decimal="," grouping="." formatOutput="#,##0.##" formatInternal="#0.000000" />
(0020797)
iciordia (manager)
2009-10-06 20:27

 Rafa,

I agree with the rational in your proposed solution but some details are wrong (eg. formatOutput for decimal should be ###,##0.###### if we want to solve this issue). But this way it requires to review all current columns using reference number (182 columns) because many of them should be amount instead. Also take into account that updating instances after this change might lead to changes in behaviour (number columns will show more decimal positions than before).

Because of this I've created a feature request (https://issues.openbravo.com/view.php?id=10887 [^]) to properly address this problem. As you can see this is not a simple request and should be managed as a project.

In the meantime you should fix the issue as originally proposed (changing reference to generalQuantity).

Ismael
(0020819)
networkb (developer)
2009-10-07 10:38

 Changing reference to generalQuantity is good because in this way
the user is able to save the conversion with six decimals what is enough
(0020879)
hgbot (developer)
2009-10-08 15:49

 Repository: erp/devel/pi
Changeset: 39e29fcb1883d49a7d2cb3d0281fc55fecabc6b2
Author: Jeneive malarkodi <jeneive.malarkodi <at> openbravo.com>
Date: Thu Oct 08 19:17:48 2009 +0530
URL: http://code.openbravo.com/erp/devel/pi/rev/39e29fcb1883d49a7d2cb3d0281fc55fecabc6b2 [^]

Fixed Issue 10574: The conversion rate table with more decimals

---
M src-db/database/sourcedata/AD_COLUMN.xml
---
(0020965)
sureshbabu (reporter)
2009-10-13 10:21

 Tested, right the conversion table with maximum of 6 decimals
(0021190)
williams-tegik (reporter)
2009-10-19 18:48

 The problem for us , was that you in the Openbravo UI, the rate it was rounded, but the rate in the database is stored exactle the way you entered.

I.E.
1. You type 13.4879 and click save
2. You see 13.49
3. The databse stores 13.4879 , and this is the the number is used.

This is not wrong, but it caused our customer a lot of problem when they created the inverse rate and they just wrote 13.49 instead of 13.4879... so this caused a big discrepancy in the rounding account, when working with this rate/day.

Our solution:
We have created a trigger so when they create a rate convertion the system creates the inverse automatically, this is up to the customer trough a check box.
If you like this solution, we are open to contribute it.

Best,
Eduardo Williams
Partner: Tegik
(0021209)
iciordia (manager)
2009-10-20 14:43

 Hi Eduardo,

be careful with your proposed fix: your are right that first time you save database stores 13.4879

But if you do another change in that record (any other field) and save again then the database will store 13.49

In any case your solution to automatically calculate the inverse is interesting, I let Rafa to manage the contribution.

Thanks,

Ismael
(0021214)
williams-tegik (reporter)
2009-10-20 16:03

 Hi Ismael,
This explains a lot of things then, Probably our customer writes it down the good way, but sometimes the make a change and this happens... This cause big problems in the accounting..
what would you recommend us to do ??
(0021241)
hgbot (developer)
2009-10-21 09:03

 Repository: erp/devel/pi
Changeset: 8000c4d08283e3653847808b95e6fee55a5dd024
Author: Harikrishnan Raja <harikrishnan.raja <at> openbravo.com>
Date: Wed Oct 21 12:29:02 2009 +0530
URL: http://code.openbravo.com/erp/devel/pi/rev/8000c4d08283e3653847808b95e6fee55a5dd024 [^]

Fixes Issue 0010941 Issue 0010574 resolves API break by reverting the change.

---
M src-db/database/sourcedata/AD_COLUMN.xml
---
(0021243)
rafaroda (developer)
2009-10-21 09:08

 Change in pi has been reverted and waiting for new solution proposed.
(0021296)
rafaroda (developer)
2009-10-22 07:29

 Isma,

Will 0010887 be implemented in order to properly fix this issue?

Thanks.
(0021297)
rafaroda (developer)
2009-10-22 07:31

 Eduardo,

Please contact me [1] since your feature for avoiding to type the inverse conversion rate sounds very interesting :)

Cheers.

[1] http://forge.openbravo.com/users/rafaroda [^]
(0021348)
iciordia (manager)
2009-10-22 19:43

 Eduardo,

my recomendation is to change the reference of multiplyRate and divideRate from Number to GeneralQty. It will be done in Openbravo core in MP10 (before we do it we need to solve a problem with wrong mapping for reference number, you will see in short in our forums). But you can do this change in advance since you don't have problems with stable API. GeneralQty reference has big precision and will remove the problem.

Ismael
(0021349)
iciordia (manager)
2009-10-22 19:48

 Rafa,

next steps:
1.- Solve wrong mapping for reference number (change from float to BigDecimal) and manage change in public API
2.- Solve this issue by my original proposal (change reference to GeneralQty) without the need to address 10887 (after 1 there will not be API change)
3.- Support for extensible references, including FR10887

Ismael
(0021405)
hgbot (developer)
2009-10-27 09:57

 Repository: erp/devel/pi
Changeset: b41bbb3be75a859e5f9cec15aef87fc9add4f7a6
Author: Harikrishnan Raja <harikrishnan.raja <at> openbravo.com>
Date: Tue Oct 27 14:23:06 2009 +0530
URL: http://code.openbravo.com/erp/devel/pi/rev/b41bbb3be75a859e5f9cec15aef87fc9add4f7a6 [^]

Fixes Issue 10574: The conversion rate table has to save the rates with more decimals.

---
M src-db/database/sourcedata/AD_COLUMN.xml
---
(0021717)
sureshbabu (reporter)
2009-11-11 12:28

 Retested working fine, as per the developer comments

- Issue History
Date Modified Username Field Change
2009-09-11 18:09 networkb New Issue
2009-09-11 18:09 networkb Assigned To => rafaroda
2009-09-11 18:09 networkb File Added: steps_to_reproduce.odt
2009-09-14 11:31 networkb Target Version => 2.40MP10
2009-09-15 11:00 rafaroda Status new => acknowledged
2009-09-15 11:42 psarobe Status acknowledged => scheduled
2009-09-15 11:42 psarobe fix_in_branch => pi
2009-09-15 15:07 rafaroda Priority immediate => urgent
2009-09-15 15:07 rafaroda fix_in_branch pi =>
2009-09-16 15:23 harikrishnan Assigned To rafaroda => harikrishnan
2009-09-24 07:01 harikrishnan Note Added: 0020327
2009-09-24 07:01 harikrishnan Status scheduled => feedback
2009-09-25 08:48 networkb Note Added: 0020355
2009-09-25 08:48 networkb Status feedback => new
2009-09-25 10:03 rafaroda Note Added: 0020357
2009-09-25 10:03 rafaroda Assigned To harikrishnan => iciordia
2009-09-25 10:03 rafaroda Status new => acknowledged
2009-09-30 07:59 rafaroda Note Added: 0020574
2009-09-30 16:27 rafaroda Note Added: 0020602
2009-10-06 20:27 iciordia Note Added: 0020797
2009-10-06 20:28 iciordia Assigned To iciordia => rafaroda
2009-10-07 06:57 rafaroda Status acknowledged => scheduled
2009-10-07 06:57 rafaroda Assigned To rafaroda => jeneivemalarkodi
2009-10-07 06:57 rafaroda fix_in_branch => pi
2009-10-07 07:01 rafaroda Relationship added related to 0010887
2009-10-07 10:38 networkb Note Added: 0020819
2009-10-08 09:43 hgbot Checkin
2009-10-08 09:43 hgbot Note Added: 0020867
2009-10-08 09:43 hgbot Status scheduled => resolved
2009-10-08 09:43 hgbot Resolution open => fixed
2009-10-08 09:43 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/stable/2.40/rev/53d63d9df25d5f8f99e97a517e14b282a04c5721 [^]
2009-10-08 15:27 rafaroda Note Deleted: 0020867
2009-10-08 15:49 hgbot Checkin
2009-10-08 15:49 hgbot Note Added: 0020879
2009-10-08 15:49 hgbot Fixed in SCM revision http://code.openbravo.com/erp/stable/2.40/rev/53d63d9df25d5f8f99e97a517e14b282a04c5721 [^] => http://code.openbravo.com/erp/devel/pi/rev/39e29fcb1883d49a7d2cb3d0281fc55fecabc6b2 [^]
2009-10-13 10:21 sureshbabu Status resolved => closed
2009-10-13 10:21 sureshbabu Note Added: 0020965
2009-10-13 10:21 sureshbabu Fixed in Version => 2.50MP7
2009-10-13 10:46 shuehner Relationship added related to 0010941
2009-10-14 00:00 anonymous sf_bug_id 0 => 2878312
2009-10-19 10:30 rafaroda Relationship added has duplicate 0011028
2009-10-19 18:48 williams-tegik Note Added: 0021190
2009-10-20 14:43 iciordia Note Added: 0021209
2009-10-20 16:03 williams-tegik Note Added: 0021214
2009-10-21 09:03 hgbot Checkin
2009-10-21 09:03 hgbot Note Added: 0021241
2009-10-21 09:03 hgbot Fixed in SCM revision http://code.openbravo.com/erp/devel/pi/rev/39e29fcb1883d49a7d2cb3d0281fc55fecabc6b2 [^] => http://code.openbravo.com/erp/devel/pi/rev/8000c4d08283e3653847808b95e6fee55a5dd024 [^]
2009-10-21 09:08 rafaroda Assigned To jeneivemalarkodi => rafaroda
2009-10-21 09:08 rafaroda Status closed => new
2009-10-21 09:08 rafaroda Resolution fixed => open
2009-10-21 09:08 rafaroda Note Added: 0021243
2009-10-21 09:09 rafaroda Fixed in Version 2.50MP7 =>
2009-10-22 07:29 rafaroda Note Added: 0021296
2009-10-22 07:29 rafaroda Assigned To rafaroda => iciordia
2009-10-22 07:29 rafaroda Status new => acknowledged
2009-10-22 07:31 rafaroda Note Added: 0021297
2009-10-22 19:43 iciordia Note Added: 0021348
2009-10-22 19:48 iciordia Note Added: 0021349
2009-10-27 09:24 harikrishnan Assigned To iciordia => harikrishnan
2009-10-27 09:57 hgbot Checkin
2009-10-27 09:57 hgbot Note Added: 0021405
2009-10-27 09:57 hgbot Status acknowledged => resolved
2009-10-27 09:57 hgbot Resolution open => fixed
2009-10-27 09:57 hgbot Fixed in SCM revision http://code.openbravo.com/erp/devel/pi/rev/8000c4d08283e3653847808b95e6fee55a5dd024 [^] => http://code.openbravo.com/erp/devel/pi/rev/b41bbb3be75a859e5f9cec15aef87fc9add4f7a6 [^]
2009-10-30 06:01 rafaroda Relationship added has duplicate 0011183
2009-11-11 12:28 sureshbabu Status resolved => closed
2009-11-11 12:28 sureshbabu Note Added: 0021717
2009-11-11 12:28 sureshbabu Fixed in Version => 2.50MP9
2009-12-14 10:16 rafaroda Relationship added related to 0011640

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker