openerp-community team mailing list archive

[Ana Juaristi <ajuaristio@xxxxxxxxx>]

Just to let you know that fiscal position aproach is valid for spain, the
way it is defined by now.

Here, we have got fixed taxes for different kind of products. So each
product needs a different tax % to be applied.
After that, the taxes are translated to the correct ones depending on
customer fiscal position.

No extra developments needed for our country regarding to fiscal position
or taxes.
Just my 2 cents.





2014-06-02 16:11 GMT+02: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
>>
>>
>
> _______________________________________________
> 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
>
>


-- 
CEO Avanzosc, S.L <http://www.avanzosc.es> : Office phone / Tfono oficina:
(+34) 943 02 69 02
Ana Juaristi Olalde <http://www.anajuaristi.com/>: Personal phone: 677 93
42 59. User/usuario skype: Avanzosc
www.openerpsite.com


*El contenido de esta comunicación y de toda su documentación anexa es
confidencial y se dirige exclusivamente a su destinatario. El uso no
autorizado de esta información está prohibido por la legislación vigente.
Si usted no es el destinatario le rogamos nos lo indique, no comunique su
contenido a terceros y proceda a su destrucción. Disculpe las molestias que
le haya ocasionado la recepción indebida de este e-mail. Sus datos figuran
en un fichero cuyo titular es Avanzosc, S.L., a quien usted puede dirigirse
para ejercer sus derechos de acceso, rectificación, cancelación y oposición
en Julio Urkijo, 32, 20720, Azkoitia (Gipuzkoa), Tef. 943 02 69 02 -
administracion@xxxxxxxxxxxx <soporte@xxxxxxxxxxxx> *

*Komunikazio honen edukia eta dokumentazio erantsia konfidentziala da eta
hartzaileak bakarrik jaso beharko luke. Indarrean dagoen legeriak debekatu
egiten du bertan eskainitako informazioa baimenik gabe erabiltzea.
Komunikazioa zuri iritsi bazaizu, baina zu ez bazara hartzailea, mesedez,
guri jakinarazi, eta jasotako informazioa ez inori jakinarazi eta suntsitu.
Barkatu okerreko email hau jasotzeak eragindako eragozpenak. Zure datuak
Avanzosc, S.L. enpresaren fitxategietan sartuta daude. Zure datuak atzitzea
eska dezakezu, bai eta, datuak zuzentzea, ezereztea eta tratamenduari aurka
egitea ere. Horretarako, enpresara jo dezakezu, helbide honetan: Julio
Urkijo, 32, 20720, Azkoitia (Gipuzkoa), telefonoa: 943 02 69 02 -
**administracion@xxxxxxxxxxxx
<soporte@xxxxxxxxxxxx> *
*This message and all documents attached to it are confidential and
intended only for the person or entity to which it is addressed. Any use of
this information by unauthorised persons is prohibited under current
legislation. If you received this message by error, please advise us,
destroy it and refrain from communicating its contents to third parties. We
apologise for any inconvenience receiving this email improperly may cause
to you. Your personal data are included in a file owned by Avanzosc, S.L.
If you want to exercise your rights of access, correction, erasure and
objection you can contact the Controller at Julio Urkijo, 32, 20720,
Azkoitia (Gipuzkoa), T: 943 02 69 02 – administracion@xxxxxxxxxxxx
<soporte@xxxxxxxxxxxx>*