Dev - facilities owned by others, ordering, a few other things (testing)

[davidnwelton]

Regarding facilities owned by others:

*) We would use facilities owned by others as a way to keep track of
their QOH, which they tell us at some interval.  We need the QOH in
order to give customers an idea of how long it might take to get a
product (if these guys have it, it'll take 5 days... these other guys
- only 2 days).  However, it's just a guestimate, because someone else
might order from the same supplier's facility, so they have to let us
know every so often how much they really have.

*) In any case, to obtain items from them, we still have to place an
order and route things through that mechanism.

Regarding ordering and requirements:

*) I fiddled with the requirement_method_enum_id, but I'm not having
any luck getting it to actually generate requirements, and thus,
orders.  If I use the 'below ATP' setting, it complains that there
aren't even inventory entries for all items, so it gets a null and
barfs:

Error in simple-method [Create a Requirement for an item  based on ATP
inventory quantity and minimum
[file:/home/davidw/workshop/ofbiz/applications/order/script/org/ofbiz/order/order/OrderServices.xml#createRequirementFromItemATP]]:;
[Error with comparison in if-compare-field between fields
[.availableToPromiseTotal] with value [-6.0] and
[.productFacility.minimumStock] with value [null] with operator [less]
and type [Double]: , Right value is null, cannot complete compare for
the operator less])

Using the 'auto' setting, it runs ok, but doesn't seem to do anything:

EntityEcaRule.java:122:INFO ] Running Entity ECA Service:
checkCreateOrderRequirement, triggered by rule on Entity: OrderItem
67226626[   PrimaryKeyFinder.java:132:INFO ] Returning null because
found incomplete primary key in find: [GenericEntity: Product]

*) Ideally, what we'd like is to have some information for each
supplier, and have a set of order rules like "order if more than 2000
dollars" or "don't order if the order is under 1000 dollars and the
shipment won't be outside the promised ship date.  I suppose that this
is something we'd add ourselves, though, to move products from
'required' to 'ordered', right?

Testing:

*) What do you guys generally do to test situations?  I realize that
the number of combinations to run through if you tested all of them
together might be astronomical, but it might be nice to have a
regression test suite where you could run through scenarious
encountered in order to ensure that they function correctly in the
future.

Thanks for any thoughts or comments,
--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

please see my comments inline:

David Welton wrote:

> Regarding facilities owned by others:
>
> *) We would use facilities owned by others as a way to keep track of
> their QOH, which they tell us at some interval.  We need the QOH in
> order to give customers an idea of how long it might take to get a
> product (if these guys have it, it'll take 5 days... these other guys
> - only 2 days).  However, it's just a guestimate, because someone else
> might order from the same supplier's facility, so they have to let us
> know every so often how much they really have.
>
> *) In any case, to obtain items from them, we still have to place an
> order and route things through that mechanism.
>

Hmmm... I'm not sure you should follow this path. Facilities and
inventory items are beasts that I'd use only when I want (and can) track
exact information about each inventory item
I'd suggest to store this information (i.e. the QOH of a given product
in a supplier's facility) in a had-hoc entity or (maybe better) you
could add a new field to the SupplierProduct entity: much more easy to
maintain and to get.
Another nice way of retrieving this information is calling a remote
command (SOAP?) on the supplier's ERP... yes, I'm only joking: if your
suppliers are from Italy you'll be lucky if they can send you an Excel
document with their inventory numbers in it

> Regarding ordering and requirements:
>
> *) I fiddled with the requirement_method_enum_id, but I'm not having
> any luck getting it to actually generate requirements, and thus,
> orders.  If I use the 'below ATP' setting, it complains that there
> aren't even inventory entries for all items, so it gets a null and
> barfs:
>
> Error in simple-method [Create a Requirement for an item  based on ATP
> inventory quantity and minimum
> [file:/home/davidw/workshop/ofbiz/applications/order/script/org/ofbiz/order/order/OrderServices.xml#createRequirementFromItemATP]]:;
> [Error with comparison in if-compare-field between fields
> [.availableToPromiseTotal] with value [-6.0] and
> [.productFacility.minimumStock] with value [null] with operator [less]
> and type [Double]: , Right value is null, cannot complete compare for
> the operator less])
>
> Using the 'auto' setting, it runs ok, but doesn't seem to do anything:
>
> EntityEcaRule.java:122:INFO ] Running Entity ECA Service:
> checkCreateOrderRequirement, triggered by rule on Entity: OrderItem
> 67226626[   PrimaryKeyFinder.java:132:INFO ] Returning null because
> found incomplete primary key in find: [GenericEntity: Product]
>

