openerp-expert-accounting team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

xrg,


> [...]
>  - countries like BR might require that there are the XB-11, XB-35 and
> XB-42
> forms in the UI, that the partner has a VAT, local area and
> samba-preference
> field, and that the 4th-digit of the VAT will always match the partner's
> street
> number. And that the tax-calculation formula can support logarithmic and
> 4th-
> order Fibonacci generators. Whatever. There, we need to test and ensure
> that
> the framework can support all that.
>

I can feel some troll here ;-)

Seriously, when I was implementing OpenERP in France 2 years ago, I was
thinking France was had complicated accounting rules. But seriously, Brazil
is just an order of magnitude more complex I give you in plain English an
idea why the core of OpenERP (without all the stuff we spent months to
develop) is really far from doing the job alone in Brazil:


- for an industry for instance, each product is sold with around 4 taxes at
the same time (not just a VAT) (a few ones: ICMS, IPIS, COFINS...). The base
layout of those taxes is governed by a global "Mercosul" product fiscal
classification (NCM)  (that's why the account_product_fiscal_classification
module). Actually some taxes will be nullified, but given that OpenERP
fiscal mapping can only switch account and values, we have to put them all
before the mapping process.

- some of those taxes are included in the price, other not and all the order
(what's in the base), has to be respected carefully. Given the fact that
OpenERP has at best experimental support for single tax included you can
imagine the trouble.

- some of those taxes that are supposed to be "included in the price" are
computed over the following base: product + taxes not included in the
price...

- some taxes like ICMS, are a kind of VAT, but vary depending on:
the federal state of the seller, the fereral state of the buyer, the type of
buyer ("pessoa juridica" or "pessoa fisica")... (that's why the
account_fiscal_position_rule module)

- there are VAT compensations system between states ("beneficio", a bit like
European countries use to have intrastat declarations).

- delivery price can't be a product line, but has to be a global "manual"
tax, something currently broken in OpenERP 6 (we have a patch coming).

- invoices have to be sent via signed WSDL webservices now. In Brazil, in
most SMB's companies now, printing invoices won't do it, to fight corruption
and tax escape, they are making electronic invoicing mandatory everywhere.
If you want to stick with your Python toy, you'll be short to implement
there WSDL over HTTPS API, something they do well in Java and we fire
directly from within TerminatOOOR thanks to the JRuby integration.

- invoices or picking documents should mention some extra fields (like type
of operation and e few others), this has to be propagated, in every possible
workflow, from the sale order. And electronic invoicing will fail if you
miss those extra fields (and if you say to your customer to digit them
manually they will laugh at you and go with a proprietary package).

- every stock move between companies/states should be accompanied by some
kind of "intrastat" invoice but for Brazil (eg if you re-send warranted
product even without charging them, if you move product between too
warehouses).

- like other localizations, to compete with proprietary packages, we should
have bank interfaces of course

- but in Brazil, lot's of things are sold "at credit" in several payments
terms. We even use to have bank interfaces to register customer payments so
your bank will try to collect the money, a bit like a factor (but with no
warranty here). This is a common feature in Brazil (called Boleto's), even
for B2C.


We also need the core of the ERP to work of course (and no this is not
trivial).

Well, I'm pretty sure the list is not over, so you see, when I see OpenERP
SA people taking care of just "the chart of account", well, excuse me, but I
feel I need to restore the truth about the level of support I'll get with
just that (cause I anticipate some BR Odoo already with same marketing
mystification and I tell you without that code logic integration, here is
all what you'll miss and that's considered basic here. If SAP, Microsoft or
Oracle or Sage have less than 3% of the Brazil SMB market shares, complexity
and poor ROI (at least in the past) was largely part of the explanation.

I hope this bring us back on the ground about localization issues with
OpenERP 6 (and I'm pretty sure other countries could present similar
discrepancy lists, even in Europe). I know that v6 can't be perfect of
course, that's perfectly normal, we know that open source is made of
iterative processes. I just hope we are all aware of the limitations of the
core framework, not hiding them and working together to have a better native
support for localizations in future versions of OpenERP. In the meantime,
yes, it's probable that BR companies will need at least a good part of the
stack of modules we have been developing and releasing as GPL in Launchpad.


Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

<http://www.akretion.com.br/>