[trunk][procurement] MRP Scheduler 'looping' on confirmed procurement past scheduled date

[John B]

I'm not quite certain how the procurement got to this state to begin with, but there seems to be an issue which will cause the scheduler to loop under the following conditions:
 1. The Procurement Order scheduled date is in the past
 2. The state is confirmed
 3. The move is not cancelled (it can be done or confirmed)

I realize that it shouldn't be in that state - however, the scheduler should handle it a tad more gracefully. Right now it continually loops on the record and the job runs continually. The offending while statement is in the schedulers.py procure_confirm() - you can see that it will never return from the loop under this scenario as it will always be true and will always return ids.
I would suggest changing the while to a for loop and just process all the ids, unless there's something I'm missing.

[Amit Parik (amit-parik)]

Hello John,

I have checked your issue But you are partially right.
you have described four different issues in bug report.

Your issue #1 which is related to scheduled date.You have a problem of scheduled date goes in to past which is only happen when your company security days in grater then the delivery lead time.

Because the scheduled date = "Sale Order Date" + "Delivery Lead Time " - " Company Security days"

So when your company security days in grater then the delivery lead time then scheduled date goes in to past.
This issue already discussed ago please see this lp:770392 and also look this lp:780337.
In this lp:770392 the problem related to our demo data we have just improved it So this problem has solved now.

Your issue#2 (The state is confirmed) which is the behavior of system i.e when you have create a SO with "On order" and you have confirmed it the procurement will automatically generated which is in "Confirmed" state.

So your Issue#1 and 2 are invalid.

And I have checked your issue #3 and find some problem in work-flow of procurement currently when the state goes in to the "confirmed" we can not cancel it But I have checked the work-flow and I have find the method of and transition of it. So the cancel button is missing the "confirmed" in states. And I have seen that the problem in signal of the transition it is button_check it should be a button_cancel.

As per my suggestion we have to add one messages on cancel button because when the procurement is in confirmed state it's related move is also in "confirmed" so first we can cancel it's move if we want to cancel the procurement So I am confirming your issue #3. For this issue I have suggested a patch to R&D team so they will look in to this and take the action.

According to your issue#4 which is related to while loop in scheduler.py I have seen that but it is totally a code side improvement So the related R&D team will check it and take the appropriate decision on it.

Thanks for understanding!

[John B (johnb-ca)]

I didn't really consider either 1 or 2 issues, as I completely understand why the procurement can be in the state it was (confirmed and past scheduled date) and I wasn't reporting those. As for #3 - yes, agreed, but it's separate from my issue.

#4 is definitely a bug and not a code improvement. Specifically, the fact that it will never break out of the while loop under the conditions I mentioned is an issue. The result it a pegged CPU and, if the scheduler is catching up on Open ERP startup, the server will not start properly.

[Kirti Savalia(OpenERP) (ksa-openerp)]

Hello,

It has been Fixed in http://bazaar.launchpad.net/~openerp-dev/openobject-addons/trunk-bug-798890-ksa
Revision ID: <email address hidden>
Revision NO: 5507

Thanks.

[Rucha (Open ERP) (rpa-openerp)]

Hello John B,
Before checking the fix done by above mentioned branch, I would like to know the whole problem in depth again, (sorry for delay)
As all others problems seems not raised now, I am considering that there is only one problem and which is of looping,
According to me it is fine with a while loop as it serves its own purpose here for scheduler,

We need to understand why/how there is a infinite loop happening in your case,
Can you please elaborate more with example/cases with proper configuration so we can investigate more on that way,

Thanks for reporting,