Scheduler don't create a second RfQ for the same part

Bug #988232 reported by I. Hohls
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Invalid
Undecided
Unassigned

Bug Description

we faced a new issue in MTS. Scenario: create MO with raw material A (not available), confirm it, run scheduler (creates RfQ - do not confirm it!). Create a second MO with same raw material and confirm it, run scheduler. Scheduler does NOT create another RfQ unless you confirm the first one... Conesequence: You will not be notyfied about the whole qty needs to be purchased.

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Hello,

This is the expected behavior, the procurement of MTS goods is triggered by orderpoints (also known as "minimum stock rules"), and by design a minimum stock rule cannot fire again until the previous item has been properly validated (or cancelled).
If the min. stock rule was allowed to fire repeatedly it would do so every time the scheduler runs until the product comes back in stock, creating many duplicate RfQs.
Minimum stock rules are *not* meant to be used for MTO-like behavior, but should be carefully configured to match the raw material requirements of the company, fine-tuned to provide a sufficient stock on hand quantity at all times. They should include a security extra quantity so that the stock cannot be depleted before the purchase manager is able to confirm the RfQ created by the min. stock rule.

Running the scheduler manually after creating a MO (as you describe) is very much a MTO-like behavior. If you are working with MTS you should start by configuring proper min. stock rules (i.e. don't simply tick the "automatic order point" option of the scheduler), and make sure the minimum and maximum quantities are properly sized for your needs, including a sufficient extra quantity to cover the time it takes for the RfQ to be validated and delivered by the supplier when the min. stock rule fires.

I hope this helps...

PS: this is by no means a "Security Vulnerability", please do not tick that option when reporting a normal bug (you'll likely delay the answer, as only the security team can see those bugs)

Changed in openobject-addons:
status: New → Invalid
security vulnerability: yes → no
visibility: private → public
Revision history for this message
Chris Halls (halls) wrote :

Hi Olivier

> Minimum stock rules are *not* meant to be used for MTO-like behavior, but should be carefully configured to match the
> raw material requirements of the company, fine-tuned to provide a sufficient stock on hand quantity at all times.

Thanks for your comments. We are looking for MTS-like behaviour, not MTO.

Imagine a product is normally sold from stock in quantities of maybe 5-10. So the product is set up as MTS with a minimum stock level of 100. This fits in with the 'finely tuned' levels as you suggest above.

However, we might occasionally also receive larger orders.

Say we have 100 units in stock. We receive 2 separate orders for 250 units and 300 units. We'll need to procure additional units to meet this demand.

We don't want to use MTO generally for the product, because smaller orders should be supplied from stock. We don't want to have to train the sales staff to remember MTS/MTO rules ('When ordering product X you have to set MTO if you order more than 100. When ordering product Y you have to set to MTO if ordering more than 50'). That might work for a few products but not for a company with a large number of products.

The person doing the purchasing does not need to know the details of the stock rules or individual sales order. They just need to know that we need an extra 450 units. The current behaviour would give an RFQ for the first order, but not the second. So the purchaser will order too few items.

So from the above explanation, is it clear to you that neither minimum stock rules, nor MTO, would solve this case?

Changed in openobject-addons:
status: Invalid → New
Revision history for this message
Ravish(OpenERP) (rmu-openerp) wrote :

Hello Folks,

I want to state my aspect here.

As bug was reported, I think you might have misunderstand something. As far as I know we don't want to confirm first RFQ for able to create another one.

@Charis: I think you don't enable "automated order point" option on scheduler (When you run the scheduler). It will helps you.

Now I am explaining the whole thing, For "Make to Stock" behavior.

For MTS product PO will created based on different two ways.

1) As Olivier already said about this, which is "Minimum Stock Rule". You have to define your min and max qty there. But here Charis and reporter doesn't want to create a "Minimum Stock Rule".

2) Which is the "Automatic Order point", Which will creates a PO/MO for all those product whom virtual stock goes to 0.0
When we runs our scheduler with this option then It will check all types of (MTS as well as MTO) product's virtual stock and then creates a PO/MO for those product ,which product's virtual stock in negative respectively. Generally we have used this option for manage our system's all product's qty which was goes into negative.

So this time for all of you 2nd option is more preferable. Because As take the same example of bug description.

You have created a product(Test) with qty 0.0. Created a MO (Test is a component for this main product ). Confirm MO, test product's virtual stock goes into -1. Now run the scheduler with Automated Order point which is created a RFQ for test with 1 qty.
Check the product's virtual stock and real stock as a 0.0 .(You can see this calculation on lp:921866) .

Created another MO confirmed it, Again virtual stock goes below 0. Run the scheduler with Automated Order point ,which is again created a RFQ for test with respective qty.

I have attached the video for this which clearly shows this things.

So no need to confirm first RFQ. And all are working fine with this option ,So please check it again with "Automatic Order point" option.

Hope this will help you!

Thanks and waiting for your reply!

Revision history for this message
Ravish(OpenERP) (rmu-openerp) wrote :
Changed in openobject-addons:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenERP Addons because there has been no activity for 60 days.]

Changed in openobject-addons:
status: Incomplete → Expired
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

You have to tried the comment#4 's video which is attached by Ravish.

Currently we can not consider this issue, If you still faced the problem then you can feel free to open it.

Thanks!

Changed in openobject-addons:
status: Expired → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.