openerp-community team mailing list archive

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

Hi Raphael, Hi Pedro

thanks for your suggestions, I will analyze that duely. Should be better to
work on a converging standard rather than create a competing one... ;)

Raphael can you elaborate on your last paragraf to make it understnadible
for a newcomer? Links? (OCA web_context_tunnel; signature
incompatibilities; new API by every addon)

Best from Bogota


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