c2c-oerpscenario team mailing list archive

["Olivier Dony \(OpenERP\)" <674763@xxxxxxxxxxxxxxxxxx>]

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