openerp-expert-accounting team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello guys,

While progressing on the full Brazilian fiscal support, we polished the two
announced modules, I think we they are close to done.
I updated the documentation to take our last changes into account here:
http://docs.google.com/View?id=ajb639cjf9fb_15c8gxjqcq
As for the second module, the fiscal position rule engine, we started
documenting it in Portuguese here (but there are screenshots + Google
translate):
http://docs.google.com/Doc?docid=0ATrgrnwli9VhZGZzajZzcF84Y2R4YzY4cTU&hl=en&pli=1

I'm now replying and detailing the changes:


@Bruno,
taxes carried by categories will attend in some cases. But:
a) they won't work in with multi-companies because a taxes will force some
taxes no matter the company (neither the categ_id neither the taxes it
carries are OpenObject properties; also OpenObject doesn't even support
properties for one2many or many2many fields which might also be an annying
limitation by the way.
b) in Brazil it's not possible: you really need to carry more than a half
dozen of taxes per product due to the fiscal rules and you really need the
"fiscal code of the product" to be within the official "NCM" common Mercosul
Nomenclature (containing over 10 000 codes I think):
http://www.mdic.gov.br/sitio/interna/interna.php?area=5&menu=1090
So using categories fro that would really mean you can't use them anymore as
categories...


@Cloves
Along with Luc Maurer from CampToCamp, we agree that the current built'in
fiscal position may not have an optimal flexibility.
However, without a clear and very strong support from Tiny in refactoring it
(we clearly don't have it), we do not dare to change its default behavior
for the 5.2 which is to be frozen in less than 2 months. So whole system we
built is fully compatible with the existing fiscal_positions. As long as
they do their mapping work, then you will have Brazilian axes right. If we
started tweaking around them to let them have more params for instance we
would have needed to refactor all their call which is absolutely not
possible in an isolated module. Without that support from Tiny should have a
huge patch and break a ton of modules. So, I'm all open for improvement of
the fiscal position engine for 2011 and later, but in the meantime we have
to support the Brazilian Accounting in a compatible and light way. What we
did does it.


Also, I had an interesting phone talk with fellow Luc Maurer from
CampToCamp. He told me three important points that I took into account in
the new implementation:

1) It has to work in a multi-company context. So, it's better that the
fiscal_position of a product is an OpenObject "property" that can be company
wise.
Optionally the fiscal position is tied to a company and carry that company
taxes. Then you can only select that fiscal position if you belong to that
company (or if you are admin; rules being used). Eventually you can still
share the fiscal position by not assigning it to a company. In that case
however it's always available.

2) Luc told me that if you need to have a localized fiscal code, you will
likely have a local company selling it (or you won't need the code to be
localized). So, instead of a code having n possible country variants, I
simplified and removed that option: just use the right company wise fiscal
position in that case.

3) In case you use the report_intrastat module, then the fiscal code should
be the same as the product code from report_intrastat.
That later is a tough one. Yes, we could have tried to have the same object
as report_intrastat to define a code, but that mean we would have lost the
multi-company handling and that would be an awkward dependency.
Actually, I think report_intrastat should depend on the new
"account_product_fiscal_classification" module, rather than the reverse!
So, to have a clean coherent solution, we would need TINY to accept
refactoring report_intrastat a bit to have a dependency
upon account_product_fiscal_classification and use the product fiscal code
field instead of the product "report_intrastat_code".


Moreover, as we announced once in the forum, we did an extensive polish of
the "report_intrastat" module for our customer Anevia.com to meet more
carefully the French legal requirements. Still, I think what we changed in
report_intrastat was mostly common sense that is very likely to better fit
for any legislation requiring stats on imported/exported products (for
instance: allow intrastat entries that have no financial moves like for a
product return under warranty; @Cloves this by the way is how we plan to
support fully the Brazilian "Nota Fiscal", take the potential discount price
into account when the intrastat entries corresponds to a normal invoice
etc...)
We will make our best to explain you and Tiny next all the improvements we
made to report_intrastat for Anevia. We would like to see you guys analysis
our changes so it could hopefully get merged into 5.2.
This might not be perfect yet, because we didn't allow ourself to largely
refactor Tiny's own code yet, but motivated folks can take a look to our
work and commits here:
https://code.launchpad.net/~akretion-team/+junk/report_intrastat

