When an invoice is reopened, it cannot be changed to Done state anymore.

[Jordi Esteve (www.zikzakmedia.com)]

When an invoice is reopened, it cannot be changed to Done state anymore. The boolean "Paid/Reconciled" is checked but it remains in Open state.

Follow these steps:

1) Create an invoice and validate (State: Open)
2) Pay the invoice (with Pay Invoice wizard or reconciling the partner account move line) (State: Done)
3) Break the reconciliation of this invoice, and Reopen it (State: Open)
4) If you pay the invoice another time (with Pay Invoice wizard or reconciling the partner account move line), the "Paid/Reconciled" boolean is checked but the Open state does not change to Done state.

Tested in last version of 5.0 (not in trunk, but maybe trunk has a similar behaviour).

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Jordi,

Would you please check the attached patch and notify me.

Thanks.

[Jordi Esteve (www.zikzakmedia.com) (jesteve-zikzakmedia)]

It works fine. Thank you for the patch and for the speed to fix it.

Notice for invoices reopened before applying the patch, they must be cancelled, setted to draft and created another time to be able to pay (done) them (they must follow the new workflow fixed by the patch).

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Vra(openerp) and Jordi,

I have attached a patch that traces out the real flow.

The previous patch disrespects the act_open_test. Actual thing is, there is a transition missing from open_test to paid.

Hope it helps.

Thanks.

[Olivier Dony (Odoo) (odo-openerp)]

@vra: as Jay says, your patch is incomplete because you are bypassing the second 'open' (act_open_test) activity of the workflow, so you need to choose: if you bypass it you should remove it and check the whole logic, or don't bypass it and do it like Jay suggests, with a transition back from act_open_test.
I agree that the act_open_test activity is not well named (should be 'act_re_open' or something) so it is confusing, but it seems its goal is to avoid calling again the other methods called by the original 'open' activity. For example if the invoice has a payment term your patch will recompute it, which is not correct.

@Jay: Your patch looks correct to me for 5.0. Now for trunk, I think we need to improve this even further. My suggestions:
 - either we remove the 'act_open_test' activity + guard better all the methods called by 'open' activity so they don't do their job twice (mainly action_date_assign()), then connect 'paid' back to 'open' directly, which looks much more intuitive to me ;
 - or at least rename 'act_open_test' to 're_open', and all related names ;
And while we're improving trunk: do we need an actual wizard for the confirmation of the 're-open' button when it seems a simple 'confirm' attribute would be sufficient?

[Nhomar - Vauxoo (nhomar)]

In V6 a cancelation of an invoice need to be improved in a lot of things....

I mean:

Case [you are using all features --accounting and stock---] if you cancel an
invoice after thi is in Open State the system should revert [all] around
this transaction.

-- Push a re-pack on stock [or at least --mark-- the first like (not invoice
related) and put its state _to invoice_] if the
account.invoice.line.produt_id.type <> service and if have a pack
related......
-- Make a reverse move in draft state. [not delete the first original to can
trace in future.]
-- Make an in_refund invoice automatically with the details in the original
[This Behaviour can be configurable not all countries work in this way].

At least in Venezuela, Colombia and I think Chile and Peru is not possible
cancel an invoice with out a document of reverse [in or out refund].....

Case [you are not using all beheviour in accounting and stock]

manage all the exceptions related to the first one....

IMHO, the concept of OpenERP to manage Stock and Invoicing and Accounting in
tottally separate flows is correct _but_ we need be carefull with all the
cancelation process, this steps on workflows need to revert all the past
actions related.... AFAIK almosts all ERP work in this way...

Right Now I see all apnorama in this way:

One of choices i know existe other ones.....
sale order ------- stock or project ------ invoice ------- accounting

If i cancel the invoice..... you can see that you can not make it alone (at
least the user indicate it in an explicit way)

Thanks.................. ;-)

2010/7/11 Olivier Dony (OpenERP) <email address hidden>

> @vra: as Jay says, your patch is incomplete because you are bypassing the
> second 'open' (act_open_test) activity of the workflow, so you need to
> choose: if you bypass it you should remove it and check the whole logic, or
> don't bypass it and do it like Jay suggests, with a transition back from
> act_open_test.
> I agree that the act_open_test activity is not well named (should be
> 'act_re_open' or something) so it is confusing, but it seems its goal is to
> avoid calling again the other methods called by the original 'open'
> activity. For example if the invoice has a payment term your patch will
> recompute it, which is not correct.
>
> @Jay: Your patch looks correct to me for 5.0. Now for trunk, I think we
> need to improve this even further. My suggestions:
> - either we remove the 'act_open_test' activity + guard better all the
> methods called by 'open' activity so they don't do their job twice (mainly
> action_date_assign()), then connect 'paid' back to 'open' directly, which
> looks much more intuitive to me ;
> - or at least rename 'act_open_test' to 're_open', and all related names ;
> And while we're improving trunk: do we need an actual wizard for the
> confirmation of the 're-open' button when it seems a simple 'confirm'
> attribute would be sufficient?
>
> --
> When an invoice is reopened, it cannot be changed to Done state anymore.
> https://bugs.launchpad.net/bugs/603095
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenObject Addons.
>
> Status in Ope...

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello,

It has been fixed by revision 2777 <email address hidden>.
@Nhomar, would you please create another bug which describes the problems in detail?

Thanks Jordi.