[
https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508785
]
Jacopo Cappellato commented on OFBIZ-653:
-----------------------------------------
Daniel,
for these complex scenarios you should really consider to run the MRP algorithm
instead.
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
