openerp-community team mailing list archive

[David Arnold - El Alemán <david@xxxxxxxxxxx>]

*Hello Raphael*

we are going forth with Colombia following your example.

At this stage I already can make my comments on the logic of the mentioned
set of modules, as they do not (yet) solve our problem, as initially stated.

Lets rename some of the concepts as mapped hereafter for better
understanding (speaking names at the right abstraction level):
fiscal position = replecement set (this is historically, but wrongly,
directly attached to the partner, because it can be equally dependent on
product caracteristics)
fiscal classification = fiscal attribute of product
fiscal position rule = replacement table controller

So what we are missing, and what you missed in barzilian localization is a
custom "fiscal attribute of partner", which then is taken by the
"replacement table controller" and funneled into the application of a
"replecement set" in the very moment that all relvant factors (fiscal
attributes of product, and fiscal attributes of partner) are available.

So we would have:
"replacement sets", which are controlled by the "replacement table
controller", which draws on "fiscal attributes of products" and "fiscal
attributes of partners" to determin the application of such sets.

Now given, that in south american countries there are various fiscal
concepts which - in the case of colombia - amount to 8 different taxation
concepts on a product (retentions included). This being said, in the world
of a one dimensional application of attributes (product and partner) and
sets, this actually amounts to the statistical combination of cases in each
concept (tax) domain. Lets say illustratively 5x2x4x5x12x5x8=96000
combinations. This is not the way to go! What we need therefore is a
flexibilisation by using the already built in tax domain concept to gather
taxes arround a specific domain - say VAT.

So the idea is, that partner and product each get an attribute per every
domain. (So if there are 8 domains, a partner or a product can have 8
respective attributes) And that each set of attributes is processed by the
replacement table controller to allocate a flexible set of replacement
tables, which are executed according to a specified sequence.

Even the creation of Tax domains, and the definition of domain items in the
respective tables should be dynamic, allowing for further flexibilisation.

I think even some concepts of brazilian tax structure have some more
generic cousins that you might have thought at the time of programming.
(but honestly, that's just an educated guess)

As leagel requirements in many jurisdiction, I think this should go into
core as "advanced taxes" some day...

*How is the situation in Thailand about those topics? Seems that Thailand
is quite similar to Colombia.*

*Nhomar,* have you checked the brazilian concepts? Might there be room for
convergence with venezuela and mexico? (maybe appling the above said)

When we start to override, where should we merge the generic portions of
code? I'd like to see that built in into the relevant Akretion modules...

*Best*, David





----------------------
*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-05-29 9:10 GMT-05:00 Raphael Valyi <rvalyi@xxxxxxxxx>:

> Hello David,
>
> double check but this OCA project may help you:
> https://launchpad.net/openerp-fiscal-rules
> And this is how we override it for Brazil for instance:
>
> https://github.com/openerpbrasil/l10n_br_core/blob/develop/l10n_br_account/account_fiscal_position_rule.py
>
> as far as I know this is also used in international commerce in Europe, in
> Canada and may be Italy or Spain.
>
> The idea is that the partner don't carry the fiscal position anymore
> exactly but instead we have that extensible intermediary flat decision
> table that will determine, depending on many extensible parameters
> (countries, states, fiscal types etc..) which fiscal position will apply
> exactly. That table can be large eventually.
>
> I think there is room to improve thee compatibility of these module for v8
> using the new OCA web_context_tunnel module to avoid creating signature
> incompatibilities with existing on_changes until the new API will be used
> everywhere in the addons (probably v9 only).
>
> Please let us know if these modules can help you.
>
>
> Regards.
>
> --
> Raphaël Valyi
> Founder and consultant
> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
> +55 21 3942-2434
> www.akretion.com
>
>
>
>
>
> On Thu, May 29, 2014 at 9:50 AM, David Arnold - El Alemán <
> david@xxxxxxxxxxx> wrote:
>
>> *Hello Fellows*
>>
>>  in Colombia we (some) are trying to adapt to local legislations by
>> following a concept of introducing multiple fiscal positions per parnter.
>> This sould only involve quite minimal code change, maybe same 30-50 lines
>> of code in total...
>>
>> The idea is to cluster fiscal positions under certain domains (such as
>> one tax1, tax2, tax3, tax4, tax5, etc.) and to be able to assing to a
>> partner an infinite number of fiscal postiones ordered by domains.
>>
>> If we don't introduce this multidimensionality of fiscal postitons, we
>> would have to multiply out (is this the corect term?) the matrix and get
>> some 5x5x5x5 (=4 domains with 5 cases each) fiscal positions... Not cool.
>>
>> Would this be a feature eligible for core aknowledging it's very small
>> code impact (using existing concepts) and its usefullness in more
>> complicated jurisdictions worldwide?
>>
>> Point two, is there some kind of classification flield on product known,
>> which can serve to prepare for granularity when it comes to concepts such
>> as BI and XBRL. We would like to link taxes and reporting requirements to
>> such product classification fields here in colombia. (there are about
>> 5000-6000 thousend different concepts of municipality tax, differing from
>> municipality to municipality - which are based on such a product - or
>> "activity " - classification)
>>
>>
>> *Freundliche Grüsse*
>>
>>
>>  ----------------------
>> *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
>>
>> _______________________________________________
>> 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
>>
>>
>