I'll have a look at these today and I'll let you know. The auto
requirement code is *experimental* i.e. I don't think that has been
never really used in production as is.


Jacopo

> *) Ideally, what we'd like is to have some information for each
> supplier, and have a set of order rules like "order if more than 2000
> dollars" or "don't order if the order is under 1000 dollars and the
> shipment won't be outside the promised ship date.  I suppose that this
> is something we'd add ourselves, though, to move products from
> 'required' to 'ordered', right?
>
> Testing:
>
> *) What do you guys generally do to test situations?  I realize that
> the number of combinations to run through if you tested all of them
> together might be astronomical, but it might be nice to have a
> regression test suite where you could run through scenarious
> encountered in order to ensure that they function correctly in the
> future.
>
> Thanks for any thoughts or comments,
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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

[Jacopo Cappellato]

David,

David Welton wrote:
> ...
 >
> Using the 'auto' setting, it runs ok, but doesn't seem to do anything:
>
> EntityEcaRule.java:122:INFO ] Running Entity ECA Service:
> checkCreateOrderRequirement, triggered by rule on Entity: OrderItem
> 67226626[   PrimaryKeyFinder.java:132:INFO ] Returning null because
> found incomplete primary key in find: [GenericEntity: Product]
>

I've tested the 'auto' requirement method with WG-1111 and it seems to
work fine... could you give me some hints on how to recreate the error?

Thanks,

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

[BJ Freeman]

We use the same model for remote supplier, like dropshippers.
I work with the suppliers and get them to provide urls for Inventory,
New, Discontinued, outofstock.
the data uses text pages and the data is separated by | with CRLF as
endofline.
I have a services that goes out and retrieves then parses this info.
I put the services in as jobs, based on how often suppliers update their
page.
for other suppliers, that support inventory, we have various services
for email and EDI.

I just have a requirement, dealing with backorders where an order is
sent, but the suppliers send back a notice that the item is backordered.
so having to notify the customer and adjust the order from the customer.
Working on how to add this to evaluating future orders to this supplier.

David Welton sent the following on 3/23/06 4:50 AM:

> Regarding facilities owned by others:
>
> *) We would use facilities owned by others as a way to keep track of
> their QOH, which they tell us at some interval.  We need the QOH in
> order to give customers an idea of how long it might take to get a
> product (if these guys have it, it'll take 5 days... these other guys
> - only 2 days).  However, it's just a guestimate, because someone else
> might order from the same supplier's facility, so they have to let us
> know every so often how much they really have.
>
> *) In any case, to obtain items from them, we still have to place an
> order and route things through that mechanism.
>
> Regarding ordering and requirements:
>
> *) I fiddled with the requirement_method_enum_id, but I'm not having
> any luck getting it to actually generate requirements, and thus,
> orders.  If I use the 'below ATP' setting, it complains that there
> aren't even inventory entries for all items, so it gets a null and
> barfs:
>
> Error in simple-method [Create a Requirement for an item  based on ATP
> inventory quantity and minimum
> [file:/home/davidw/workshop/ofbiz/applications/order/script/org/ofbiz/order/order/OrderServices.xml#createRequirementFromItemATP]]:;
> [Error with comparison in if-compare-field between fields
> [.availableToPromiseTotal] with value [-6.0] and
> [.productFacility.minimumStock] with value [null] with operator [less]
> and type [Double]: , Right value is null, cannot complete compare for
> the operator less])
>
> Using the 'auto' setting, it runs ok, but doesn't seem to do anything:
>
> EntityEcaRule.java:122:INFO ] Running Entity ECA Service:
> checkCreateOrderRequirement, triggered by rule on Entity: OrderItem
> 67226626[   PrimaryKeyFinder.java:132:INFO ] Returning null because
> found incomplete primary key in find: [GenericEntity: Product]
>
> *) Ideally, what we'd like is to have some information for each
> supplier, and have a set of order rules like "order if more than 2000
> dollars" or "don't order if the order is under 1000 dollars and the
> shipment won't be outside the promised ship date.  I suppose that this
> is something we'd add ourselves, though, to move products from
> 'required' to 'ordered', right?
>
> Testing:
>
> *) What do you guys generally do to test situations?  I realize that
> the number of combinations to run through if you tested all of them
> together might be astronomical, but it might be nice to have a
> regression test suite where you could run through scenarious
> encountered in order to ensure that they function correctly in the
> future.
>
> Thanks for any thoughts or comments,
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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

