Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012068Openbravo ERP09. Financial managementpublic2010-01-26 12:202010-04-16 00:00
Reportereduardo_Argal 
Assigned Toeduardo_Argal 
PriorityhighSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Versionpi 
Target VersionpiFixed in Version2.50MP15 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0012068: Tax definition enhancement: Multiple nesting levels
DescriptionTax definition enhancement: Multiple nesting levels

Enhance taxes definition to allow more than one level of nesting.

Let me state it with a little example:


Having taxes:

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:

TaxA+B+C

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
. Why?
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")
Steps To Reproduce
Proposed Solution1) 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"
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-01-26 12:20eduardo_ArgalNew Issue
2010-01-26 12:20eduardo_ArgalAssigned To => eduardo_Argal
2010-01-26 12:21eduardo_ArgalStatusnew => scheduled
2010-01-26 12:21eduardo_Argalfix_in_branch => pi
2010-02-04 20:11eduardo_ArgalNote Added: 0023970
2010-02-04 20:11eduardo_ArgalStatusscheduled => resolved
2010-02-04 20:11eduardo_ArgalFixed in SCM revision => 32862cded0b5
2010-02-04 20:11eduardo_ArgalResolutionopen => fixed
2010-02-04 20:11eduardo_ArgalNote Added: 0023971
2010-04-15 14:23sureshbabuNote Added: 0026262
2010-04-15 14:23sureshbabuStatusresolved => closed
2010-04-15 14:23sureshbabuFixed in Version => 2.50MP15
2010-04-16 00:00anonymoussf_bug_id0 => 2987950

Notes
(0023970)
eduardo_Argal   
2010-02-04 20:11   
Project finally merged and pushed to pi:
32862cded0b5
(0023971)
eduardo_Argal   
2010-02-04 20:11   
Some more enhancements where done:
http://wiki.openbravo.com/wiki/Projects/TaxEnhancement [^]
(0026262)
sureshbabu   
2010-04-15 14:23   
Tested working fine