So currently this code doesn't take into account the point 3) we mentioned
here. We are all OK to contribute that last refactoring miles if we get your
and Tiny's blessing for it. Otherwise, it's just pointless to kill ourself
trying to improve the software if that's not going to happen anyway. BTW, I
think that's were we have issues with Tiny, we need them to do their work in
orienting community work. We did here important things they can't even
tackle themselves, it's capital they just tell us if we can merge it in 5.2
or what should be done else.


Issues encountered:
- as noted here we hit a framework limitation with domain that I think would
be better removed. I'll talk about it in more details in a next mail on the
framework list + possibly a blueprint+patch.
- I'm really not sure the situation of trunk is correct (and I'm sure 5.0.x
is not) regarding to product taxes when you sale a same product in multiple
companies: Luc believed taxes are a company wise property. But because
property don't work for many2many, they are not, so they are all attached to
the product! You could hide them using rules, but, when picking them to
assign them to an order/invoice lines, I'm quite sure OpenERP doesn't give a
shit to the tax company, meaning it will blows out saying your try to make a
move with different account charts. If we really want a decent multi-company
support out of the box, we need to fix this!


All right folks,

I'm now replying to the community expert thread with the worries about Tiny
lack of reactivity in those expert lists (here
http://n3.nabble.com/Simple-things-we-need-from-Tiny-for-better-bug-planning-management-tc132053.html#nonefor
those who are not member; Tiny wanted it restricted). As I'll explain,
I'm quite optimistic given the recent re-organization inside Tiny and I'll
let them present their plan to tackle our doubts.


Raphaël Valyi
http://www.akretion.com


2010/1/7 Cloves Almeida <cjalmeida@xxxxxxxxx>

> Hi Raphael,
>
> The ridiculously complex Brazilian tax code possibly have all corner cases
> in existence :)
>
> About the rule engine, my suggestions:
> I strongly suggest that it be a  scriptable python snippet.  It gives more
> flexibility because tax rules can get really nasty.
> An "item" browse object would be passed into context then the developer
> could navigate to get item detail, partner, order, company, etc.
>
> The developer would return either
> a) False or None, indicating the tax does not apply.
> b) True, indicating that id does apply.
> c) A decimal/float indicating it does apply but a different tax percentage
> should be applied
>
> The last one is optional, since you could achieve the same behavior with
> another rule; still it makes life a bit easier.
>
> Best regards,
>
> Cloves
>
> Raphaël Valyi escreveu:
>
>> Hello,
>>
>> We are currently leading the Brazilian localization of OpenERP and we were
>> missing a few things that are very important. Basically the Brazilian
>> fiscality is rather complex: for instance a product may have 3 different
>> kind of VAT all together and depending the state where you sale the product,
>> one of those VAT ratio will switch between two values or more (and this is
>> actually a lot more complex than that).
>>
>> So we needed two things:
>> 1) the need to easily generate for each product all those different
>> sale/purchase taxes (letting the user enter every product tax manually was
>> not an option and we would miss the fiscal classification in fiscal reports)
>>
>> 2) the need to easily filter the taxes that will actually apply to your
>> specific sale/purchase. Actually every product get a lot of different base
>> taxes (like 5/6 sale taxes, but half get nullified by the fiscal position
>> applied. Is that a valid approach (we can just let the fiscal position
>> switch a tax, because it's there are per product switch while the fiscal
>> position is per order).
>>
>>
>> For 1) de developed a simple module called
>> account_product_fiscal_classification
>> Please read the details and screenshots here:
>> http://docs.google.com/View?id=ajb639cjf9fb_15c8gxjqcq
>>
>> For 2) we rely on the fiscal position feature of course, but we created a
>> rule engine selecting the appropriate fiscal position depending on the user
>> company and partner fields. But I'll talk about that one again later when it
>> will be more polished.
>>
>> So I would like to know your feedback about
>> account_product_fiscal_classification
>> Do you find it useful in your country? Do you have change suggestions?
>> Does it make sense, as we thought to release it a generic module in trunk
>> extra addons rather than just part of the Brazilian localization? For
>> instance, in France where fiscality is simpler (yes I know that's tough to
>> hear), I think installing this module is also an easy way to make sure
>> product taxes are not forgotten by the people entering products and it can
>> even help generating the few VAT taxes.
>> So what do you think?
>>
>>
>> Thank you for your feedback/suggestions.
>>
>> Raphaël Valyi
>> http://www.akretion.com
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-expert-accounting
>> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>