openerp-expert-localization team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Xrg,

I agree, ideally localizations will come with tests (I think we didn't do it
for the Brazilian localization yet because the YAML stuff has been mature
only very lately and commitment to support OERPScenario too, test first only
works when it's not too much of a burden, I think we are finally here, but
it's very recent...).
I tend to think the Cucumber standard (eg OERPScenario), or even RSpec (also
runs though OOOR, it's used in the OOOR testsuite itself BTW) is more
appropriate for those complex cross modules scenario tests, but may be it's
just a personnal view).

Still IMHO it doesn't prevent from debating the localization modules layout
as we have been doing last two days in the localization list (was it the
"endless discussions" you were referring to?) as OpenERP, as the leader, is
expected to provide suitable guidelines that make sense and ruin OpenERP
modularity, one of its main benefits, as soon as you use it outside from
Belgium or France (the current one module per localization guideline issue).

I'm forwarding your mail to the localization list which I think was also the
main target.

Regards,


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

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







---------- Forwarded message ----------
From: P. Christeas <p_christ@xxxxxx>
Date: Sat, Nov 6, 2010 at 11:30 AM
Subject: [Openerp-community-leaders] Accounting rules for localized
versions: YAML
To: openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx, Ferdinand Gassauer <
office@xxxxxxxxxx>
Cc: Nicolas Vanhoren <nicolas.vanhoren@xxxxxxxxxxx>,
openerp-community-leaders@xxxxxxxxxxxxxxxxxxx


Following the discussions we're having these days about l10n_xx modules,
accounting features and legal requirements, I believe that the local
integrators and the community have to follow a trivial rule[1]:

 * All legal requirements for a country should be codes as (YAML) tests. *

.. well, not strictly YAML, but any of the supplied mechanisms could do.

The point is that whenever sth. is changed in the rest of OpenERP, the whole
thing should be tested against these cases (requirements).

Example (from Dr. Gassauer): whenever some invoice or account.move is
posted,
that entry shall never be allowed to change, or even the partner's "law-
scoping" details (such as company name, VAT no., I suppose) should be locked
down.
 --> write a yaml test that generates an invoice, and then tries to hack the
details in several ways. Ensure that all attempts fail [2].

Tests may be more important than the python code of the addons, itself.
Because, tests will make sure the code is ok and won't disappoint our
customers.
In some countries, it is a legal requirement, indeed, to run those tests and
prove (through them) that the ERP is obeying the law.

To OpenERP SA's developers, these tests will be a good guide to know that we
are not breaking some country's logic. Sometimes, better than skimming
through
endless discussions to find out what happened to each country's integration.


[1] It must not be a new idea. But I wanted to remind everybody of it.
[2] in such a common case, we could put the test somewhere central, so that
several countries can reuse the same code. I hope.


--
Say NO to spam and viruses. Stop using Microsoft Windows!

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community-leaders<https://launchpad.net/%7Eopenerp-community-leaders>
Post to     : openerp-community-leaders@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community-leaders<https://launchpad.net/%7Eopenerp-community-leaders>
More help   : https://help.launchpad.net/ListHelp