openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello David,

I'm not sure about the performance trade-off you may need to do. Usually I
would say assigning taxes isn't really a bottleneck fortunately (as long as
you wouldn't be crazy enough to use them in the fields of decision tables).

That being said there is an other important functional consideration in our
experience: sometimes the several companies belong to the same tax
jurisdiction and sometimes not...
That is if you force to share tax settings between companies it may not
work in some situations.
While on the other hand, if you force to re-configure possibly complex tax
settings when companies belong to the same tax jurisdiction, well you might
force your customer to depend on expert fiscal consulting when he isn't
psychologically ready for that...

So as I explained in a other post, in Brazil we started with properties and
changed some fields to regular many2one to cut the bureaucracy in case of
companies sharing similar settings. We did that for the fiscal
classification (the "Nomenclatura Comum do MERCOSUL" in Brazil) attached to
the product.template.
A possible evolution that may fulfill all requirements in this case would
be 2 fields: 1 m2o property and and regular m2o. If the m2o is set it would
shadow the property setting. That may fit most of the use case (the case
with some companies of the DB sharing tax settings and some other not is
very rare and can still be addressed by using properties all the way at the
cost of the extra bureaucracy of setting all these properties).

I'm not sure what would be these many2many relations in your case though.

Regards, and sorry for not having looked deeply at your work yet.

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 3942-2434
www.akretion.com



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <david@xxxxxxxxxxx
> wrote:

> *Hi*
>
> I already read some remarks on pros and cons about property fields.
>
> As far as my knowledge reaches, property fields are not best for
> performance. On the other side, you can assign to the same object (let's
> say a product) various properties based on the current users company.
>
> The case is an advanced tax engine (posted about before), where I have to
> make a choice about, wether to implement fiscal properties of products and
> partners as ir.properties or as regular many2many fields.
>
> If the decision would be principally in favor of fiscal properties, if the
> benefits of properties would justify to hack the core method in fields.py
> to accomodate many2many properties.
>
> *Thank you beforehand for your opinion.*
>
> *Best*
>
> David
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>