[
https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467880
]
Fred Forester commented on OFBIZ-653:
-------------------------------------
Hi Si,
I think I already have something that does this. the difference is that we are
accumulating requirements if one already exists for that product. this reduces
the number of requirements per product. it also creates a commitment but only
if the item causes a backorder. the commitment of for the backorder qty.
one major problem we have found with both the existing code and our new code is
that when an order is updated
duplicate requirements and commitments are created for unchanged items.
I can send you the code or post it here for you to look at.
Fred
> 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.
