← Back to team overview

openerp-expert-accounting team mailing list archive

Re: Openerp accounting constraints module -> ideas?

 

Hi Fred,

Welcome aboard. Very good point – this and the costing method
(average/standard) should be global options as they are determined by the
accounting policy for stock valuation not on a by product option.

Yet even with these fixes, the mrp functions our of the box are a far cry
from being suitable in production where real-time integration with
accounting is used.



* *

*Vadim Chobanu*

Managing Partner

[image: enapps logo email]



T: +44 020 8090 9222

M: +44 079 3923 0959

E: vadim@xxxxxxxxxxxx

W: www.enapps.co.uk

-------------------------------------------------------------------------
Information in this email is confidential and may be privileged.
It is intended for the addressee only. If you have received it in error,
please notify the sender immediately and delete it from your system.
You should not otherwise copy it, retransmit it or use or disclose its
contents to anyone.
Thank you for your co-operation.
-------------------------------------------------------------------------

Address: 010 Coppergate House; 16 Brune Street; London E1 7NJ

Registered in England No: 07746264

Reg. VAT No. GB 124 1001 86









*From:* openerp-expert-accounting-bounces+vadim=
enapps.co.uk@xxxxxxxxxxxxxxxxxxx [mailto:
openerp-expert-accounting-bounces+vadim=enapps.co.uk@xxxxxxxxxxxxxxxxxxx] *On
Behalf Of *fred blauer
*Sent:* 28 October 2012 15:16
*To:* Joël Grand-Guillaume
*Cc:* Quentin; openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx Experts
*Subject:* Re: [Openerp-expert-accounting] Openerp accounting constraints
module -> ideas?



I just completed the training last week, so I am a little new to the
conversation. But I am a Canadian Chartered Accountant and have worked with
other ERP/accounting systems. I think that some of the things discussed
here are very important for the data integrity of the core accounting. One
of the other things that I noticed is some potential problem with
accounting integration to the inventory control. It seems that you can set
the accounting method to periodic or real time by product. It seems to me
that this could cause a lot of confusion, especially when we look at real
time integration of the manufacturing inventory with the accounting. For
example, what would happen if you set the raw materials to periodic, and
the finished goods (produced ) to real time, or vice versa? Wouldn't this
cause a lot of problems and confusion? Has someone verified all the
permutations and combinations of accounting entries that would be produced
to see if they are correct? I can't think of any reason why this should be
allowed. In other words, why not make periodic vs. real time inventory
accounting a global option for the whole company only? I think that this
would be a lot safer, and I don't think it would unnessarily restrict
anyone.

On Thu, Oct 25, 2012 at 10:13 AM, Joël Grand-Guillaume <
joel.grandguillaume@xxxxxxxxxxxxxx> wrote:

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




_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-accounting
Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-expert-accounting
More help   : https://help.launchpad.net/ListHelp




-- 
Fred Blauer CA, CA.IT, CISA
http://openacct.ca
fred@xxxxxxxxxxx
514-667-1555

PNG image


Follow ups

References