[jira] Created: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Pranay Pandey (JIRA)" <ji...@apache.org>]

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
            Reporter: Pranay Pandey




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Ashish Vijaywargiya <as...@hotwaxmedia.com>]

+1

--
Ashish Vijaywargiya

Scott Gray wrote:
> Hi Divesh (and anybody else who does this regularly)
>
> Wherever possible please avoid editing comments (I almost wish we 
> could turn it off), most of us read jira issues through email 
> notifications and it is impossible to know what you've changed in your 
> comment.
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>
>>
>>    [ 
>> 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 :
>>
>

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Divesh Dutta <di...@hotwaxmedia.com>]

I have exactly done the same when I edited the comment.

Divesh

Scott Gray wrote:
> Yeah Jira doesn't make it easy but we've got wiki markup in there so 
> you can easily do:
>
> David wrote:
> {quote}
> Great work Scott!
> {quote}
> Thanks David!
>
> in a new comment, it does require a little copy/paste but at least you 
> know people will read it.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 1/05/2009, at 8:20 PM, David E Jones wrote:
>
>>
>> The problem with Jira is that there is no good way to do threaded 
>> discussions. If it is a single and very simple topic, no big deal... 
>> but as soon as you have multiple questions or comments to respond 
>> to... how do you do that?
>>
>> Editing previous comments is an interesting way, but if people do 
>> that they MUST put a BIG prefix before their comments so it is 
>> possible to distinguish them from the original text. That should 
>> include more than just a pair of "*" to bold part or all of the 
>> response, and should also include your initials so that it is clear 
>> which things you added. Also, for these sorts of things we should be 
>> sure to add and not edit wherever possible.
>>
>> Anyway, if there is a better way to handle threaded discussions and 
>> keep things in context that would be GREAT as this is pretty kludgy.
>>
>> -David
>>
>>
>> On May 1, 2009, at 12:22 AM, Scott Gray wrote:
>>
>>> Yeah I guess at the end of the day it doesn't really bother me, I 
>>> just like to let people know that if you edit your comment and I've 
>>> already read the original, well I won't be reading it a second time 
>>> :-)  My guess is that a lot of other people don't bother reading 
>>> edits either.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:
>>>
>>>> I personnaly prefer that we keep it (anyway this would be a Jira 
>>>> demand to infra) because sometimes it's useful. But totally agree 
>>>> that we should use this feature parsimoniously
>>>> The problem with this kind of non authoritative approach is that 
>>>> you have to explain over and over. On the other hand, this is what 
>>>> we call education...
>>>>
>>>> Jacques
>>>>
>>>> From: "Scott Gray" <sc...@hotwaxmedia.com>
>>>>> Hi Divesh (and anybody else who does this regularly)
>>>>>
>>>>> Wherever possible please avoid editing comments (I almost wish we  
>>>>> could turn it off), most of us read jira issues through email 
>>>>> notifications and it is impossible to know what you've changed in 
>>>>> your  comment.
>>>>>
>>>>> Thanks
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>>>>>
>>>>>>
>>>>>> [ 
>>>>>> 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.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Ashish Vijaywargiya <as...@hotwaxmedia.com>]

David wrote:
 >> {quote}
 >> Great work Scott!
 >> {quote}
 >> Thanks David!

I liked the sentence you have opted to put inside the {quote} :-)

--
Ashish

Scott Gray wrote:
> Yeah Jira doesn't make it easy but we've got wiki markup in there so 
> you can easily do:
>
> David wrote:
> {quote}
> Great work Scott!
> {quote}
> Thanks David!
>
> in a new comment, it does require a little copy/paste but at least you 
> know people will read it.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 1/05/2009, at 8:20 PM, David E Jones wrote:
>
>>
>

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Jacques Le Roux <ja...@les7arts.com>]

From: "Scott Gray" <sc...@hotwaxmedia.com>
> Yeah Jira doesn't make it easy but we've got wiki markup in there so  you can easily do:
>
> David wrote:
> {quote}
> Great work Scott!
> {quote}
> Thanks David!

I found this comment a little biased :D

Jacques

