http://ofbiz.116.s1.nabble.com/OFBiz-Users-Automatic-Purchasing-tp136301p136313.html
I think Christopher brought up many good points. Do you have anything
> Hi Christopher,
>
>
> this thread is very interesting. I'd like to have more time to jump
> into it...
>
> Have you ever considered to use the MRP algorithms for requirements'
> generation?
>
> Jacopo
>
>
> Christopher Farley wrote:
>
>> 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.
>>
>
>
> _______________________________________________
> Users mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/users>