Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0036522 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Retail Modules] Web POS | major | random | 2017-07-20 15:31 | 2018-01-09 15:38 | |||
| Reporter | jorge-garcia | View Status | public | |||||
| Assigned To | jorge-garcia | |||||||
| Priority | urgent | Resolution | fixed | Fixed in Version | ||||
| Status | closed | Fix in branch | Fixed in SCM revision | be61ad967886 | ||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Merge Request Status | ||||||||
| Review Assigned To | migueldejuana | |||||||
| OBNetwork customer | OBPS | |||||||
| Support ticket | ||||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| Summary | 0036522: With Synchronize mode the cashup could be incorrect | |||||||
| Description | In synchronize mode, the cashup is always retrieved from the backend. Using the functionality of Pay Open Tickets, it's possible to generate a incorrect cashup. | |||||||
| Steps To Reproduce | 1) Active Synchronize mode preference in the backend 2) Login webPOS 3) Do a cashup and keep nothing 4) create one ticket with products but don't complete it 5) Load a layway from the backend and do nothing 6) Create another ticket with products but don't complete it 7) Go to the menu and go to Pay Open Tickets section 8) Select the two tickets created and, for example, a layaway 9) Look at the total to pay. Pay all with cash. 10) Go to the cashup. Sometimes, the total of the expected amount of cash is not the same as in the step 9. | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
 Relationships |
|
Notes |
|
|
(0098156) hgbot (developer) 2017-07-20 15:42 |
Repository: erp/pmods/org.openbravo.retail.posterminal Changeset: be61ad967886ecd5db46ce20a47104a74c04d605 Author: Jorge Garcia <jorge.garcia <at> openbravo.com> Date: Thu Jul 20 15:40:39 2017 +0200 URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/be61ad967886ecd5db46ce20a47104a74c04d605 [^] Fixed issue 36522: With Synchronize mode the cashup could be incorrect The solution is to sort the array of receipts from the webPOS in the same way as it’s retrieve in the websql database of the client. The cashup is an accumulative sum of all transactions from webPOS. It’s important to the order of the transactions generated to avoid differences problems in the cashup. This problem only happens in synchronize mode, where the cashup is always retrieve from the backend instead of using the cashup report from the client. --- M web/org.openbravo.retail.posterminal/js/data/dataordersave.js --- |
|
(0098174) migueldejuana (viewer) 2017-07-21 12:55 |
Tested and reviewed |
|
(0099967) hgbot (developer) 2017-10-19 16:50 |
Repository: tools/automation/pi-mobile Changeset: 33a4541fb1d2b48a77f174bab40a6579e9e1fe28 Author: Alejandro <alekosmp86 <at> gmail.com> Date: Thu Oct 19 10:36:26 2017 -0400 URL: http://code.openbravo.com/tools/automation/pi-mobile/rev/33a4541fb1d2b48a77f174bab40a6579e9e1fe28 [^] Verifies issue 36522: With Synchronize mode the cashup could be incorrect --- A src-test/org/openbravo/test/mobile/retail/pack/selenium/tests/cashup/I36522_VerifyCashUpInSynchronizeMode.java --- |
|
(0101639) hgbot (developer) 2018-01-09 15:38 |
Repository: tools/automation/pi-mobile Changeset: 612c83bba401214d279c21721b9a1fe3a1b123f4 Author: Alejandro <alekosmp86 <at> gmail.com> Date: Thu Dec 21 14:00:30 2017 -0500 URL: http://code.openbravo.com/tools/automation/pi-mobile/rev/612c83bba401214d279c21721b9a1fe3a1b123f4 [^] Refactor test for issue 36522: Logic for setting the synchronization is done in beforeWithReload and afterWithReload methods. A new layaway is created instead of using an existing one. Done extra verifications in cashup process. --- M src-test/org/openbravo/test/mobile/retail/pack/selenium/tests/cashup/I36522_VerifyCashUpInSynchronizeMode.java --- |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2017-07-20 15:31 | jorge-garcia | New Issue | |
| 2017-07-20 15:31 | jorge-garcia | Assigned To | => jorge-garcia |
| 2017-07-20 15:31 | jorge-garcia | OBNetwork customer | => Yes |
| 2017-07-20 15:31 | jorge-garcia | Resolution time | => 1501711200 |
| 2017-07-20 15:31 | jorge-garcia | Triggers an Emergency Pack | => No |
| 2017-07-20 15:33 | jorge-garcia | Status | new => scheduled |
| 2017-07-20 15:42 | hgbot | Checkin | |
| 2017-07-20 15:42 | hgbot | Note Added: 0098156 | |
| 2017-07-20 15:42 | hgbot | Status | scheduled => resolved |
| 2017-07-20 15:42 | hgbot | Resolution | open => fixed |
| 2017-07-20 15:42 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/be61ad967886ecd5db46ce20a47104a74c04d605 [^] |
| 2017-07-21 12:55 | migueldejuana | Review Assigned To | => migueldejuana |
| 2017-07-21 12:55 | migueldejuana | Note Added: 0098174 | |
| 2017-07-21 12:55 | migueldejuana | Status | resolved => closed |
| 2017-10-19 16:50 | hgbot | Checkin | |
| 2017-10-19 16:50 | hgbot | Note Added: 0099967 | |
| 2018-01-09 15:38 | hgbot | Checkin | |
| 2018-01-09 15:38 | hgbot | Note Added: 0101639 | |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |