[trunk/7.0]Purchase order doesn't go into done state when Invoice policy="based on reception" or "based on purchase order lines"

[Linh Banh]

After creating a purchase order and confirming it, the purchase order is in a "purchase order" state. After generating the invoice and paying it, and after treating the incoming shipment, the purchase order still appears in "purchase order" state and not in "done" or "completed". Since there is no further action to do on this purchase order, it remains in this state while it should be closed.

please make sure your invoice type = "Based on incoming shipment"
Would you please see the step on lp:1118096

Kindly check and advise.

[Amit Bhavsar (Open ERP) (amb-openerp)]

Hello Linh,

I have checked your scenario with follwing revision.
(Build 1543)
server : 4774
addons : 8558
web : 3694.

But I did not faced any problem. That's why I have attached the screen-cast for your reference. would you please check It and notify us where you have faced the problem.

Thanks and waiting for your reply!

[Linh Banh (lba-b)]

Hello, you are right. I just tried with the latest code and it works fine. However I tried on a sale order and it did not work. The state of a sale order is now blocked at "sale order" and does not change into "completed" or "done" even when I processed the delivery and paid the invoice. Could you please have a look and advise ?

Thanks and kind regards

[Amit Parik (amit-parik)]

Hello Linh,

I think you didn't register( make ) the payment that's why you are not able to see the sale order on done state.

When you done the deilivey and paid then invocie then and only then your sale order goes into done state.

I have attached the video for your which make you more clear,So would you please check it.

Hope this wil help.

Thank you!

[Linh Banh (lba-b)]

Hello,

I did the same test as yours and came up with the same results indeed. However when you follow another scenarioq, the sale order stays in "sale order" state. Please see below details of the test cases :

Test Case 1
 I created a new sale order with :
- shipping policy = deliver all the products at once
- create invoice = on demand
I then selected a service product. I confirmed the sale order. I created the final invoice and paid it. I come back to the sale order view and the sale order is still in "sale order" state.

Test Case 2
I created a new sale order with :
- shipping policy : deliver all the products at once
- create invoice = on delivery order
I then selected a stockable product. I confirmed the sale order. I created the delivery note and processed the delivery. I come back to the sale order, the sale order appears to be in "done" status even though there is no invoice generated nor paid.

Also quick question on the availability of the product : by default, when the delivery order is created in the system, it always shows up as "waiting for availability" even though the product is in stock. Everytime I have a delivery order with a product in stock, I need to first click on "check availability" for the line to change statuts to "available". Why ?

Second additionnal question : in your video, there is a popup error message. I also have the same one, kindly advise the reason behind it and when it will be fixed.

Thanks and kind regards

[Amit Parik (amit-parik)]

Hello Linh,

Your last comment doesn't recommended with your original bug report which is posted for purchase order state.

In your last comment you have asked the lots of question, If any question and query in your mind then you have to post this into https://answers.launchpad.net/openobject-addons doesn't report the bug for your question.

And yes for your first point which you think that its bug (Test Case 1). Actual you doesn't properly understand the business flow .
Whenever you sale the service type of product then it never creates a delivery order rather then its generated the project task.

For that you have to install project_mrp module, go to the task . Select your task done it. Then after your SO will goes into done state.

Currently I am closing this issue, now then after you fell that its bug then you have to post new bug report for new bug doesn't reopen the old bug your reported point is solved. Cause this will better for checking the issue as well as understanding purpose.

Thanks for understanding!

[Linh Banh (lba-b)]

Hello,

Apologies but I don't quite understand why the test case 1 would be logic. I understand that for service products, there is of course no delivery note. However when I paid the invoice linked to this sale order, the sale order still stays in a "sale order" status instead of "done". As you confirmed, there is no other action than pay the invoice since there is no delivery out. Therefore I don't understand why the order would not go into the "done" state.

Why should the client install an additional module if there is no dependance mentioned in the sale module ? The sale module should work on its own or at least without the project mrp module if not installed as dependance.

Could you please advise the reason behind this ?

Also, have you checked the test case 2 which seems unlogic to me too ?

Thanks and kind regards.

[Amit Parik (amit-parik)]

Hi Linh,

Thanks for your reply.

Yes, you are correct. Your test case-2 is point out a bug.

I have reported a bug for your this issue on lp:1100699. So you can see there.

Thank you!

[Mihalache Ciprian (ciprian-mihalache)]

Same state here ... no change from purchase order to done.

Try to change default language to simulate bug. Maybe a procedure is not called when both steps received and paid are completed.

I attached the file with both steps completed and same status on purchase order.

[Twinkle Christian(OpenERP) (tch-openerp)]

Hello Linh Banh ,

Yes, it is a bug but faced only when invoice type = "Based on Incoming shipment".

