> Clean Up Requirement from ATP Services
> --------------------------------------
>
> Key: OFBIZ-653
> URL:
https://issues.apache.org/jira/browse/OFBIZ-653> Project: OFBiz
> Issue Type: Bug
> Components: order
> Reporter: Si Chen
> Attachments: requirements.patch
>
>
> 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
Locked
