Hello, Your bug report makes perfect sense, however we cannot implement the refactoring of the server core as such in the upcoming v6.0, because it would create many other issues. One of the reasons why we have sample rates in a default installation is because at least one rate is required in a given currency before being able to use it for any operation. Many internal sanity checks, tests or other sample data thus depend on these sample rates.
Concerning the fact that l10n_* modules could install a proper set of currency exchange rates, this is indeed a correct option, and one that is not in conflict with having sample rates in the server. We have merged many localization modules in v6.0RC2 (available in a few weeks), including a newer l10n_uk. Contributors are encouraged to work together to improve the localizations and propose patches to the existing localizations (there was a big community effort around this a few weeks ago: http://www.openerp.com/node/502/2010/10) Please feel free to contribute to l10n_uk, also following the process explained here: http://doc.openerp.com/contribute/15_guidelines/contribution_guidelines.html As a conclusion, validating the currencies and rates is part of the important tasks that must be accomplished when setting up a production OpenERP system, and as you suggest, this could be even more complicated in multi-companies setup (where you may need to duplicate the currencies per-company depending on the needs). There is also the matter of updating the rates more frequently for the current year, required in some companies, etc. Not all these tasks can be performed automatically. Thanks for the detailed report! PS: I am closing this bug for the current 6.0 release, but we'll keep it in mind for post-6.0 improvements, and patches/merge proposals are always welcome for the localizations ** Changed in: openobject-server Importance: Undecided => Low ** Changed in: openobject-server Status: New => Won't Fix -- OpenrERP installs currency data that is always wrong https://bugs.launchpad.net/bugs/674763 You received this bug notification because you are a member of C2C OERPScenario, which is subscribed to the OpenERP Project Group. Status in OpenObject Server: Won't Fix Bug description: The data installed in Server/addons/base/base_data.xml which is installed into each new database, is always wrong for a number of reasons. If you choose a currency other than EUR on database creation, say GBP, then it says the GBP is worth 0.675 GBP! It should be 1. But even for a EUR creation, all the others are wrong too, (except the trivial EUR/EUR because when you install the database, OpenERP sets them to be the rate on the 1st of January of the year you install them: <field eval="time.strftime('%Y-01-01')" name="name"/> They may have been right at some point (when the base_data file was written), but are no longer right if set to the 1st of January of the year you install them. If I install the current OpenERP now (2010) it sets EURGBP to 0.675 which has not been true for years. I think in most countries, there are "official" rates that are set by the tax authorities, and these are the rate that have to be used for valid accounting. For example, in the UK the exchange rates are set as a yearly average and are available on the web: http://www.hmrc.gov.uk/exrate So my suggestion is to remove all the currency data from base_data.xml and install only the Local Currency/Local Currency cross to be 1, read-only, as of Jan. 1 1970. Then put the currency data in the l10n_?? modules, and derive it from the country's official sources, and document the source of the numbers in the file. For example, for a l10n_uk GBP install, the official HMRC GBP rates are: <?xml version="1.0" encoding="utf-8"?> <openerp> <data> <!-- FixMe: Delete the existing rate for these currencies --> <assert id="base.main_company" model="res.company"> <test expr="currency_id.code == 'gbp'.upper()"/> </assert> <!-- Average year rates from HMRC; see: --> <!-- http://www.hmrc.gov.uk/exrate --> <!-- 2006 --> <record id="rate2006CAD" model="res.currency.rate"> <field name="rate">2.0901</field> <field name="currency_id" ref="base.CAD"/> <field name="name">2005-12-31</field> </record> <record id="rate2006EUR" model="res.currency.rate"> <field name="rate">1.4666</field> <field name="currency_id" ref="base.EUR"/> <field name="name">2005-12-31</field> </record> <record id="rate2006USD" model="res.currency.rate"> <field name="rate">1.8424</field> <field name="currency_id" ref="base.USD"/> <field name="name">2005-12-31</field> </record> <!-- 2007 --> <record id="rate2007CAD" model="res.currency.rate"> <field name="rate">2.1484</field> <field name="currency_id" ref="base.CAD"/> <field name="name">2006-12-31</field> </record> <record id="rate2007EUR" model="res.currency.rate"> <field name="rate">1.4604</field> <field name="currency_id" ref="base.EUR"/> <field name="name">2006-12-31</field> </record> <record id="rate2007USD" model="res.currency.rate"> <field name="rate">2.0020</field> <field name="currency_id" ref="base.USD"/> <field name="name">2006-12-31</field> </record> <!-- 2008 --> <record id="rate2008CAD" model="res.currency.rate"> <field name="rate">2.0725</field> <field name="currency_id" ref="base.CAD"/> <field name="name">2007-12-31</field> </record> <record id="rate2008EUR" model="res.currency.rate"> <field name="rate">1.4178</field> <field name="currency_id" ref="base.EUR"/> <field name="name">2007-12-31</field> </record> <record id="rate2007USD" model="res.currency.rate"> <field name="rate">2.0080</field> <field name="currency_id" ref="base.USD"/> <field name="name">2007-12-31</field> </record> <!-- 2009 --> <record id="rate2009CAD" model="res.currency.rate"> <field name="rate">1.7801</field> <field name="currency_id" ref="base.CAD"/> <field name="name">2008-12-31</field> </record> <record id="rate2009EUR" model="res.currency.rate"> <field name="rate">1.1235</field> <field name="currency_id" ref="base.EUR"/> <field name="name">2008-12-31</field> </record> <record id="rate2009USD" model="res.currency.rate"> <field name="rate">1.5633</field> <field name="currency_id" ref="base.USD"/> <field name="name">2008-12-31</field> </record> <!-- 2010 --> <record id="rate2010CAD" model="res.currency.rate"> <field name="rate">1.7398</field> <field name="currency_id" ref="base.CAD"/> <field name="name">2009-12-31</field> </record> <record id="rate2010EUR" model="res.currency.rate"> <field name="rate">1.1298</field> <field name="currency_id" ref="base.EUR"/> <field name="name">2009-12-31</field> </record> <record id="rate2010USD" model="res.currency.rate"> <field name="rate">1.5962</field> <field name="currency_id" ref="base.USD"/> <field name="name">2009-12-31</field> </record> </data> </openerp> This makes it all the more important to have an official certified l10_?? that is maintained and delivered with OpenERP, even if it does not include a chart of accounts or tax code data. It's quite possible that you will have a multi-company scenario with the companies in different countries, where the official rates do not agree, but still have to be used officially. There is no official l10_uk for example for 5.0, which I think should be a priority given the number of dissatisfied SAGE users there are in the UK :-). The currency info above should be put into a l10n_uk official module, along with the base_changes.py factored out of l10n_chart_uk_netinsight declaring the counties of Britain. That much can be certified easily, even if you don't adopt l10n_chart_uk_netinsight entirely (with fixes to some of the close_methods in data/account.account.type.csv), which is harder to certify. Then introduce l10_uk as a dependency to l10n_chart_uk_netinsight or l10n_chart_uk_minimal etc. The official l10_?? that is maintained and delivered with OpenERP should then be installed as a part of database creation, if it exists, with the address/country made a required field. 5.0.14 5.0.15 and 6.0rc1 _______________________________________________ Mailing list: https://launchpad.net/~c2c-oerpscenario Post to : [email protected] Unsubscribe : https://launchpad.net/~c2c-oerpscenario More help : https://help.launchpad.net/ListHelp