> in a new comment, it does require a little copy/paste but at least you  know people will read it.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 1/05/2009, at 8:20 PM, David E Jones wrote:
>
>>
>> The problem with Jira is that there is no good way to do threaded  discussions. If it is a single and very simple topic, no big 
>> deal...  but as soon as you have multiple questions or comments to respond  to... how do you do that?
>>
>> Editing previous comments is an interesting way, but if people do  that they MUST put a BIG prefix before their comments so it is 
>> possible to distinguish them from the original text. That should  include more than just a pair of "*" to bold part or all of the 
>> response, and should also include your initials so that it is clear  which things you added. Also, for these sorts of things we 
>> should be  sure to add and not edit wherever possible.
>>
>> Anyway, if there is a better way to handle threaded discussions and  keep things in context that would be GREAT as this is pretty 
>> kludgy.
>>
>> -David
>>
>>
>> On May 1, 2009, at 12:22 AM, Scott Gray wrote:
>>
>>> Yeah I guess at the end of the day it doesn't really bother me, I  just like to let people know that if you edit your comment 
>>> and I've  already read the original, well I won't be reading it a second  time :-)  My guess is that a lot of other people don't 
>>> bother  reading edits either.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:
>>>
>>>> I personnaly prefer that we keep it (anyway this would be a Jira  demand to infra) because sometimes it's useful. But totally 
>>>> agree  that we should use this feature parsimoniously
>>>> The problem with this kind of non authoritative approach is that  you have to explain over and over. On the other hand, this is 
>>>> what  we call education...
>>>>
>>>> Jacques
>>>>
>>>> From: "Scott Gray" <sc...@hotwaxmedia.com>
>>>>> Hi Divesh (and anybody else who does this regularly)
>>>>>
>>>>> Wherever possible please avoid editing comments (I almost wish  we  could turn it off), most of us read jira issues through 
>>>>> email  notifications and it is impossible to know what you've changed in  your  comment.
>>>>>
>>>>> Thanks
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>>>>>
>>>>>>
>>>>>> [ 
>>>>>> 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.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
> 

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Scott Gray <sc...@hotwaxmedia.com>]

Yeah Jira doesn't make it easy but we've got wiki markup in there so  
you can easily do:

David wrote:
{quote}
Great work Scott!
{quote}
Thanks David!

in a new comment, it does require a little copy/paste but at least you  
know people will read it.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 1/05/2009, at 8:20 PM, David E Jones wrote:

>
> The problem with Jira is that there is no good way to do threaded  
> discussions. If it is a single and very simple topic, no big deal...  
> but as soon as you have multiple questions or comments to respond  
> to... how do you do that?
>
> Editing previous comments is an interesting way, but if people do  
> that they MUST put a BIG prefix before their comments so it is  
> possible to distinguish them from the original text. That should  
> include more than just a pair of "*" to bold part or all of the  
> response, and should also include your initials so that it is clear  
> which things you added. Also, for these sorts of things we should be  
> sure to add and not edit wherever possible.
>
> Anyway, if there is a better way to handle threaded discussions and  
> keep things in context that would be GREAT as this is pretty kludgy.
>
> -David
>
>
> On May 1, 2009, at 12:22 AM, Scott Gray wrote:
>
>> Yeah I guess at the end of the day it doesn't really bother me, I  
>> just like to let people know that if you edit your comment and I've  
>> already read the original, well I won't be reading it a second  
>> time :-)  My guess is that a lot of other people don't bother  
>> reading edits either.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:
>>
>>> I personnaly prefer that we keep it (anyway this would be a Jira  
>>> demand to infra) because sometimes it's useful. But totally agree  
>>> that we should use this feature parsimoniously
>>> The problem with this kind of non authoritative approach is that  
>>> you have to explain over and over. On the other hand, this is what  
>>> we call education...
>>>
>>> Jacques
>>>
>>> From: "Scott Gray" <sc...@hotwaxmedia.com>
>>>> Hi Divesh (and anybody else who does this regularly)
>>>>
>>>> Wherever possible please avoid editing comments (I almost wish  
>>>> we  could turn it off), most of us read jira issues through email  
>>>> notifications and it is impossible to know what you've changed in  
>>>> your  comment.
>>>>
>>>> Thanks
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>>>>
>>>>>
>>>>> [ 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.
>>>>>
>>>>
>>>
>>>
>>
>

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Jacques Le Roux <ja...@les7arts.com>]

