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/25 04:08:49 UTC
[jira] Created: (OFBIZ-653) Requirement from ATP appears to be
broken
Requirement from ATP appears to be broken
-----------------------------------------
Key: OFBIZ-653
URL: https://issues.apache.org/jira/browse/OFBIZ-653
Project: Apache OFBiz (The Open for Business Project)
Issue Type: Bug
Components: order
Reporter: Si Chen
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Jacopo Cappellato (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Fred Forester (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Daniel Martínez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508782 ]
Daniel Martínez commented on OFBIZ-653:
---------------------------------------
Looked at this interesting issue and I think that Si's proposition is the right thing to do. I am beginning an implementation of it. Some more ideas for comment:
- Create requirements with PROPOSED state
- Right now, requirements are not re-calculated when cancelling order items. IMO this is necessary, do you know which is the right service for a secas?
- Automatic date scheduling for the requirements depending on supplier dates/sales orders/manufacturing times.
Please correct me if my appreciations are wrong.
> 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.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Si Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467993 ]
Si Chen commented on OFBIZ-653:
-------------------------------
Jacopo, I just noticed I recommended the opposite of what you mentioned! The reason is because PRODRQM_STOCK_ATP only creates requirements the first time a product's ATP falls below minimum stock, which seems to cause many products not to have requirements created.
> 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
> 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.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Daniel Martínez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508789 ]
Daniel Martínez commented on OFBIZ-653:
---------------------------------------
Thanks Jacopo,
I will look onto it.
> 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.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Si Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467948 ]
Si Chen commented on OFBIZ-653:
-------------------------------
Fred,
If you have something you'd like to contribute, that's great. Please create a patch and put it here, and we'll look through it.
Si
> 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.
[jira] Updated: (OFBIZ-653) Clean Up Requirement from ATP Services
Posted by "Fred Forester (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Forester updated OFBIZ-653:
--------------------------------
Attachment: requirements.patch
Si,
I dont have a patch per se but its all new code so should be easy to put in.
it requires a new method type of PRODRQM_STOCK_ATP_SC
it does fail on a duplicate commitment when an order is updated. I'm trying to work that out now. the code for the others seems to create a new commitment when an order is updated so I was thinking of just updating the current commitment if it exists.
I think it would be nice when an order is updated that only the affected items (or new items) go back through inventory reserve. the requirement code would also need to know the old and new values of the qty (or the delta) in order to update correctly.
> 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
> 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.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Si Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467989 ]
Si Chen commented on OFBIZ-653:
-------------------------------
As a temporary measure Jacopo's suggestion might be the best one--just remove checkCreateStockRequirementAtp for now and let createRequirementFromItemATP rely on PRODRQM_ATP to create a requirement each time.
This however is not perfect and liable to create more requirements than necessary.
> 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
> 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.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Si Chen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (OFBIZ-653) Clean Up Requirement from ATP
Services
Posted by "Jacopo Cappellato (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (OFBIZ-653) Clean Up Requirement from ATP Services
Posted by "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.