openerp-expert-accounting team mailing list archive

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

Hi,


First, thanks to start working on this, we really need it ! Just had a look on the runbot, and here is what failed:

1)
openerp.tools.yaml_import: I create a cash account with currency USD
2012-11-22 15:57:25,698 25691 ERROR trunk-account_constraints-qdp2_25720_all openerp.tools.yaml_import: ('Warning !', 'You cannot change the code of account which contains journal items!')
Traceback (most recent call last):
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/tools/yaml_import.py", line 862, in process
    self._process_node(node)
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/tools/yaml_import.py", line 873, in _process_node
    self.process_record(node)
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/tools/yaml_import.py", line 328, in process_record
    self.module, record_dict, record.id, noupdate=self.isnoupdate(record), mode=self.mode, context=context)
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/addons/base/ir/ir_model.py", line 925, in _update
    model_obj.write(cr, uid, [res_id], values, context=context)
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/addons/account/account.py", line 691, in write
    self._check_allow_code_change(cr, uid, ids, context=context)
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/addons/account/account.py", line 667, in _check_allow_code_change
    raise osv.except_osv(_('Warning !'), _("You cannot change the code of account which contains journal items!"))
except_osv: ('Warning !', 'You cannot change the code of account which contains journal items!')

=> Here, you'll need to change the YAML test. This not the constraints that is false, but rather the test that shouldn't do that !

2)
2012-11-22 16:02:14,267 25691 ERROR trunk-account_constraints-qdp2_25720_all openerp.tools.safe_eval: Cannot eval u'action_cancel()'
Traceback (most recent call last):
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/tools/safe_eval.py", line 242, in safe_eval
    return eval(test_expr(expr, _SAFE_OPCODES, mode=mode), globals_dict, locals_dict)
  File "", line 1, in <module>
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/osv/orm.py", line 375, in function_proxy
    return attr(self._cr, self._uid, [self._id], *args, **kwargs)
  File "/home/odoo/runbot/static/openerp-dev-trunk-account-constraints-qdp2-25720/server/openerp/addons/account_payment/account_invoice.py", line 36, in action_cancel
    inv_mv_lines = [x.id for x in inv.move_id.line_id]
3) Same reason !
4) Same reason !

=> just need a test more to avoid an empty list !


Well, so I corrected what's wrong on my branch (after merging your branch Quentin).

I resubmitted the work in the same MP.

Regards,



Joël





Le 26 nov. 2012 à 09:05, Quentin <qdp@xxxxxxxxxxx> a écrit :

> I fully agree with Nhomar, and actually i already registered a branch on runbot with these constraints, and the only reason it's not yet merged is because it's red :( https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-account_constraints-qdp2
> 
> I hadn't had the time yet to check why, but if some of you are willing to help.... 
> 
> @Joel: i made some corrections, and dropped one test on which we hadn't gave our green signal (longly discussed with luc last week: the community doesn't agree and we, at openerp, have a doubt about it. So it's better to left it aside for now). You may want to check if i made mistakes
> 
> cheers,
> 
> On 26/11/12 01:56, Nhomar Hernández wrote:
>> @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, CISA
>>> http://openacct.ca
>>> fred@xxxxxxxxxxx
>>> 514-667-1555
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Fred Blauer CA, 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
> 
> <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