Done in an info block (for the color difference actually)

Jacques
PS : I got the habit of sending such messages. The intention is of course to grab attention and reviews... Without comments I 
suppose it's ok, thanks!

From: "Jacques Le Roux" <ja...@les7arts.com>
> We could put some comments in contributors best practices.
>
> Jacques
>
> From: "David E Jones" <da...@hotwaxmedia.com>
>> The problem with Jira is that there is no good way to do threaded  discussions. If it is a single and very simple topic, no big
>> deal...  but as soon as you have multiple questions or comments to respond  to... how do you do that?
>>
>> Editing previous comments is an interesting way, but if people do that  they MUST put a BIG prefix before their comments so it is
>> possible to  distinguish them from the original text. That should include more than  just a pair of "*" to bold part or all of
>> the response, and should  also include your initials so that it is clear which things you added.  Also, for these sorts of things
>> we should be sure to add and not edit  wherever possible.
>>
>> Anyway, if there is a better way to handle threaded discussions and  keep things in context that would be GREAT as this is pretty
>> kludgy.
>>
>> -David
>>
>>
>> On May 1, 2009, at 12:22 AM, Scott Gray wrote:
>>
>>> Yeah I guess at the end of the day it doesn't really bother me, I  just like to let people know that if you edit your comment
>>> and I've  already read the original, well I won't be reading it a second  time :-)  My guess is that a lot of other people don't
>>> bother  reading edits either.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:
>>>
>>>> I personnaly prefer that we keep it (anyway this would be a Jira  demand to infra) because sometimes it's useful. But totally
>>>> agree  that we should use this feature parsimoniously
>>>> The problem with this kind of non authoritative approach is that  you have to explain over and over. On the other hand, this is
>>>> what  we call education...
>>>>
>>>> Jacques
>>>>
>>>> From: "Scott Gray" <sc...@hotwaxmedia.com>
>>>>> Hi Divesh (and anybody else who does this regularly)
>>>>>
>>>>> Wherever possible please avoid editing comments (I almost wish we   could turn it off), most of us read jira issues through
>>>>> email  notifications and it is impossible to know what you've changed in  your  comment.
>>>>>
>>>>> Thanks
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>>>>>
>>>>>>
>>>>>>  [
>>>>>> 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.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Jacques Le Roux <ja...@les7arts.com>]

We could put some comments in contributors best practices.

Jacques

