openerp-community team mailing list archive

[Gustavo Adrian Marino <gamarino@xxxxxxxxx>]

I hope that what Odoo is going to present is the start of a community
discussion and not as usual what they decided we should think.

We know how hard is to adapt the vision of OpenERP to the real needs we
face in our markets. Even if what they propose as new features is aligned
with our needs, v9 means we are talking about something 12/18 months ahead.
It is too far away for any real solution.

We already know what to expect from OpenERP S.A. and v8. Let's work to make
our work a little bit easier. Do not expect too much from Odoo.

A common criteria on taxes treatment is a desirable goal, and something it
could save us real work.

Best regards

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: gamarino@xxxxxxxxx

Skype: gustavo.adrian.marino






2014-06-02 14:42 GMT-03:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:

> So *please, anyone, *tag this conversation as relevant for such talks!!!!
> ;)
>
>
>  ----------------------
> *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-06-02 12:09 GMT-05:00 Marcelo Bello <marcelo.bello@xxxxxxxxx>:
>
> David, just a heads up, there is a focus on accounting and changes to
>> allow for greater tax flexibility for v9, I think on OpenDays there will be
>> a talk just on that. May be good to get to know how SA is thinking about
>> this.
>>  On 2 Jun 2014 12:54, "David Arnold - El Alemán" <david@xxxxxxxxxxx>
>> wrote:
>>
>>> To sum it up in a kind of to do list for Colombia tax project
>>> (containing additional items):
>>>
>>> - widen concept of fiscal position to be allocation (and not only
>>> replacement tables)
>>> - allow for n allocation tables, n product attributes and n partner
>>> attributes (ideally grouped around tax domains), which steer behaviour of
>>> fiscal position roules (tax controller)
>>> - reframe fiscal classification to match the requirements of being a n
>>> product attribute
>>> - prepare for generic granularity (now via individual XML reports) - >
>>> maybe pentaho integration
>>> - allow tax precision be independent of account precision (blame OpenERP
>>> SA R&D for not being able to solve this since 2011 despite several bug
>>> reports and fierce discussion)
>>> - allow tax chart queries for an individualized set of periods (not just
>>> one) - in case reporting periods differ on different concepts
>>>
>>> Anything to add? Further comments?
>>>
>>> *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-06-02 10:32 GMT-05:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:
>>>
>>>> *Hello Marcelo, Hello Gustavo*
>>>>
>>>> I hope that at least during World Championship, Brazilian accountants
>>>> might find some spare time to watch some games... ;)
>>>>
>>>> I think the kind of flexibilzation proposed, could get you generically
>>>> covered on everything which are attributes of partners and products. It is
>>>> true that the invoice line itself, in other words: the specific
>>>> characteristics of a particular sale  (which are not attributed to partner
>>>> or product) are somewhat difficult.
>>>>
>>>> The Tax Include /Base Amount Include topic I also noticed. The *Core
>>>> here seems utterly buggy *afaik, Akretion completely overwrote it to
>>>> make it somewhat intelligent. See a pull request, i made recently: https://
>>>> github.com/odoo/odoo/pull/219
>>>> (I think I'm not the first one to notice, that bugs/pull requests are
>>>> handled very inefficiently at the moment? A perceived lack of respect.
>>>> Other projects do that way better. Hint!)
>>>>
>>>> I got the AHA moments. ;) I think probably the tax break logic can be
>>>> kind of a generic use case. In some countries of the world, there are a lot
>>>> of Free Trade Zones and probably special tax brakes. But I'm not sure, if
>>>> this should be calculated on the invoice or even line-item
>>>> granularity. My best guess is rather that it is more appropriate to account
>>>> for such situation at an accounting level.
>>>>
>>>> As to *Argentina* it seems, the that tax system is very parallel to
>>>> the Colombian one. I'm not sure about the "activity", because in fact this
>>>> is kind of an aggregate product classification. In case of Colombia we
>>>> are talking about CIIU (ISIC: http://unstats.un.org/unsd/cr/registry/
>>>> isic-4.asp), which can be mapped for example to product classification
>>>> CPC (http://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=25&Lg=1). So
>>>> in fact "activity" refers to kind of a simplified product
>>>> classification, which is trying to cover the standard case, where one
>>>> company is dedicated to one or few activities. But caution! A company
>>>> can pursue multiple activities depending on the specific product it is
>>>> producing. So this way, the CIIU is a *product * attribute.
>>>>
>>>> I think as to the base done, we have great modules like Fiscal
>>>> Classification and Fiscal Position Rule available, however these must
>>>> be altered, to reflect an adaptable high level logic. (The ones mentioned
>>>> by Pedro and Raphael) Fiscal Position Rule already allows for a logic
>>>> depending on State, Country (all three: Issuer Address, Delivery or
>>>> Invoice Address) But what it does lack is to account for other fiscal
>>>> attributes of the partner and the product.
>>>>
>>>> On the partner side, there can be applied for example in the case of
>>>> the domain of a specific national tax a *retention *depending on
>>>> issuer *and * buyer characteristics. This actually is not an available
>>>> attribute in Fiscal Position Rule. On the other Hand, *fiscal
>>>> classification * is a module to provide tax-sets on products. If we
>>>> dismantle this concept, it comprises a classification + an actual
>>>> allocation (two in one). Additionally, it is single-dimension. So there is
>>>> only one possible classification available at the moment.
>>>>
>>>> The Brazilian localization from Akretion (credits!) tackle this issues
>>>> in a very country specific and "hard coded" way. But it's readily available
>>>> for *"genericalization" *If you think then the Fiscal Position module
>>>> as an extensible controller logic, you probably could cover all Argentinian/
>>>> Venezuelan/etc. tax cases.
>>>>
>>>> Such a common framework would then also be easier to adapt at those
>>>> Brazilian specialties (such that line order attributes are important).
>>>>
>>>> I value your ideas, of abstracting taxes further. Actually when having
>>>> dinner yesterday with the localization team we ran about the idea of an
>>>> completely independent tax enginge with an API to provide for south
>>>> America's ERP, to outsource the headache of tax calculation to a
>>>> central company. (Hint for smart entrepreneurs!) There are some US
>>>> companies for a possible exit strategy on such a project. I think, such
>>>> ideas are probably outside the focus of OpenERP (I know, the culture
>>>> is somewhat let's copy/reinvent the wheel in some cases, but you probably
>>>> already know my opinion on that).
>>>>
>>>> However some aspects, I see, can be covered by the localization
>>>> *templates* (not the updating aspect). You can define tax accounts on
>>>> the general ledger an allocate taxes to, etc. To abstract this, I'm not
>>>> sure, if that wouldn't be too specific, as you would have map your accounts
>>>> to a set of tax-concepts (kind of tax api), but this set of concepts can be
>>>> very dynamic as per jurisdiction. So this mapping effort would have to be
>>>> done also in case of an update in the mapping structure.
>>>>
>>>> A side note on aggregating granularity to obtain tax statements: I
>>>> think that the Odoo way of displaying taxes (Chart of Taxes will in
>>>> the near future become deprecated as concepts such as XBRL (http://es.
>>>> wikipedia.org/wiki/XBRL) win ground. Basicially you take a xml-tag of
>>>> the official or national "taxonomy", then you define which data has to be
>>>> aggregated around that specific tag, then you file via XML to your
>>>> authorities) This granularity approach will certainly be necessary for a
>>>> lot of countries (also for statistical reporting, which can be tied to
>>>> taxes or not). So I think at least we wouldn't have to bother to much about
>>>> in which tax account to strategically allocate a tax perspectively.
>>>> (Maybe the whole concept of tax accounts will get deprecated, as
>>>> granularity advances, as it's basically replicated information and a
>>>> violation of the DRY principle)
>>>>
>>>> I think, it would be very helpful if you could publish your code on
>>>> github, in order to be able to analyze it and look for parallel
>>>> concepts. Maybe the multicompany-management approach can be refactored
>>>> as a compatible delta module in the future?
>>>>
>>>> The Colombian one lives at: https://github.com/odoo-colombia/odoo-
>>>> colombia
>>>>
>>>> @ Ana: Europe gratefully in't the sad standard of tax complexity. The
>>>> only tax retention to be known in Germany is in construction (as a sector
>>>> which has a lot of tax evasion).
>>>>
>>>> *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-06-02 9:11 GMT-05:00 Gustavo Adrian Marino <gamarino@xxxxxxxxx>:
>>>>
>>>> Let me add some considerations for Argentina: In our country is very
>>>>> clear that the taxes to be applied are dependant on:
>>>>>
>>>>>    - The issuer company, and the possibility to act as a retention
>>>>>    agent for some taxes
>>>>>    - The issuer activity
>>>>>    - The fiscal address: one set of taxes could be potentially
>>>>>    applied based on city, federal state and country
>>>>>    - The product
>>>>>    - The buyers activity
>>>>>    - The buyers fiscal address
>>>>>
>>>>> If you are trying to define a new way to treat taxes, for sure the
>>>>> idea of redefining the tax structure per company (as today in Odoo) and
>>>>> "fixing" via a simple table is simply not reflecting reality nor the common
>>>>> use pattern of any real customer
>>>>>
>>>>> I have started developing a module to redefine taxes accounts as
>>>>> properties per company and assigning a set of taxes to federal states and
>>>>> countries. This set of taxes should be applied depending on issuing
>>>>> companies fiscal federal_state and country.
>>>>>
>>>>> This arrangement allows us to deliver an incremental set of taxes
>>>>> covering first the country level and then federal state taxes as needed.
>>>>> This taxes could be configured AFTER the company account plan is set for
>>>>> the company set needed, and thus allowing to adapt the DB to changes in
>>>>> taxes without having to do manual editing on every company in the database.
>>>>>
>>>>> Of course a set of company specific taxes is also provided
>>>>>
>>>>> Additionally, due to the fact now taxes are global (not company
>>>>> specific), you can define taxes on products without be worried to point to
>>>>> the exact account on each company, and avoiding to rely on obscure access
>>>>> rules to manage taxes.
>>>>>
>>>>> Under the new scenario, accounts could be only visible to the company
>>>>> they are defined on, reflecting the fact they are strongly tied to
>>>>> company's account plan.
>>>>>
>>>>> Under this schema, the need of fiscal positions for customers is
>>>>> strongly reduced to some simple cases, reflecting just special cases for
>>>>> some customers, and thus using the simple standard approach is enough in
>>>>> most cases.
>>>>>
>>>>> The module is still not in production. If you think this approach
>>>>> could be used as a common strategy, I have no problem publishing it
>>>>>
>>>>> Best regards
>>>>>
>>>>>
>>>>>
>>>>> Gustavo Adrian Marino
>>>>>
>>>>> Mobile: +54 911 5498 2515
>>>>>
>>>>> Email: gamarino@xxxxxxxxx
>>>>>
>>>>> Skype: gustavo.adrian.marino
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2014-06-02 10:14 GMT-03:00 Marcelo Bello <marcelo.bello@xxxxxxxxx>:
>>>>>
>>>>> David, my 2cents as an user of the Brazilian localization (I am not
>>>>>> aware of all the technical challenges, I am just speaking from an end user
>>>>>> PoV).
>>>>>>
>>>>>>    The idea of an application instead of replacement table sounds
>>>>>> good to me. Usability-wise I always found strange that by default a product
>>>>>> would have dozens of taxes pre-applied to it only for most to be filtered
>>>>>> out later in the process. Again, I am sure there are design decisions to
>>>>>> justify that, but usability-wise it is not ideal.
>>>>>>
>>>>>>    Regarding what you say about the flexibility of the current
>>>>>> implementation, I agree with you that some pieces might be missing, but at
>>>>>> least in the context of the Brazilian tax legislation what you propose will
>>>>>> still not cover the full range of possibilities that need to be taken into
>>>>>> account.
>>>>>>
>>>>>>     At least in the case of Brazil, the taxation of a sale needs to
>>>>>> take into account information from:
>>>>>>
>>>>>> - The buyer/partner;
>>>>>>
>>>>>> - The product itself;
>>>>>>
>>>>>> - The seller (the company selling, in the case of a company with
>>>>>> multiple branches - like my company - this is extremely relevant because
>>>>>> some of my branches are on special trade zones which change the tax
>>>>>> calculation significantly);
>>>>>>
>>>>>> *- The order.line: *for example, a product in Brazil is taxed
>>>>>> differently depending on whether the buyer plans to resell the item or if
>>>>>> it is going to consume it (or add it to its assets).
>>>>>>
>>>>>> *- The product unit being sold* - yes, some pieces of legislation
>>>>>> requires us in Brazil to keep track of individual units so that they are
>>>>>> sold the same way they were bought. Sometimes this do not impact the tax
>>>>>> rate, but do impact the tax codes we need to use to fill eInvoicing,
>>>>>> sometimes it affects both. For instance, in Brazil if I buy an imported
>>>>>> product from a distributor, the goods I purchased from that distributor
>>>>>> will use a specific CST code, but if I import it myself I will have to sell
>>>>>> them with another CST code. In a few cases even the tax rate changes. For a
>>>>>> company like mine, we sometimes buy locally, sometimes import and this kind
>>>>>> of "lot-number-like" control is very difficult to handle without an ERP
>>>>>> system. Our localization still can't handle this.
>>>>>>
>>>>>>       Think about it and check if in your country you do not have
>>>>>> cases where you need info from order.line (or even just the order itself),
>>>>>> and/or if you need to do the lot-number-like tracking I mentioned in some
>>>>>> cases. Of course, these two last items account for a smaller % of total
>>>>>> transactions in my country, but they are relevant for a large number of
>>>>>> organizations (they happen often enough that one wishes it were handled by
>>>>>> their ERP system).
>>>>>>
>>>>>> *A few more things to consider before you get your hands dirt:*
>>>>>>
>>>>>> - As far as I know, today the tax calculation does not work well as
>>>>>> an independent tax-engine. Therefore, it is hard to make Odoo provide the
>>>>>> sales agent a table like the one below (showing taxes as a function of sale
>>>>>> location). This is useful for companies that are trying to optimize their
>>>>>> taxation, avoiding taxes when possible. Companies usually achieve this by
>>>>>> setting up factories or branches in special tax locations so it is
>>>>>> interesting if the system can be made easy to offer tax simulations like I
>>>>>> show in the table below, so that a sales agent can place the order in the
>>>>>> best possible way.
>>>>>>
>>>>>>              Product Cost     Tax A     Tax B     Tax C        Total
>>>>>>
>>>>>> Location A       X              X         X         X            X
>>>>>>
>>>>>> Location B       X              X         X         X            X
>>>>>>
>>>>>> - At least in Brazil, taxes have an hierarchy. Taxes must be
>>>>>> calculated on top of a base value. Such base value sometimes is the value
>>>>>> of the goods being sold but sometimes, for some taxes, it is the value of
>>>>>> the goods PLUS the value of another tax (so tax applies over other tax, in
>>>>>> cascading style). Maybe this is an exclusivity of the crazy Brazilian tax
>>>>>> legislation, maybe not, but one needs to consider it for the tax engine to
>>>>>> work well.
>>>>>>
>>>>>> - Taxes may or may not be part of the product price. In Brazil
>>>>>> usually the price list is inclusive of some taxes so the total price to be
>>>>>> paid by the client will not change if some taxes (that are included in the
>>>>>> price) change;
>>>>>>
>>>>>> - It would be wise if the system had three fields for each tax rate:
>>>>>> (a) tax_rate_for_display: the tax rate % used for display purposes;
>>>>>> (b) tax_rate_for_invoice_calculation: the tax rate % used for
>>>>>> calculating the tax used for invoicing;
>>>>>> (c) tax_rate_for_effective_payment: the tax rate % that will actually
>>>>>> be paid to the government
>>>>>>
>>>>>>         Usually a=b=c, but not ALWAYS!
>>>>>>
>>>>>> (b) is for when you have a tax that is not applied in the usual
>>>>>> TAX_AMOUNT=BASE_VALUE*TAX_RATE way. Hence you need to convert the way the
>>>>>> tax must actually be calculated so that it will work when calculated in the
>>>>>> standard TAX_AMOUNT=BASE_VALUE*TAX_RATE. We have one such case in Brazil,
>>>>>> where the tax called ICMS must be calculated in a way that the tax_rate is
>>>>>> applied over the value of the goods PLUS the value of the ICMS tax itself!
>>>>>> Yes, the tax applies over itself (this is usually the AHA moment, when
>>>>>> foreigners realize how fucked up our tax system is in Brazil). So ICMS has
>>>>>> a tax rate of 25%,18%,17%,12%,7%,4% or 0% depending on a number of
>>>>>> variables. When you need to print the tax rate applied you must write 18%,
>>>>>> but the tax rate you actually use to calculate the tax is given by the
>>>>>> formula TAX_AMOUNT = BASE_VALUE * [1/(1-TAX_RATE)-1]. Hence the need for
>>>>>> the field (b) tax_rate_for_invoice_calculation, one would write (a) = 0.18,
>>>>>> (b) = 0.21951219512 in this example.
>>>>>>
>>>>>> (c) is for when a company has a tax incentive that is not reflected
>>>>>> on the invoices (which is very often in Brazil). So for instance, I may
>>>>>> have a tax break and instead of paying 10% tax I effectively pay only 5%.
>>>>>> But the government still requires me to issue my eInvoices with the 10%
>>>>>> rate like everyone else and I am given a rebate at the end of the month. So
>>>>>> for accounting purposes, in this example we would have (b) = 0.10, (c)
>>>>>> =0.05.
>>>>>>
>>>>>>         So one can actually have a situation where all three fields
>>>>>> are different. Not sure you have a similar case in Colombia.
>>>>>>
>>>>>>         I wanted to point out all these use cases so that if there is
>>>>>> a coordinated effort to standardize across the "tax calculation engine"
>>>>>> some of these items could be taken into account (not all of them I am
>>>>>> sure).
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Marcelo
>>>>>> On 2 Jun 2014 02:54, "David Arnold - El Alemán" <david@xxxxxxxxxxx>
>>>>>> wrote:
>>>>>>
>>>>>>> *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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>