You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Paul Foxworthy <pa...@cohsoft.com.au> on 2012/01/03 00:14:17 UTC
Re: Tax calculation for all order adjustments
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" <mailinglist@>
>> 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.
Re: Tax calculation for all order adjustments
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ja...@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" <pa...@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" <paul@.com>
>>>> 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" <mailinglist@>
>>>>>> 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.
Re: Tax calculation for all order adjustments
Posted by Jacques Le Roux <ja...@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" <pa...@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" <paul@.com>
>>> 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" <mailinglist@>
>>>>> 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.
Re: Tax calculation for all order adjustments
Posted by Paul Foxworthy <pa...@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" <paul@.com>
>> 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" <mailinglist@>
>>>> 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.
Re: Tax calculation for all order adjustments
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <pa...@cohsoft.com.au>
> 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" <mailinglist@>
>>> 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.