Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0041446
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Cash upmajoralways2019-07-24 15:082019-08-08 15:38
ReporteraaroncaleroView Statuspublic 
Assigned Toranjith_qualiantech_com 
PriorityhighResolutionfixedFixed in VersionRR19Q4
StatusclosedFix in branchFixed in SCM revisioned73651c1cfd
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Merge Request Status
Review Assigned Tomarvintm
OBNetwork customerGold
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0041446: Duplicated cashup requests under specific circumstances in Synchronized Mode

DescriptionIt is possible to process the same cashup two times when using synchronized mode when the processing of the first cashup is slow.
The second processing fails because the cashup is already processed and the cashup is sent to Errors While Importing POS Data window, preventing login on the affected terminal.
Steps To ReproduceIn a modules environment.
1. Log in Web POS in the terminal YS-11 to ensure that the terminal loads without problems.
2. Log out.
3. Log in backend, go to the Preference window and configure the WebPOS Synchronized Mode preference with value Y.
4. Go to the Terminals and Tills Status window and close all tills of the Yosemite store
5. Execute the Close Store process to close the Yosemite Store
6. Execute the Open Store process to open the Yosemite Store again.
7. In eclipse, open the ProcessCashClose.java file and set a breakpoint in the saveRecord method.
8. In web pos, log in again. Since the till was closed in backend, it will be required to close the cashup.
9. Finish the cashup process. The login window will be shown. The breakpoint in eclipse will trigger. Do not continue it yet.
10. Log in again.
11. The cashup will be requested again because the old cashup is detected to be still open.
12. When the cashup window is loaded, let the java code continue executing.
13. Finish the second cashup and continue the java code when the breakpoint hits.
=> Verify that when the second cashup finishes processing the following error appears in the eclipse console:
org.openbravo.base.exception.OBException: Cash up is processed and cannot be set as processed again. OBPOS_APP_CASHUP_ID: F2D583A3E2CFB856728EAD3823059DF4
    at org.openbravo.retail.posterminal.ProcessCashClose.saveRecord(ProcessCashClose.java:159)
    at org.openbravo.mobile.core.process.DataSynchronizationProcess.saveRecord(DataSynchronizationProcess.java:200)
    at org.openbravo.mobile.core.process.DataSynchronizationProcess.exec(DataSynchronizationProcess.java:155)

=> Verify also that the cashup appears in the Errors While Importing POS Data window, and that it is not possible to do login on the YS-11 terminal.
Proposed SolutionIn the step 9, when finishing the cashup process the first time, the WebPOS must wait until the response form the server is received and do not go to the login window directly without confirming the cashup has been processed succesfully or with errors.

TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 0041025 closedranjith_qualiantech_com Login process asks for Cash up unnecessarily if there is a cashup record in Errors While Importing 

-  Notes
(0113890)
hgbot (developer)
2019-08-08 07:40

 Repository: erp/pmods/org.openbravo.retail.sessions
Changeset: f75f99a3df77812336bd76fe8faf712b6795fc1d
Author: Ranjith S R <ranjith <at> qualiantech.com>
Date: Thu Aug 08 11:10:10 2019 +0530
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.sessions/rev/f75f99a3df77812336bd76fe8faf712b6795fc1d [^]

Related to issue 41446 : Cashup window should not be shown if cashup is processing in backoffice

* If cashup is processing in backoffice (with till closed in backoffice),
  and user try to reload POS, Force Cashup window should not be shown again

---
M web/org.openbravo.retail.sessions/js/components/loginhook.js
---
(0113907)
hgbot (developer)
2019-08-08 13:15

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: ed73651c1cfd594d76f09604700cf090fe724ad1
Author: Ranjith S R <ranjith <at> qualiantech.com>
Date: Thu Aug 08 16:45:33 2019 +0530
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/ed73651c1cfd594d76f09604700cf090fe724ad1 [^]

Fixed issue 41446 : Cashup should be verified in pos before rebuild from backoffice

* In Sync Mode, last Cashup id will be stored in localStorage.
  When Cashup will be rebulid from Server, if localStorage Cashup is same as Backoffice cashup,
  then new Cashup will created in POS.

---
M web/org.openbravo.retail.posterminal/js/closecash/model/cashup-model.js
M web/org.openbravo.retail.posterminal/js/utils/cashUpReportUtils.js
---

- Issue History
Date Modified Username Field Change
2019-07-24 15:08 aaroncalero New Issue
2019-07-24 15:08 aaroncalero Assigned To => Retail
2019-07-24 15:08 aaroncalero OBNetwork customer => Gold
2019-07-24 15:08 aaroncalero Resolution time => 1565128800
2019-07-24 15:08 aaroncalero Triggers an Emergency Pack => No
2019-07-24 15:10 aaroncalero Description Updated View Revisions
2019-07-25 10:59 adrianromero Steps to Reproduce Updated View Revisions
2019-07-25 10:59 adrianromero Proposed Solution updated
2019-07-26 12:29 ranjith_qualiantech_com Assigned To Retail => ranjith_qualiantech_com
2019-07-30 09:36 ranjith_qualiantech_com Status new => scheduled
2019-08-08 07:40 hgbot Checkin
2019-08-08 07:40 hgbot Note Added: 0113890
2019-08-08 13:15 hgbot Checkin
2019-08-08 13:15 hgbot Note Added: 0113907
2019-08-08 13:15 hgbot Status scheduled => resolved
2019-08-08 13:15 hgbot Resolution open => fixed
2019-08-08 13:15 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/ed73651c1cfd594d76f09604700cf090fe724ad1 [^]
2019-08-08 15:38 marvintm Review Assigned To => marvintm
2019-08-08 15:38 marvintm Status resolved => closed
2019-08-08 15:38 marvintm Fixed in Version => RR19Q4
2019-12-30 17:38 ngarcia Relationship added related to 0041025

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker