openerp-expert-localization team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

On Fri, Nov 5, 2010 at 7:25 AM, Nicolas Vanhoren <
nicolas.vanhoren@xxxxxxxxxxx> wrote:

>  Hello Raphael,
>
> First, let met state that the rules you criticize are not my idea, and they
> are not new either. They were always active it's just we have never written
> them anywhere before.
>

Well, but now that you look and see that out of Belgium, localization
experts emit reserve against that one module per localization policy (at
least OpenERP being what it is now, that is unable to support most of
localizations without important extensions), may be it's time to re-think
that rule, well hopefully...


>
> Let's be clear, the purpose of the l10n modules, until now, is mainly to
> provide a default chart of account for people that install OpenERP and just
> would like a correct chart of account for their country. Sometimes, we don't
> mind adding extra functionalities as they are related to accounting and
> independent from the other modules of OpenERP (that's the case for bank
> import/export and reports). But that's all.
>

Just a remark: may be your l10n_xx localization module idea with just a
chart of account is an effort to make localization converge for the future
and in this case I respect the concept.
But you have to be aware, and let people be aware that in many countries,
having only the basic chart of account is totally useless for now!!

So, just to give an idea, at least for Spain, Brazil, Venezuela, Thailand (I
give those examples because I know the work done here by
the prominent members of the community), only the chart of account is a
joke. It doesn't cover accounting at all: at best it might work if enter
every account move manually in your chart of accounts (who would do that?).
But no invoice, or now product tax would even get written properly in the
account chart without a large part of the rest of the localization (for
Brazil, accounting is only possible if you install at least l10n_br_account
to be clear).

In Brazil for instance, if what you want is "accounting only", then instead
of just the charts you extracted into l10n_br, you should actually include
the whole l10n_br_account module, that also depends on l10n_br_base (which
extends partners, address and co but depends only upon 'base'). I see that
you don't want to do that, I respect the fact OpenERP has limited resources
for releasing that v6 and this is just a start (a good one). Now, we
wouldn't like to see our effort ruined in the future and OpenERP asking to
migrate features from l10n_br_account without preserving the modularity of
l10n_br_base and or breaking customer installations by having to rename
objects/references over that sub-optimal modularity, instead of respecting
the work of people that know their localization and made the effort to think
about preserving the modularity of OpenERP.
So yes, for converging and starting right no, but please just say no to
mystification.


> Maybe in the future we will allow localization modules for more than just
> accounting, and we will create new guidelines and maybe new module naming
> convention for those. But that's not for this version.
>

Again, if what you want is "accounting" for the Brazilian localization, your
module is l10n_br_account and depends on l10n_br_base. Else it's only a
"work in progress toward future convergence", but shouldn't be presented
differently (specially for maintenance contracts, please ask to take a look
to the recent private discussion between OpenERP SA, CampToCamp and us to
this respect if you don't see what I mean in practice).

>
> Even if the code provided is related to accounting, we really can't accept
> everything. If you add to much fields in the base objects of OpenERP, if you
> redefine to much methods and modify too much views, if will obviously not
> fit correctly with the other modules.
>

Yes, we override lot's of things but:
- often that's all we can do to support our localization given the
OpenObject base (tax included stuff was not working when we started the
localization, lots of code logic in OpenERP is duplicated no modular
enough...)
- all serious integrator are forced to do that currently. Take your "gold
level" partner Almacom, well, in all their work your recognize as  "gold
level quality", they can do no better than override lot's of things for
their Thai localization (look all they had to override
http://bazaar.launchpad.net/~openerp-thai-team/openerp-thai/openobject-addons-thai/files
...).
Other many other serious integrators around can do no better unfortunately.


> Plus we don't have time to review each line of code to check if it's not
> gona make bug appears, especially when it's hard to understand the purpose
> of that code because there is no comments to explain the rationale.
>

Well, at some point it's totally normal that half a dozen of guys from
OpenERP SA can't know and support all localizations in the world. No-one
would do better, and IMHO that's why you should work better with local
partners.


> Yes, I know OpenERP's code doesn't contain too much comments either, but
> that's not a good excuse to do the same. I would also like to say that
> comments that are in any other language than English are just useless.
>

Now, yes, we should document that better too. I have personally been very
active to force the Brazilian localization to use English terms in the code
for instance to avoid that kind of issues, if you look my commits, they
where always in English, and it cost us to do so... Also be aware that local
folks will understand the concepts of their country (they know it already),
and may be that was the priority, before trying to teach OpenERP SA which
wasn't answering threads because too busy when we tried to teach discuss
features. Now, that would be a pleasure to help make things converge in the
future as I said.

Anyway, just a detail: Please, in the future, could you avoid to broadcast
> on a mailing list a mail I sent to you personally? Thanks in advance.
>

Nicolas, I did that because I saw nothing confidential in your email. But
mainly because I think that often OpenERP SA isn't communicative enough with
it's developer community. Look here,  this email thread has been useful to
many guys starting a localization and possibly the comments from the
advanced community members such as Borja Lopez will be useful to OpenERP for
them to re-consider some of their localization guidelines. Honestly,
general interest is what should prevail here. Now next time, as you ask it,
I'll re-phrase your statements instead.


Best regards and thank you for your valuable time, this is the kind of
discussion that make OpenERP progress.


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

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



>
> Best regards.
> Nicolas Vanhoren
>
> Le 04/11/10 14:16, Raphaël Valyi a écrit :
>
>
>
> ---------- 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/%7Eopenerp-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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-localization
>
> Post to     : openerp-expert-localization@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-localization
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-localization
> Post to     : openerp-expert-localization@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-localization
> More help   : https://help.launchpad.net/ListHelp
>
>