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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0035709
TypeCategorySeverityReproducibilityDate SubmittedLast Update
design defect[Retail Modules] StoreServermajorhave not tried2017-04-06 10:272017-06-19 19:11
ReportermtaalView Statuspublic 
Assigned Tomtaal 
PrioritynormalResolutionfixedFixed in VersionRR17Q3
StatusclosedFix in branchFixed in SCM revision4eb0b0388472
ProjectionnoneETAnoneTarget VersionRR17Q3
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tomarvintm
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0035709: Synchronized Mode: ensure that when sending ticket the latest cashup information is used

Description==DESCRIPTION OF THE ORIGINAL PROBLEM==
This is essentially the same case which we had in another customer around two years ago. In the Web POS, the final update of the ticket and the update of the cashup report information are two different actions in two different tables in the local database. In previous releases of the Web POS, the user could press F5 in a very particular moment, and the ticket would become processed, but the cashup report would not be updated. This was more frequently reproducible in low-end devices, as the actions were quite slower there, and the chance that the user pressed the button in the precise moment was higher.

To fix the problem, we introduced the concept of "transaction" in ob-dal, so that you can define several actions belonging to the same transaction, and all of them will either be fully completed and persisted, or none of them will be. This required quite a fair amount of work, but was at least possible because we were working on the same database the whole time. Once we did this change, we have never seen this problem again in any customer working with normal, non-synchronized mode.

==CURRENT PROBLEM IN SYNC MODE==
The problem in synchronized mode is actually quite similar, but the solution however cannot be the same. Currently, when working on synchronized mode, when you complete the ticket, we do three main actions:
- We save the checkpoint of the current status of the cashup report
- We mark the ticket as processed.
- We update the cashup report information.

Then, we initiate the synchronization to the backend. If the synchronization is successful, then nothing else happens, and we are good. If, however, the synchronization fails due to an error in the backend, then we use the saved checkpoint in the previous step to restore the cashup report info to its original value, as the ticket was actually not processed, so we shouldn't count it as a sale.

The obvious problem here is that if the user presses F5 in the precise moment in which we are about to restore the checkpoint, then this won't happen, and the sale will have been counted, even if it actually didn't take place.

==POSSIBLE SOLUTION TO THIS PROBLEM==

We don't have an easy to use tool to create a transaction which groups all of these actions, including the remote call to synchronize the ticket to the backend. Therefore, we would need to invent some kind of mechanism to do the rollback properly.

My idea would be to persist this checkpoint info in the database (if it's not already, I'm currently not sure if it is), and then, whenever the user presses F5, check if there is a pending checkpoint. If it is, we would need to make a remote call to the backend to check if the message associated with this checkpoint (which we should also have saved, btw) was actually processed correctly. If it was, then we can safely delete the checkpoint. If it was not, then we need to apply the rollback using the checkpoint and then delete it.

I think this solution would cover this case, but I'm currently not 100% sure that it would fix all F5-related problems we might have. We would need to invest some time to analyze this topic, to ensure that no other bad cases may happen, and if they are, think on how to handle them.

==CHANCES OF THIS PROBLEM HAPPENING AGAIN==
My understanding is that the main reason for users hitting F5 many times in this case was that the store had connection problems, and the backend was temporarily not available. I think if they had had Store Server, this would most likely not have happened (but please correct me if I'm wrong).
Steps To ReproduceSee Description
Proposed SolutionThere are two alternative solutions:
1- only send deltas with the ticket to the server: although the client still can be out of line there is no problem as in synchronized mode we always reload the cashup information when doing the cashup. So the server keeps the real truth. But, this is more work/more impact than the second alternative.
2- for each ticket, when sending the ticket reload the cashup information before sending the ticket to the server. The reload logic is already present in several places and we use it more times (at login for example), so it is quite stable and only a few lines of code.

For now we will implement solution 2.
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
has duplicate defect 0036046 closedRetail [SER-QA 2868] Wrong amount in the "amount to keep field" during the cash up 
related to defect 0036105 closedmtaal Synchronized Mode: cashupId change before and after a sale 

-  Notes
(0096431)
hgbot (developer)
2017-05-06 08:50

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 4eb0b03884724e59158308631a70e0d772676e96
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Sat May 06 08:50:17 2017 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/4eb0b03884724e59158308631a70e0d772676e96 [^]

Fixes issue 35709: Synchronized Mode: ensure that when sending ticket the latest cashup information is used
In synchronized mode reread the cashup from the server before using it when sending order or cash management records to the server. Also solve some async logic which was not working correctly/

Cashup.java: send back the payment method id using different properties to match what javascript expects here (see the diff: return payMthd.paymentTypeId === payment.payment.id;)
cashmgmt-model.js: rebuild the cashup from the server
dataordersave.js: when closing a (multi) ticket read the cashup from the server
cashUpReportUtils.js: restructure the saving of the new cashup from the server so that all the save's are done before the callback is executed. Use synchronized cashup service when applicable,
Specifically see also this code change:
+ // if the last cashup payments are read locally then their structure
+ // is different from when reading from the server
+ if (_.isObject(pAux.paymentMethod)) {
+ startingCash = pAux.paymentMethod.amountToKeep;
+ } else {
+ startingCash = pAux.amountToKeep;
+ }

---
M src/org/openbravo/retail/posterminal/master/Cashup.java
M web/org.openbravo.retail.posterminal/js/cashmgmt/model/cashmgmt-model.js
M web/org.openbravo.retail.posterminal/js/data/dataordersave.js
M web/org.openbravo.retail.posterminal/js/utils/cashUpReportUtils.js
---

- Issue History
Date Modified Username Field Change
2017-04-06 10:27 mtaal New Issue
2017-04-06 10:27 mtaal Assigned To => mtaal
2017-04-06 10:27 mtaal Triggers an Emergency Pack => No
2017-04-24 17:31 mtaal Status new => scheduled
2017-05-06 08:44 mtaal Review Assigned To => marvintm
2017-05-06 08:50 hgbot Checkin
2017-05-06 08:50 hgbot Note Added: 0096431
2017-05-06 08:50 hgbot Status scheduled => resolved
2017-05-06 08:50 hgbot Resolution open => fixed
2017-05-06 08:50 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/4eb0b03884724e59158308631a70e0d772676e96 [^]
2017-05-25 13:13 Sandrahuguet Relationship added related to 0036105
2017-06-06 10:59 marvintm Relationship added has duplicate 0036046
2017-06-19 19:11 marvintm Status resolved => closed
2017-06-19 19:11 marvintm Fixed in Version => RR17Q3

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker