Dear community, Dear Quentin,
Here is my merge proposal for implementing all accounting constraints. It implements all point where everybody agreed. We've make a consensus : https://code.launchpad.net/~jgrandguillaume-c2c/openobject-addons/account_constraints/+merge/132293 Comments et review we'll be welcome. We're looking forward to see this in the trunk :) Regards, Joël Le 29 oct. 2012 à 15:31, fred blauer <[email protected]> a écrit : > Thanks Vadim, and nice to meet you. I don't have a problem with different > costing for different products, as long as the valuation is based on the > costing method used for that product. But I don't believe the different > account methods (periodic vs. real time) should be mixed within the same > company since this could cause confusion with the accounting entries, like > the example that I gave. Are there any plans to restrict this in the new > version? > Sounds like you are saying that real time accounting integration with mrp > should be avoided for now. Do you recommend any add-ons for this, or is this > something that will change in 7.0? I heard something about the manufacturing > system being revised, but is someone dealing with the accounting integration > portion? > > On Mon, Oct 29, 2012 at 4:20 AM, Enapps :: Vadim Chobanu <[email protected]> > wrote: > 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 > > > <image001.png> > > > T: +44 020 8090 9222 > > M: +44 079 3923 0959 > > E: [email protected] > > 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...@lists.launchpad.net > [mailto:openerp-expert-accounting-bounces+vadim=enapps.co...@lists.launchpad.net] > On Behalf Of fred blauer > Sent: 28 October 2012 15:16 > To: Joël Grand-Guillaume > Cc: Quentin; [email protected] 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 > <[email protected]> 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 <[email protected]> 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: [email protected] > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-accounting > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-accounting > More help : https://help.launchpad.net/ListHelp > > > > > -- > Fred Blauer CA, CA.IT, CISA > http://openacct.ca > [email protected] > 514-667-1555 > > > > > -- > Fred Blauer CA, CA.IT, CISA > http://openacct.ca > [email protected] > 514-667-1555 -- 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: [email protected]
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp
