thanks Jacques
Jacques Le Roux sent the following on 12/4/2011 11:03 AM: >> From: "BJ Freeman" <bjf...@free-man.net> >>> 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. >> >> There is already a page with some points >> https://cwiki.apache.org/confluence/display/OFBIZ/VAT > > Ha , and I forgot the > https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model > which is maybe not up to date... > > Jacques > >> Jacques >> >>> >>> >>> 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. >>>> >
