openerp-community team mailing list archive

[Ana Juaristi <ajuaristio@xxxxxxxxx>]

Hello Gustavo:
Its not so easy.
In Spain, for instance taxes are only set by product and after by customer
but we do not have such state, federal, local structure that you are
telling us.
 El 24/06/2014 01:34, "Gustavo Adrian Marino" <gamarino@xxxxxxxxx> escribió:

> 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.
>
> Let's tie tax definitions to national, federal states and locations/cities
> (defined once for every company and transaction they apply). 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).
>
> 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.
>
> My 2 cents.
>
> And I really appreciate your commitment to pursue your ideas and your good
> attitude of sharing your thoughts with us
> 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
>
>