openerp-community team mailing list archive
Mailing list archive
Re: many2many Property Fields
Thank you Raphael! I'm on the edge of understanding ;) After further
research, I would even consider my previous question obsolete, as all
(relevant stuff) that fields.property() does is implement a company_id
statment on a domain search.. This company_id-domain search however is in
my case already implemented at the moment of application. so using
properties as many2many (if there were such) would result in doing the same
*Further comments in orange.*
2014-06-23 16:22 GMT-05:00 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).
*I might have reason to be concerned, as I might have been crazy enough ;)*
The situation so far is  of properties of the actual tax case on a
inoice.line basis (collectet from m2m fields of product and partner)
matching against a  of properties of the tax rule set by a regular
> 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...
*Thanks for the hint!* *I think this also refers to a comment made by
Gustavo Marino earlier on multicompany setups.*
> 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).
*Probably a more elegant and generic solution could be via templates and
then run template updates sporadically on different companies. Although
this is not a true share on the object level, it might cover the needs and
include optional extra flexbility on the company level. I ignore however,
if a template is able to update content or just can create content, and if
the latter, how difficult it would be to add sort of a diff-funcionality
(update, create, unlink).*
*I say this because similar issues arise on account charts, e.g. if the
mother house has a given, but extensible set and wants to populate it
within the holding companies with regular updates. So abstracting, this is
a generic multicompany maintainance topic...*
> I'm not sure what would be these many2many relations in your case though.
*As explained above, the idea is to have a highly flexible set of
properties on products and partners, clustered by tax domains*
*Product: Airbus A380*
*Property 1: Fiscal Domain = VAT; Attribute Use = Product; Name = "has a
left wing (attribute for left wing tax exempt rule XY as of law 12345 of
*Property 2: Fiscal Domain = IPI; Attribute Use = Product; Name = "I'm a
*Property 3: Fiscal Domain = Withholding; Attribute Use = Product; Name =
Not subject to tax withholding as of national development plan 1369 of
*Property n: Fiscal Domain = Aduana; Attribute Use = Product ; Name =
"Aircraft over 200 metric tons"*
*Partner: Client in Zona Franca Property 1: Fiscal Domain: Aduana;
Attribute Use = Partner_Shipping; Name = "Professional Aircraft buyer under
National Aircraft prolifertion regime"*
*Property n: ....*
> Regards, and sorry for not having looked deeply at your work yet.
*It's still debugging ;)*
> Raphaël Valyi
> Founder and consultant
> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
> +55 21 3942-2434
> On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <
> david@xxxxxxxxxxx> wrote:
>> 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.*
>> 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