OFBiz › OFBiz - Dev

Re: Dev - [OFBiz] Users - requirements - atp reaches minimum stock

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Jacopo Cappellato

Re: Dev - [OFBiz] Users - requirements - atp reaches minimum stock

I've moved this thread to the dev list because I'd like to discuss some
design decision about the auto requirement creation.

I've reviewed the mods Si did to the checkCreateStockRequirement (i.e.
the service that creates the requirements testing QOH inventory) in rev.
5409 and there is one thing that I don't think is correct:
when the inventory is issued and the qoh is already under the minimum
quantity, a research for existing requirements (in "created" status) has
been added to update their required qty to reflect the new issuance; I
think this is wrong because we cannot know if a requirement has already
been approved and maybe already transformed into a purchase order (still
not received).
The original idea of that service was based on a simple assumption: the
minimum levels and the reorder quantity in the ProductFacility are
properly set to maintain the stock levels sufficient to fulfill a
'normal' number of sales.
For this reason the requirement, for the reorder qty, should be created
only when the qoh reaches the minimum level: the remaining stock will be
sufficient to fulfill all the incoming orders before the new purchase
order (generated from the requirement) is received.

This is a simple strategy but it works for many simple companies; if we
need an advanced requirement strategy (that takes into account every
sales order, purchase order, manufacturing order and requirements in the
system) we should use the MRP instead of the simple requirement creation
algorithms.

So I propose to reintegrate some of the logic in rev. 5202 in the
checkCreateStockRequirement service.

What do you think of this? Si, what do you think?

After this is done, I'll create a new service that does the same but
looking at the ATP levels instead.

Jacopo

Scott Gray wrote:

> Ignore my second paragraph, an inventory transfer i was playing with
> last month caused the problem, so my atp must have been 0
>
> On 4/29/06, *Scott Gray* < [hidden email] <mailto:[hidden email]>>
> wrote:
>
> Hi Joachim
>
> At the moment a Product Requirement is created as soon as the order is
> placed but as you mention this is only for the qty ordered. You
> need to run
> an mrp from the manufacturing app which will create a requirement
> for the
> reorder qty under 'Purchase Order proposed by the mrp process'.
>
> The whole thing seems a bit buggy at the moment, I just created an
> order for
> 6 Big Gizmos (ATP: 15, QOH: 15, MIN: 10), the Product Requirement
> suggested
> I order another 6 and also the inventory details are now ATP: -6,
> QOH: 15.
>
> I do intend to tidy up the requirement processes but won't have the
> time for
> another month or so.
>
> Regards
> Scott
>
> -----Original Message-----
> From: [hidden email]
> <mailto:[hidden email]>
> [mailto:[hidden email]
> <mailto:[hidden email]>]
> On Behalf Of Schreibmaier Joachim
> Sent: Saturday, 29 April 2006 4:09 a.m.
> To: [hidden email] <mailto:[hidden email]>
> Subject: Re: [OFBiz] Users - requirements - atp reaches minimum stock
>
> Jacopo,
>
> > in my opinion the requirement method based on ATP is not correctly
> > implemented; I'd suggest using that based on QOH instead.
>
> > For more information see the thread "Requirements based on ATP
> levels"
> > happened earlier this month in this list.
>
> Thanks for the info about the other thread. But there isn't a solution
> (patch) for it. I would be happy if there is the same mechanism like
> in the
> QOH but the requirement is created after the order is created.
>
> Best Regards
>
> Joachim
>
> --
> Joachim Schreibmaier
>
>
> _______________________________________________
> Users mailing list
> [hidden email] <mailto:[hidden email]>
> http://lists.ofbiz.org/mailman/listinfo/users
> <http://lists.ofbiz.org/mailman/listinfo/users>
>
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Scott Gray

Re: Dev - [OFBiz] Users - requirements - atp reachesminimum stock

I agree, reorder qty should essentially be synonymous with max qty.

After looking through the requirements code, my first thought was that the
requirement generation code should be triggered through an EECA on
InventoryItemDetail, that would certainly make it easier to track the code
down and make custom changes when needed.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Jacopo Cappellato
Sent: Sunday, 30 April 2006 5:36 a.m.
To: OFBiz Project Development Discussion (High Traffic)
Cc: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Dev - [OFBiz] Users - requirements - atp reachesminimum
stock

I've moved this thread to the dev list because I'd like to discuss some
design decision about the auto requirement creation.

I've reviewed the mods Si did to the checkCreateStockRequirement (i.e.
the service that creates the requirements testing QOH inventory) in rev.
5409 and there is one thing that I don't think is correct:
when the inventory is issued and the qoh is already under the minimum
quantity, a research for existing requirements (in "created" status) has
been added to update their required qty to reflect the new issuance; I
think this is wrong because we cannot know if a requirement has already
been approved and maybe already transformed into a purchase order (still
not received).
The original idea of that service was based on a simple assumption: the
minimum levels and the reorder quantity in the ProductFacility are
properly set to maintain the stock levels sufficient to fulfill a
'normal' number of sales.
For this reason the requirement, for the reorder qty, should be created
only when the qoh reaches the minimum level: the remaining stock will be
sufficient to fulfill all the incoming orders before the new purchase
order (generated from the requirement) is received.

