openerp-expert-localization team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

---------- Forwarded message ----------
From: Raphaël Valyi <rvalyi@xxxxxxxxxxxx>
Date: 2010/11/4
Subject: Re: openerp localization module
To: Nicolas Vanhoren <nicolas.vanhoren@xxxxxxxxxxx>
Cc: Raphaël Valyi <rvalyi@xxxxxxxxx>, renato lima <
renato.lima@xxxxxxxxxxxxxxx>, sebastien beau <sebastien.beau@xxxxxxxxxxxxxxx
>


Hello Nicolas and all,

We have seen you merge on
https://code.launchpad.net/~openerp-brazil-team/openerp.pt-br-localiz/l10n_br_modularized
<https://code.launchpad.net/~openerp-brazil-team/openerp.pt-br-localiz/l10n_br_modularized>So
basically you extracted the chart of account data from our l10n_br_account
module and put it into a new l10n_br module, to match your new "standard" I
guess.

We have no big problem with that, but would like to give some important
remarks:

1) Currently, the Brazilian tax definition (account.tax.template) you moved
in l10n_br, are actually lacking the "tax_discount" additional tax fields
(you can see them in l10n_br_account/account.py for the account.tax object).

Why did we not put that "tax_discount" field into the template?
Because in OpenERP v5, the generation of the account chart + tax from the
template was an hardcoded pig old style wizard we couldn't override to
properly propagate that field from account.tax.template to account.tax.
On recent v6, fortunately, we can finally do it, so we will add the field on
the tax template too and propagate it, overriding the nice osv.memory
wizard.
So when we will do it, we will need to had a python file in the l10n_br
module, adding those fields and overriding the chart creation wizard.
Is that OK for you (I see that the reference l10n_be module has Python too)
?


2) In your localization guidelines here
http://pad.openerp.com/6-test-accounting-localisation-guidelines , I think
the following assertion "the whole localization must be contained in one and
only one module" is wrong and misleading.
Seriously, take a look as some complex localization modules. I know that
OpenERP has been made for Belgium and then extended to countries with
similar accounting such as France, but if you look at Spain, Brazil or UK
localizations you understand that those localizations are a lot more complex
than just 10n_be.

Take the example of Brazil: when you do a delivery for instance, you should
have specific picking fields such as the code of operation (CFOP, see
Openbravo Brazilian localization bring it , possibly taken "
http://forge.openbravo.com/plugins/espforum/view.php?group_id=100&forumid=775787&topicid=7006503";
), fiscal category etc..., and you should propagate them to the invoice if
you invoice upon the delivery.

So, we ate Akretion, we are a consulting service company using OpenERP v6
and the Brazilian localization. Now suppose we follow that brilliant
guideline of making localization only one module: we, service company should
install the delivery module, just because eventually, if one company
installs the delivery module, they would need extensions to make it work in
Brazil?

I think this is wrong and that you should rather insist so
that localization teams build modular solutions such as we did in the
Brazilian localization, so please change that statement.
Instead, I think localization should never bring OpenERP modules you
wouldn't need for your business, else you just destroy all the benefit of
the great OpenERP modularity for 90% of the users (who would need
localizations, obviously not as trivial as the Belgium one).


3) Again, take the Brazilian localization, the very base of it is
l10n_br_base, because it will extend basic objects such as partners and
address, without requiring any extra dependency.
We have case, of people wanting to do CRM only, they might then install only
the CRM and l10n_br_base module then so far.
Instead, when you install l10n_br you already brings the account module...
So at some point, may be it would be better if the name of l10n_br would
explicit this is not the base but actually some chart of account only, hence
may be name l10n_br_chart.
I'm not sure this is generic, but eventually I suggest to name those
localization modules 10n_xx_chart instead of l10n_xx if chart is the only
thing you want in them.
Well this lats point is open for debate, in any case this is only a
terminology issue.


Thank for your time, we are on site today for consulting, but don't hesitate
to ask us if you have questions.


 Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

 <http://www.akretion.com.br/>






2010/11/4 Nicolas Vanhoren <nicolas.vanhoren@xxxxxxxxxxx>

