openerp-community team mailing list archive

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

​Another Idea:

Couldn't there be a company_id field as a many2many field or is this
incopatible with the ​core rutoines on company_id fields? Like this every
object could be individually assigned to various companies in a flexible
way.

I'm sure though I missed something.. ;)


----------------------
*David Arnold B.A. HSG*
*Gerente*

+57 315 304 1368
david@xxxxxxxxxxx
www.elaleman.co

​El Alemán S.A.S, Carrera 13 # 93 - 40 P4, Bogotá D.C, Colombia


2014-06-23 17:04 GMT-05:00 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
>>>
>>>
>>
>