Openbravo Issue Tracking System - Retail Modules |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0054743 | Retail Modules | Web POS | public | 2024-02-22 12:26 | 2024-10-31 13:10 |
|
| Reporter | marvintm | |
| Assigned To | sreehari | |
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | |
| Platform | | OS | 5 | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | RR24Q3 | |
| Merge Request Status | |
| Review Assigned To | |
| OBNetwork customer | |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0054743: When the state persistence fails, the information of the cashup becomes outdated, and this can lead to data corruption |
| Description | When 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 Reproduce | The 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 Solution | We 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. |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | feature request | 0056377 | | scheduled | AugustoMauch | POS2 | Management of inconsistent application state should be properly addressed in core2 applications |
|
| Attached Files | |
|
| 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 |