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 [email protected] 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 <[email protected]>: > 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 <[email protected]>: > > 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 < >> [email protected]> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~openerp-community >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