[davidnwelton]

> I've tested the 'auto' requirement method with WG-1111 and it seems to
> work fine... could you give me some hints on how to recreate the error?

I wiped everything, updated to the latest SVN (from my checkout about
a week ago), and indeed, now it works:-/  At least I have a
requirement.  Now to find out how to make an order out of that.

Not sure why it was dying earlier... perhaps it was a strange/bad
sequence of things.

Thanks for taking a look!
--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

David Welton wrote:
>> I've tested the 'auto' requirement method with WG-1111 and it seems to
>> work fine... could you give me some hints on how to recreate the error?
>
> I wiped everything, updated to the latest SVN (from my checkout about
> a week ago), and indeed, now it works:-/  At least I have a
> requirement.  Now to find out how to make an order out of that.

How to make an order out of a requirement:

1) Go to the order->Requirements page end change the requirement's
status to 'approved'. (you can also bulk approve requirements in the
manufacturing->approve requirements page)

2) go to the order->order entry page and start a new purchase order

3) in the left column you'll see a "requirement" link that will point to
a page from which you can select the approved requirements

>
> Not sure why it was dying earlier... perhaps it was a strange/bad
> sequence of things.
>

Maybe... however now I'm testing the other two methods... I'll let you know.

Jacopo

> Thanks for taking a look!
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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

[Jacopo Cappellato]

David,

ok I've tested the requirement method "When QOH reaches minimum
stock..." and it seems to work.

This method creates a requirement when the qoh of the product goes under
the minimum quantity set in the product->facility tab.
This can happen after that you ship (or quick ship) an order.

Now I'll have a look at the "ATP method", but this one was not written
by me so I'm not sure on how it really works.

Stay tuned :-)

Jacopo

Jacopo Cappellato wrote:

> David,
>
> David Welton wrote:
>>> I've tested the 'auto' requirement method with WG-1111 and it seems to
>>> work fine... could you give me some hints on how to recreate the error?
>> I wiped everything, updated to the latest SVN (from my checkout about
>> a week ago), and indeed, now it works:-/  At least I have a
>> requirement.  Now to find out how to make an order out of that.
>
> How to make an order out of a requirement:
>
> 1) Go to the order->Requirements page end change the requirement's
> status to 'approved'. (you can also bulk approve requirements in the
> manufacturing->approve requirements page)
>
> 2) go to the order->order entry page and start a new purchase order
>
> 3) in the left column you'll see a "requirement" link that will point to
> a page from which you can select the approved requirements
>
>> Not sure why it was dying earlier... perhaps it was a strange/bad
>> sequence of things.
>>
>
> Maybe... however now I'm testing the other two methods... I'll let you know.
>
> Jacopo
>
>
>> Thanks for taking a look!
>> --
>> David N. Welton
>>  - http://www.dedasys.com/davidw/
>>
>> Linux, Open Source Consulting
>>  - http://www.dedasys.com/
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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

[davidnwelton]

> How to make an order out of a requirement:
>
> 1) Go to the order->Requirements page end change the requirement's
> status to 'approved'. (you can also bulk approve requirements in the
> manufacturing->approve requirements page)
>
> 2) go to the order->order entry page and start a new purchase order
>
> 3) in the left column you'll see a "requirement" link that will point to
> a page from which you can select the approved requirements

Ok, thanks, I see how it works now.   I suppose this is something we'd
have to hack on, because it doesn't scale at all - imagine lots of
orders coming in from a store, each one for lots of different things,
each one of those being made into a requirement, that must be
approved, and then dragged through the entire purchase order process.

