ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Subject Re: Tax calculation for all order adjustments
Date Sun, 04 Dec 2011 18:59:48 GMT
>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

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.
>>

Mime
View raw message