You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Daniel Kunkel <Da...@BioWaves.com> on 2007/02/08 05:30:48 UTC
Purchase Orders and Requirements
Hi
I'm finally getting around to playing with purchasing requirements, and
it seems that the current schemes are not well setup for the way we
operate.
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"
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.
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?
Thanks
--
Daniel
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!
Daniel Kunkel DanielKunkel@BioWaves.com
BioWaves, LLC http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588 425-895-0050
http://www.Apartment-Pets.com http://www.Illusion-Optical.com
http://www.Card-Offer.com http://www.RackWine.com
http://www.JokesBlonde.com http://www.Brain-Fun.com
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Re: Purchase Orders and Requirements
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
Re: Purchase Orders and Requirements
Posted by Chris Howe <cj...@yahoo.com>.
The feature set that Daniel is describing is _often used in small
business where minimum/maximum levels are set by gut instead of
historical/data projected needs. Small businesses are further lulled
into this type of ordering because of "free freight" incentives offered
by their vendors. While this may not be a best practice for a company
where this would fluctuate their inventory by hundreds of thousands of
dollars, it is the best practice in a business where the practice would
only fluctuate inventory levels by a couple thousand dollars. There is
a tipping point in size where a company would change their inventory
strategy.
I think we should remember that and ensure that we're extensible enough
to be able to handle both scenarios (which i think we are) but that we
incorporate various settings to configure the various strategies.
--- Daniel Kunkel <Da...@BioWaves.com> wrote:
> Excellent Points.
>
> The real point of my e-mail is to look at what seems to me to be a
> rather different way of handling requirements. I think the algorithm
> is
> versatile enough that it can handle inventory purchasing different
> ways,
> as it can be setup for more automatic ordering, can provide inventory
> alerts, whereas the current system seems a little more confining.
>
> That may not be the case, as I don't know that much about how the
> rest
> of the world orders inventory, which is the largest reason for my
> sharing. I'm also hoping to spark more ideas, and best of all would
> be
> if the idea had enough merit, that someone else would sponsor the
> development. Finally, I do want a more automatic ordering system, and
> might develop it myself eventually, and would want it to be something
> that could be integrated back into the project. (I hope this answer's
> all your points Jacopo)
>
> ---
>
> With regards to the gas tank analogy:
>
> I think we're going for the same purpose, but different ways... You
> have big car tanks, and if you use the fulfillment the way I'm
> thinking
> it works in OFBiz, you fill one car at a time... and have to fill
> that
> car with enough to qualify for price breaks.
>
> I'm thinking... Hey, let's run all these cars with smaller gas
> tanks,
> and none/some/many/all will top off anytime anyone NEEDS to get fuel.
>
> A few things fall out of this...
>
> 1.) Running with minimum quantity = maximum quantity reproduces
> effectively what seems to be functioning currently.
>
> 2.) Being able to use small tanks depends on the vendor
> relationship...
> Some of our vendors don't care what mix of products we get... as
> long
> as we get at least X dollars, we get the quantity discount. Other
> products need to be bought in large packages, crates, truckloads,
> whatever to qualify for the quantity discounts.
>
> 3.) Refilling many at a time is more complicated and more work
> because
> the invoices will have more line items (different products) albeit a
> smaller numbers of each item in any given order.
>
> 4.) An extra "quantity discount module" could be added that will
> guarantee you to meet still meet $ discount requirements by pushing
> for
> the order of a product that would be predicted to be needed soon.
> (Easiest idea here is to slowly raise the minimum qty across all
> vendor
> products until the required $ order was met.)
>
> Would this system be better? I think (depending on vendor
> relationships) it can be engineered to actually give your boss more
> working capital, not less since you can be running with smaller
> tanks,
> or less in the tanks on average while being adjustable for each
> product.
> I think it could be far more automatic. I think it gives the
> businessman
> much more control over how different products are ordered. I think I
> might be overlooking something important!
>
> Thanks
>
> Daniel
>
>
> On Thu, 2007-02-08 at 22:09 +1300, Scott Gray wrote:
> > Hi Daniel
> >
> > > 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.
> > >
> > It still seems like the same analogy applies except this time your
> > traveling in a convoy of cars, when the car with the worst fuel
> economy
> > runs out of gas we all stop and fill up our cars whether we need it
> or
> > not. The net result being that the average amount of fuel in the
> tanks
> > is higher than if everyone just filled up when they needed to.
> >
> > If I was to tell my boss I wanted him to invest an extra hundred
> > thousand in inventory because I don't like too many purchase
> orders, I
> > don't think he'd trust me to spend his money anymore :-)
> > > --
> > > 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).
> > >
> > I prefer ATP but I guess it depends on the circumstances?
> > > --
> > > 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.
> > >
> > What I always try to consider is how low can I take the inventory
> levels
> > without losing customers. Having inventory levels higher than
> necessary
> > is like stuffing cash in your mattress as a preferred investment
> option.
> > >>> E-mail alerts...
> > >>>
> > > 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.
> > >
> > I don't personally have a problem with it and will probably use
> > something similar eventually
> >
> > Regards
> > Scott
> >
>
>
Re: Purchase Orders and Requirements
Posted by Daniel Kunkel <Da...@BioWaves.com>.
Excellent Points.
The real point of my e-mail is to look at what seems to me to be a
rather different way of handling requirements. I think the algorithm is
versatile enough that it can handle inventory purchasing different ways,
as it can be setup for more automatic ordering, can provide inventory
alerts, whereas the current system seems a little more confining.
That may not be the case, as I don't know that much about how the rest
of the world orders inventory, which is the largest reason for my
sharing. I'm also hoping to spark more ideas, and best of all would be
if the idea had enough merit, that someone else would sponsor the
development. Finally, I do want a more automatic ordering system, and
might develop it myself eventually, and would want it to be something
that could be integrated back into the project. (I hope this answer's
all your points Jacopo)
---
With regards to the gas tank analogy:
I think we're going for the same purpose, but different ways... You
have big car tanks, and if you use the fulfillment the way I'm thinking
it works in OFBiz, you fill one car at a time... and have to fill that
car with enough to qualify for price breaks.
I'm thinking... Hey, let's run all these cars with smaller gas tanks,
and none/some/many/all will top off anytime anyone NEEDS to get fuel.
A few things fall out of this...
1.) Running with minimum quantity = maximum quantity reproduces
effectively what seems to be functioning currently.
2.) Being able to use small tanks depends on the vendor relationship...
Some of our vendors don't care what mix of products we get... as long
as we get at least X dollars, we get the quantity discount. Other
products need to be bought in large packages, crates, truckloads,
whatever to qualify for the quantity discounts.
3.) Refilling many at a time is more complicated and more work because
the invoices will have more line items (different products) albeit a
smaller numbers of each item in any given order.
4.) An extra "quantity discount module" could be added that will
guarantee you to meet still meet $ discount requirements by pushing for
the order of a product that would be predicted to be needed soon.
(Easiest idea here is to slowly raise the minimum qty across all vendor
products until the required $ order was met.)
Would this system be better? I think (depending on vendor
relationships) it can be engineered to actually give your boss more
working capital, not less since you can be running with smaller tanks,
or less in the tanks on average while being adjustable for each product.
I think it could be far more automatic. I think it gives the businessman
much more control over how different products are ordered. I think I
might be overlooking something important!
Thanks
Daniel
On Thu, 2007-02-08 at 22:09 +1300, Scott Gray wrote:
> Hi Daniel
>
> > 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.
> >
> It still seems like the same analogy applies except this time your
> traveling in a convoy of cars, when the car with the worst fuel economy
> runs out of gas we all stop and fill up our cars whether we need it or
> not. The net result being that the average amount of fuel in the tanks
> is higher than if everyone just filled up when they needed to.
>
> If I was to tell my boss I wanted him to invest an extra hundred
> thousand in inventory because I don't like too many purchase orders, I
> don't think he'd trust me to spend his money anymore :-)
> > --
> > 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).
> >
> I prefer ATP but I guess it depends on the circumstances?
> > --
> > 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.
> >
> What I always try to consider is how low can I take the inventory levels
> without losing customers. Having inventory levels higher than necessary
> is like stuffing cash in your mattress as a preferred investment option.
> >>> E-mail alerts...
> >>>
> > 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.
> >
> I don't personally have a problem with it and will probably use
> something similar eventually
>
> Regards
> Scott
>
Re: Purchase Orders and Requirements
Posted by Scott Gray <le...@gmail.com>.
Hi Daniel
> 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.
>
It still seems like the same analogy applies except this time your
traveling in a convoy of cars, when the car with the worst fuel economy
runs out of gas we all stop and fill up our cars whether we need it or
not. The net result being that the average amount of fuel in the tanks
is higher than if everyone just filled up when they needed to.
If I was to tell my boss I wanted him to invest an extra hundred
thousand in inventory because I don't like too many purchase orders, I
don't think he'd trust me to spend his money anymore :-)
> --
> 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).
>
I prefer ATP but I guess it depends on the circumstances?
> --
> 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.
>
What I always try to consider is how low can I take the inventory levels
without losing customers. Having inventory levels higher than necessary
is like stuffing cash in your mattress as a preferred investment option.
>>> E-mail alerts...
>>>
> 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.
>
I don't personally have a problem with it and will probably use
something similar eventually
Regards
Scott
Re: Purchase Orders and Requirements
Posted by Daniel Kunkel <Da...@BioWaves.com>.
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
Re: Purchase Orders and Requirements
Posted by Scott Gray <le...@gmail.com>.
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