Posted by
Christopher Farley on
URL: http://ofbiz.116.s1.nabble.com/OFBiz-Users-Automatic-Purchasing-tp136301p136311.html
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.
--
Christopher Farley
www.northernbrewer.com
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users