openerp-community team mailing list archive

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

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