You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Si Chen (JIRA)" <ji...@apache.org> on 2007/01/26 19:32:49 UTC

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

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

Si Chen commented on OFBIZ-653:
-------------------------------

An alternative instead of wiping out old REQ_PROPOSED is to find the first existing one, add to it, and create another RequirementOrderCommitment (or whatever it is) entity to record the new order against it.

> 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.