openerp-community team mailing list archive

[David Arnold - El Alemán <david@xxxxxxxxxxx>]

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

*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
many2many field.

> 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*
*e.g.:*
*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
1995)"*
*Property 2: Fiscal Domain = IPI; Attribute Use = Product; Name = "I'm a
passenger aircraft"*
*Property 3: Fiscal Domain = Withholding; Attribute Use = Product; Name =
Not subject to tax withholding as of national development plan 1369 of
1634"*
*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
> 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
>>
>>
>