OFBiz
  1. OFBiz
  2. OFBIZ-653

Clean Up Requirement from ATP Services

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: order
    • Labels:
      None

      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

        Activity

        Hide
        Fred Forester added a comment -

        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

        Show
        Fred Forester added a comment - 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
        Hide
        Si Chen added a comment -

        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.

        Show
        Si Chen added a comment - 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.
        Hide
        Si Chen added a comment -

        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

        Show
        Si Chen added a comment - 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
        Hide
        Jacopo Cappellato added a comment -

        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.

        Show
        Jacopo Cappellato added a comment - 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.
        Hide
        Fred Forester added a comment -

        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.

        Show
        Fred Forester added a comment - 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.
        Hide
        Si Chen added a comment -

        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.

        Show
        Si Chen added a comment - 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.
        Hide
        Si Chen added a comment -

        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.

        Show
        Si Chen added a comment - 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.
        Hide
        Daniel Martínez added a comment -

        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.

        Show
        Daniel Martínez added a comment - 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.
        Hide
        Jacopo Cappellato added a comment -

        Daniel,

        for these complex scenarios you should really consider to run the MRP algorithm instead.

        Show
        Jacopo Cappellato added a comment - Daniel, for these complex scenarios you should really consider to run the MRP algorithm instead.
        Hide
        Daniel Martínez added a comment -

        Thanks Jacopo,

        I will look onto it.

        Show
        Daniel Martínez added a comment - Thanks Jacopo, I will look onto it.

          People

          • Assignee:
            Unassigned
            Reporter:
            Si Chen
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development