Scheduler created PO's affects virtual stock

Hello Kyle Waid,

I agreed with you ,that when the Purchase Order is In "quotation" state at that time virtual stock not affect. It is affect after confirm the order.

But When the Purchase Order created by the Scheduler at that time Virtual Stock affect base on Min - Max Rules setup. So Scheduler can not wait for the confirmation of order. Because we need to run the scheduler when we must get the stock.

Correct me If I am wrong!

Thanks and Waiting For your Reply!

Hello,

So it is as I suspected. You have the purchase orders generated by the scheduler add to "Virtual stock" even though they are only quotation, as a work around. This is because when the scheduler runs it uses as you said, Virtual Stock to calculate what should be ordered.

This is bad practice. Companies using OpenERP and many modules depend on virtual stock to accurately tell what stock they have, not real stock. So, by adding to virtual stock, it makes it not possible for a company to maintain accurate stock. (virtual stock shows what you have, what you intend to sell (confirmed sales) and what you have ordered (confirmed orders) This is core function. If I create a quotation order, or a quotation purchase order it does not add to virtual stock or subtract. This is the principal functionality.

Problem:
I have 20 pieces and the scheduler generates a purchase order for 120 pieces, well, now I think I have 140 pieces when really I only have 20 and I have not even ordered the extra product yet. It is only a quotation.

This effect completely ruins the stock management. Instead of this current (bug),

The scheduler should maintain cached values of the previous orders that were generated. Each time the scheduler runs before it creates a new purchase order it should check against already created purchase orders. Then create a new one. If a purchase order previously generated from the scheduler is confirmed or deleted, then the rules are no longer calculated. This cached value should be used on the purchase order object. Roughly, when the min/max rules are calculated it takes the purchase orders generated as a factor.

Hello Kyle,

Thanks for your nice explanation here.

As per basic scenario (without running scheduler) we have used following formula for virtual stock and real stock.

Real Stock :-Incoming stock move (which is on done state)-Outgoing stock move(which is on done state)
Virtual stock :- Incoming stock move (which is on draft and waiting state) - Outgoing stock move(which is on draft and waiting state) + real stock

Now comes up to your point. Yes, you are right currently the PO's qty are calculated on virtual stock because If we don't calculated in it and then run the scheduler again and again then it will create a Purchase order more times which doesn't make sense;-)
Another point of view, If my product is manufacturing product (Supply method-> produce) which have component(procure method: make to order, supply method: buy) and I creates a Manufacturing Order for this product. Now I runs the scheduler then it will creates a PO for the component. So for this also component 's product comes on virtual stock and my production order goes into "ready to produce" state.

So this is an intensional behavior of OpenERP that when the purchase order created form the scheduler the it will be count in virtual stock.

I appreciate your efforts on this issue also about your solution which is described in last paragraph of your comment. Your suggested solution is very nice for this.So we can consider this as a "Wishlist".

You have suggested that we have cached values of the previous Purchase Orders that were generated form the scheduler and Each time the scheduler runs before it creates a new purchase order it should check against already created purchase orders. Then create a new one. But it becomes too sticky to check it and there is also lots of possibility that we have cancel that purchase order or we have changed the qty of PO then we have confirm it.

That's why currently I am considering this as an "Opinion" because before Implementing/Confirming this we need a more discussion on this. After a discussion over here we will decide the better solution for this and then we will set this as a "Wishlist" or any importance.

Correct me If I am wrong.

@Stock Accounting experts: Would you please share your views on this!

Thanks and more suggestions are welcomed!

In other ERP's generated MRP orders are with a new MRP run deleted and regenerated based on the new situation.
These orders are called "Planned Orders" and have that status in the system, so they are easily detectable.

When a planner is working on a "Planned Order" he can set the order in status "Firm Planned" and MRP will not affect the order.
If planner has finished his work on the order the status will change to confirmed and virtual stock will be affected.

Concluding that virtual stock is functional misused as Kyle did report.
the way to go for MRP calculation should be:
1. Delete all "Planned Orders" for the calculated item.
2. Calculated what should be ordered. Take current Firm Planned orders into this calculation.

planned order =
A suggested production, purchase or replenishment order generated by an MRP or other planning system to meet a projected shortage against desired safety stock levels. The shortage date becomes the due date, the release date is backward scheduled based on lead time, and the quantity is based on the specified lot size. Planned orders for upper level items create requirements for lower level components, and MRP generations delete existing planned orders and regenerate new ones based on changes in requirements. Planned orders must be firmed or accepted before releasing to production or to a vendor.

 jm2c

<quote>
In other ERP's generated MRP orders are with a new MRP run deleted and regenerated based on the new situation.
</quote>

+1

+1 also to solution proposed by Jan in comment #4

For me is a total mistake taking in account draft orders in virtual stock. Imposible controlling right procurement with this aproach.

Isn't this what mrp.procurement is all about ? Tracking the need for products and their respective (planned) answers ?

Afaik the Virtual stock does not count Purchase Order amounts unless it has been confirmed simply because a draft Purchase Order does not create a picking (and the relevant stock.move records)

+1 also to solution proposed by Jan in comment #4

+1 for solution proposed by Jan in #4

+1 for solution proposed by Jan in #4

Hello Folks,

I totally agree with regarding solution of Jan 's comment#4.
@jan thanks for providing excellent solution.

Here, we considered the comment#4's solution because it's quite better then kyle's suggested solution.

This is a good improvement as well as feature request, So I am setting this as a "Wishlist".
We will surely consider this as a future road-maps.

Thanks for a efficient discussion..!!

Steven and Laurie,

Not sure if any of your clients have a minimum stock rule and also wish to
use the scheduler to create POs but this sounds like it is a bit screwed up
and may need another look. I don't know if it will affect things over time
or self-correct but it doesn't seem right.

DP

On Thu, Feb 2, 2012 at 1:23 AM, Launchpad Bug Tracker <
<email address hidden>> wrote:

> You have been subscribed to a public bug by Amit Parik (OpenERP)
> (amp-openerp):
>
> I have min/max rules setup. When the scheduler runs nightly it auto-
> generates purchase orders. It generates them correctly. They are in
> quotation state.
>
> The problem is that they affect virtual stock. If I have 5 parts left in
> stock. A minimum rule of 10. It creates a purchase order for 5 in
> quotation. Now it says I have 10 in virtual stock, but this is not
> right. It should never ever effect virtual stock unless it is confirmed.
> A quotation has no value.
>
> Does it do this behavior intentionally to avoid creating the same
> purchase order again the next night? If so thats a bad work around.
>
> ** Affects: openobject-addons
> Importance: Undecided
> Status: Opinion
>
> --
> Scheduler created PO's affects virtual stock
> https://bugs.launchpad.net/bugs/921866
> You received this bug notification because you are a member of OpenERP
> Manufacturing Experts, which is subscribed to the bug report.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-production
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openerp-expert-production
> More help : https://help.launchpad.net/ListHelp
>

--
D.P. Hicks
Managing Partner
NovaPoint Group LLC
810.531.1777
www.novapointgroup.com
"An OpenERP U.S. Silver Partner"

Hi guys,

Thanks for the great collaboration on this issue. Seems like we have a clear vision on what needs to be done. Instead of adding it to a wishlist, I would like to get moving forward on a solution to this problem. Anyone currently using scheduler created po's will have this issue.

I would consider it much more important, than a minor inconvenience because it affects accuracy of the stock.

Hello,

I have been developing this feature myself and I have it nearly ready. I added a new filter called Planned Orders. I added a new workflow state and made it the beginning or equal to draft. Planned orders can be confirmed but not converted into draft.

By default, purchase orders created will be in 'state': draft. I passed an extra line for 'state': 'planned' in create_po. Now purchase orders generated exclusively by the scheduler will be in planned state. I also had to make other minor tweaks and I added the new state selection.

I also added an if, else, statement to update existing purchase orders in planned state (thanks to code by others). So instead of creating one purchase order per product, it creates one purchase order per supplier.

The two things I have yet to do and I could use some guidance, I am not sure the proper way to call a delete before the make_po is called. I also am not sure where the purchase confirm method is being called, (whats adding to virtual stock). If everyone can comment on the design so far and the things I need help with, I would be happy to publish this back to the community when it is ready. Thanks

I have an update,

I have this feature working. I am preparing a merge proposal and will link here. Currently it still will add to virtual stock, but I am working on it.

http://bazaar.launchpad.net/~gadgetscentralservice/openobject-addons/planned_purchasev6/revision/5069

Hello kyle,
First nice work !
But if you want to share your contribution with everyone, I suggest to create a merge proposal for the trunk.

But this kind of big change will not be merged into stable release, what can be done for stable version is creating a new module with those change and publish the module on http://apps.openerp.com

Hi my customer have the same need so I propose this for V61 version

Refactor of purchase module :
https://code.launchpad.net/~akretion-team/openobject-addons/openobject-addons-purchase-61

Then a generic module that update automatically the purchase order
https://code.launchpad.net/~akretion-team/+junk/purchase_auto_merge

Here is my merge proposal for trunk version https://code.launchpad.net/~sebastien.beau/openobject-addons/openobject-addons-purchase-refactor-trunk/+merge/113618

Have a nice day

Hello,

This is an old post, but if anyone is still using 6.1 and need purchase orders to merge automatically, I created a much simpler module. It is very lightweight and does not require any system modifications. There is already the functionality to merge purchase orders in OpenERP but it must be done manually. So what I did is just create a scheduler that will do this automatically using the same logic already in place.

It merges scheduler Po's M20 po's, all of it. It will adjust the quantities correctly as well.

Here if anyone wants it.

https://code.launchpad.net/~gekkotek/+junk/purchase_merge_scheduler