openerp-community team mailing list archive

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

*Marcelo*

I just noticed, that probably this might help in declaring another amount
than our invoicing:
[image: Inline-Bild 1]

here you can say which percentage of the invoiced tax should go on the
respective tax account... From which reporting could be done.

*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 20:09 GMT-05:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:

> *Lorenzo Battistini*
>
> could you drop some comments on this from an italian perspective? I hope
> to fetch best practices from around the world!
> I've seen you've done quite a bit of coding in your localization, but on
> the other hand there are some modules rediliy available...
>
> - Fiscal Classification
> - Fiscal Position
> - Fiscal Position Rule
>
> Whith some amendemnds this could serve your case quite generically... But
> maybe we're missing something.
>
> *Mille Grazie*
>
> 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 14:01 GMT-05:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:
>
>  +1 for gustavo... Let's not be sheeps.. ;) (http://goo.gl/UISRs5)
>>
>>
>> ----------------------
>> *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 13:07 GMT-05:00 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>