>  Hi,
>
> Ok, that does not change many things for me. You can see what I merged
> here:
> https://code.launchpad.net/~openerp-dev/openobject-addons/niv-dev-addons<https://code.launchpad.net/%7Eopenerp-dev/openobject-addons/niv-dev-addons>.
>
> By the way, we were not really clear with what things are allowed to be in
> the localization modules. I invite you to consult the updated guidelines
> http://pad.openerp.com/6-test-accounting-localisation-guidelines . I you
> have bank interfaces or reports that you think could be in the l10n module,
> added to the chart of accounts, tell me.
>
> Thanks in advance.
> Nicolas Vanhoren
>
> Le 03/11/10 17:46, Raphaël Valyi a écrit :
>
> Hello Nicolas!
>
>  Arrggghh too bad you didn't contact us (remember, you can call me with
> raphael.valyi on skype or the contacts mentioned here
> http://www.akretion.com/en/contact ) , we have been working like mads the
> last week to refactor the localization in more more modular way (especially
> in the idea to have a great quality), please you should absolutely use that
> branch now:
>
> https://code.launchpad.net/~openerp-brazil-team/openerp.pt-br-localiz/l10n_br_modularized<https://code.launchpad.net/%7Eopenerp-brazil-team/openerp.pt-br-localiz/l10n_br_modularized>
>
>  This branch is mostly a simple refactoring consisting in splitting the
> modules properly. Please update your merge, we invested around 6 man months
> in the Brazilian localization, we don't want OpenERP S.A. to freeze it in a
> bad shape, we have just deployed that new branch at 4 customers and even
> spend 2 days migrating one customer in production to the new branch, so we
> absolutely need that new branch! It would be terrible if your packaging
> force us, the localization author, to start crappy projects because people
> wouldn't start their project right on the modular solution. We think the
> modular solution is a lot better, the reason we didn't do it better was more
> because of a lack of resource. Now that we made that tremendous effort,
> including to deal with our production customers, it would be great to
> promote it as the standard, not the contrary (think about that: I've
> deployed OpenERP around 10 times and it took me 2 days to migrate the
> customer. If you don't provide the right module already in v6, how many
> companies will fail to migrate to the modular version when there will be no
> other choice...)
>
>  I think you can merge only some modules (like l10n_br_base at least). If
> you look at the size of the modules, I do not recommend you merge the _data*
> modules (contains all the streets of Brazil, fiscal classification of
> products etc... those are lots of Mb). Merging the extra addons in
> dependence would also be a nice start as they could be used by other
> localizations.
>
>  You have the first announcement of our refactoring work in the Brazilian
> mailing list:
>  https://lists.launchpad.net/openerp-brazil-team/msg01061.html
> Google would try to translate it for you into (not perfect because
> my Portuguese isn't perfect):
>
> http://translate.google.com.br/translate?js=n&prev=_t&hl=pt-BR&ie=UTF-8&layout=2&eotf=1&sl=pt&tl=en&u=https://lists.launchpad.net/openerp-brazil-team/msg01061.html
>
>  Can you update your merge to the right modules and explain us how can we
> update them in the regular distro then?
> Thank you very much for your time and sorry, for the inconvenience. But you
> know yesterday was a day off in Brazil and I worked until 3 AM as you can
> see in the mailing list, it's really not like we forgot to notify you about
> the refactoring, but just that we were working like mads.
>
>  Can you please tell us what you can do about that refactoring?
>
>
>   Raphaël Valyi
> Founder and ERP Consultant
>  +55 21 3010 9965
>  http://www.akretion.com
>
>    <http://www.akretion.com.br/>
>
>
>
>
>
> 2010/11/3 Nicolas Vanhoren <nicolas.vanhoren@xxxxxxxxxxx>
>
>> Hi,
>>
>> I merged you Brasilian accounting localization module with our development
>> branch. I did some small changes, which are pushed on your branch so it's
>> easy for you to consult them.
>>
>> Yeah, I know, you would have preferred that we did wait a bit more. But my
>> boss asked me to merge anyway if I thought it was stable, and your chart of
>> account seemed so. It will still be possible for you to send us updates
>> later, so it's not really a problem.
>>
>> Best regards.
>>  Nicolas Vanhoren
>>
>
>
>
> --
> Raphaël Valyi
> http://www.akretion.com
>
>
>


-- 
Raphaël Valyi
http://www.akretion.com