Posted by
Christopher Farley on
URL: http://ofbiz.116.s1.nabble.com/OFBiz-Users-Automatic-Purchasing-tp136301p136314.html
Si Chen (
[hidden email]) wrote:
> Christopher, Jacopo -
>
> I think Christopher brought up many good points. Do you have anything
> you can show us of what you've done?
I worked on it a bunch this weekend, and unfortunately reached another
major stumbling block.
In order to handle continous, automatic purchasing AND support something
like reorderQuantity, something needs to change with purchase orders or
requirements. The problem can be summed up as follows:
When a sales order comes in for product X, a requirement is generated.
It is certainly possible to support reorderQuantity -- you must inspect
the existing requirements to make sure you do this properly. Next you go
to order entry and enter a purchase order. You add the requirement for
product X to the purchase order. Once the purchase order is placed, the
requirements change status from "APPROVED" to "ORDERED".
It is at this moment (after the purchase order has been created, but
before any shipments have been entered on the purchase order) that there
is a major inconsistency. If I'm not mistaken, purchase orders are
associated with a company and not a facility. So if somebody enters a
new sales order for product X, there are no existing requirements, and
no incoming shipments, and you will generate a requirement for the
reorderQuantity, which is NOT what you want to do.
I can think of three possible solutions:
1. purchase orders are associated with a facility, so you can atomically
change the requirement to 'ORDERED' and have a countable 'on order'
quantity for a given product/facility.
2. Create a new status for requirements, say, REQ_COMPLETED. When the
purchase order is received, the requirement can go from REQ_ORDERED
to REQ_COMPLETED. When calculating reorder quantity, you would count
requirements with a status of REQ_CREATED, REQ_APPROVED and
REQ_ORDERED, and ignore those that were completed.
3. Abandon continuously-generated requirements altogether. Continuously
generated requirements might save you a little bit of time, but they
open up major cans of worms on several fronts. What happens if you
change the facility's minimumStock or reorderQuantity after a
requirement already exists? What happens if you do a physical count
and adjust the quantity on hand/available to promise? Do you adjust
the requirements to take this in to account? If so, when? When a
sales order is placed? When the inventory adjustment is made?
Furthermore, replentishment orders are generally made periodically
(daily, weekly, monthly, etc). Then why not simply generate a list of
requirements periodically, when you want to place an order.
So, on the one hand it seems like a trivial bug, but on closer
inspection it looks more like there are some architecture issues.
--
Christopher Farley
www.northernbrewer.com
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users