Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
ID | ||||||||||||
0018930 | ||||||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
design defect | [Openbravo ERP] 09. Financial management | major | always | 2011-10-28 18:16 | 2016-06-03 14:41 | |||||||
Reporter | Xpand-IT | View Status | public | |||||||||
Assigned To | dmiguelez | |||||||||||
Priority | high | Resolution | open | Fixed in Version | ||||||||
Status | new | 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 | 3.0MP2 | SCM revision | ||||||||||
Review Assigned To | ||||||||||||
Web browser | ||||||||||||
Modules | Core | |||||||||||
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. | |||||||||||
Tags | No tags attached. | |||||||||||
Attached Files | ||||||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |
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 |
Copyright © 2000 - 2009 MantisBT Group |