openerp-community team mailing list archive

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