Openbravo Issue Tracking System - Retail Modules |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0049840 | Retail Modules | Web POS | public | 2022-07-19 13:43 | 2022-08-03 08:46 |
|
| Reporter | XABIER_AGUADO | |
| Assigned To | ranjith_qualiantech_com | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | | OS | 5 | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | | |
| Merge Request Status | approved |
| Review Assigned To | |
| OBNetwork customer | Gold |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0049840: [SALES] Cash amount limited with an error message |
| Description | A screen appears with an error message when a certain amount of money is entered and by clicking on number 9 only , the number is rounded and numbered not required are displayed
Video: https://watch.screencastify.com/v/L86KGu6rZBIaI4mqHaix [^] |
| Steps To Reproduce | Log in on a POS
Click on "show all payment mt"
Click in the "espèces" field
Enter the number 22 times number 9 |
| Proposed Solution | The field should limit the entry of number rather than crashing with an error message that forced the user to refresh the page |
| Additional Information | |
| Tags | FASH |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2022-07-19 13:43 | XABIER_AGUADO | New Issue | |
| 2022-07-19 13:43 | XABIER_AGUADO | Assigned To | => Retail |
| 2022-07-19 13:43 | XABIER_AGUADO | OBNetwork customer | => Gold |
| 2022-07-19 13:43 | XABIER_AGUADO | Triggers an Emergency Pack | => No |
| 2022-07-19 13:43 | XABIER_AGUADO | Tag Attached: FASH | |
| 2022-07-21 11:23 | ranjith_qualiantech_com | Assigned To | Retail => ranjith_qualiantech_com |
| 2022-07-21 11:23 | ranjith_qualiantech_com | Status | new => scheduled |
| 2022-07-27 07:21 | hgbot | Merge Request Status | => open |
| 2022-07-27 07:21 | hgbot | Note Added: 0139624 | |
| 2022-08-02 11:22 | hgbot | Merge Request Status | open => approved |
| 2022-08-02 11:22 | hgbot | Resolution | open => fixed |
| 2022-08-02 11:22 | hgbot | Status | scheduled => closed |
| 2022-08-02 11:22 | hgbot | Fixed in Version | => 22Q4 |
| 2022-08-02 11:22 | hgbot | Note Added: 0139810 | |
| 2022-08-02 11:22 | hgbot | Note Added: 0139811 | |
| 2022-08-02 11:23 | marvintm | Note Added: 0139812 | |
| 2022-08-03 08:46 | hgbot | Note Added: 0139820 | |
|
Notes |
|
|
(0139624)
|
|
hgbot
|
|
2022-07-27 07:21
|
|
|
|
|
(0139810)
|
|
hgbot
|
|
2022-08-02 11:22
|
|
|
|
|
(0139811)
|
|
hgbot
|
|
2022-08-02 11:22
|
|
|
|
|
|
One note from my side: with the merged change, the POS no longer crashes. However, the behaviour is a bit strange, as once the amount is big enough, it will go back to being small.
This is the behaviour encountered in other fields like the payment field though, so we decided to make it at least consistent. We need to review in general how these kinds of fields should work with very large numbers, but we will do that separately. |
|
|
|
(0139820)
|
|
hgbot
|
|
2022-08-03 08:46
|
|
|