openerp-community team mailing list archive
-
openerp-community team
-
Mailing list archive
-
Message #05888
Re: Multiple fiscal positions on partners
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
>
>
Follow ups
References