Also, something that apparently is missing from this process, but
which I do see in the database tables and data model book is the
concept of automatically picking a supplier based on preferences, as
well as factors such as overall order price, and the time it would
take to complete vs time promised to customers.  I realize that that's
perhaps fancier than most people need, though, and something I'd have
to work on if we end up using OFBiz in some capacity (I have the ok to
evaluate it in detail for a few new things we're doing, which is good
news!)

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

David Welton wrote:
>
> Ok, thanks, I see how it works now.   I suppose this is something we'd
> have to hack on, because it doesn't scale at all - imagine lots of
> orders coming in from a store, each one for lots of different things,
> each one of those being made into a requirement, that must be
> approved, and then dragged through the entire purchase order process.
>

Yes, definitely it can be tuned to work well with big numbers.
However, the concept of the "auto" requirement is that it should be used
only to generate requirement for the products that I have in my catalog,
but that I don't want to keep in warehouse i.e. I buy them from a
supplier when a customers orders them. So the requirement is specific to
fulfill that order and in fact, when you create the purchase order you
can see that the purchase order item is linked to the sales order item.
On the other hand the "QOH requirement" is generated only when the qty
in inventory goes under the minimum stock, and so it is well suited for
the products that I maintain in stock.

> Also, something that apparently is missing from this process, but
> which I do see in the database tables and data model book is the
> concept of automatically picking a supplier based on preferences, as
> well as factors such as overall order price, and the time it would
> take to complete vs time promised to customers.

Yes, this is not implemented, and it would a very nice feature.
I think that the best thing is to leave the requirement generation as is
now and then implement a new service (that can be run as a scheduled job
or triggered by a system event - ECA) that reads all the requirements
and based on some of the factors that you have cited above (some of them
can be stored in the SupplierProduct entity), will generate entries in
the RequirementRole entity.
Examples of the roles I have in mind are: PRIMARY_SUPPLIER,
QUICKEST_SUPPLIER, etc...

>  I realize that that's
> perhaps fancier than most people need, though, and something I'd have
> to work on if we end up using OFBiz in some capacity (I have the ok to
> evaluate it in detail for a few new things we're doing, which is good
> news!)
>

Great news!

Jacopo

> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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

[Jacopo Cappellato]

David,

ok, I've also tested the "ATP" method.
It works but... I think that there are some problems:
It is something in the middle between the AUTO and the QOH methods.

It creates a requirement when the atp quantity (not the qoh) goes under
the minimum stock qty (this can happen when you create an order).
However the requirement that is generated is associated to the order
itself (such as in the AUTO method): this in my opinion is not correct.

Maybe we could ask to Si what he thinks about this issue (if I'm not
wrong Si developed this part).

Jacopo

Jacopo Cappellato wrote:

> David,
>
> David Welton wrote:
>> Ok, thanks, I see how it works now.   I suppose this is something we'd
>> have to hack on, because it doesn't scale at all - imagine lots of
>> orders coming in from a store, each one for lots of different things,
>> each one of those being made into a requirement, that must be
>> approved, and then dragged through the entire purchase order process.
>>
>
> Yes, definitely it can be tuned to work well with big numbers.
> However, the concept of the "auto" requirement is that it should be used
> only to generate requirement for the products that I have in my catalog,
> but that I don't want to keep in warehouse i.e. I buy them from a
> supplier when a customers orders them. So the requirement is specific to
> fulfill that order and in fact, when you create the purchase order you
> can see that the purchase order item is linked to the sales order item.
> On the other hand the "QOH requirement" is generated only when the qty
> in inventory goes under the minimum stock, and so it is well suited for
> the products that I maintain in stock.
>
>> Also, something that apparently is missing from this process, but
>> which I do see in the database tables and data model book is the
>> concept of automatically picking a supplier based on preferences, as
>> well as factors such as overall order price, and the time it would
>> take to complete vs time promised to customers.
>
> Yes, this is not implemented, and it would a very nice feature.
> I think that the best thing is to leave the requirement generation as is
> now and then implement a new service (that can be run as a scheduled job
> or triggered by a system event - ECA) that reads all the requirements
> and based on some of the factors that you have cited above (some of them
> can be stored in the SupplierProduct entity), will generate entries in
> the RequirementRole entity.
> Examples of the roles I have in mind are: PRIMARY_SUPPLIER,
> QUICKEST_SUPPLIER, etc...
>
>>  I realize that that's
>> perhaps fancier than most people need, though, and something I'd have
>> to work on if we end up using OFBiz in some capacity (I have the ok to
>> evaluate it in detail for a few new things we're doing, which is good
>> news!)
>>
>
> Great news!
>
> Jacopo
>
>> --
>> David N. Welton
>>  - http://www.dedasys.com/davidw/
>>
>> Linux, Open Source Consulting
>>  - http://www.dedasys.com/
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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

