[Openerp-community] many2many Property Fields

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[Openerp-community] many2many Property Fields

David Arnold - El Alemán
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

Raphael Valyi
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).

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

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).

I'm not sure what would be these many2many relations in your case though.

Regards, and sorry for not having looked deeply at your work yet.

-- 
Raphaël Valyi
Founder and consultant
+55 21 3942-2434



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

David Arnold - El Alemán
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 <[hidden email]>:
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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp




_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

David Arnold - El Alemán
​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

​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 <[hidden email]>:
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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

Gustavo Adrian Marino
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: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-23 19:12 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
​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

​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 <[hidden email]>:

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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

David Arnold - El Alemán
comments in plain red


2014-06-23 18:34 GMT-05:00 Gustavo Adrian Marino <[hidden email]>:
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: <a href="tel:%2B54%20911%205498%202515" value="+5491154982515" target="_blank">+54 911 5498 2515

Email: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-23 19:12 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
​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

<a href="tel:%2B57%20315%20304%201368" value="+573153041368" target="_blank">+57 315 304 1368

​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 <[hidden email]>:

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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

David Arnold - El Alemán
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
Gerente

+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 <[hidden email]>:
comments in plain red


2014-06-23 18:34 GMT-05:00 Gustavo Adrian Marino <[hidden email]>:

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: <a href="tel:%2B54%20911%205498%202515" value="+5491154982515" target="_blank">+54 911 5498 2515

Email: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-23 19:12 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
​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

<a href="tel:%2B57%20315%20304%201368" value="+573153041368" target="_blank">+57 315 304 1368

​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 <[hidden email]>:

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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp




_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

Ana Juaristi
In reply to this post by Gustavo Adrian Marino

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" <[hidden email]> 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: <a href="tel:%2B54%20911%205498%202515" value="+5491154982515" target="_blank">+54 911 5498 2515

Email: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-23 19:12 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
​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

<a href="tel:%2B57%20315%20304%201368" value="+573153041368" target="_blank">+57 315 304 1368

​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 <[hidden email]>:

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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

Humberto Arocha
In reply to this post by David Arnold - El Alemán

Hello all you guys I am quite glad to see that tax issue has been addressed, though not un the regarding trend, sorry for preaching, 'cause I'll contribute to it,

We Vauxoo, formerly known as a branch of netquatro, developed a localization for Colombia on 2011

http://bazaar.launchpad.net/~openerp-colombia/openerp-colombia-localization/5.0/files

At that time we addressed those concerns in the way David is pointing

Actually, Vat withholding, income withholding and municipality withholding are addressed there,
That is: retencion Iva, retención en la fuente, y Retención ICA

In the same way we have being addressing the issues in Venezuelan Location

Best regards

On Jun 23, 2014 8:17 PM, "David Arnold - El Alemán" <[hidden email]> wrote:
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
Gerente

<a href="tel:%2B57%20315%20304%201368" value="+573153041368" target="_blank">+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 <[hidden email]>:
comments in plain red


2014-06-23 18:34 GMT-05:00 Gustavo Adrian Marino <[hidden email]>:

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: <a href="tel:%2B54%20911%205498%202515" value="+5491154982515" target="_blank">+54 911 5498 2515

Email: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-23 19:12 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
​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

<a href="tel:%2B57%20315%20304%201368" value="+573153041368" target="_blank">+57 315 304 1368

​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 <[hidden email]>:

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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434



On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp




_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

David Arnold - El Alemán
Hello Humberto

glad you join in, I actually have analyzed this module in depth, and I think - apart from rewriting part of the move.line logic (which porbably for 5 was necesary) - I think, what we are trying is kind of a synopsis of your approach, akretions approcha and the existing fiscal_position to make it more flexible...

For having tax records available for reporting I would rather point to JOIN operations or Postgresviews to get al necessary information ready for a cube to draw reports on. (see slide 15, 16 & 17 http://de.slideshare.net/openobject/business-intelligence-35790564)

I'm still debugging, but hope to get something presentable this week.

Best, David

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] many2many Property Fields

David Arnold - El Alemán

2014-06-24 12:44 GMT-05:00 David Arnold - El Alemán <[hidden email]>:
For having tax records available for reporting I would rather point to JOIN operations or Postgresviews to get al necessary information ready for a cube to draw reports on. (see slide 15, 16 & 17 http://de.slideshare.net/openobject/business-intelligence-35790564)

​As this might have been the major motivation to replay move.line logic...​


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp