You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by biletnikov <bi...@gmail.com> on 2011/12/03 17:16:24 UTC
Tax calculation for all order adjustments
*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.
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.
Re: Tax calculation for all order adjustments
Posted by 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.
Re: Tax calculation for all order adjustments
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ma...@antwebsystems.com>
> 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.
>
Re: Tax calculation for all order adjustments
Posted by Hans Bakker <ma...@antwebsystems.com>.
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.
Re: Tax calculation for all order adjustments
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
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.
Re: Tax calculation for all order adjustments
Posted by Jacques Le Roux <ja...@les7arts.com>.
>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.
>>
Re: Tax calculation for all order adjustments
Posted by BJ Freeman <bj...@free-man.net>.
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.
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.
>
Re: Tax calculation for all order adjustments
Posted by BJ Freeman <bj...@free-man.net>.
Thanks. I am trying to pinpoint how to approach this.
If your doing it for yourself then you have more latitude not to take
into considerations like the US Tax authority.
The next consideration is when you upgrade you will have to make sure
your changes are not overwritten with the SVN image.
If you plan to submit a patch then the design has to be reviewed to make
sure it does not effect other Tax authority uses.
You also have a migration to setup for productions systems.
biletnikov sent the following on 12/5/2011 10:35 PM:
> Firstly, for myself. But I think this solution is useful not only for me,
> especial for VAT users and if all is ok, it would be grateful to contribute
> to SVN.
> The most tricky question for me is what I should do with "Tax shipping" and
> "Tax promotion" in the TaxAuthorityRateProduct? Actually, they will be
> retired, and should not be used anymore, because all tax rate adjustments
> will be setup in a separate tab.
>
> -----
> Kind regards,
> Sergei
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4163677.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
Re: Tax calculation for all order adjustments
Posted by biletnikov <bi...@gmail.com>.
That is interesting idea.
But which properties settings do you mean?
Because a property setting can be changed manually.
If you mean to keep it like a mail settings, that is ok.
In this case we can even hide shipping and promotions flags if the use
choose OrderAdjustMentTaxSettingAll = true
Another idea: we can have the new tax adjustments settings with the current
shipping & promotion flag settings in the product rates, but if a user
starts to use shipping or promotions in the new tax adjustments tab, the tax
calculation function just ignores promotion & shipping flags in the tax
product rate tab.
What is better?
-----
Kind regards,
Sergei
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4172956.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>.
Yes, I agree with that.
Cheers
Paul Foxworthy
biletnikov wrote
>
> Hi Paul,
> as you said, the different product stores can depend on different tax
> jurisdictions, it is ok, you can setup the tax rates per each store.
> The most important thing is how to design a flexible solution to allow
> taxing for the necessary adjustments.
>
> On the one hand, it is obvious that OFBiz should have the similar "tax
> rate" design for the adjustments, but on the other hand we already have a
> design, which marks promotion and shipping adjustments as a special case
> and we can control them via "TaxAuthorityRateProduct" , it makes this
> similar to a trick.
> In my opinion, I would skip "taxShipping" and "taxPromotions" fields from
> "TaxAuthorityRateProduct" at all, and create "TaxAuthorityRateAdjustment",
> plus rework the tax calculation.
>
> Kind regards,
> Sergei
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4247724.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Tax calculation for all order adjustments
Posted by biletnikov <bi...@gmail.com>.
Hi Paul,
as you said, the different product stores can depend on different tax
jurisdictions, it is ok, you can setup the tax rates per each store.
The most important thing is how to design a flexible solution to allow
taxing for the necessary adjustments.
On the one hand, it is obvious that OFBiz should have the similar "tax rate"
design for the adjustments, but on the other hand we already have a design,
which marks promotion and shipping adjustments as a special case and we can
control them via "TaxAuthorityRateProduct" , it makes this similar to a
trick.
In my opinion, I would skip "taxShipping" and "taxPromotions" fields from
"TaxAuthorityRateProduct" at all, and create "TaxAuthorityRateAdjustment",
plus rework the tax calculation.
Kind regards,
Sergei
-----
Kind regards,
Sergei
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4245684.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 Hans,
I don't think it's that simple.
Different product stores located in different jurisdictions will have
different tax rules. The destination for the order will affect tax rules -
it's common that exports are not taxed.
A property would apply a blanket rule to all orders, and I don't think that
would be flexible enough.
Cheers
Paul Foxworthy
hans_bakker wrote
>
> You could introduce a properties setting:
>
> OrderAdjustMentTaxSettingAll=true/false
>
> false: as is now: only promotion & shipping according
> TaxAuthorityRateProduct
> true: tax on all order adjustments: ignore TaxAuthorityRateProduct
>
> Show this setting on the TaxAuthorityRateProduct screen or do not allow
> setting there
>
> so everybody happy....
>
> Regards,
> Hans
>
> On 12/06/2011 01:35 PM, biletnikov wrote:
>> Firstly, for myself. But I think this solution is useful not only for me,
>> especial for VAT users and if all is ok, it would be grateful to
>> contribute
>> to SVN.
>> The most tricky question for me is what I should do with "Tax shipping"
>> and
>> "Tax promotion" in the TaxAuthorityRateProduct? Actually, they will be
>> retired, and should not be used anymore, because all tax rate adjustments
>> will be setup in a separate tab.
>>
>> -----
>> Kind regards,
>> Sergei
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4163677.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-tp4153757p4244464.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Tax calculation for all order adjustments
Posted by Hans Bakker <ma...@antwebsystems.com>.
You could introduce a properties setting:
OrderAdjustMentTaxSettingAll=true/false
false: as is now: only promotion & shipping according
TaxAuthorityRateProduct
true: tax on all order adjustments: ignore TaxAuthorityRateProduct
Show this setting on the TaxAuthorityRateProduct screen or do not allow
setting there
so everybody happy....
Regards,
Hans
On 12/06/2011 01:35 PM, biletnikov wrote:
> Firstly, for myself. But I think this solution is useful not only for me,
> especial for VAT users and if all is ok, it would be grateful to contribute
> to SVN.
> The most tricky question for me is what I should do with "Tax shipping" and
> "Tax promotion" in the TaxAuthorityRateProduct? Actually, they will be
> retired, and should not be used anymore, because all tax rate adjustments
> will be setup in a separate tab.
>
> -----
> Kind regards,
> Sergei
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4163677.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Tax calculation for all order adjustments
Posted by biletnikov <bi...@gmail.com>.
Firstly, for myself. But I think this solution is useful not only for me,
especial for VAT users and if all is ok, it would be grateful to contribute
to SVN.
The most tricky question for me is what I should do with "Tax shipping" and
"Tax promotion" in the TaxAuthorityRateProduct? Actually, they will be
retired, and should not be used anymore, because all tax rate adjustments
will be setup in a separate tab.
-----
Kind regards,
Sergei
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4163677.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Tax calculation for all order adjustments
Posted by BJ Freeman <bj...@free-man.net>.
are you planning to add this to the svn or just for yourself?
biletnikov sent the following on 12/5/2011 12:41 AM:
> Hello Jacques,
> thanks for the links.
> It is a good idea to keep all tax things in one wiki page.
> However, these articles can not answer my questions.
>
> -----
> Kind regards,
> Sergei
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4159696.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
Re: Tax calculation for all order adjustments
Posted by biletnikov <bi...@gmail.com>.
Hello Jacques,
thanks for the links.
It is a good idea to keep all tax things in one wiki page.
However, these articles can not answer my questions.
-----
Kind regards,
Sergei
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4159696.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.