Openbravo Issue Tracking System - Retail Modules | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0038315 | Retail Modules | Web POS | public | 2018-04-10 17:48 | 2018-04-10 17:48 |
| Reporter | plujan | ||||
| Assigned To | Retail | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Merge Request Status | |||||
| Review Assigned To | |||||
| OBNetwork customer | |||||
| Support ticket | |||||
| Regression level | |||||
| Regression date | |||||
| Regression introduced in release | main | ||||
| Regression introduced by commit | |||||
| Triggers an Emergency Pack | No | ||||
| Summary | 0038315: [RR18Q2] The 20-char limit in the keypad is too large and can cause rounding issues | ||||
| Description | The webPOS keypad has a maximum of 20 chars for setting values like quantity and price. However, this number is too big for the precision of the variables underneath, creating some rounding issues. See steps. | ||||
| Steps To Reproduce | 1. In the main screen of the webPOS go to browse and add a product to a ticket. 2. Note the quantity default is 1. Press the '9' key in the keypad 20 times to get the maximum number you are allowed to enter. 3. Note that you cannot enter more than 20 and that a warning message is shown. 4. Tap the Quantity button and check that the quantity of the line has changed to 100000000000000000000 (which is not correct since the actual number entered was 99999999999999999999 ) 5. Use the - and + keys of the keypad to add or remove one item from the quantity. Note that nothing happens (since one is less than the current precision) Alternative scenario: Having 100000000000000000000 in quantity, tap the 1 key and tap Quantity button. Note that the whole line is removed (since it has removed EnteredQty - CurrentQty units) Working scenario: By using values closer to the one in quantity, the precision is not interfering and the results are correct. Like using 1000000 instead of 1 in previous steps. | ||||
| Proposed Solution | Precision and rounding are inherent to computer design, so there is not an actual solution for this. Some mitigation actions can be taken tough. 1. (Simpler) Evaluate if the 20 char limit is too high and can be reduced. A 14 char number will fit current precision with no further changes 2. (somewhat simple) If 14char+ values are required, do not allow values under the precision (ie Currencies can be often very big, but they will lack cents and even smaller units) 3. (complex) There are algorithms to increase precision by using more than one variable to represent different parts of a number. | ||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2018-04-10 17:48 | plujan | New Issue | |||
| 2018-04-10 17:48 | plujan | Assigned To | => Retail | ||
| 2018-04-10 17:48 | plujan | Regression introduced in release | => main | ||
| 2018-04-10 17:48 | plujan | Triggers an Emergency Pack | => No | ||
| There are no notes attached to this issue. |