Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0051049 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Retail Modules] Selfcheckout | major | always | 2022-12-01 16:54 | 2023-01-12 09:43 | |||
| Reporter | hector_hernaez | View Status | public | |||||
| Assigned To | ranjith_qualiantech_com | |||||||
| Priority | high | Resolution | no change required | Fixed in Version | ||||
| Status | closed | Fix in branch | Fixed in SCM revision | |||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Review Assigned To | marvintm | |||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| Summary | 0051049: In SCO, the Incremental Refresh process is executed during the purchase in DKT APAC | |||||||
| Description | There is an issue with the timing of master data refresh (Field 'Time to force masterdata refresh on inactivity (in minutes)') and the saving in the local ddbb in DKT APAC because the customer is complaining due to the refresh happens in the middle of a purchase Checking it and after executing several tests, we have noticed that this time doesn't depend on if there is activity or not. When this time is reached, the saving of the changes in the local ddbb is executed. | |||||||
| Steps To Reproduce | - Make a change in a product in the backoffice from 10 to 20 - Login in SCO - add a product - Wait the time of incremental refresh - The loading message with the download of the products to the local ddbb appears blocking the purchase | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
||||||||
|
||||||||
 Relationships |
|
Notes |
|
|
(0145043) ranjith_qualiantech_com (developer) 2022-12-28 05:43 |
Submitted MR https://gitlab.com/openbravo/customers/DKT/org.openbravo.retail.posterminal_apac_19q3/-/merge_requests/26 [^] https://gitlab.com/openbravo/customers/DKT/com.openbravo.decathlon.retail.selfcheckout.customizations/-/merge_requests/18 [^] |
|
(0145115) marvintm (manager) 2023-01-02 07:31 |
Implemented via a custom change in the customer |
|
(0145246) hector_hernaez (developer) 2023-01-10 17:26 |
It is happening the same issue in payment panel |
|
(0145314) marvintm (manager) 2023-01-12 09:43 |
Just discussed with malsasua. As a summary of the situation: - There are two configuration fields for the incremental refresh, "time to refresh masterdata", and "time to force masterdata refresh" - Normally, the blocking part of the masterdata refresh will only happen once the user completes the current ticket. - However, the second field allows customers to define a timeout, so that once incremental refresh is done in the background, if the current order is not completed in some minutes, the blocking part of the incremental refresh is enforced anyway - With the provided fix, this timeout is reset every time the users add a product to the basket. This is done to cover the case in which there are many products, and actually scanning them takes quite a long time. As far as we can see, this is working correctly. - However, once the last product is scanned, if the user doesn't complete the order in the amount of minutes specified in this second field, the incremental refresh will still be enforced, as designed. We believe this is the correct behavior. - It is very important to take into account that this timeout should be configured to a functionally logical and meaningful value. So, it should be normally configured to something like 10, or 20 minutes in most cases. - If it is configured like this, the probability that the user takes so much time from scanning the last product, to finally being able to pay and complete the ticket, should be extremely low, and in case this happens, we believe it is a good indication that something went wrong, and the user is most probably not in the terminal at the moment, so it should be fine to force the incremental refresh at this point. So, in our opinion, we should not implement any further change, and instead we should focus on making sure this timeout value is properly configured, and we should also clearly explain to the customer how this works in practice. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2022-12-01 16:54 | hector_hernaez | New Issue | |
| 2022-12-01 16:54 | hector_hernaez | Assigned To | => Retail |
| 2022-12-01 16:54 | hector_hernaez | Triggers an Emergency Pack | => No |
| 2022-12-02 06:56 | ranjith_qualiantech_com | Relationship added | related to 0050258 |
| 2022-12-02 08:05 | ranjith_qualiantech_com | Assigned To | Retail => ranjith_qualiantech_com |
| 2022-12-02 08:05 | ranjith_qualiantech_com | Status | new => scheduled |
| 2022-12-28 05:43 | ranjith_qualiantech_com | Note Added: 0145043 | |
| 2023-01-02 07:31 | marvintm | Review Assigned To | => marvintm |
| 2023-01-02 07:31 | marvintm | Note Added: 0145115 | |
| 2023-01-02 07:31 | marvintm | Status | scheduled => closed |
| 2023-01-02 07:31 | marvintm | Resolution | open => no change required |
| 2023-01-10 17:26 | hector_hernaez | Note Added: 0145246 | |
| 2023-01-10 17:26 | hector_hernaez | Status | closed => new |
| 2023-01-10 17:26 | hector_hernaez | Resolution | no change required => open |
| 2023-01-11 09:06 | ranjith_qualiantech_com | Status | new => scheduled |
| 2023-01-12 09:43 | marvintm | Note Added: 0145314 | |
| 2023-01-12 09:43 | marvintm | Status | scheduled => closed |
| 2023-01-12 09:43 | marvintm | Resolution | open => no change required |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |