openerp-expert-accounting team mailing list archive

[Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>]

Hello Quentin,


That's a good idea to have such a kind of module to verify some of the points raised. But, honestly, we do need some
strong constraints on most of them.

I suggest I start an addons branch to make a MP on v7.0 that include all the points on which we agree.

We'll then discuss the possibility to include the others as a test in your module. We do also have some kind of complex
check that we currently made via SQL queries. I think we should include them in this module as well.

Thanks for your time, my MP will come ASAP.

Cheers !


Joël


Le 23 oct. 2012 à 13:42, Quentin <qdp@xxxxxxxxxxx> a écrit :

> Hello ,
> 
> i just exported in http://bazaar.launchpad.net/~openerp-dev/openobject-addons/trunk_account_test_qdp <http://bazaar.launchpad.net/%7Eopenerp-dev/openobject-addons/trunk_account_test_qdp> a module named 'account_test' that launches a bunch of checks validating the current state of the database (just have a look at account_test/account_test_data.xml), at request, and providing a report showing which test failed/succeeded.
> 
> This module was developed for v6 (i think) and the forward-port to trunk postponed because of a lack of resource. If you guys are willing to help, i suggest you to have a look at it. If it can work under v7 we can include it in this release :-)
> 
> We will review again all of the points raised and decide if it
> *can be a strong constraint or exception raised
> *should rather be included in the module account_test
> *should rather be addressed by a usability improvement
> *is rejected
> 
> Thanks for anything,
> Quentin
> 
> 
> On 22/10/12 18:55, Olivier Dony wrote:
>> On 10/22/2012 01:03 PM, Joël Grand-Guillaume wrote:
>>> To ease this work, we decided with Frederic to take time today  to summarize
>>> all the suggestions at the bottom of the pad
>>> (http://pad.openerp.com/p/accounting-constraints), taking car of all returns
>>> people made. All those constraints will be very much appreciated.
>> Thanks for coordinating the discussion and providing a summary!
>> (BTW, everyone who commented might want to review the summary)
>> 
>> We will analyze the outcome of the discussion in details asap and give feedback
>> on what could be done in the core modules, what belongs to a separate module,
>> what should be done in localizations, etc.
>> 
>> Based on that we'll be able to plan the next steps.
>> 
>> 
>>> Concerning the way to work normally with those constraints, I mean with not too
>>> much work overhead, we would suggest to always have the accounting entries of
>>> the current period in draft. This way, you can benefit of the constraints on
>>> all the validated work, and have a kind of ease to use on the current one. This
>>> would as well means that OpenERP should have a way to generate all accounting
>>> entries in draft (even invoices, bank statement, and so on). This is the way
>>> other accounting software are working as well. This is simple to understand,
>>> simple to implement and just work well.
>> Quick feedback on this one: having all entries as draft until a period is
>> closed seems to be quite the opposite of the original goal (more constraints).
>> That could mean not only a lot of bad surprises at the end of the period, but
>> also means that invoices would be editable even after being issued to the
>> customers. Yes OpenERP has an option to allow this, but it's been moved to a
>> separate module meant to be installed only in countries where this is legally
>> allowed.
>> Any feedback from the other contributors to the discussion?
>> 
>> 
>> In any case, we'll provide feedback on the complete summary soon.
>> 
>> 
>> Thanks!
> 
> <qdp.vcf>

-- 

Joël Grand-Guillaume 
Division Manager
Business Solutions

Camptocamp SA
PSE A, CH-1015 Lausanne
http://openerp.camptocamp.com/

Phone: +41 21 619 10 28
Office: +41 21 619 10 10
Fax: +41 21 619 10 00
Email: joel.grandguillaume@xxxxxxxxxxxxxx