Daniel,
I'm not sure to understand if what you are suggesting is just a wish
list of features that you would like to see implemented in the system
sooner or later, or it is something you are working on (or plan to work
on) and would like to contribute or something that your company would be
interested in sponsoring (if this last option is true, the upcoming
developer conference would probably be the right place to try to setup a
working group).
In general however I think that some of your requirements seem pretty
specific (and I agree with most of Scott's comments on this), even if
there is definitely room for many improvements to the existing
requirement generation processes that can lead to aggregate
requirements/orders.
However, for more advanced requirement generation strategies, I always
strongly recommend to look at the existing MRP features (but also there
there is room for many improvements).
Jacopo
Daniel Kunkel wrote:
Hi
Wouldn't that increase inventory levels rather than lower them? It
seems like that would equate to filling your petrol tank every time you
see a station instead of waiting until your almost empty.
I guess I didn't explain that very well. Lets say had products A, B, and
C. What I'm suggesting is when A is down to the point that you need to
reorder, why not also fill up on B and C to the "max stock" level.
And, rather than tracking requirements during each order, why not
perform this as a scheduled service with alert e-mails, and auto created
purchase orders. In some businesses this could mean calculating the
order 10 minutes before your vendor's cut-off time for the day.
The real situation gets a little more complicated. For instance, if it
wasn't just A, B and C, but 26 products, A to Z with min 10 and max of
30, and an order for 50 B. I usually wouldn't want lots of line items
only ordering 1 and 2 to fill up again, but instead would probably set a
minimum order qty of 5 so in the same order with 50 B's, I'd also get 5
A, 12 C, and 8 D, but not 1 E or 2 H. If there was a price break at 10
per item, I'd change the auto_Order minimum order to 10, in this case
only ordering 59 B and 12 C.
--
In my previous e-mail I wasn't sure if it would be easier to work with
QOH, or ATP, but after thinking about it, I think ATP is much easier to
work with. In essence, the ordering algorithm calculates Order Qty =
max qty - ATP only when Order Qty > auto_order minimum qty. For
example, if I had 21 B's before the order for 50 units came in, I would
order 59. 30 - (-29).
--
So far, I've been thinking about items that you want to keep in stock,
while minimizing the number of orders you need to place with the vendor.
If the product was an expensive component that you only wanted to stock
when needed, you would set the maximum quantity equal to the minimum
quantity. By doing this, the system would only place an order when the
atp was below the minimum, and only for the minimum necessary according
to the suppliers set minimum order .
--
E-mail alerts...
Thats easily done as a customization rather than something in svn that
may not suit the needs of others?
I would think this would be a very much loved feature by lots of people as long
as it could be made to work reliably! Once you had the order quantities tweaked
for your business, just go about your business knowing you'll be alerted to any
purchases you need to make. From my experience I believe small business
owners would love this feature since they could concentrate on other things!
Finally, if someone doesn't want to use the feature, just leave the
alert e-mail field blank. What's one empty field in the scheme of
things.
Thanks
Daniel
On Thu, 2007-02-08 at 18:37 +1300, Scott Gray wrote:
Hi Daniel
A few quick comments inline:
Daniel Kunkel wrote:
As I understand the current main options:
STOCK_QOH: when qoh goes under minimum stock a requirement is created for the
reorder qty.
STOCK_ATP: when atp goes under minimum stock a requirement is created for the
reorder qty.
ATP: creates a requirement on ATP levels and links it to the order item that
caused the reservations
Regardless, I wonder if there isn't another way at approaching this whole thing
that might help reduce inventory levels and number of orders while keeping
everything in stock...
Rather than just working with a reorder quantity, include a target quantity or
max quantity of stock allowed to be ordered.
When making an order from a supplier, order all items that you can while staying
below the max quantity. The current enumeration field is "Main Supplier", but it
might help to create a new field, perhaps something like "Auto_Order"
Wouldn't that increase inventory levels rather than lower them? It
seems like that would equate to filling your petrol tank every time you
see a station instead of waiting until your almost empty.
A question is whether it would be better to work from qoh, or atp. Can anyone shed
light on what might work better, or if we would want to support both?
Rather than tracking and checking for requirements during every order placed,
work from a timetable. That way, an order could automatically be placed including
as many things as were needed for delivery from that supplier all at once than
having separate requirements for different items.
That is part of the point of minimums, so that you are ordering as much
product as possible each time and are then able to take advantage of
price breaks. More work could be done with order consolidation by
calculating lead times versus promised delivery dates to your customers.
But if you wanted to do the above you could easily run the mrp process
according to your timetable which would delete and recreate the
requirements on the spot (I think).
E-mail alerts. The requirements service could create an inventory report
that could be seen by qualified users of the system, and/or be e-mailed to
the list of appropriate personnel.
I haven't thought through what features would be optimum for the
manufacturing process... Does any of this spark any more ideas?
Thats easily done as a customization rather than something in svn that
may not suit the needs of others?
Regards
Scott
