openerp-community team mailing list archive

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