This is a simple strategy but it works for many simple companies; if we
need an advanced requirement strategy (that takes into account every
sales order, purchase order, manufacturing order and requirements in the
system) we should use the MRP instead of the simple requirement creation
algorithms.

So I propose to reintegrate some of the logic in rev. 5202 in the
checkCreateStockRequirement service.

What do you think of this? Si, what do you think?

After this is done, I'll create a new service that does the same but
looking at the ATP levels instead.

Jacopo

Scott Gray wrote:

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Si Chen-2

Re: Dev - [OFBiz] Users - requirements - atp reaches minimum stock

In reply to this post by Jacopo Cappellato

Jacopo,

I just read some books (Gordon Graham's Distribution Inventory Management), and I think most systems have the concept of an Order Point, Line Point, and an Economic Order Quantity (EOQ). Order Point is the quantity threshold for ordering more inventory. Line Point is the normal amount we try to keep inventory at. EOQ is the quantity to order which would minimize total costs of carrying inventory versus processing orders and receipts. The idea seems to be that one should at least order an EOQ each time, instead of whenever inventory falls below Order Point.

I think this might translate into a process where Requirements are created every time an item is ordered but the inventory is already below a threshold quantity, but purchase orders are only created when we have sufficient Requirements. In that sense, perhaps the whole thing with checking existing Requirements and Purchase Orders is unnecessary?

Sorry it's been a while (r 5409!) so I'm a little hazy too. What are you thoughts for fixing it?

I definitely agree, also, that integrating in the MRP code would be a good idea.

Have a great weekend,

Si

Jacopo Cappellato wrote:

I've moved this thread to the dev list because I'd like to discuss some 
design decision about the auto requirement creation.

I've reviewed the mods Si did to the checkCreateStockRequirement (i.e. 
the service that creates the requirements testing QOH inventory) in rev. 
5409 and there is one thing that I don't think is correct:
when the inventory is issued and the qoh is already under the minimum 
quantity, a research for existing requirements (in "created" status) has 
been added to update their required qty to reflect the new issuance; I 
think this is wrong because we cannot know if a requirement has already 
been approved and maybe already transformed into a purchase order (still 
not received).
The original idea of that service was based on a simple assumption: the 
minimum levels and the reorder quantity in the ProductFacility are 
properly set to maintain the stock levels sufficient to fulfill a 
'normal' number of sales.
For this reason the requirement, for the reorder qty, should be created 
only when the qoh reaches the minimum level: the remaining stock will be 
sufficient to fulfill all the incoming orders before the new purchase 
order (generated from the requirement) is received.

This is a simple strategy but it works for many simple companies; if we 
need an advanced requirement strategy (that takes into account every 
sales order, purchase order, manufacturing order and requirements in the 
system) we should use the MRP instead of the simple requirement creation 
algorithms.

So I propose to reintegrate some of the logic in rev. 5202 in the 
checkCreateStockRequirement service.

What do you think of this? Si, what do you think?

After this is done, I'll create a new service that does the same but 
looking at the ATP levels instead.

Jacopo

Scott Gray wrote:

Ignore my second paragraph, an inventory transfer i was playing with 
last month caused the problem, so my atp must have been 0

On 4/29/06, *Scott Gray* < [hidden email] [hidden email]> 
wrote:

    Hi Joachim

    At the moment a Product Requirement is created as soon as the order is
    placed but as you mention this is only for the qty ordered.  You
    need to run
    an mrp from the manufacturing app which will create a requirement
    for the
    reorder qty under 'Purchase Order proposed by the mrp process'.

    The whole thing seems a bit buggy at the moment, I just created an
    order for
    6 Big Gizmos (ATP: 15, QOH: 15, MIN: 10), the Product Requirement
    suggested
    I order another 6 and also the inventory details are now ATP: -6,
    QOH: 15.

    I do intend to tidy up the requirement processes but won't have the
    time for
    another month or so.

    Regards
    Scott

    -----Original Message-----
    From: [hidden email]
    [hidden email]
    [[hidden email]
    [hidden email]]
    On Behalf Of Schreibmaier Joachim
    Sent: Saturday, 29 April 2006 4:09 a.m.
    To: [hidden email] [hidden email]
    Subject: Re: [OFBiz] Users - requirements - atp reaches minimum stock

    Jacopo,

     > in my opinion the requirement method based on ATP is not correctly
     > implemented; I'd suggest using that based on QOH instead.

     > For more information see the thread "Requirements based on ATP
    levels"
     > happened earlier this month in this list.

    Thanks for the info about the other thread. But there isn't a solution
    (patch) for it. I would be happy if there is the same mechanism like
    in the
    QOH but the requirement is created after the order is created.

    Best Regards

    Joachim

    --
    Joachim Schreibmaier


    _______________________________________________
    Users mailing list
    [hidden email] [hidden email]
    http://lists.ofbiz.org/mailman/listinfo/users
    <http://lists.ofbiz.org/mailman/listinfo/users>



------------------------------------------------------------------------

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev