← Back to team overview

openerp-expert-localization team mailing list archive

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