Hi Nicolas,
Spanish localization team has split the l10n_es module in two modules:
1) l10n_es: It only contains the template definitions (account
templates, tax templates, tax code templates and fiscal position
templates). It is almost identical the one you have merge to the
official trunk branch, except it contains some important fixes of
several Spanish account names. So we suggest you to update the
l10n_es module in the official trunk branch before releasing RC2.
2) l10n_es_account: This new module contains all the code from
l10n_es not related to chart templates:
* Searching of accounts using a dot to fill the zeroes
* account chart template field is added to account templates, tax
templates, tax codes templates and fiscal positions templates in list
and search views
So, in the l10n_es_account has been programmed, as you suggested 1
week ago, all the functional fields that helps to filter all template
items by the account chart template that they belong. We have also
added the chart template in the search, tree and form views to the
account templates, tax templates, tax code templates and fiscal
position templates. We hope you merge this code to the official branch.
You could find all these changes in the 6.0 branch
(https://code.launchpad.net/~openerp-spain-team/openerp-spain/6.0)
(revisions 191 and 192)
Regards,
Jordi
En/na Nicolas Vanhoren ha escrit:
Hi Jordi,
For your point 2), yes, if you code those function fields I agree to
merge them. You can commit them in l10n_es , if that's clean enough
will copy them myself to account_chart (or the module that contains
those objects, don't remember well).
For point 3), that don't seem to be a type of feature we would like
to integrate, so I will prefer that you put it in another module.
Thanks in advance and best regards.
Nicolas Vanhoren
Le 04/11/10 12:35, Jordi Esteve a écrit :
En/na Nicolas Vanhoren ha escrit:
Hi everyone,
I contact you all to make clearer a point we've not really well
explained until then. It's about the things that are allowed or
not in the localization modules. I updated the guideline page for
that:
http://pad.openerp.com/6-test-accounting-localisation-guidelines .
Normally, until then the only things I merged in your localization
modules was the chart of accounts/chart of taxes. But for the
Spain, Thailand and Venezuala localizations the contributions is
far more important than just those charts. If you have bank
interfaces or report that you would like to merge too, and that
can be easily extracted for the rest of your modules, please tell
me and I would take a look at them. Please also take into account
that I will have to take those parts and put them in the l10n_xx
module (only one localization module per country rule).
Anyway, thanks for your contributions!
Nicolas Vanhoren
Spanish localization includes a lot of modules, not only the
account charts included in the l10n_es module. All these modules
deal with several OpenERP objects, like toponyms (place names like
zip codes, city, federal state), payments orders, validation of
bank accounts. So it is not possible (well, not elegant) to include
all of them in only one module.
Then, if only one localization module per country is allowed, it
must include (as you said) only the account chart templates. In the
current l10n_es module (attention, update the Spanish localization
branch, last week we did some fixes), basically 3 things are
implemented:
1) Definition of Spanish account chart templates (accounts, taxes,
tax codes and fiscal positions)
2) Adding a 'template_name' field in all these objects (as you tell
in other email, this must be removed to prevent inconsistency.
Taxes and fiscal positions have many2one links to the chart
template and for accounts and tax codes is necessary to add a
function field to account.account.template and to
account.tax.code.template that applies an algorithm to search the
root)
3) Redefinition of search in account.account to allow searching of
accounts using a dot (so 430.23 gives you the account 430000023).
It is very important for Spanish accountants.
So
point 1) is ok.
point 2) you asked if someone take time to create that function
field you could consider to integrate it in the account module
directly. I can try to do that next week. Could it be integrated?
If not, we will left 'template_name' field for the moment in the
Spanish localization branch, because it is important to distinguish
the template in all these objects.
point 3) it is ok to remain the redefinition of search in the
current l10n_es module? If not, it will moved to another Spanish
localization module (despite other countries could have interest on
it).
Jordi
