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

[Jacques Le Roux]

From: "Scott Gray" <[hidden email]>
> 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" <[hidden email]>
>>>>> 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.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>

[Nicolas Malin (Jira)]

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

[Jacques Le Roux]

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" <[hidden email]>

> We could put some comments in contributors best practices.
>
> Jacques
>
> From: "David E Jones" <[hidden email]>
>> 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" <[hidden email]>
>>>>> 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.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>

[Nicolas Malin (Jira)]

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

[Nicolas Malin (Jira)]

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