[
https://issues.apache.org/jira/browse/OFBIZ-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887494#action_12887494
]
Albert Mayo edited comment on OFBIZ-3856 at 7/12/10 4:05 PM:
-------------------------------------------------------------
I like the simplicity of your solution. I may have taken some unneeded steps
in attempt to minimize the number of loops -- for instance my solution will
loop through orders with a previous history of canceled/finished picklists to
see if they need to be added again, versus looping through all approved orders.
My method may be unnecessary since both situations would be completed quickly,
even with thousands of approved orders.
Here are some logical points that I considered while I was programming and
testing. These may help with test cases when someone attempts to integrate a
solution:
- Joining to the picklist tables for the views can add to the count results if
an order has multiple picklists in its history. To test, create and cancel a
picklist with the same order multiple times. When the order is available to be
picked again, be sure the count does not increase.
- If an order can be split and an item is partially backordered, should the
partially available inventory be added to the picklist? My solution adds the
item to the picklist with the available quantity. I believe OFBiz 4.0 does as
well. Example: If someone orders a quantity of 3 of an item and a quantity of
1 is on backorder and maySplit equals Yes, then when a picklist is created for
the order this particular item should have a pick for a quantity of 2.
- Continuing the last example, if maySplit equals No, then the complete order
should not be put on a picklist. Testing should be done to ensure partial
backorders are filtered out of picklist availability when maySplit equals No.
- testing should ensure the oldest orders are added to the picklist first
- testing should ensure that if an order has any item in a Bulk location, that
it is added once under the "Need stock move" column and that it is not added
under the "Ready to pick" column. Similarly, if a picklist is created and an
order has any item in a Bulk location, then no items from order should not be
put into a picklist.
- Test case:
A splittable order with 2 items has 1 of its items on backorder. A picklist is
created and the 1 available item is put on a picklist. Then the backordered
item becomes available, allowing the 2nd item of the order to be picked. What
should happen when a picklist is created now? In OFBiz 4.0 I believe it will
create a new picklist with the order and 2 of its items, duplicating the one
item on the original picklist. My solution will only add the recently
backordered item to the new picklist. I do not know what is best for most
warehouse situations.
Hope this helps someone in the future.
was (Author: amayo):
I like the simplicity of your solution. I may have taken some unneeded
steps in attempt to minimize the number of loops -- for instance my solution
will loop through orders with a previous history of canceled/finished picklists
to see if they need to be added again, versus looping through all approved
orders. My method may be unnecessary since both situation would be completed
quickly, even with thousands of approved orders.
Here are some logical points that I considered while I was programming and
testing. These may help with test cases when someone attempts to integrate a
solution:
- Joining to the picklist tables for the views can add to the count results if
an order has multiple picklists in its history. To test, create and cancel a
picklist with the same order multiple times. When the order is available to be
picked again, be sure the count does not increase.
- If an order can be split and an item is partially backordered, should the
partially available inventory be added to the picklist? My solution adds the
item to the picklist with the available quantity. I believe OFBiz 4.0 does as
well. Example: If someone orders quantity 4 of an item and quantity 1 is on
backorder and maySplit equals Yes, then when a picklist is created for the
order this particular item should have a pick for a quantity of 2.
- Continuing the last example, if maySplit equals No, then the complete order
should not be put on a picklist. Testing should be done to ensure partial
backorders are filtered out of picklist availability when maySplit equals No.
- testing should ensure the oldest orders are added to the picklist first
- testing should ensure that if an order has any item in a Bulk location, that
it is added once under the "Need stock move" column and that it is not added
under the "Ready to pick" column. Similarly, if a picklist is created and an
order has any item in a Bulk location, then the complete order should not be
put into a picklist.
- Test case:
An splittable order with 2 items has 1 of its items on backorder. A picklist
is created and the 1 available item is put on a picklist. Then the backordered
item becomes available, allowing the 2nd item of the order to be picked. What
should happen when a picklist is created now? In OFBiz 4.0 I believe it will
create a new picklist with the order and 2 of its items, duplicating the 1 item
on the original picklist. My solution will only add the recently backordered
item. I do not know what is best for most warehouse situations.
Hope this helps someone in the future.
> quicker picklist option functionality
> -------------------------------------
>
> Key: OFBIZ-3856
> URL: https://issues.apache.org/jira/browse/OFBIZ-3856
> Project: OFBiz
> Issue Type: Improvement
> Components: product
> Affects Versions: Release 4.0, Release 09.04, SVN trunk
> Reporter: Albert Mayo
> Priority: Minor
> Attachments: entitymodel.xml, FindOrdersToPick.groovy,
> PickListServices.java, quicker picklist.diff
>
>
> I am noticing as our OFBiz database grows larger, it is taking the
> PicklistOptions longer to load. Even for a batch as small as 50 orders it can
> take up to a couple minutes to load. 300 orders can take upwards of 5-10
> minutes. My development system with much lesser hardware can get through a
> hundred orders in seconds, so I have a feeling it has to do with the
> process/code inefficiency.
> For instance, the picklistoptions function does the following (abbreviated):
> select * from OrderHeader
> for each orderHeader {
> select * from OrderItemShipGroup where orderId = orderHeader.orderId
> for each orderItemShipGroup in orderItemShipGroupList {
> select * from OrderItemShipGrpInvRes where orderId =
> orderItemShipGroup.orderId;
> for each orderItemShipGrpInvRes in orderItemShipGrpInvResList {
> etc....
> }
> }
> }
> These kind of loops can create many hits to the database and greatly slow
> down the process, especially if the database tables have many records. Our
> database is now almost 8 gigs. The PicklistOptions process took ~4 minutes
> for 40 pickable orders.
> I am using OFBiz 4.0, but the trunk version has a lot of the same code. I am
> opening this ticket to start a conversation of a quicker method to create
> picklists, like with the use of views or DynamicViewEntitys.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