From: "David E Jones" <da...@hotwaxmedia.com>
> The problem with Jira is that there is no good way to do threaded  discussions. If it is a single and very simple topic, no big 
> deal...  but as soon as you have multiple questions or comments to respond  to... how do you do that?
>
> Editing previous comments is an interesting way, but if people do that  they MUST put a BIG prefix before their comments so it is 
> possible to  distinguish them from the original text. That should include more than  just a pair of "*" to bold part or all of the 
> response, and should  also include your initials so that it is clear which things you added.  Also, for these sorts of things we 
> should be sure to add and not edit  wherever possible.
>
> Anyway, if there is a better way to handle threaded discussions and  keep things in context that would be GREAT as this is pretty 
> kludgy.
>
> -David
>
>
> On May 1, 2009, at 12:22 AM, Scott Gray wrote:
>
>> Yeah I guess at the end of the day it doesn't really bother me, I  just like to let people know that if you edit your comment and 
>> I've  already read the original, well I won't be reading it a second  time :-)  My guess is that a lot of other people don't 
>> bother  reading edits either.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:
>>
>>> I personnaly prefer that we keep it (anyway this would be a Jira  demand to infra) because sometimes it's useful. But totally 
>>> agree  that we should use this feature parsimoniously
>>> The problem with this kind of non authoritative approach is that  you have to explain over and over. On the other hand, this is 
>>> what  we call education...
>>>
>>> Jacques
>>>
>>> From: "Scott Gray" <sc...@hotwaxmedia.com>
>>>> Hi Divesh (and anybody else who does this regularly)
>>>>
>>>> Wherever possible please avoid editing comments (I almost wish we   could turn it off), most of us read jira issues through 
>>>> email  notifications and it is impossible to know what you've changed in  your  comment.
>>>>
>>>> Thanks
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>>>>
>>>>>
>>>>>  [ 
>>>>> 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.
>>>>>
>>>>
>>>
>>>
>>
> 

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[David E Jones <da...@hotwaxmedia.com>]

The problem with Jira is that there is no good way to do threaded  
discussions. If it is a single and very simple topic, no big deal...  
but as soon as you have multiple questions or comments to respond  
to... how do you do that?

Editing previous comments is an interesting way, but if people do that  
they MUST put a BIG prefix before their comments so it is possible to  
distinguish them from the original text. That should include more than  
just a pair of "*" to bold part or all of the response, and should  
also include your initials so that it is clear which things you added.  
Also, for these sorts of things we should be sure to add and not edit  
wherever possible.

Anyway, if there is a better way to handle threaded discussions and  
keep things in context that would be GREAT as this is pretty kludgy.

-David


On May 1, 2009, at 12:22 AM, Scott Gray wrote:

> Yeah I guess at the end of the day it doesn't really bother me, I  
> just like to let people know that if you edit your comment and I've  
> already read the original, well I won't be reading it a second  
> time :-)  My guess is that a lot of other people don't bother  
> reading edits either.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:
>
>> I personnaly prefer that we keep it (anyway this would be a Jira  
>> demand to infra) because sometimes it's useful. But totally agree  
>> that we should use this feature parsimoniously
>> The problem with this kind of non authoritative approach is that  
>> you have to explain over and over. On the other hand, this is what  
>> we call education...
>>
>> Jacques
>>
>> From: "Scott Gray" <sc...@hotwaxmedia.com>
>>> Hi Divesh (and anybody else who does this regularly)
>>>
>>> Wherever possible please avoid editing comments (I almost wish we   
>>> could turn it off), most of us read jira issues through email  
>>> notifications and it is impossible to know what you've changed in  
>>> your  comment.
>>>
>>> Thanks
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>>>
>>>>
>>>>  [ 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.
>>>>
>>>
>>
>>
>

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Scott Gray <sc...@hotwaxmedia.com>]

Yeah I guess at the end of the day it doesn't really bother me, I just  
like to let people know that if you edit your comment and I've already  
read the original, well I won't be reading it a second time :-)  My  
guess is that a lot of other people don't bother reading edits either.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:

> I personnaly prefer that we keep it (anyway this would be a Jira  
> demand to infra) because sometimes it's useful. But totally agree  
> that we should use this feature parsimoniously
> The problem with this kind of non authoritative approach is that you  
> have to explain over and over. On the other hand, this is what we  
> call education...
>
> Jacques
>
> From: "Scott Gray" <sc...@hotwaxmedia.com>
>> Hi Divesh (and anybody else who does this regularly)
>>
>> Wherever possible please avoid editing comments (I almost wish we   
>> could turn it off), most of us read jira issues through email  
>> notifications and it is impossible to know what you've changed in  
>> your  comment.
>>
>> Thanks
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>>
>>>
>>>   [ 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.
>>>
>>
>
>

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Jacques Le Roux <ja...@les7arts.com>]

I personnaly prefer that we keep it (anyway this would be a Jira demand to infra) because sometimes it's useful. But totally agree 
that we should use this feature parsimoniously
The problem with this kind of non authoritative approach is that you have to explain over and over. On the other hand, this is what 
we call education...

Jacques

From: "Scott Gray" <sc...@hotwaxmedia.com>
> Hi Divesh (and anybody else who does this regularly)
>
> Wherever possible please avoid editing comments (I almost wish we  could turn it off), most of us read jira issues through email 
> notifications and it is impossible to know what you've changed in your  comment.
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>
>>
>>    [ 
>> 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.
>>
>
> 

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Divesh Dutta <di...@hotwaxmedia.com>]

Thanks Scott,

