Openbravo Issue Tracking System - Openbravo ERP | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0018930 | Openbravo ERP | 09. Financial management | public | 2011-10-28 18:16 | 2016-06-03 14:41 |
| Reporter | Xpand-IT | ||||
| Assigned To | dmiguelez | ||||
| Priority | high | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | 3.0MP2 | ||||
| Target Version | Fixed in Version | ||||
| Merge Request Status | |||||
| Review Assigned To | |||||
| OBNetwork customer | |||||
| Web browser | |||||
| Modules | Core | ||||
| Support ticket | |||||
| Regression level | |||||
| Regression date | |||||
| Regression introduced in release | |||||
| Regression introduced by commit | |||||
| Triggers an Emergency Pack | No | ||||
| Summary | 0018930: Tax Definition requires lots of redundant work and leads to rounding issues | ||||
| Description | Right now, a tax can be defined as summary level and then several other taxes can pick this tax to be it's parent tax. The problem with this is that sometimes we would have a tax configuration as following: TaxA - tax that depends on the price (example: IRPF for spain, IRS for portugal, etc) TaxB - tax that does not depend on the price TaxC = TaxA + TaxB TaxC.1 = 1% TaxA.1 + 11% TaxB.1 TaxC.2 = 2% TaxA.2 + 11% TaxB.2 ... TaxC.20 = 20% TaxA.3 + 11% TaxB.3 With the current design, this means that we have to create 20! TaxB records, all of them exactly the same, with the same rate and everything, just with a different parent tax rate. This is the redundant work mentioned on the summary. Now consider that TaxB has its "Document Tax Amount Calculation" as "Document tax amount by rate". Consider an invoice with 4 lines: Line 1: 850€ + TaxC.10 Line 2: 212.50€ + TaxC.10 Line 3: 708.33€ + TaxC.1 Line 4: 177.08€ + TaxC.1 If we look at the Invoice Tax tab we will have: TaxA.10: 106.25 TaxB.10: 116.88 (116.8750) TaxA.1: 8.85 TaxB.1: 97.40 (97.3951) But the truth is that the user just wants to have one instance of TaxB, the only reason why there are 20 is because of the current tax definition design limitation. And because TaxB was intendend to be calculated as "Document tax amount by rate" this leads to a rounding issue as 116.875+97.3951=214.2701, which rounded is 214.27; if we sum TaxB.10 + TaxB.1 = 214.28. | ||||
| Steps To Reproduce | ... | ||||
| Proposed Solution | Instead of choosing a Parent tax rate for a tax, it should be possible to select several "Child Tax Rate" for a tax. The same tax could be child of several different taxes. | ||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2011-10-28 18:16 | Xpand-IT | New Issue | |||
| 2011-10-28 18:16 | Xpand-IT | Assigned To | => jonalegriaesarte | ||
| 2011-10-28 18:16 | Xpand-IT | Modules | => Core | ||
| 2012-09-13 10:43 | jonalegriaesarte | Assigned To | jonalegriaesarte => dmiguelez | ||
| 2016-06-03 14:30 | ngarcia | Triggers an Emergency Pack | => No | ||
| 2016-06-03 14:41 | ngarcia | Issue Monitored: ngarcia | |||
| There are no notes attached to this issue. |