← Back to team overview

openerp-community team mailing list archive

Re: many2many Property Fields


Last but not least, this concept is at least configurable by an accountant.
So far we oftentimes see hard coded concepts that are only configurable by
developers. I acknowledge that with the pace of changing tax jurisdiction
in south america this might be a sustainable resource of income.

But it definitly not is what the coustomers want.

Here in Colombia, many people have stated privately to me, that service of
some local partners is very bad and unresponsive (= general colombian
cultural issue). They would love to only depend on inhouse accountants,
which oftentimes are the most knowledgable people of the organization... ;)

*David Arnold B.A. HSG*

+57 315 304 1368

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

2014-06-23 19:35 GMT-05:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:

> *comments in plain red*
> 2014-06-23 18:34 GMT-05:00 Gustavo Adrian Marino <gamarino@xxxxxxxxx>:
> Raphäel, David:
>> I really believe we should not fall in love with Odoo, so hard than we
>> try to explain everything in a Odoo compatible way.
>> Taxes are part of legislation. And in all countries I know, they are
>> organized in three levels: Federal or nationals, Federal States and local
>> (Municipal). Each level has his own taxes and rules to be applied to
>> products, companies and types of transactions.
>> Why not try to define objects in OpenERP following the same logic? It
>> will be easier to explain to customers and accountants, to implement and to
>> spot errors in configuration.
> *​Somehow, we're trying to achieve exactly this in the present colombian
> localizacion effort by defining tax domains (which can split up further
> each level into its corresponding concepts (eg. VAT, Coustoms, Retentions,
> etc.). This should be a rather short list not superating 20 different
> concepts in most countries. (hint for europeans, who might not understand
> at all, what we are talking about: European countries mostly have only 1 of
> those domains on the invoice level: VAT)​ The hirachy information is
> implicit to the domain, as users usually know, which tax is from which
> level (eg. VAT = national).*
>> Let's tie tax definitions to national, federal states and
>> locations/cities (defined once for every company and transaction they
>> apply).
> ​*This is exactly the proposed concept of tax application steered by
> decision tables. After it's release you should be able to define a state
> tax based on the combination of state and additional attributes of partner
> and product (attributes ideally clusterd under the "state tax" domain) -
> transacction attribute, or how a brazilian collegue called it "attributes
> of the invoice.line level" should be not too difficult to implement. It was
> kept in mind while coding.*
>  Lets make easy to apply the mandatory taxes and cases. Let's tie the
>> specific taxes to companies, products and types of transactions where they
>> belong and conditionally if they dont belong to some of them: to companies,
>> products and documents (invoices, refunds and payments).
> *​What we're working on is fully conditional like so: If set of conditions
> met, then apply set of tax/taxcodes and go to next condition set and apply
> it additionally in a way so that the same tax is only applied onces.​*
> *You could probably define standard state taxes in a set of rules under
> the "state tax" domain, and then apply some additional special cases under
> some additional circumstances under the same state tax domain.*
> *I acknowledge that sometimes deviation from standard case, in other words
> alteration of a tax (as it is done by the fiscal position rule concept)
> would reduce complexity. Also, having kind of logical operators on rule
> conditions would greatly reduce complexity. See task formulation further
> down...*
> *Is there a tax concept which is applied on the generating fact
> (causación), but not reversed on the reversal (refund) of its generation
> fact??? This would be once more typical of south american creative
> jurisdictions...*
>> The idea of making a flexible but complex set of rules, not natural to
>> anyone out of the OpenERP world seems to me at least difficult to
>> understand.
> *​To reduce complexity, we propose the use of fiscal domains. It's left to
> be seen in action to determin how complex it really is, but i belive
> "separate and conquer"​ is always a good strategy to cutting through
> complexity. Think of defining a fiscal domain "State Tax", so then you're
> only looking at state tax rules, and you can only apply taxes that are
> within this domain (or have no domain), and you can only take
> product/partner attributes of this domain (or which have no domain), etc.
> So then, once finished with "State Taxes", you might parametrize "national
> taxes" or let's say "IVA" the next day, you can fully filter on that, and i
> hope it's rather easy to grasp, once understanding "additionality" (which
> might be not sufficient for complexity reduction)*
> *What is missing at this stage of development, is community/city taxes and
> transaction attributes (invoice.line level attributes), as this is not the
> most urgent focus for colombia. but should be easy to implement, as said
> before.*
>> My 2 cents.
> ​*Thank you,​ i've the same complexity concerns in fact in mind. And I
> see that a first release of the module would probably not be optimzied
> completely. I therefore want to state two pending tasks already here for
> public consideration:*
> *- Apply configurable logical operators to rules' conditions. (Common use
> case made simple: If I'm in state X and partner is NOT in my state -
> Reduces number of rules by factor of number of states)*
> *- Unify the concepts of fiscal positions (where the module is partly
> derived from) and fiscal allocations. A posible approach could be to define
> child rules on application rules which define exeption handling and have an
> inherent ALTERATION logic, constrained to parent rules for even more
> usability. (would greatly reduce complexity in the case, that a standard
> case applies taxes, which in a very special case should not apply)*
>> And I really appreciate your commitment to pursue your ideas and your
>> good attitude of sharing your thoughts with us
> ​*Thanks, I very much apreciate your feedback!*
>> Best regards
>> Gustavo Adrian Marino
>> Mobile: +54 911 5498 2515
>> Email: gamarino@xxxxxxxxx
>> Skype: gustavo.adrian.marino
>> 2014-06-23 19:12 GMT-03:00 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
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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

Follow ups