I will surely keep this thing in mind. Thanks for your suggestion.

Divesh


Scott Gray wrote:
> Hi Divesh (and anybody else who does this regularly)
>
> Wherever possible please avoid editing comments (I almost wish we 
> could turn it off), most of us read jira issues through email 
> notifications and it is impossible to know what you've changed in your 
> comment.
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
>
>>
>>    [ 
>> 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.
>>
>

Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

[Scott Gray <sc...@hotwaxmedia.com>]

Hi Divesh (and anybody else who does this regularly)

Wherever possible please avoid editing comments (I almost wish we  
could turn it off), most of us read jira issues through email  
notifications and it is impossible to know what you've changed in your  
comment.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:

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

[jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Divesh Dutta (JIRA)" <ji...@apache.org>]

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

[jira] Updated: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Arun Patidar (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arun Patidar updated OFBIZ-2388:
--------------------------------

    Attachment: ofbiz-2388.patch

Here is the patch for functionality to show list of orders which have 'pick sheet printed date' but not in 'picked' or 'packed' status yet. 

Steps to test this functionality :-

# Create two or more sales order with products GZ-2644 and WG-1111
# Go to Facility -> Picking
# Click on 'Print Pick Sheet' button
# Now click on 'Review Orders Not Picked-Packed' button

Expected result:- It Shows list of orders with 'pick sheet printed date' which are not in 'picked' or 'packed' status yet.

> 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
>             Fix For: SVN trunk
>
>         Attachments: ofbiz-2388.patch
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["David E. Jones (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704927#action_12704927 ] 

David E. Jones commented on OFBIZ-2388:
---------------------------------------


Question from Divesh:

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.

Answer from David:

When an OrderItem is added to a Shipment there should ALWAYS be an ItemIssuance along with it. Why is that not done in the Verify Pick process like it is for the Packing screens that those are based on? The main service called for this is the issueOrderItemShipGrpInvResToShipment service, and it is called from the AddItemsFromOrder screen for manual shipments, and the issueItemToShipment method in the PackingSession.java class.

In other words, the best solution to that problem would be to issue the items to the shipment as they are marked "picked". In fact, how else would you keep track of them?

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

[jira] Closed: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Vikas Mayur (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vikas Mayur closed OFBIZ-2388.
------------------------------

    Resolution: Fixed

Thanks Arun,

Your patch is in rev. 769770



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

[jira] Closed: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Vikas Mayur (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vikas Mayur closed OFBIZ-2388.
------------------------------

    Resolution: Fixed

Thanks Arun and others!

Arun your second patch is in trunk rev. 773185.

Vikas

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

[jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Divesh Dutta (JIRA)" <ji...@apache.org>]

    [ 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:41 AM:
--------------------------------------------------------------

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

      was (Author: diveshdut):
    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.

[jira] Reopened: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Vikas Mayur (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vikas Mayur reopened OFBIZ-2388:
--------------------------------


Re-opening this task so that all the reported issue are not overlooked over time and can be fixed.

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

[jira] Commented: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Divesh Dutta (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704689#action_12704689 ] 

Divesh Dutta commented on OFBIZ-2388:
-------------------------------------

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.

[jira] Commented: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["David E. Jones (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704114#action_12704114 ] 

David E. Jones commented on OFBIZ-2388:
---------------------------------------

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.

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!

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.

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

[jira] Assigned: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Vikas Mayur (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vikas Mayur reassigned OFBIZ-2388:
----------------------------------

    Assignee: Vikas Mayur

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

[jira] Updated: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Pranay Pandey (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pranay Pandey updated OFBIZ-2388:
---------------------------------

          Component/s: product
        Fix Version/s: SVN trunk
          Description: 
*  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.


    Affects Version/s: SVN trunk

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

[jira] Updated: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field

["Arun Patidar (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arun Patidar updated OFBIZ-2388:
--------------------------------

    Attachment: ofbiz-2388.patch

Here is improved  patch according to David's suggestions.

I improved following:-

1) Applied conditions during fetching records from OrderHeader entity.

2) Checked entry in ItemIssuance entity for shipment association instead from Shipment entity.

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