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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0054743
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajorhave not tried2024-02-22 12:262024-04-02 07:45
ReportermarvintmView Statuspublic 
Assigned Tosreehari 
PrioritynormalResolutionopenFixed in Version
StatusscheduledFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0054743: When the state persistence fails, the information of the cashup becomes outdated, and this can lead to data corruption

DescriptionWhen the state persistence fails, the information of the cashup will be retrieved from an outdated state, and as it is the base for subsequent sales, the aggregated information can then become corrupted, as it will be missing the information from previous sales.

Although the final solution will be to fix the persistence issues, there is a simple mitigation mechanism that we can implement, and it would then avoid the problem in many cases, thus avoiding the unnecessary problems that are currently happening randomly in the customers.
Steps To ReproduceThe problem can only be reproduced in when the state persistence fails, and the terminal is opened with an outdated cashup information that is missing some sales.
Proposed SolutionWe can use the lastCashupReport property to identify a case that is impossible to happen unless the persistence failed.

The main idea would be, when the POS login happens, to validate the lastCashupReportDate in the client against the one in the frontend.

In case they are the same, everything is fine.
In case the client is more recent that the backend, then it is also fine, as maybe there are errors while importing pending to be processed, or some message not yet fully processed in the backend.
However, when the backend is more recent than the frontend, we know for sure something wrong happened, because under normal conditions this cannot happen as this property comes from the client side. So in this case, we need to regenerate the cashup information, from the information we currently have in the backend.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0162761)
hgbot (developer)
2024-04-02 07:45

Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/1522 [^]

- Issue History
Date Modified Username Field Change
2024-02-22 12:26 marvintm New Issue
2024-02-22 12:26 marvintm Assigned To => Retail
2024-02-22 12:26 marvintm Triggers an Emergency Pack => No
2024-02-22 13:38 Practics Issue Monitored: Practics
2024-03-06 11:06 jorgewederago Status new => acknowledged
2024-03-08 12:36 sreehari Assigned To Retail => sreehari
2024-03-08 12:36 sreehari Status acknowledged => scheduled
2024-04-02 07:45 hgbot Note Added: 0162761


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker