Openbravo Issue Tracking System - Retail Modules | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0040864 | Retail Modules | Web POS | public | 2019-05-13 15:51 | 2019-05-31 15:31 |
| Reporter | ucarrion | ||||
| Assigned To | ranjith_qualiantech_com | ||||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | |||||
| Target Version | Fixed in Version | RR19Q3 | |||
| Merge Request Status | |||||
| Review Assigned To | marvintm | ||||
| OBNetwork customer | Gold | ||||
| Support ticket | |||||
| Regression level | |||||
| Regression date | |||||
| Regression introduced in release | |||||
| Regression introduced by commit | |||||
| Triggers an Emergency Pack | No | ||||
| Summary | 0040864: The CL and C&R actions should check if the order has been updated | ||||
| Description | Cancel Layaway and Cancel&Replace actions should call IsOrderCancelled.java in order to check if there’s a ticket update. This check would contribute not to allow users to do incoherent actions (for example, be able to cancel delivered lines). In addition, the message shown when a receipt has been updated in the backoffice and the Web POS doesn't have the order with the last changes is always referring to layaways, when the document status can be different. The message shown must be generic for every case, like "not updated DOCUMENT", or should tell about the specific status of the ticket that is being checked: "not updated TICKET", "not updated LAYAWAY", etc. | ||||
| Steps To Reproduce | Following steps will result an incoherent flow : 1. Create a layaway including two lines 2. Pay the layaway totally. 3. (If the ‘Enable Remote Orders’ preference is set to ‘Y’ an order preparation proposal popup will be displaed; in this case, cancel it). 4. Open the order again from ‘Open Receipt’ menu entry 5. Once the order is opened select ‘Prepare current ticket’ menu option 6. In the preparation popup, select only the first line and prepare it. 7. A picking lis twill be created. 8. From backend: assign, confirm and issue the picking list in order to deliver the orderline. 9. Check in Sales Order window that the first line is delivered. 10. Go back to webpos, the order is still opened in the screen 11. Select ‘Cancel this order’ menú option 12. Check that both lines are able to be cancelend being one of them already delivered | ||||
| Proposed Solution | |||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2019-05-13 15:51 | ucarrion | New Issue | |||
| 2019-05-13 15:51 | ucarrion | Assigned To | => Retail | ||
| 2019-05-13 15:51 | ucarrion | OBNetwork customer | => Gold | ||
| 2019-05-13 15:51 | ucarrion | Resolution time | => 1559512800 | ||
| 2019-05-13 15:51 | ucarrion | Triggers an Emergency Pack | => No | ||
| 2019-05-16 10:14 | ucarrion | Description Updated | bug_revision_view_page.php?rev_id=18779#r18779 | ||
| 2019-05-24 08:47 | guillermogil | Type | feature request => defect | ||
| 2019-05-24 13:26 | ranjith_qualiantech_com | Assigned To | Retail => ranjith_qualiantech_com | ||
| 2019-05-24 13:26 | ranjith_qualiantech_com | Status | new => scheduled | ||
| 2019-05-27 14:25 | hgbot | Checkin | |||
| 2019-05-27 14:25 | hgbot | Note Added: 0112177 | |||
| 2019-05-27 14:25 | hgbot | Status | scheduled => resolved | ||
| 2019-05-27 14:25 | hgbot | Resolution | open => fixed | ||
| 2019-05-27 14:25 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/4a435b3d540a027a224293b0622e295f30abf075 [^] | ||
| 2019-05-31 15:31 | marvintm | Review Assigned To | => marvintm | ||
| 2019-05-31 15:31 | marvintm | Status | resolved => closed | ||
| 2019-05-31 15:31 | marvintm | Fixed in Version | => RR19Q3 | ||
| Notes | |||||
|
|
|||||
|
|
||||