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 Wed, 04 Jan 2012 07:54:40 GMT
Also one of my client is interested by having shipping rates by suppliers, just another idea
in this field (I don't develop for this 
client, just some consulting by mail)

Jacques

From: "Jacques Le Roux" <jacques.le.roux@les7arts.com>
> Hi Paul,
>
> Yes you are right, could be a fallback only indeed (in some cases no needs to create
more, for instance if you are doing business 
> only in France then the rates don't change)
>
> Jacques
>
> From: "Paul Foxworthy" <paul@cohsoft.com.au>
>> Hi Jacques,
>>
>> I think there's a difference.
>>
>> Yes, the ProductStore is indeed a profit centre for our organization.
>>
>> It is reasonable to have VAT parameters related to a ProductStore for sales,
>> because the product store is in one location for tax accounting purposes.
>> The entries in TaxAuthorityRateProduct define the tax authorities that are
>> relevant to the location of the product store. Note that the taxAuthGeoId
>> attribute in TaxAuthorityRateProduct is for the location of the purchaser,
>> not the seller. Now, if we had two product stores located close to each
>> other, say in the same state/province, they could well have duplicated VAT
>> information. Provided the number of stores isn't huge, we can live with the
>> duplication.
>>
>> In contrast, for purchases, there are many suppliers, perhaps in many
>> different locations with different VAT policies. The new entity we're
>> envisaging should have rows for each location where there is at least one
>> supplier, and we want estimated VAT to be automatically added to purchase
>> orders. I don't envisage a row for each supplier. That would mean an
>> explosion of rows with duplicated information on the VAT rates for some
>> location.
>>
>> I think it most unlikely that you would want to allocate cost centres to a
>> purchase based just on the *location* of the supplier. You might want to do
>> it based on who the supplier is, which division of our organization is
>> making the purchase, what project the purchase is relevant to, or many other
>> criteria. But none of those facts will be in the new entity we're
>> considering.
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>>
>> Jacques Le Roux wrote
>>>
>>> Hi Paul,
>>>
>>> This comes from Hans's answer
>>>>>> as you suggested,
>>>>>> producrstore should not be used for purchase orders or anything
>>>>>> purchase
>>>>>> tax related,
>>>>>> productstore is for sales only
>>>
>>> My basic idea was that you set VAT parameters on profit center (VAT fields
>>> in ProductStore UI:
>>> ...catalog/control/EditProductStore?productStoreId=...) so if you need to
>>> set VAT for incoming orders (purchases) the same kind of
>>> stuff could be set from a new CostCenter Entity. But really I did not put
>>> much thoughts in that, just remembered this thread, and
>>> it's maybe not even a good idea...
>>>
>>> Jacques
>>>
>>> From: "Paul Foxworthy" &lt;paul@.com&gt;
>>>> Hi Jacques and Happy New Year,
>>>>
>>>> I had thought cost centres are a separate issue. An organization using
>>>> OFBiz
>>>> might want to break down a purchase into multiple cost centres even if no
>>>> tax is involved.
>>>>
>>>> Is there a need to consider cost centres as part of this? Why so?
>>>>
>>>> Cheers
>>>>
>>>> Paul Foxworthy
>>>>
>>>>
>>>> Jacques Le Roux wrote
>>>>>
>>>>> This remembers me this dicussion
>>>>> http://markmail.org/message/oisyr3hqq2vn3yfz
>>>>> There are maybe some good ideas there, are we not looking for cost
>>>>> centers?
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Hans Bakker" &lt;mailinglist@&gt;
>>>>>> 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.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4254879.html
>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>
>>
>> --
>> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4259790.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. 

Mime
View raw message