Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0047673 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [POS2] Restaurants | major | always | 2021-09-10 14:28 | 2021-10-28 10:18 | |||
Reporter | timothee_catteeuw | View Status | public | |||||
Assigned To | javierRodriguez | |||||||
Priority | normal | Resolution | fixed | Fixed in Version | ||||
Status | closed | Fix in branch | Fixed in SCM revision | |||||
Projection | none | ETA | none | Target Version | TAP | |||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Review Assigned To | jorge-garcia | |||||||
Regression level | ||||||||
Regression date | ||||||||
Regression introduced in release | ||||||||
Regression introduced by commit | ||||||||
Triggers an Emergency Pack | No | |||||||
Summary | 0047673: JIRA 2304 - Proof of payment - rounding are not properly executed in some cases | |||||||
Description | At some point when you want to generate a proof of payment the split amount values are not correctly done. You can find several cases which allow to reproduce. There is an issue on how we distribute amount and/or taxes. | |||||||
Steps To Reproduce | Case 1 : On WebPOS (TAP version), select 2 different products with 1.95 € amount (let's say item A and item B). Both articles have the same tax (10%) --> Amount with tax 3.90, without taxes 3.55 and taxes are equals to 0.35 Currently what we do in OB in that case 1st proof of payment : 1.94 including 0.17 € 2nd proof of payment : 1.96 including 0.18 € The correct result has to be : 1st proof of payment : 1.95 including 0.17 € 2nd proof of payment : 1.95 including 0.18 € For information if I select item A twice for example, both proof of payment are OK. Case 2 : I put several articles in my basket with this configuration ITEM A amount without tax = 6.77, 10% tax = 0.68 €, amount by including tax 7.45 € ITEM B amount without tax = 1.63, 20% tax = 0.32 €, amount by including tax 1.95 € ITEM C amount without tax = 0.59, 10% tax = 0.06 €, amount by including tax 0.65 € ITEM D amount without tax = 0.91, 10% tax = 0.09 €, amount by including tax 1.00 € ITEM E amount without tax = 7.23, 10% tax = 0.72 €, amount by including tax 7.95 € If I split in 2 proof of payments, it necessary to manage amount like that : 1) Total amount = 9,50 € 10 % tax 0,78 € 20 % tax 0,16 € 2) Total amount = 9,50 € 10% tax 0,77 € 20% tax 0,16 € Nowadays we manage it in OB like that : 1) Total amount = 9,52 € 10 % tax 0,78 € 20 % tax 0,16 € 2) Total amount = 9,48 € 10% tax 0,77 € 20% tax 0,16 € | |||||||
Proposed Solution | Split correctly (in equal part) as much as possible. There will some cases when proof of payment amounts won'be equal (ex: 19.55 /2 = 9.77 and 9.78) | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |||||||||||||||
|
Notes | |
(0131766) jorge-garcia (reporter) 2021-09-14 10:54 |
The divide in equal parts does not divide the ticket in equal parts, it divides the LINES of the ticket in equal parts. Let's put an example: Ticket - 3.90€ ---------------- Line 1 - 0.70€ Line 2 - 0.83€ Line 3 - 1.11€ Line 4 - 0.47€ Line 5 - 0.79€ The user selects to generate proofs of payments dividing in two parts Step 1 - The first proof of payment divides each line by two Pop 01 - 1.97€ ---------------- Line 1 - 0.35€ Line 2 - 0.42€ (in reality it should be 0.415 but it is rounded as it is an amount so it adds +0.1) Line 3 - 0.56€ (in reality it should be 0.555 but it is rounded as it is an amount so it adds +0.1) Line 4 - 0.24€ (in reality it should be 0.235 but it is rounded as it is an amount so it adds +0.1) Line 5 - 0.40€ (in reality it should be 0.395 but it is rounded as it is an amount so it adds +0.1) Step 2 - The second proof of payment is adjusted in each line to avoid to be higher than the line original amount (requirement from agapes) Pop 01 - 1.93€ ---------------- Line 1 - 0.35€ Line 2 - 0.41€ Line 3 - 0.55€ Line 4 - 0.23€ Line 5 - 0.39€ This is working in the same way for detailed and summarized proof of payments as the information for each line must always available |
(0132300) guilleaer (manager) 2021-10-11 20:40 |
Specs https://docs.google.com/document/d/1xY8T-wuFotr6VWrYeG31836sNSwYUsxffUdCzyYCG8o/edit [^] |
(0132700) guilleaer (manager) 2021-10-28 10:17 |
https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/merge_requests/709 [^] |
Issue History | |||
Date Modified | Username | Field | Change |
2021-09-10 14:28 | timothee_catteeuw | New Issue | |
2021-09-10 14:28 | timothee_catteeuw | Assigned To | => Retail |
2021-09-10 14:28 | timothee_catteeuw | Triggers an Emergency Pack | => No |
2021-09-13 15:54 | dmiguelez | Status | new => scheduled |
2021-09-13 16:09 | dmiguelez | Assigned To | Retail => jorge-garcia |
2021-09-14 10:54 | jorge-garcia | Note Added: 0131766 | |
2021-09-14 11:12 | guilleaer | Summary | Proof of payment - rounding are not properly executed in some cases => JIRA 2304 - Proof of payment - rounding are not properly executed in some cases |
2021-09-14 11:26 | guilleaer | Status | scheduled => feedback |
2021-10-11 20:39 | guilleaer | Status | feedback => scheduled |
2021-10-11 20:39 | guilleaer | Assigned To | jorge-garcia => javierRodriguez |
2021-10-11 20:40 | guilleaer | Note Added: 0132300 | |
2021-10-15 12:34 | guilleaer | Relationship added | duplicate of 0047855 |
2021-10-28 10:17 | guilleaer | Note Added: 0132700 | |
2021-10-28 10:17 | guilleaer | Status | scheduled => resolved |
2021-10-28 10:17 | guilleaer | Resolution | open => fixed |
2021-10-28 10:18 | guilleaer | Review Assigned To | => jorge-garcia |
2021-10-28 10:18 | guilleaer | Status | resolved => closed |
Copyright © 2000 - 2009 MantisBT Group |