[davidnwelton]

On 3/24/06, Jacopo Cappellato <[hidden email]> wrote:

> > Ok, thanks, I see how it works now.   I suppose this is something we'd
> > have to hack on, because it doesn't scale at all - imagine lots of
> > orders coming in from a store, each one for lots of different things,
> > each one of those being made into a requirement, that must be
> > approved, and then dragged through the entire purchase order process.

> Yes, definitely it can be tuned to work well with big numbers.
> However, the concept of the "auto" requirement is that it should be used
> only to generate requirement for the products that I have in my catalog,
> but that I don't want to keep in warehouse i.e. I buy them from a
> supplier when a customers orders them. So the requirement is specific to
> fulfill that order and in fact, when you create the purchase order you
> can see that the purchase order item is linked to the sales order item.
> On the other hand the "QOH requirement" is generated only when the qty
> in inventory goes under the minimum stock, and so it is well suited for
> the products that I maintain in stock.

Right... although... does AUTO *always* order from a supplier?  Once
in a while, you might have something in stock because it got returned
and couldn't be sent back to the supplier... because the supplier gave
you one for free, or various other reasons.  In that case, you want to
unload the one in your warehouse.

> > Also, something that apparently is missing from this process, but
> > which I do see in the database tables and data model book is the
> > concept of automatically picking a supplier based on preferences, as
> > well as factors such as overall order price, and the time it would
> > take to complete vs time promised to customers.

> Yes, this is not implemented, and it would a very nice feature.

...

> Examples of the roles I have in mind are: PRIMARY_SUPPLIER,
> QUICKEST_SUPPLIER, etc...

Well, if everything goes well, hopefully I will be able to work on
this, but it won't be all that soon.  I've already partially built it
for our in-house system, so I have some ideas on how it ought to work.
 What might be difficult is to create a system flexible enough that
people could plug in their own rules... I'm not sure I'd have time for
that.

In any case, thanks again for your help!
--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David Welton wrote:
> On 3/24/06, Jacopo Cappellato <[hidden email]> wrote:
>
>
> Right... although... does AUTO *always* order from a supplier?  Once
> in a while, you might have something in stock because it got returned
> and couldn't be sent back to the supplier... because the supplier gave
> you one for free, or various other reasons.  In that case, you want to
> unload the one in your warehouse.
>

Good point. However you can (manually) cancel a requirement and so the
item in warehouse will be reserved and shipped. Or add some logic in the
service to see if there are units (not reserved) of the product in
warehouse and if so, do not generate the requirement at all.

>>> Also, something that apparently is missing from this process, but
>>> which I do see in the database tables and data model book is the
>>> concept of automatically picking a supplier based on preferences, as
>>> well as factors such as overall order price, and the time it would
>>> take to complete vs time promised to customers.
>
>> Yes, this is not implemented, and it would a very nice feature.
>
> ...
>
>> Examples of the roles I have in mind are: PRIMARY_SUPPLIER,
>> QUICKEST_SUPPLIER, etc...
>
> Well, if everything goes well, hopefully I will be able to work on
> this, but it won't be all that soon.  I've already partially built it
> for our in-house system, so I have some ideas on how it ought to work.
>  What might be difficult is to create a system flexible enough that
> people could plug in their own rules... I'm not sure I'd have time for
> that.
>

It would be great. If you'll implement your logic into a service then it
would be rather easy for others to take it and customize for their needs.

Jacopo

> In any case, thanks again for your help!
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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