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-10-31 13:10
ReportermarvintmView Statuspublic 
Assigned Tosreehari 
PrioritynormalResolutionfixedFixed in VersionRR24Q3
StatusclosedFix 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 ]
related to feature request 0056377 scheduledAugustoMauch POS2 Management of inconsistent application state should be properly addressed in core2 applications 

-  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 [^]
(0163361)
hgbot (developer)
2024-04-18 11:58

Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/1522 [^]
(0163362)
hgbot (developer)
2024-04-18 11:58

Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal [^]
Changeset: 93ec5386b5cd9213776123ecb347b178c35a384e
Author: Sreehari Venkataraman <sreehari.venkataraman.ext@openbravo.com>
Date: 18-04-2024 06:41:09
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/commit/93ec5386b5cd9213776123ecb347b178c35a384e [^]

Fixes ISSUE-54743: Added postHook for initCashup Action
*used cashupDate for validating the cashup info
*changed cashUpReportDate & cashUpCreationDate accordingly
*this hooks checks the client & server lastcashup time
*and if client cashup time is older than server cashup time
*then, we regenerate the cashup data from the back office with the not processed data
*added log message for overriding cashup
*fixed test failures

---
M src/org/openbravo/retail/posterminal/UpdateCashup.java
M src/org/openbravo/retail/posterminal/master/Cashup.java
M web-test/model/business-object/cashup/Cashup-InitCashup-ActionPreparation.test.js
M web-test/model/business-object/cashup/Cashup-initCashup-StateAction-fromLocal.test.js
M web-test/model/business-object/cashup/Cashup-updateCashupFunction-afterTicketDone.test.js
M web-test/model/business-object/cashup/test-data/cashupAfterComplete.js
M web-test/model/business-object/cashup/test-data/cashupAfterTicketDone.js
M web-test/model/business-object/cashup/test-data/cashupCreatedFromScratch.js
M web-test/model/business-object/cashup/test-data/cashupCreatedFromScratchWithoutLastCashupPayments.js
M web-test/model/business-object/cashup/test-data/cashupMessageSharedPayments.js
M web-test/model/business-object/cashup/test-data/messagesAfterCompleteCashupSharedPayments.js
M web-test/model/business-object/cashup/test-data/ticketAfterTicketDone.js
M web/org.openbravo.retail.posterminal/app/model/business-object/cashup/CashupUtils.js
M web/org.openbravo.retail.posterminal/app/model/business-object/cashup/actions/InitCashup.js
---

- 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
2024-04-18 11:58 hgbot Resolution open => fixed
2024-04-18 11:58 hgbot Status scheduled => closed
2024-04-18 11:58 hgbot Note Added: 0163361
2024-04-18 11:58 hgbot Fixed in Version => RR24Q3
2024-04-18 11:58 hgbot Note Added: 0163362
2024-10-31 13:10 malsasua Relationship added related to 0056377


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker