|
Notes |
|
|
|
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.
|
|
|
|
|
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. |
|
|
|
|
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. |
|
|
|
|
|
|
|
|
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" /> |
|
|
|
|
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 |
|
|
|
|
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
|
|
2009-10-08 15:49
|
|
|
|
|
|
|
Tested, right the conversion table with maximum of 6 decimals |
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
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
|
|
2009-10-21 09:03
|
|
|
|
|
|
|
Change in pi has been reverted and waiting for new solution proposed. |
|
|
|
|
Isma,
Will 0010887 be implemented in order to properly fix this issue?
Thanks. |
|
|
|
|
|
|
|
|
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 |
|
|
|
|
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
|
|
2009-10-27 09:57
|
|
|
|
|
|
|
Retested working fine, as per the developer comments |
|
steps_to_reproduce.odt (745,071) 2009-09-11 18:09