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:30:34 GMT
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