openerp-expert-accounting team mailing list archive

[Nhomar Hernández <nhomar@xxxxxxxxx>]

@Joel.

I really think we need this for v7.0 it will help a lot in new
implementations and even avoid a lot of mistakes.

Question:

Can we make 2 little task?:

1.- Put in runbot.
2.- Make a copy to test in our enviroments and propose to you some
pre-mergeproposal?

Regards.

2012/10/31 Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>

> 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 <fblauer@xxxxxxxxx> 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 <
> vadim@xxxxxxxxxxxx> 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: 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 <http://ca.it/>, CISA
>> http://openacct.ca
>> fred@xxxxxxxxxxx
>> 514-667-1555
>>
>
>
>
> --
> Fred Blauer CA, CA.IT <http://ca.it/>, CISA
> http://openacct.ca
> fred@xxxxxxxxxxx
> 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: 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
>
>


-- 
--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
nhomar@xxxxxxxxxxxxxx
nhomar@xxxxxxxxxx
twitter @nhomar