openerp-community team mailing list archive

[Humberto Arocha <humbertoarocha@xxxxxxxxx>]

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" <david@xxxxxxxxxxx>
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*
>
> +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 19:35 GMT-05:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:
>
>> *comments in plain red*
>>
>>
>> 2014-06-23 18:34 GMT-05:00 Gustavo Adrian Marino <gamarino@xxxxxxxxx>:
>>
>> Raphäel, David:
>>>
>>> I really believe we should not fall in love with Odoo, so hard than we
>>> try to explain everything in a Odoo compatible way.
>>>
>>> Taxes are part of legislation. And in all countries I know, they are
>>> organized in three levels: Federal or nationals, Federal States and local
>>> (Municipal). Each level has his own taxes and rules to be applied to
>>> products, companies and types of transactions.
>>>
>>> Why not try to define objects in OpenERP following the same logic? It
>>> will be easier to explain to customers and accountants, to implement and to
>>> spot errors in configuration.
>>>
>> *​Somehow, we're trying to achieve exactly this in the present colombian
>> localizacion effort by defining tax domains (which can split up further
>> each level into its corresponding concepts (eg. VAT, Coustoms, Retentions,
>> etc.). This should be a rather short list not superating 20 different
>> concepts in most countries. (hint for europeans, who might not understand
>> at all, what we are talking about: European countries mostly have only 1 of
>> those domains on the invoice level: VAT)​ The hirachy information is
>> implicit to the domain, as users usually know, which tax is from which
>> level (eg. VAT = national).*
>>
>>
>>> Let's tie tax definitions to national, federal states and
>>> locations/cities (defined once for every company and transaction they
>>> apply).
>>>
>> ​*This is exactly the proposed concept of tax application steered by
>> decision tables. After it's release you should be able to define a state
>> tax based on the combination of state and additional attributes of partner
>> and product (attributes ideally clusterd under the "state tax" domain) -
>> transacction attribute, or how a brazilian collegue called it "attributes
>> of the invoice.line level" should be not too difficult to implement. It was
>> kept in mind while coding.*
>>
>>  Lets make easy to apply the mandatory taxes and cases. Let's tie the
>>> specific taxes to companies, products and types of transactions where they
>>> belong and conditionally if they dont belong to some of them: to companies,
>>> products and documents (invoices, refunds and payments).
>>>
>> *​What we're working on is fully conditional like so: If set of
>> conditions met, then apply set of tax/taxcodes and go to next condition set
>> and apply it additionally in a way so that the same tax is only applied
>> onces.​*
>> *You could probably define standard state taxes in a set of rules under
>> the "state tax" domain, and then apply some additional special cases under
>> some additional circumstances under the same state tax domain.*
>> *I acknowledge that sometimes deviation from standard case, in other
>> words alteration of a tax (as it is done by the fiscal position rule
>> concept) would reduce complexity. Also, having kind of logical operators on
>> rule conditions would greatly reduce complexity. See task formulation
>> further down...*
>>
>> *Is there a tax concept which is applied on the generating fact
>> (causación), but not reversed on the reversal (refund) of its generation
>> fact??? This would be once more typical of south american creative
>> jurisdictions...*
>>
>>>
>>> The idea of making a flexible but complex set of rules, not natural to
>>> anyone out of the OpenERP world seems to me at least difficult to
>>> understand.
>>>
>> *​To reduce complexity, we propose the use of fiscal domains. It's left
>> to be seen in action to determin how complex it really is, but i belive
>> "separate and conquer"​ is always a good strategy to cutting through
>> complexity. Think of defining a fiscal domain "State Tax", so then you're
>> only looking at state tax rules, and you can only apply taxes that are
>> within this domain (or have no domain), and you can only take
>> product/partner attributes of this domain (or which have no domain), etc.
>> So then, once finished with "State Taxes", you might parametrize "national
>> taxes" or let's say "IVA" the next day, you can fully filter on that, and i
>> hope it's rather easy to grasp, once understanding "additionality" (which
>> might be not sufficient for complexity reduction)*
>>
>> *What is missing at this stage of development, is community/city taxes
>> and transaction attributes (invoice.line level attributes), as this is not
>> the most urgent focus for colombia. but should be easy to implement, as
>> said before.*
>>
>>>
>>> My 2 cents.
>>>
>> ​*Thank you,​ i've the same complexity concerns in fact in mind. And I
>> see that a first release of the module would probably not be optimzied
>> completely. I therefore want to state two pending tasks already here for
>> public consideration:*
>> *- Apply configurable logical operators to rules' conditions. (Common use
>> case made simple: If I'm in state X and partner is NOT in my state -
>> Reduces number of rules by factor of number of states)*
>> *- Unify the concepts of fiscal positions (where the module is partly
>> derived from) and fiscal allocations. A posible approach could be to define
>> child rules on application rules which define exeption handling and have an
>> inherent ALTERATION logic, constrained to parent rules for even more
>> usability. (would greatly reduce complexity in the case, that a standard
>> case applies taxes, which in a very special case should not apply)*
>>
>>>
>>> And I really appreciate your commitment to pursue your ideas and your
>>> good attitude of sharing your thoughts with us
>>>
>> ​*Thanks, I very much apreciate your feedback!*
>>
>>> Best regards
>>>
>>> Gustavo Adrian Marino
>>>
>>> Mobile: +54 911 5498 2515
>>>
>>> Email: gamarino@xxxxxxxxx
>>>
>>> Skype: gustavo.adrian.marino
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2014-06-23 19:12 GMT-03:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:
>>>
>>>>  ​Another Idea:
>>>>
>>>> Couldn't there be a company_id field as a many2many field or is this
>>>> incopatible with the ​core rutoines on company_id fields? Like this every
>>>> object could be individually assigned to various companies in a flexible
>>>> way.
>>>>
>>>> I'm sure though I missed something.. ;)
>>>>
>>>>
>>>> ----------------------
>>>> *David Arnold B.A. HSG*
>>>> *Gerente*
>>>>
>>>> +57 315 304 1368
>>>> david@xxxxxxxxxxx
>>>> www.elaleman.co
>>>>
>>>> ​El Alemán S.A.S, Carrera 13 # 93 - 40 P4, Bogotá D.C, Colombia
>>>>
>>>>
>>>> 2014-06-23 17:04 GMT-05:00 David Arnold - El Alemán <david@xxxxxxxxxxx>
>>>> :
>>>>
>>>> Thank you Raphael! I'm on the edge of understanding ;)  After further
>>>>> research, I would even consider my previous question obsolete, as all
>>>>> (relevant stuff) that fields.property() does is implement a company_id
>>>>> statment on a domain search.. This company_id-domain search however is in
>>>>> my case already implemented at the moment of application. so using
>>>>> properties as many2many (if there were such) would result in doing the same
>>>>> thing twice.
>>>>>
>>>>> *Further comments in orange.*
>>>>>
>>>>> 2014-06-23 16:22 GMT-05:00 Raphael Valyi <rvalyi@xxxxxxxxx>:
>>>>>
>>>>> Hello David,
>>>>>>
>>>>>> I'm not sure about the performance trade-off you may need to do.
>>>>>> Usually I would say assigning taxes isn't really a bottleneck fortunately
>>>>>> (as long as you wouldn't be crazy enough to use them in the fields of
>>>>>> decision tables).
>>>>>>
>>>>> ​*I might have reason to be concerned, as I might have been crazy
>>>>> enough ;)*​ The situation so far is [] of properties of the actual
>>>>> tax case on a inoice.line basis (collectet from m2m fields of product and
>>>>> partner) matching against a [] of properties of the tax rule set by a
>>>>> regular many2many field.
>>>>>
>>>>>> That being said there is an other important functional consideration
>>>>>> in our experience: sometimes the several companies belong to the same tax
>>>>>> jurisdiction and sometimes not...
>>>>>> That is if you force to share tax settings between companies it may
>>>>>> not work in some situations.
>>>>>> While on the other hand, if you force to re-configure possibly
>>>>>> complex tax settings when companies belong to the same tax jurisdiction,
>>>>>> well you might force your customer to depend on expert fiscal consulting
>>>>>> when he isn't psychologically ready for that...
>>>>>>
>>>>> ​*Thanks for the hint!*​ *I think this also refers to a comment made
>>>>> by Gustavo Marino earlier on multicompany setups.*
>>>>>
>>>>>>
>>>>>> So as I explained in a other post, in Brazil we started with
>>>>>> properties and changed some fields to regular many2one to cut the
>>>>>> bureaucracy in case of companies sharing similar settings. We did that for
>>>>>> the fiscal classification (the "Nomenclatura Comum do MERCOSUL" in Brazil)
>>>>>> attached to the product.template.
>>>>>> A possible evolution that may fulfill all requirements in this case
>>>>>> would be 2 fields: 1 m2o property and and regular m2o. If the m2o is set it
>>>>>> would shadow the property setting. That may fit most of the use case (the
>>>>>> case with some companies of the DB sharing tax settings and some other not
>>>>>> is very rare and can still be addressed by using properties all the way at
>>>>>> the cost of the extra bureaucracy of setting all these properties).
>>>>>>
>>>>> ​*Probably a more elegant and generic solution could be via templates
>>>>> and then run template updates sporadically on different companies. Although
>>>>> this is not a true share on the object level, it might cover the needs and
>>>>> include optional extra flexbility on the company level. I ignore however,
>>>>> if a template is able to update content or just can create content, and if
>>>>> the latter, how difficult it would be to add sort of a diff-funcionality
>>>>> (update, create, unlink).*
>>>>>
>>>>> *I say this because similar issues arise on account charts, e.g. if
>>>>> the mother house has a given, but extensible set and wants to populate it
>>>>> within the holding companies with regular updates. So abstracting, this is
>>>>> a generic multicompany maintainance topic...*
>>>>>
>>>>>>
>>>>>> I'm not sure what would be these many2many relations in your case
>>>>>> though.
>>>>>>
>>>>> ​*As explained above​, the idea is to have a highly flexible set of
>>>>> properties on products and partners, clustered by tax domains*
>>>>> *e.g.:*
>>>>> *Product: Airbus A380*
>>>>> *Property 1: Fiscal Domain = VAT; Attribute Use = Product; Name = "has
>>>>> a left wing (attribute for left wing tax exempt rule XY as of law 12345 of
>>>>> 1995)"*
>>>>> *Property 2: Fiscal Domain = IPI; Attribute Use = Product; Name = "I'm
>>>>> a passenger aircraft"*
>>>>> *Property 3: Fiscal Domain = Withholding; Attribute Use = Product;
>>>>> Name = Not subject to tax withholding as of national development plan 1369
>>>>> of 1634"*
>>>>> *Property n: Fiscal Domain = Aduana; Attribute Use = Product ; Name =
>>>>> "Aircraft over 200 metric tons"*
>>>>>
>>>>>
>>>>> *Partner: Client in Zona Franca Property 1: Fiscal Domain: Aduana;
>>>>> Attribute Use = Partner_Shipping; Name = "Professional Aircraft buyer under
>>>>> National Aircraft prolifertion regime"*
>>>>> *Property n: ....*
>>>>>
>>>>>>
>>>>>> Regards, and sorry for not having looked deeply at your work yet.
>>>>>>
>>>>> ​*It's still debugging ;)*​
>>>>>
>>>>>>
>>>>>> --
>>>>>> Raphaël Valyi
>>>>>> Founder and consultant
>>>>>> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
>>>>>> +55 21 3942-2434
>>>>>> www.akretion.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán <
>>>>>> david@xxxxxxxxxxx> wrote:
>>>>>>
>>>>>>> *Hi*
>>>>>>>
>>>>>>> I already read some remarks on pros and cons about property fields.
>>>>>>>
>>>>>>> As far as my knowledge reaches, property fields are not best for
>>>>>>> performance. On the other side, you can assign to the same object (let's
>>>>>>> say a product) various properties based on the current users company.
>>>>>>>
>>>>>>> The case is an advanced tax engine (posted about before), where I
>>>>>>> have to make a choice about, wether to implement fiscal properties of
>>>>>>> products and partners as ir.properties or as regular many2many fields.
>>>>>>>
>>>>>>> If the decision would be principally in favor of fiscal properties,
>>>>>>> if the benefits of properties would justify to hack the core method in
>>>>>>> fields.py to accomodate many2many properties.
>>>>>>>
>>>>>>> *Thank you beforehand for your opinion.*
>>>>>>>
>>>>>>> *Best*
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~openerp-community
>>>>>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~openerp-community
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openerp-community
>>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openerp-community
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openerp-community
>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openerp-community
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
> _______________________________________________
> 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
>
>