http://ofbiz.116.s1.nabble.com/OFBiz-Users-Automatic-Purchasing-tp136301p136312.html
this thread is very interesting. I'd like to have more time to jump into
> Si Chen (
[hidden email]) wrote:
>
>
>>>For example, if you have a product with the following properties:
>>>
>>>minimumStock: 10
>>>reorderQuantity: 20
>>>availableToPromiseTotal: 5
>>>order line Quantity: 1
>>>
>>>The createRequirementFromItemATP service creates a requirement for...
>>>only 1. It chooses the lesser of the quantityShortfall (based only
>>>on minimumStock, it doesn't even consider reorderQuantity) or the
>>>order line quantity. My service would take into account minimumStock
>>>and reorderQuantity, and create a requirement for 25.
>>>
>>>
>>>
>>
>>Yes, that's a bug. Can you fix it?
>
>
> Fixing the problem properly could require some substantial
> re-architecting.
>
> The major problem, IMO, is that in order to do
> the calculations properly, you need to consider the existing
> automatically generated requirements for that product/facility. If
> you do not consider them, then each time you do a requirement
> quantity calculation, you will be ignoring the quantities the system
> previously required, and you will keep requiring more and more and
> more...
>
> Now this seems weird to me, because you are now calculating the
> required quantity on the basis of requirements that are in the database,
> but not even approved. Also, I'm not 100% sure about this, but I don't
> think you want to consider all requirements in your calculation.
> If there's an internal requirement, or if manufacturing enters a
> requirement, you should *not* use those in the calculation. (True??)
>
> So given that, here's how I think you could fix the bug:
>
> - Create a new requirementTypeId that is used by the automatic
> requirement generation system, say AUTO_REQUIREMENT
> - When it is time to generate a requirement by ATP, you will:
> a. Search for all existing AUTO_REQUIREMENTs for the product/facility
> with a status of REQ_CREATED or REQ_APPROVED
> b. If there is not an existing AUTO_REQUIREMENT with a status of
> REQ_CREATED, create one
> c. Take the first requirement with a status of REQ_CREATED and update
> its quantity according to this formula:
> requirementQuantity = minimumStock + reorderQuantity - (availableToPromisQuantity + incomingShipmentQuantity + sumOfExistingRequirementQuantities)
> d. You also need to add an orderRequirementCommitment to the
> updated requirement for the new sales order line item.
>
> This solves a couple problems. Namely, the quantity calculation.
> But it also fixes another ugly problem, where incoming sales orders
> could generate hundreds of new requirements for the same exact item
> at the facility. (Imagine if you were a supplier and you received
> a 90 page purchase order for only three distinct items. Ick.) There
> will only be one AUTO_REQUIREMENT for each product/facility. I think
> it is possible to have many orderReqirementCommitments for a single
> order line. And, on the purchase order, it should also be possible
> to link multiple orderItemAssociations to a single order line.
>
> I'm not 100% sure about the details. Maybe it is fine to use the
> existing PRODUCT_REQUIREMENT as the requirementTypeId. I'm not sure
> what else creates PRODUCT_REQUIREMENTS, and if it would be sensible
> to consider them.
>
> But all of this complexity is really unique to continuously generated
> requirements (requirements generated after each sales order). Periodicly
> generated requirements (aka "batch" or "bulk" requirements) are much
> easier to handle. You don't really care about existing requirements,
> especially if you segregate the periodic requirements with their own
> requirementTypeId. You don't even link them to specific sales orders, so
> its a lot easier to deal with overall...
>
>
>>By the way, how are you getting a list of all products? From a
>>warehouse? From a store? From a catalog? What if, for example, I had
>>none of something in stock, so there's no InventoryItem for it. Will it
>>create a Requirement?
>
>
> I'm using ProductFacility to get a list of all products. Generally a
> purchase order must come to a specific facility, and that's where
> minimumStock and reorderQuantity are, so I figured it was sensible.
>