Community mailing list archives
Re: Accounting v9: updated specificationsby
Akretion, Raphael Valyi
this sounds nice overall and Sebastien gave us a positive feedback from the meeting. That's amazing if v9 makes the same leap in accounting than v8 did with WMS.
As you asked about fiscal stuff for Brazil which certainly is among the most bureaucratic cases you can imagine (if not the most), here are a the answers to your questions:
On Sat, Oct 25, 2014 at 1:46 PM, Fabien Pinckaers <firstname.lastname@example.org> wrote:
Dear Odoo community, Following our accounting workshop with community members (around 25 attendees from UK, NL, BE, CH, FR, RO, DE), we updated the accounting specifications for version 9: https://docs.google.com/document/d/1MahXh0TdfjI0ohdTSz_c8cML7HqxvcAtvSAY63N20Tc/edit?usp=sharing We still have a few open questions for the community: 1/ does anyone use "Python" computed taxes for another reason than: rounding (at 0.05 in Switzerland) or division computation (like in Bolivia or Brazil)
We don't use them in Brazil. Tax computations will never fit into a data model that will also fit other countries because it's way too specific (you are free not believing it, I just give us what we think after years of experience adapting Odoo here). So we have the localization extension modules do the right things. Hacking a lot the data model, python taxes would do it too certainly, but it's like the old Magento connector, if no power user actually tweak into the interactive DSL, it's just useless and harder to debug/maintain than pure Python code in regular modules.
2/ does anyone have refund Tax accounts that are different from the tax account of the related invoice? (I mean account.account, not account.tax.code)
Yes we do need a different account for tax refund in Brazil.
3/ do you sometimes have for THE SAME invoice, some lines which are with tax included in price and other lines with tax excluded of the price?
Absolutely for Brazil. In fact it's worse than that, there are between 4 to 6 taxes per invoice line with kafkaian tax computations with taxes included, excluded, included from some base but excluded for the base of the next tax of the same line, with base changing according to dozens of parameters going as far as the line unit of measure. It's not for no reason that big ERP players have close to zero market shares in Brasil SMB mid market or lower.
4/ did you ever needed a tax with two levels? (a tax that has children and those children also have children)
Hey, a complexity we don't have here... We don't need children of children taxes no.
As for the other parts of the document. We are only concerned with the removal of the tax codes and its hierarchy. We do use them and are going to use them even more in future consolidated fiscal reports (SPED). If you remove them I'm afraid we would just bring them back in some OCA module I believe But of course, that's up to you do decide what is covered/maintained as part of the standard modules and what is in OCA.
Now speaking about Brazil specifically, I don't think issues are technical anymore. I think what limits you in the market is only a commercial issue. Please don't let people which don't have a f*g clue about ERP's nor open source try to shape that market. Please listen the guys who make the things work instead and make fair deals, then you will meet your market.
Good luck with that and congratulation again for that v8 which set the bar quite high without any step back.