openerp-community team mailing list archive

[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
>
>