Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
None
-
None
-
None
Description
After some tinkering it appears that it is not broken but simply very confusing.
There are now two types of requirements from ATP: PRODRQM_STOCK_ATP (When ATP Reaches Minimum Stock for Product-Facility) and PRODRQM_ATP (Requirement for order when ATP Reaches Minimum Stock for Product-Facility)
There are now also two services which run as SECAs: checkCreateStockRequirementAtp creates a product requirement if the ATP has just fallen below the minimum and the requirement is in reorderQty. createRequirementFromItemATP creates a requirement and a commitment regardless of the previous state of stock - it will always execute if the ATP is below minimum
the requirement will be for the lesser of the quantity of the order vs. the shortfall (minimum - ATP).
I propose that we get rid of one of these requirement types and one of these services and follow this logic:
If ATP + existing APPROVED requirements < product facility minimum threshold THEN
if a reorderQty exists then create a Requirement for the reorderQty
Otherwise, create a Requirement for the the lesser of order quantity or minimum - (ATP + existing requirements)
To put it into numbers:
If you had a product whose minimum quantity is 0 units
You start out with ATP = 2 units
You order 7 units
Your ATP becomes -5, and a Requirement for min(7, 0+5) = 5 units is created.
If you approve this requirement, then another 4 units get ordered
Your ATP is now -9, and a Requirement for min (4, 0 - (-9 + 5)) = 4 units is created.
If however you had a reorderQty = 20 units, then after the first order for 7 units, ATP is -2, and a Requirement for 20 units is created.
If you approve this Requirement for 20 units, then ATP is -9 units, but ATP + existing Approved requirements is 11 units, which is greater than the product facility minimum of 0. No more requirements are created.
One issue of course is if you get a whole bunch of requirements created during say a long weekend when nobody is around to approve them. They'll pile up and you'll think you'd need 100 units of stuff!
The logical solution is to create a new status "PROPOSED" for automatically proposed requirements, which are wiped out before any new automatically proposed requirements are created. This echoes a suggestion Jacopo made in MrpServices.java:
// Proposed requirements are deleted
// TODO: we have to find a way (a new status REQ_PROPOSED?) to recognize the requirements automatically created by the MRP process