[
https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704689
#action_12704689 ]
Divesh Dutta edited comment on OFBIZ-2388 at 4/30/09 9:35 PM:
--------------------------------------------------------------
Hello David,
Please see my comments inline :
The way this is implemented will not scale adequately for deployments with
large numbers of orders.
In the ReviewOrdersNotPickedOrPacked.groovy file the first line of code gets
ALL OrderHeader records from the database, ie:
orderHeaders = delegator.findList("OrderHeader", null, null, null, null,
false);
This is not acceptable as there could be hundreds of thousands of millions of orders in the database, and so this line will
fail.
*Very true. Here we can add condition. Below is the code snippet. Please
suggest.*
{quote}condList.add(EntityCondition.makeCondition("statusId", EntityOperator.EQUALS,
"ORDER_APPROVED"));
condList.add(EntityCondition.makeCondition("orderTypeId", EntityOperator.EQUALS,
"SALES_ORDER"));
condList .add(EntityCondition.makeCondition("pickSheetPrintedDate",
EntityOperator.NOT_EQUAL, null));
cond = EntityCondition.makeCondition(condList, EntityOperator.AND);
orderHeaderList = delegator.findList("OrderHeader", cond, null, null, null,
false);{quote}
Later on down in the file the code looks for Shipment records with a primaryOrderId that matches the orderId on each
OrderHeader, and then looks at other things on the Shipment record(s) corresponding.
All of this can, and should, be done with a view entity. In fact, it must be done with a view entity so that the work is
done in a query in the database and not in a script on the app server which is hugely inefficient, so much so that in even
moderately large systems it simply WILL NOT WORK!
*Agreed*
An addition note: looking for shipments by matching the OrderHeader.orderId with the Shipment.primaryOrderId is not
adequate. Please change it to match the OrderHeader.orderId with the ItemIssuance.orderId and then ItemIssuance.shipmentId
with Shipment.shipmentId. Not that there will be many records for a single OrderHeader and Shipment combination since the
ItemIssuance really ties a OrderItem to a ShipmentItem, but that is fine since in this case all we care about is the
OrderHeader to Shipment relationship. Why do we need this? Because it is possible for a single Shipment to have items from
different orders on it, and simply looking at the Shipment.primaryOrderId won't capture that... that field is only the
PRIMARY orderId.
*But here the confusion is , Entries in ItemIssuance Entity is not done when we do "Verify Pick" (only done when shipment
is created in Packed status). So Entries are not present in ItemIssuance entity for Orders which have shipment in
"Input", "Picked", and "Scheduled" status. So IMO above given logic will not help . Please let me know if I am wrong.*
was (Author: diveshdut):
Hello David,
Please see my comments inline :
The way this is implemented will not scale adequately for deployments with
large numbers of orders.
In the ReviewOrdersNotPickedOrPacked.groovy file the first line of code gets
ALL OrderHeader records from the database, ie:
orderHeaders = delegator.findList("OrderHeader", null, null, null, null,
false);
This is not acceptable as there could be hundreds of thousands of millions of orders in the database, and so this line will
fail.
*Very true*
Later on down in the file the code looks for Shipment records with a primaryOrderId that matches the orderId on each
OrderHeader, and then looks at other things on the Shipment record(s) corresponding.
All of this can, and should, be done with a view entity. In fact, it must be done with a view entity so that the work is
done in a query in the database and not in a script on the app server which is hugely inefficient, so much so that in even
moderately large systems it simply WILL NOT WORK!
*Agreed*
An addition note: looking for shipments by matching the OrderHeader.orderId with the Shipment.primaryOrderId is not
adequate. Please change it to match the OrderHeader.orderId with the ItemIssuance.orderId and then ItemIssuance.shipmentId
with Shipment.shipmentId. Not that there will be many records for a single OrderHeader and Shipment combination since the
ItemIssuance really ties a OrderItem to a ShipmentItem, but that is fine since in this case all we care about is the
OrderHeader to Shipment relationship. Why do we need this? Because it is possible for a single Shipment to have items from
different orders on it, and simply looking at the Shipment.primaryOrderId won't capture that... that field is only the
PRIMARY orderId.
*But here the confusion is , Entries in ItemIssuance Entity is not done when we do "Verify Pick" (only done when shipment
is created in Packed status). So Entries are not present in ItemIssuance entity for Orders which have shipment in
"Input", "Picked", and "Scheduled" status. So IMO above given logic will not help . Please let me know if I am wrong.*
Add a page that shows orders with the "pick sheet printed date" field
---------------------------------------------------------------------
Key: OFBIZ-2388
URL: https://issues.apache.org/jira/browse/OFBIZ-2388
Project: OFBiz
Issue Type: Sub-task
Components: product
Affects Versions: SVN trunk
Reporter: Pranay Pandey
Assignee: Vikas Mayur
Fix For: SVN trunk
Attachments: ofbiz-2388.patch
* Add page that shows orders with the "pick sheet printed date" field set that do not have a Shipment associated with
them that is in the "Input" or "Scheduled" statuses (should be in Input status, but just in case Scheduled is eventually
used), sorted by the oldest date first to see the ones that have gone the longest without being picked and verified.
* Link to new page from the PicklistOptions page.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
