openerp-expert-localization team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

On more important remark,

Obviously, past the 3 - 4 simples localizations that fit OpenERP the way it
has been designed historically, the reality is that a lot of localization
introduce a lot of new concepts.
We already tried to have some of those concepts merged into generic concepts
into OpenERP, this has been the sense for instance of our threads regarding
the federal Brazilian fiscality and European report_intrastat for instance.
Many time, obviously OpenERP SA didn't had the structure to analyse those
concepts for OpenERP v6.0.

The drawback is that by having each localization adding concepts
independently, of course, as soon as you have a multi-companies install
targetting several different countries you are likely to have troubles
unless you have some skilled integrator patching heavily the whole system.

Well, I want to say, so let it be for v6.0. Of course version 6 can't be
perfect and should be out as it's already much better than v5. It's
important to be aware of those multi-localizations limitations for v6.0 and
work in the future to make sure we converge later.

I think v6.2 or whatever you will call it will need to tackle those
localization convergence. I think this will be one of the biggest next
coming challenge (I would say along with the refactoring of the on_change
methods crap: the positional arguments based system instead of dictionary is
a major source of module incompatibilities, for instance now, if you install
the Brazilian localization with both sale and delivery, you will need a
third crappy localization module that would just override
sale#partner_id_change to make it compatible, otherwise you are screw; if
you need a new module for every module combo, modularity is a dream).

I see two ways localizations can play nice together on the same install in
the future:

1) adopt generic concepts common to all localizations (for instance things
we did with the 'account_fiscal_position_rule',
 'account_product_fiscal_classification' modules, targetting primarily the
Brazilian localization, but in fact generic, so put in the extra addons).

2) invent a system so that some localization features, essentially
consisting into view extensions and method override can be applied only
company wide and not system wide.
For the views, it doesn't seem so complex, what we have for group visibility
would almost make it.
As for method overrides, it could be inside each localization methods, but
may be a smarter solution would be to hack the method dispatch directly to
make it company wise at some point.
Well those are just ideas for now.


Thank you for contributing to that important debate.


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

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



On Thu, Nov 4, 2010 at 12:45 PM, Nhomar Hernández <nhomar@xxxxxxxxxxxxxx>wrote:

> Hello.
>
> I think as Rvalyi
>
> the unique option here is improve the core with blueprints explained and
> propose for merge.
>
> Several "Concepts" Commun for almost all LATAM are  in Venezuela
> Localization.
>
> -- WithHolding:
> Take an amount of money as part of the invoicing process.
> For Example.
> You buy 100 $ with 12% of VAT.
> Total Invoice 112$
>
> But, Your "Fiscal Position" AND "Partner Fiscal Position" said by law:
>
> You will pay in this way to your supplier:
>
> 103$ more a "Paper" that represent the another 9$ this 9$ are called
> "WithHolding " In Spanish "Retención"
>
> This is one case. there are at least in colombia and Venezuela 20 Variants
> for Customers and 20 Variants for Suppliers the combination between them
> generate automatically a "Especific Fiscal Position".
>
> For this reason, we build several modules to make:
> -- LEgal Data to filter conditions.
> -- Report to print the report necesary to pay or receive "WithHoldings".
> -- Fiscal Report to declare this "WithHoldings" to Goverment.
> -- XML interface to connect to state.
>
> For this at least 10 modules has been builded.
>
>
> -- "DEbit Note":
>
> OpenERP (And at least 99% of european Software.) Has 4 transaction types
> Invoice - Refund (in ando out), but, In LA exist a transaction called "Debit
> Note", from an accounting point of view is exactly like an Invoice, but from
> an administrative point of view is an invoice "extending" the transaction
> from other Invoice (see module debit_credit_note).
>
> We make a little improve very very simple to be used in reports, and put
> some inteligence in the "rml " files.
>
> http://bazaar.launchpad.net/~openerp-venezuela/openerp-venezuela-localization/trunk/files/head%3A/debit_credit_note/<http://bazaar.launchpad.net/%7Eopenerp-venezuela/openerp-venezuela-localization/trunk/files/head%3A/debit_credit_note/>
>
> IOH, by law (and for a functional point of view), we in Venezuela MUST to
> have strong (m2o) relation between "debit notes| refund"  and this is not in
> core, obviously with simply ad a field it is enough, we did it, and imporve
> a wizard to verify this at the end of the  month by hand if in some case you
> didn't put this relation, for this verification we used
> l10n_ve_fiscal_reports + debit_credit_note module.
>
> -- Several other thing....
>
> BTW Friend Nicolas, if OpenERP SA want to broke the world with SAAS
> services NEED trust in them partners and community members as Jordi - Pexeg
> - Akretion - US to give you OUR point of view for a Generic way to do this
> stuff.
>
> To us take at least 6 month study, Laws - Accountig - Finance in depth to
> really understand what i trying to explain in one mail, for this reason, I
> think Oerp SA has 2 options.
>
> -- Allow more than 1 module per localization and improve a "profile" module
> to install them, mantained by community with access to core and audited with
> a clear process from local experts named by you.
> -- Improve by yourself all basic and common concepts necesary to manage
> this law's stuff.
>
>
> The first one is a LOT less expensive to the second one but obviously you
> will need to share the credits around this modules,
>
> *I really want to see in every corner around the world people using
> OpenERP bu*t, with this little options you will be only in the 8 countries
> that use Accounting proccess as Belgium and france.
>
> Please think about this, because, if it isn't in this way, we localization
> team will need to use SEPARATE branches again and the merge of localization
> process will be lost time.....
>
> With all respect.
>
> Nhomar Hernandez.
>
> Localization Team Leader
> Venezuela
>
> 2010/11/4 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/%7Eopenerp-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<https://launchpad.net/%7Eopenerp-expert-localization>
>> Post to     : openerp-expert-localization@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-expert-localization<https://launchpad.net/%7Eopenerp-expert-localization>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Saludos Cordiales
>
> Nhomar G. Hernandez M.
> +58-414-4110269
> Skype: nhomar00
> Web-Blog: http://geronimo.com.ve
> Servicios IT: http://openerp.com.ve <http://openerp.netquatro.com>
> Linux-Counter: 467724
> Correos:
> nhomar@xxxxxxxxxxxxxx <nhomar.hernandez@xxxxxxxxxxxxx>
> nhomar@xxxxxxxxxxxxxxx
>