openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello David,

this explains the problem and the temporary hack that is web_context_tunnel
that gives us a better compatibility with existing modules:
http://bazaar.launchpad.net/~server-env-tools-core-editors/server-env-tools/7.0/view/head:/web_context_tunnel/__openerp__.py

In the fiscal rules modules, there is room for such usage instead of
overriding some on_changes event in a way that makes them incompatibles
with other such overrides (because both try to alter the on_change
signature to pass their extra parameters in a function that sadly expect
python positional arguments).

I think what we do in Brazil illustrates that the fiscal rules modules can
be overriden a lot to meet more specific requirements. But if you spot
simple changes in these modules that would make it easier for you to use
it, then the OCA is listening to your suggestion because we understand that
it's a benefit to us all to implement minor enhancements if that allows
more people to consolidate around the same abstractions and tools.

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 11:42 AM, David Arnold - El Alemán <
david@xxxxxxxxxxx> wrote:

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