openerp-expert-localization team mailing list archive
-
openerp-expert-localization team
-
Mailing list archive
-
Message #00098
Re: Accounting rules for localized versions: YAML
On Saturday 06 November 2010, F. Gassauer wrote:
> Nevertheless I want to emphasize that customers willand do request that
> OpenERP (as any other ERP system) will conform to local laws and audit
> rules and will expect from partners implementing these localized OpenERP
> versions, that OpenERP can be lawfuly used as accounting system in this
> wider sense. IMHO the market acceptance will dramatically improve if
> OpenERP gets certified in one of the major economic or EU countries.
Well, I can think of different kinds of country requirements, let me do some
wild guess (most probably just a hypothesis):
- countries like BE may have an "if you don't cheat and can provide us with
all your account.moves, you are legal" rule. I think we are already fine for
countries like that.
- countries like FR could have a "you have to be able to print the FR-10AB
form in order to be compliant". We're there, too.
- countries like CH could have the "the CH-10AB form must be printed with the
ocrb.ttf font, because it needs to be machine readable". Done that, too
(recent commit, btw.)
- countries like AT have a "you have to be able to display all your moves in
a 'account-partner-inv.no.-credit-debit' table". Possible, but my proposed
tests will ensure that the layout is not broken by some careless
"improvement". Also the "you must NEVER be possible to manipulate an entry
after posting date" would be possible and formally verified through the tests.
(btw. see ISO27001 certification procedure. That's the one my little brain
happens to know.)
- countries like DE could have a "you must submit all your final version of
the software, let it pass certification and have it locked at the customer's
site" requirement. In that field, we might to improve a bit. Nevertheless, we
already are able to provide binary packages, have the structure to make
formally-acceptable releases etc.
- 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.
- country GR requires all the above, plus to have a few k EUR to spare for
the tax authorities in case of a "visit".
(of course, the country names and "features" are a fairy tale so far.) But I
think you can get the point.
It would be interesting to put these "must-haves" in some list, or wiki. Or do
we have them already and I'm missing something?
--
Say NO to spam and viruses. Stop using Microsoft Windows!
Follow ups