|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|feature request||[Openbravo ERP] 09. Financial management||major||N/A||2010-01-26 12:20||2010-04-16 00:00|
|Priority||high||Resolution||fixed||Fixed in Version||2.50MP15|
|Status||closed||Fix in branch||pi||Fixed in SCM revision||32862cded0b5|
|OS Version||Database version||Ant version|
|Product Version||pi||SCM revision|
|Review Assigned To|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0012068: Tax definition enhancement: Multiple nesting levels
|Description||Tax definition enhancement: Multiple nesting levels|
Enhance taxes definition to allow more than one level of nesting.
Let me state it with a little example:
TaxA: Dependant on price Rate 10
TaxB: dependant on price+TaxA Rate 5
TaxC: dependant on price+TaxA Rate 5
With current Openbravo taxes implementation we could define a summary level tax:
Then we could define taxes having previous (TaxA+B+C) as parent. At this point everything seems to be fine. But When trying to take approach:
dependant on price+TaxA , we could use cascade flag for the first one (TaxB) but then we are locked for TaxC
A) if we use flag cascade we would be including not just denpendant on price+TaxA as tax base amount but as well TaxB, resulting in:
TaxC: dependant on price+TaxA+TaxB Rate 5
Which is not the desired calculation.
B) if we do not use the flag cascade we would be not including any tax, resulting in:
TaxC: dependant on price Rate 5
Which is not the desired calculation as well.
After this explanation we realize that the desired behavior can not be driven with current tax implementation in Openbravo. Which is the solution then? We would need to modify core to make this configuration doable.
My proposal is the following:
1) Lets enhance current tax logic to accept multiple levels of tax definition as a tree hierarchy. Current implementation just allows one level of nesting.
2) Lets modify business logic for processing of invoices and orders to take 1) into account.
Having this two prerequisites I think previous constraint can be solved as follows:
1) "TaxA+B+C" ( as sumary level tax)
1.1) "TaxA" (Dependant on price)
1.2) "TaxB+TaxC" ( as sumary level tax with parent: "TaxA+B+C" and flag cascade to make it dependat on price+TaxA)
1.2.1) "TaxB" (having as parent "TaxB+TaxC". This will result into taking as tax base amount price+TaxA, as this is set in parent tax "TaxB+TaxC")
1.2.2) "TaxC" (having as parent "TaxB+TaxC". This will result into taking as tax base amount price+TaxA, as this is set in parent tax "TaxB+TaxC")
|Proposed Solution||1) Eliminate display logic for parent tax field in tax rate window to allow defining multiple nesting levels|
2) Modify Invoice "Complete" process
3) Modify Order "Complete process"
|Tags||No tags attached.|
Project finally merged and pushed to pi:
Some more enhancements where done:
|Tested working fine|
|2010-01-26 12:20||eduardo_Argal||New Issue|
|2010-01-26 12:20||eduardo_Argal||Assigned To||=> eduardo_Argal|
|2010-01-26 12:21||eduardo_Argal||Status||new => scheduled|
|2010-01-26 12:21||eduardo_Argal||fix_in_branch||=> pi|
|2010-02-04 20:11||eduardo_Argal||Note Added: 0023970|
|2010-02-04 20:11||eduardo_Argal||Status||scheduled => resolved|
|2010-02-04 20:11||eduardo_Argal||Fixed in SCM revision||=> 32862cded0b5|
|2010-02-04 20:11||eduardo_Argal||Resolution||open => fixed|
|2010-02-04 20:11||eduardo_Argal||Note Added: 0023971|
|2010-04-15 14:23||sureshbabu||Note Added: 0026262|
|2010-04-15 14:23||sureshbabu||Status||resolved => closed|
|2010-04-15 14:23||sureshbabu||Fixed in Version||=> 2.50MP15|
|2010-04-16 00:00||anonymous||sf_bug_id||0 => 2987950|
|Copyright © 2000 - 2009 MantisBT Group|