Comment 17 for bug 1097633

I have hit this bug as well. Alas I must say that it can't be solved just modifying the workflow.
The purchase order workflow has suffered a modification on the transition out of the router activity that makes the workflow never take that branch. AFAIU this is caused for the implementation details of the workflow engine besides the fact the the purchase order does not know in advance which invoices are related to it, since they are going to be either created manually or upon receptions.

For what I could see in version 6.1 the workflow did not wait for the invoices to be created or validated and the purchase order reached done state as soon as the receptions where done in any invoice_method != 'order'.

In order to the workflow to behave properly both workflow and code need to be modified, since invoices need to "signal" they have reached valid state to "trigger" purchase order workflow conditions to be reevaluated. Regrettably both invoices are not using triggers and workflow triggers can't be "installed" since purchase order would need to know "in advance" (mainly when "installing" the trigger) which invoice ids are needed to be "listened". IMHO there is only a way to do this properly and it is making invoices call trg_write on the purchase order ids related to them through the many2many relation. IMHO this is an ugly solution for we are making invoices aware of purchase order; although we are using extension mechanism for this.

I can't come up with a better solution with my today knowledge. I will try and post a patch implementing the modifications I have described here today. If anyone has a better idea or insight on how to do this more canonically I will be very happy to know.

Hope this helps someone.