Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0041446Retail ModulesCash uppublic2019-07-24 15:082019-08-08 15:38
Reporteraaroncalero 
Assigned Toranjith_qualiantech_com 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in VersionRR19Q4 
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
Summary0041446: 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.

Additional Information
TagsNo tags attached.
Relationships
related to defect 0041025 closed ranjith_qualiantech_com Login process asks for Cash up unnecessarily if there is a cashup record in Errors While Importing 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2019-07-24 15:08aaroncaleroNew Issue
2019-07-24 15:08aaroncaleroAssigned To => Retail
2019-07-24 15:08aaroncaleroOBNetwork customer => Gold
2019-07-24 15:08aaroncaleroResolution time => 1565128800
2019-07-24 15:08aaroncaleroTriggers an Emergency Pack => No
2019-07-24 15:10aaroncaleroDescription Updatedbug_revision_view_page.php?rev_id=19189#r19189
2019-07-25 10:59adrianromeroSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=19197#r19197
2019-07-25 10:59adrianromeroProposed Solution updated
2019-07-26 12:29ranjith_qualiantech_comAssigned ToRetail => ranjith_qualiantech_com
2019-07-30 09:36ranjith_qualiantech_comStatusnew => scheduled
2019-08-08 07:40hgbotCheckin
2019-08-08 07:40hgbotNote Added: 0113890
2019-08-08 13:15hgbotCheckin
2019-08-08 13:15hgbotNote Added: 0113907
2019-08-08 13:15hgbotStatusscheduled => resolved
2019-08-08 13:15hgbotResolutionopen => fixed
2019-08-08 13:15hgbotFixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/ed73651c1cfd594d76f09604700cf090fe724ad1 [^]
2019-08-08 15:38marvintmReview Assigned To => marvintm
2019-08-08 15:38marvintmStatusresolved => closed
2019-08-08 15:38marvintmFixed in Version => RR19Q4
2019-12-30 17:38ngarciaRelationship addedrelated to 0041025

Notes
(0113890)
hgbot   
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   
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
---