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 [email protected] 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 <[email protected]>: > 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 < > [email protected]> 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 >> [email protected] >> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
