openerp-expert-localization team mailing list archive

[Borja LS <borjalopezsoilan@xxxxxxxxx>]

On 2010-11-04 16:05, Raphaël Valyi wrote:
> 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.

That is just the case for the Spanish localization. We made "too many" 
;) features on the 5.0 version. We hoped some of those features (like 
the fiscal-year-closing wizard improvements) to be integrated on the 
OpenERP v6.0 core accounting, but I know it's not an easy task...

> 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've seen some products implementing multi-country features, like 
allowing the users to have two simultaneous charts of accounts. Nicolas 
asked the localization maintainers to create single-module 
localizations. As localizations add more features it becames harder to 
make them coexist on a single OpenERP installation: On 5.0 you might be 
able to install the Portuguese and Spanish charts of accounts at the 
same time (as they were separated modules) as they have no incompatible 
features, but I fear that on 6.0 (if finally there is one module per 
localization) it would be much harder as each localization will install 
a lot of features that may be incompatible (unless those features are 
implemented as common multi-localization addons).


> 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).

+1 for on_change methods refactoring. +1.5 if on_change methods are 
moved outside the view and into the model/controller (tnot easy, I don't 
even don't know an alternative, but it just feels bad to have behavior 
information on the views).

> 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).

+1 but it's not easy, as usually those localization needs and features 
do not receive publicity (I didn't knew there was an 
"account_product_fiscal_classification" [sounds like may be useful on 
some special tax management here]; and OpenERP SA didn't know the 
invoice sequences feature was fundamental outside Belgium and France) 
many localization developers may not be aware of them and reinvent the 
wheel again and again.

> 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.

As an example, if I install the full Spanish localization on one 
company, and the Portuguese localization on other company, I would see 
Spain-specific menu entries like the "347 report" on both companies :( 
It would be nice to be able to hide menus and fields based on the 
current company base-localization (not just the current user groups) to 
prevent this.

> 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.

Didn't got you here. What would do such method overrides? What do you 
override?


Regards.

--
Borja López Soilán
borja@xxxxxxx