[
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.
