[jira] Updated: (OFBIZ-653) Clean Up Requirement from ATP Services

["Si Chen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Si Chen updated OFBIZ-653:
--------------------------

    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




  was:
Steps to create problem:

1.  Select any physical product
2.  Set its Product Requirement Enum Type = "When ATP Reachs Threshold"  (on main Product tab)
3.  Set its Facility threshhold for WebstoreWarehouse to a number, say 2 (on the Facilities tab)

Order this product so that its ATP is below the threshold set in #3 above.

A Requirement should be created but is not.  I checked the log and both createRequirementFromItemATP and checkCreateStockRequirementAtp are called, and these are the services which should be doing it.  

        Summary: Clean Up Requirement from ATP Services  (was: Requirement from ATP appears to be broken)

> Clean Up Requirement from ATP Services
> --------------------------------------
>
>                 Key: OFBIZ-653
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-653
>             Project: OFBiz (The Open for Business Project)
>          Issue Type: Bug
>          Components: order
>            Reporter: Si Chen
>
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.