[
https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467959
]
Jacopo Cappellato commented on OFBIZ-653:
-----------------------------------------
I'm sorry but I can just quickly jump at this interesting issue with one quick
comment.
If possible, I'd suggest to just disable one of the two eca (the one that
doesn't take into account the existing approved requirements, that should be
PRODRQM_STOCK_ATP) but leave the service as simple as is now.
The reason for this is that PRODRQM_STOCK_ATP and PRODRQM_STOCK_QOH actually do
the same simple stuff: they create one requirement when the ATP or (QOH)
reaches the minimum stock; they don't consider other requirements or other
complex logic.
For the ones that need more complex requirements' generation, I'd strongly
suggest to use the MRP (or the other type of requirement method, such as
PRODRQM_ATP (that, if I'm not wrong, also links the requirement to an order).
I agree with Si that it doesn't make a big sense to use more than one
requirement strategy running in a system.
> 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.
