ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bakker <mailingl...@antwebsystems.com>
Subject Re: Tax calculation for all order adjustments
Date Sat, 31 Dec 2011 08:51:51 GMT
Sergei,  Paul.

as you suggested,
producrstore should not be used for purchase orders or anything purchase 
tax related,
productstore is for sales only

regards,
Hans

On 12/31/2011 01:44 PM, Paul Foxworthy wrote:
> Hi Sergei,
>
> Title transfer is about when ownership transfers from the seller to the
> purchaser. See
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000
> for the complete list of values. I don't think title transfer is relevant to
> adjustments, so I think it is not needed in the new entity.
>
> productStoreId is fine for sales, but is useless for purchases. I suggest
> the entity have both a productStoreId and a sellerGeoId. For purchases, the
> location of the seller would be used to locate tax rules. I've discussed
> this issue before on the mailing list at
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000
> .
>
> Cheers
>
> Paul Foxworthy
>
>
> biletnikov wrote
>> *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-tp4153757p4247763.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.


Mime
View raw message