cannot duplicate journal entries

Hello Stéphane Bidoul,

Thanks for your time and contribution. I have checked and applied your patch and it works fine. The solution of the bug will be merged in main addons. Following are the Revision ID and Number of the proposed branch:

Revision ID : <email address hidden>
Revision Number : 5323

Thanks & Regards,
Devnani Bharat R.

sorry but i feel like it's a little unsafe, out of scope of the current release and a bit pointless too to duplicate account.move.line. You'd probably prefer duplicate the entire account.move, no?

Anyway, for those reasons i don't want to take the risk to include that patch in the next version (maybe later?), and i'll reject the merge proposal and setting this bug as wishlist (not to forget it). Those who wants that feature can still install/test the proposed patch.

But thanks, Stéphane, for the contribution and the proposal.

Quentin

Hello Mustufa,

The purpose of my patch is indeed to make the duplication of account.move useful, not account.move.line.

The point, though, is that when you duplicate an account.move, you usually want to change the period, which is currently not possible since the period is duplicated on each move.line. Therefore my patch propagates a change of period (and journal) on account.move to the account.move.line's inside the move.

IMHO, this is rather safe, and a huge plus for accountants.

This is somewhat related to issue #777640, although I don't quite understand the patch propsed on that one.

Best regards,

-sbi

ha, ok sorry i misunderstood the purpose of this bug report. Then i think we should reconsider your patch. We will let you know as soon as possible.

Thanks for your time,
Quentin

Ok, i choose a slightly different approach to fix the problem: i replaced the fields 'journal_id' and 'period_id' by fields.related ones (and i removed the constraint, because it became useless).

The reason why i choosed this solution and not the proposed one is because it seems much more clean and it renders a better design of the objects by including a more strong link between them... and also because it was really a kind of insanity not to have them already as fields.related! ^^

My patch has landed on trunk in revision 5366.

Anyway, thanks for the bug report and the proposal.
Quentin

Excellent, thanks!

-sbi

Quentin:

I do not know even how to program well python in openerp, is there a recommended way to use the solution proposed into versión 6.0?

Regards
Ariel

Hello,

Since this is an important need for us, I applied the edits made in revision 5366 to latest 6.0 code. The edits did indeed allow duplication of edits, but had the side effect of not being able to do manual delete of moves any longer.

We get the error: "Operation prohibited by access rules, or performed on an already deleted document (Operation: read, Document type: ...."

Haven't had the chance to check this against the trunk, but I suspect it has the same side effect.

Regards

@Ariel: hum honnestly, i wouldn't recommand to apply this modification in a stable production environnement at all as it changes the design of objects deeply. Some code may not work everywhere. Though, if you still want to take the risk you can
*download the diff here: http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/diff/5366
*Then apply it manually (or using a tool like 'patch' but as it was made for trunk and not for v6 it will probably fail) by editing the files in the same way (beware that the line numbers won't be the same because it was made for trunk and not for v6, so you need to find the right place by yourself).

But it will probably be easier for you to ask David Stonely for his v6 patch ^^

@David Stonely: i've tested in trunk and didn't get any problem at all. Either your patch isn't exactly the same, either someone else fixed an error i left in a further revision of trunk.

Regards,
Quentin