[jira] Created: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
Locked
12
12
[jira] Created: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
 
|
[jira] Updated: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
[jira] Updated: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
[jira] Assigned: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
[jira] Closed: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
[jira] Commented: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
[jira] Commented: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
[jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
[jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
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. > |
smime.p7s (3K)
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
+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
|
|
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
Administrator
|
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
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. >>> >> > > |
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
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" <[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. >>>>> >>>> >>> >>> >> > |
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
In reply to this post by Scott Gray-2
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: > >> > |
[jira] Commented: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
|
Re: [jira] Issue Comment Edited: (OFBIZ-2388) Add a page that shows orders with the "pick sheet printed date" field
|
Administrator
|
| Free forum by Nabble | Edit this page |