@Mihalache: Thanks for the nice screens.
@BrowseInfo: Thanks for the detail steps for the same bug on lp:1118096 but this bug is reported first, So lp:1118096 will become duplicate of this.

Please try the invoice type = "Based on Incoming shipment" then you can faced this error.

Thank you!

[Bertrand Rétif (bretif)]

Hello,

Any plans for the correction of this bug?
It is a real issue for me to have the purchase workflow that is not working properly on 7.0

Brgds / Bertrand

[Nik T (flying-dane)]

I would also like to see some solution to this. Seems like quite a basic thing to get right!

[Yoshi Tashiro (yostashiro)]

I think the problem exists when Invoicing Control = "Based on Purchase Order lines" as well. The status doesn't update to "Done" even when you have done the invoice and payment. My environment is 7.0, nightly build version as of 15 Mar 2013.

[Shahar Or (mightyiam)]

I've changed the title but I'm not sure about it.

[V Alberici (valentinalberici)]

Same problem here.
Is it possible to fix it by editing the workflow? I've been trying... unsuccessfully so far...

[charlee.papah (n-hartmann)]

hi, has this issue been fixed? i am still having this issue. thanks.

[Carlos Sierra Andrés (csierra-h)]

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.

[charlee.papah (n-hartmann)]

thank you Carlos. i think we will all be eagerly waiting for a solution to this bug.

[Carlos Sierra Andrés (csierra-h)]

Hi again,

here you have a patch on branch 7.0 revision 9114. It works on my box.

It changes both the workflow and the code. I would appreciate if you could give me some feedback.

Bests.

[Carlos Sierra Andrés (csierra-h)]

I have made a merge proposal here: https://code.launchpad.net/~csierra-h/openobject-addons/7.0/+merge/163556

Cheers.

[duncanlin (drduncanlin)]

Hi Carlos,

I modified purchase.py and purchase_workflow.xml according to the merge proposal.
I am testing 'Invoice Control: Based on Purchase Order lines'.
Unfortunately the Purchase Orders still showing 'Purchase Order' state instead of 'Done'.

The scenarios I tried were:

Scenario 1
i. Create a new purchase order with
  - Service product
  - Invoice Control: Based on Purchase Order lines.
ii. Receive Product. Receive Invoice, Validate and Pay.

Scenario 2
i. As Scenario 1 except with Consumable product

Scenario 3
i. As Scenario 1 except with Stockable product

I don't know if my version issue or not. My version is 7.0-20130204-000102

[Carlos Sierra Andrés (csierra-h)]

Hi duncanlin,

did you update the modules after modifying purchase_workflow.xml? Note that you have to explicitily do so either from the installed modules interface or by starting the server with the -u and -d options.

This is necessary in order to modify the working worflow. Just check that, after updating the module, the workflow is different than before.

Bests.

[Bertrand Rétif (bretif)]

Hi,

Your patch is working on my side with Invoice control: "Based on incoming shipments"

Thanks for your patch

Brgds / Bertrand

[Oliver Yuan (oliver-yuan)]

Any progress to merge the patch?

[Anton Chepurov (anton-chepurov)]

The current fix marks an order as done when all its invoices are validated (state == 'open').

However, the default Invoicing Control (generate a draft invoice) considers a purchase order to be done only when it's invoice is paid (state == 'paid').

What is the reasoning behind marking an order as done as soon as invoices are generated, but haven't been paid yet?

Shouldn't we check for all the invoices to be paid before marking the order as done?

E.g. consider the attached patch.
 (note the 'invoiced and paid' in the workflow.xml)

[Andrew (bj7u6139zdyf2a6nz2l-andy-jjcftv6wldnzq84csky)]

I tried this fix (with updating the database) and it is not working for me. How is this still an issue after a year?

[David Ellison (dave-e-9)]

We have the issue still, has there been a fix for this. This is pretty fundemental issue and stops closing down Purchase Orders.

[Michael Karrer (michaelkarrer81)]

No fix? After a year of waiting? This makes me wonder if OE is the right choice.

[Tomás Pascual (tomas-pascual)]

Hi Sirs,
I'm using ocb, for old records it doesn't works, and for the new ones neither.
What a pitty.
Regards,

[Stefan Rijnhart (Opener) (stefan-opener)]

Looks like this is fixed in http://bazaar.launchpad.net/~openerp/openobject-addons/7.0/revision/9761. I can't seem to reproduce it anymore. Maybe the bug tracker can be updated? A bug with 27 affected people looks pretty bad stuck on 'confirmed' ;-)

[mrmango (register-coloniesonline)]

No fix here, just downloaded the latest build and it's still broke. Come on guys, this is fundemental to a businesses process.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Continued on Github here https://github.com/odoo/odoo/issues/2324