I am not familiar with VAT so I can not comment on the best way to approach this for VAT. For USA our Tax Authority is based on Government (IRS) which I guess is similar to VAT But not on Items but gross profit at the end of the fiscal year. In manufacturing you can not charge off the deduction of the piece manufactured till the piece is sold. Under this senario the calculations are done durring the manufaturing process and is additive, then assigned to IRIS ledger..
The Tax authority for Sales is based on Geo with separate Tax authorities. Like State, County, city. These are compounded So Adjustments are complex in computations. I bring this up so that the model that is used will accommodate all Tax Authority scenarios. This was not a simple effort when we did it so I don't think a discussion would be simple. Maybe a Wiki page would be appropriate to come up with a viable design. biletnikov sent the following on 12/3/2011 8:16 AM: > *Current problem:* > we manage tax calculation for products by setting up a tax authority. > The tax rate for products is set with TaxAuthorityRateProduct. > In addition, tax setting for shipping and promotions adjustments can be set > as special flags to each TaxAuthorityRateProduct (tax shipping/promotion Y > or N). However, these 2 adjustments are taxed only if productCategoryId is > empty, and these 2 adjustments look like a hack or temp solution here... > I faced with a problem, where all adjustments must be taxed (very common > case for VAT tax system) and it is very unhandy when you have to control the > tax amount manually. In our case, the system taxes the shipping and > promotion adjustments, but we have to add Sales tax to all another > adjustments manually. > In addition, OFBiz has tax amount correction logic, which compensates the > tax difference automatically, example: > Prdouct 100 euro > Sales tax (VAT 19%) = 100 * 0.19 = 19 euro > Shipping charge 10 euro > Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro > Other adjustment 20 euro > Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) > *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added difference > to correct the sales tax amount, because the sales tax for other adjustment > is not taken into account.) > and we have to delete the last tax adjustment manually. > > *Solution:* > As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of > products, so why not to have the same mechanism for all adjustments? > I propose the solution to have the TaxAuthorityRateAdjustment entity. > TaxAuthorityRateAdjustment will have the following fields: > > *Tax type* (Sales Tax, etc) > *Store ID* > *Adjustment Type or (All adjustments)* > Title Transfer ??? (I do not know, what can you suggest?) > *Tax Percentage * > *From Date * > *Thru Date* > *Description* > > The settings will be placed in the separate "Adjustment rates" tab, near to > "Product rates" (Tax Authority settings). > The UI should be very similar! > > RE: TaxAuthorityRateProduct > we should retire > *Tax Shipping* > *Tax Promotions* > > The tax calculation service must be reworked, > > <service name="calcTax" engine="java" > location="org.ofbiz.accounting.tax.TaxAuthorityServices" > invoke="rateProductTaxCalc"> > <description>Tax Authority Rate Product Calc Service</description> > <implements service="calcTaxInterface"/> > </service> > > <service name="calcTaxInterface" engine="interface" location="" > invoke=""> > <description>Tax Calc Service Interface</description> > <attribute name="productStoreId" type="String" mode="IN" > optional="true"></attribute> > <attribute name="facilityId" type="String" mode="IN" > optional="true"></attribute> > <attribute name="payToPartyId" type="String" mode="IN" > optional="true"/> > <attribute name="billToPartyId" type="String" mode="IN" > optional="true"></attribute> > <attribute name="itemProductList" type="java.util.List" mode="IN" > optional="false"></attribute> > <attribute name="itemAmountList" type="java.util.List" mode="IN" > optional="false"></attribute> > <attribute name="itemPriceList" type="java.util.List" mode="IN" > optional="false"></attribute> > <attribute name="itemQuantityList" type="java.util.List" mode="IN" > optional="true"></attribute> > <attribute name="itemShippingList" type="java.util.List" mode="IN" > optional="true"></attribute> > * <attribute name="orderShippingAmount" type="BigDecimal" mode="IN" > optional="true"/> > <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN" > optional="true"/> > * <attribute name="shippingAddress" > type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> > <attribute name="orderAdjustments" type="java.util.List" mode="OUT" > optional="false"></attribute> > <attribute name="itemAdjustments" type="java.util.List" mode="OUT" > optional="false"></attribute> > </service> > > This interface must have /OrderAdjustment/ list as IN parameter. > > That is my draft solution. > Any ideas? What is your opinion? > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4153757.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. >
