You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Paul Foxworthy <pa...@cohsoft.com.au> on 2011/12/01 07:50:53 UTC
Re: Tax calculation for all order adjustments
Hello Sergei,
I had a suggestion to address this in February:
http://ofbiz.135035.n4.nabble.com/VAT-is-not-applied-for-the-shipping-tp3234699p3303377.html
I haven't had a need to work on the proposal yet. What do you think of the
idea?
Cheers
Paul Foxworthy
biletnikov wrote
>
> Hello,
> I use for my project a tax calculation in VAT style.
> For this goal I use the OFBiz Tax authority settings and
> *TaxAuthorityRateProduct* mechanism.
> To be more precise, I added the content of the entity here:
>
> /<TaxAuthorityRateProduct description="VAT 19%" productStoreId="BStore"
> taxAuthGeoId="DEU" taxAuthPartyId="taxAuthority"
> taxAuthorityRateSeqId="10004" taxAuthorityRateTypeId="SALES_TAX"
> taxPercentage="19.000000" taxPromotions="Y" taxShipping="Y"/> /
>
> Please, notice that : *productCategoryId* is not specified - it is empty
> (null).
> The empty *productCategoryId* allows to calculate taxes for shipping and
> promotions.
> Why it is so, could be find in
> org.ofbiz.accounting.tax.TaxAuthorityServices.getTaxAdjustments() method.
> As result, the tax calculation for shipping and promotions works fine.
> But what is about another adjustments? We have another adjustments which
> must be taxed as well, but the system does not allow to setup this
> somewhere.
> Why only shipping charge and promotion adjustments have a special status
> and can be controlled in the tax authority settings?
>
> "calcTax" service is one key service in tax calculation, and it is obvious
> which input data it expects for:
> ...
> /<attribute name="orderShippingAmount" type="BigDecimal" mode="IN"
> optional="true"/>
> <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN"
> optional="true"/>/
> ...
> and again, shipping charge amount and promotions amount have a special
> role in tax calculation...
> Is it a good design for tax calculation in context where each adjustment
> has to be taxed? I do not think so.
>
> I am looking for an elegant solution to fix my problem.
> Thanks.
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4127264.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Tax calculation for all order adjustments
Posted by BJ Freeman <bj...@free-man.net>.
the Tax Authority was implemented and VAT was added later.
Thanks for your links.
Since you have a thread on the Dev list, lets keep it on the dev list
for continuity.
biletnikov sent the following on 12/5/2011 12:38 AM:
> Thank you for your reply BJ Freeman.
> I am not aware of USA Tax Authority, just know some basic principles. VAT
> system is used by many countries. Of course, gross profit is very important
> for any company and it is used in tax computation for local Tax authority.
> Some VAT info you may read here:
> http://en.wikipedia.org/wiki/Value_added_tax
> http://en.wikipedia.org/wiki/Value_added_tax
> The main points for VAT is:
> VAT amount depends on a country
> Some products, materials or services can have different VAT amount per
> country (but that is more exceptional case, when a government wishes to
> reduce taxes for some kinds of business...)
> VAT is applied for product, material or service
> VAT should be specified in each order and invoice (for some countries, it is
> mandatory, but for another it is a best practice)
>
>>From these points, it is interesting to know is "VAT" the same as "Sales
> tax" , I saw many discussions about this in the mail list, and as I see VAT
> is the same as "Sales tax". Ok.
>
> According to VAT, all order items and invoice items must have VAT. In OFBiz,
> adjustments are additional things and services! *Shipping charge* is the
> service adjustment. Fortunately, OFBiz can tax it.
>
> Conclusion,
> for VAT users it is important to have the correct orders and invoices. They
> are correct, when they have all necessary items and adjustments, plus tax
> (VAT). Currently, the orders and invoices are not correct if a company use
> additional adjustments (not shipping and promotion), because they can not be
> taxed. To fix it, the company must edit each order manually. When you add
> additional tax for some adjustments, OFBiz makes tax recalculation according
> to its internal tax model and compensate additional tax by tax deduction.
> This tax deduction must be removed manually. As result ,we have manual,
> unhandy and error risky tax calculation. Each order must be reworked.
>
>
> -----
> Kind regards,
> Sergei
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4159691.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
Re: Tax calculation for all order adjustments
Posted by biletnikov <bi...@gmail.com>.
Thank you for your reply BJ Freeman.
I am not aware of USA Tax Authority, just know some basic principles. VAT
system is used by many countries. Of course, gross profit is very important
for any company and it is used in tax computation for local Tax authority.
Some VAT info you may read here:
http://en.wikipedia.org/wiki/Value_added_tax
http://en.wikipedia.org/wiki/Value_added_tax
The main points for VAT is:
VAT amount depends on a country
Some products, materials or services can have different VAT amount per
country (but that is more exceptional case, when a government wishes to
reduce taxes for some kinds of business...)
VAT is applied for product, material or service
VAT should be specified in each order and invoice (for some countries, it is
mandatory, but for another it is a best practice)
>From these points, it is interesting to know is "VAT" the same as "Sales
tax" , I saw many discussions about this in the mail list, and as I see VAT
is the same as "Sales tax". Ok.
According to VAT, all order items and invoice items must have VAT. In OFBiz,
adjustments are additional things and services! *Shipping charge* is the
service adjustment. Fortunately, OFBiz can tax it.
Conclusion,
for VAT users it is important to have the correct orders and invoices. They
are correct, when they have all necessary items and adjustments, plus tax
(VAT). Currently, the orders and invoices are not correct if a company use
additional adjustments (not shipping and promotion), because they can not be
taxed. To fix it, the company must edit each order manually. When you add
additional tax for some adjustments, OFBiz makes tax recalculation according
to its internal tax model and compensate additional tax by tax deduction.
This tax deduction must be removed manually. As result ,we have manual,
unhandy and error risky tax calculation. Each order must be reworked.
-----
Kind regards,
Sergei
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4159691.html
Sent from the OFBiz - User 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 scenario the
calculations are done during the manufacturing 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/4/2011 9:17 AM:
> In my opinion, TaxAuthorityRateAdjustment can not relate to
> TaxAuthorityRateProduct, because these entities are responsible for
> different taxing scopes : Product and Adjustment.
>
> *TaxAuthorityRateAdjustment* has relation to :
>
> - TAXAUTHORITY<https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=TaxAuthority&find=true&VIEW_SIZE=50&VIEW_INDEX=0>
> - TAXAUTHORITYRATETYPE<https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=TaxAuthorityRateType&find=true&VIEW_SIZE=50&VIEW_INDEX=0>
> - PRODUCTSTORE<https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=ProductStore&find=true&VIEW_SIZE=50&VIEW_INDEX=0>
>
>
> Product or adjustment can be items in each order and it is reasonable to
> have the ability for each item being taxed, as I said that is very actual
> for VAT style calculation.
>
> These TaxAuthorityRateAdjustment and TaxAuthorityRateProduct will exist in
> parallel, but TaxAuthorityRateProduct is oriented on product store and
> product categories, but TaxAuthorityRateAdjustment operates with product
> store and adjustment types!
>
> The tax computation should be carried out in this order:
>
> - Read the appropriate tax authority rates
> - Calculate product taxes
> - Calculate adjustment taxes
> - Sum these adjustments
>
>
> On Sat, Dec 3, 2011 at 8:57 PM, BJ Freeman [via OFBiz] <
> ml-node+s135035n4154077h74@n4.nabble.com> wrote:
>
>> how does this relate to
>>
>> https://demo-trunk.ofbiz.apache.org/webtools/control/ViewRelations?entityName=TaxAuthorityRateProduct
>> Order Adustements
>> an
>> return Adjustments
>>
>> biletnikov sent the following on 12/3/2011 1:26 AM:
>>
>>> In general, we manage tax calculation for products and adjustments (only
>> for
>>> shipping and promotions).
>>> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of
>>> products, so why not to have the same system for adjustments?
>>> I propose the solution to have the TaxAuthorityRateAdjustment entity,
>> who is
>>> related in similar order to TaxAuthority.
>>> TaxAuthorityRateAdjustment will have the following fields:
>>>
>>> *Tax type* (Sales Tax, etc)
>>> *Store ID*
>>> *Catetgory* (empty category means all categories)
>>> Title Transfer ??? (I do not know, what can you suggest?)
>>> Min Item Pirce ??? (I do not know, what can you suggest?)
>>> Min Purchase Price ???? (I do not know, what can you suggest?)
>>> *Tax Percentage *
>>> *From Date *
>>> *Thru Date*
>>> *Description*
>>>
>>> The settings will be placed in the separate tab near to "Product rates"
>> (Tax
>>> Authority settings).
>>> The UI is very similar!
>>>
>>> RE: TaxAuthorityRateAdjustment
>>> we should retire
>>> *Tax Shipping*
>>> *Tax Promotions*
>>> because they look more like a hack.
>>>
>>>
>>> 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.
>>> What do you think about this?
>>>
>>> --
>>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4152813.html
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4154077.html
>> To unsubscribe from Tax calculation for all order adjustments, click here<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4119597&code=YmlsZXRuaWtvdkBnbWFpbC5jb218NDExOTU5N3wyMDcwNzk3NDQ4>
>> .
>> NAML<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
>
Re: Tax calculation for all order adjustments
Posted by biletnikov <bi...@gmail.com>.
In my opinion, TaxAuthorityRateAdjustment can not relate to
TaxAuthorityRateProduct, because these entities are responsible for
different taxing scopes : Product and Adjustment.
*TaxAuthorityRateAdjustment* has relation to :
- TAXAUTHORITY<https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=TaxAuthority&find=true&VIEW_SIZE=50&VIEW_INDEX=0>
- TAXAUTHORITYRATETYPE<https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=TaxAuthorityRateType&find=true&VIEW_SIZE=50&VIEW_INDEX=0>
- PRODUCTSTORE<https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=ProductStore&find=true&VIEW_SIZE=50&VIEW_INDEX=0>
Product or adjustment can be items in each order and it is reasonable to
have the ability for each item being taxed, as I said that is very actual
for VAT style calculation.
These TaxAuthorityRateAdjustment and TaxAuthorityRateProduct will exist in
parallel, but TaxAuthorityRateProduct is oriented on product store and
product categories, but TaxAuthorityRateAdjustment operates with product
store and adjustment types!
The tax computation should be carried out in this order:
- Read the appropriate tax authority rates
- Calculate product taxes
- Calculate adjustment taxes
- Sum these adjustments
On Sat, Dec 3, 2011 at 8:57 PM, BJ Freeman [via OFBiz] <
ml-node+s135035n4154077h74@n4.nabble.com> wrote:
> how does this relate to
>
> https://demo-trunk.ofbiz.apache.org/webtools/control/ViewRelations?entityName=TaxAuthorityRateProduct
> Order Adustements
> an
> return Adjustments
>
> biletnikov sent the following on 12/3/2011 1:26 AM:
>
> > In general, we manage tax calculation for products and adjustments (only
> for
> > shipping and promotions).
> > As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of
> > products, so why not to have the same system for adjustments?
> > I propose the solution to have the TaxAuthorityRateAdjustment entity,
> who is
> > related in similar order to TaxAuthority.
> > TaxAuthorityRateAdjustment will have the following fields:
> >
> > *Tax type* (Sales Tax, etc)
> > *Store ID*
> > *Catetgory* (empty category means all categories)
> > Title Transfer ??? (I do not know, what can you suggest?)
> > Min Item Pirce ??? (I do not know, what can you suggest?)
> > Min Purchase Price ???? (I do not know, what can you suggest?)
> > *Tax Percentage *
> > *From Date *
> > *Thru Date*
> > *Description*
> >
> > The settings will be placed in the separate tab near to "Product rates"
> (Tax
> > Authority settings).
> > The UI is very similar!
> >
> > RE: TaxAuthorityRateAdjustment
> > we should retire
> > *Tax Shipping*
> > *Tax Promotions*
> > because they look more like a hack.
> >
> >
> > 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.
> > What do you think about this?
> >
> > --
> > View this message in context:
> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4152813.html
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
> >
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4154077.html
> To unsubscribe from Tax calculation for all order adjustments, click here<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4119597&code=YmlsZXRuaWtvdkBnbWFpbC5jb218NDExOTU5N3wyMDcwNzk3NDQ4>
> .
> NAML<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
Best regards,
Sergei Biletnikov
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4157423.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Tax calculation for all order adjustments
Posted by BJ Freeman <bj...@free-man.net>.
how does this relate to
https://demo-trunk.ofbiz.apache.org/webtools/control/ViewRelations?entityName=TaxAuthorityRateProduct
Order Adustements
an
return Adjustments
biletnikov sent the following on 12/3/2011 1:26 AM:
> In general, we manage tax calculation for products and adjustments (only for
> shipping and promotions).
> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of
> products, so why not to have the same system for adjustments?
> I propose the solution to have the TaxAuthorityRateAdjustment entity, who is
> related in similar order to TaxAuthority.
> TaxAuthorityRateAdjustment will have the following fields:
>
> *Tax type* (Sales Tax, etc)
> *Store ID*
> *Catetgory* (empty category means all categories)
> Title Transfer ??? (I do not know, what can you suggest?)
> Min Item Pirce ??? (I do not know, what can you suggest?)
> Min Purchase Price ???? (I do not know, what can you suggest?)
> *Tax Percentage *
> *From Date *
> *Thru Date*
> *Description*
>
> The settings will be placed in the separate tab near to "Product rates" (Tax
> Authority settings).
> The UI is very similar!
>
> RE: TaxAuthorityRateAdjustment
> we should retire
> *Tax Shipping*
> *Tax Promotions*
> because they look more like a hack.
>
>
> 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.
> What do you think about this?
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4152813.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
Re: Tax calculation for all order adjustments
Posted by biletnikov <bi...@gmail.com>.
In general, we manage tax calculation for products and adjustments (only for
shipping and promotions).
As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of
products, so why not to have the same system for adjustments?
I propose the solution to have the TaxAuthorityRateAdjustment entity, who is
related in similar order to TaxAuthority.
TaxAuthorityRateAdjustment will have the following fields:
*Tax type* (Sales Tax, etc)
*Store ID*
*Catetgory* (empty category means all categories)
Title Transfer ??? (I do not know, what can you suggest?)
Min Item Pirce ??? (I do not know, what can you suggest?)
Min Purchase Price ???? (I do not know, what can you suggest?)
*Tax Percentage *
*From Date *
*Thru Date*
*Description*
The settings will be placed in the separate tab near to "Product rates" (Tax
Authority settings).
The UI is very similar!
RE: TaxAuthorityRateAdjustment
we should retire
*Tax Shipping*
*Tax Promotions*
because they look more like a hack.
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.
What do you think about this?
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4152813.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Tax calculation for all order adjustments
Posted by biletnikov <bi...@gmail.com>.
Hi Paul,
Your proposal is very good, I am agree totally with you.
What I had in mind as a long term fix was generalising the calcTax service
> and rateProductTaxCalc (line 141 in
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java)
> to take a list of order adjustments, instead of specifically one shipping
> and one promotion amount.
The calls to getTaxAdjustments on lines 224 and 228 would be changed to
> call a separate method that searches a different table, not
> TaxAuthorityRateProduct. This new table would define tax rules for the
> various order adjustment types, much as TARP defines tax rules for product
> categories.
It is very strange for me that the shipping and promotion adjustments have
the special taxable status in OFBiz, although another adjustments are out
of the taxable context.
Do you have an implementation plan?
Also, please notice that this calculation interface gets only promotion and
shipping amounts.... so that follows to changing of another dependent code.
<service name="calcTaxInterface" engine="interface" location=""
invoke="">
<description>Tax Calc Service Interface</description>
<attribute name="productStoreId" type="String" mode="IN"
optional="true"><!-- this will be used to find the payToPartyId, if the
payToPartyId parameter is not explicitly passed, and as one of the columns
to constrain by on the lookup --></attribute>
<attribute name="payToPartyId" type="String" mode="IN"
optional="true"/>
<attribute name="billToPartyId" type="String" mode="IN"
optional="true"><!-- would like to have this not-optional, but in some
circumstances may need a tax estimate without knowing who the customer is
--></attribute>
<attribute name="itemProductList" type="java.util.List" mode="IN"
optional="false"><!-- List of GenericValues --></attribute>
<attribute name="itemAmountList" type="java.util.List" mode="IN"
optional="false"><!-- List of BigDecimals --></attribute>
<attribute name="itemPriceList" type="java.util.List" mode="IN"
optional="false"><!-- List of BigDecimals --></attribute>
* <attribute name="itemShippingList" type="java.util.List" mode="IN"
optional="true"><!-- List of BigDecimals --></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"><!-- List of GenericValues (OrderAdjustment)
--></attribute>
<attribute name="itemAdjustments" type="java.util.List" mode="OUT"
optional="false"><!-- List of Lists of GenericValues (OrderAdjustment), one
List of Adjustments per item --></attribute>
</service>
Of course, it is needed to be refactored.
Kind regards,
Sergei
On Thu, Dec 1, 2011 at 9:50 AM, Paul Foxworthy [via OFBiz] <
ml-node+s135035n4127264h71@n4.nabble.com> wrote:
> Hello Sergei,
>
> I had a suggestion to address this in February:
>
>
> http://ofbiz.135035.n4.nabble.com/VAT-is-not-applied-for-the-shipping-tp3234699p3303377.html
>
> I haven't had a need to work on the proposal yet. What do you think of the
> idea?
>
> Cheers
>
> Paul Foxworthy
>
> biletnikov wrote
> Hello,
> I use for my project a tax calculation in VAT style.
> For this goal I use the OFBiz Tax authority settings and *
> TaxAuthorityRateProduct* mechanism.
> To be more precise, I added the content of the entity here:
>
> *<TaxAuthorityRateProduct description="VAT 19%" productStoreId="BStore"
> taxAuthGeoId="DEU" taxAuthPartyId="taxAuthority"
> taxAuthorityRateSeqId="10004" taxAuthorityRateTypeId="SALES_TAX"
> taxPercentage="19.000000" taxPromotions="Y" taxShipping="Y"/> *
>
> Please, notice that : *productCategoryId* is not specified - it is empty
> (null).
> The empty *productCategoryId* allows to calculate taxes for shipping and
> promotions.
> Why it is so, could be find in
> org.ofbiz.accounting.tax.TaxAuthorityServices.getTaxAdjustments() method.
> As result, the tax calculation for shipping and promotions works fine.
> But what is about another adjustments? We have another adjustments which
> must be taxed as well, but the system does not allow to setup this
> somewhere.
> Why only shipping charge and promotion adjustments have a special status
> and can be controlled in the tax authority settings?
>
> "calcTax" service is one key service in tax calculation, and it is obvious
> which input data it expects for:
> ...
> *<attribute name="orderShippingAmount" type="BigDecimal" mode="IN"
> optional="true"/>
> <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN"
> optional="true"/>*
> ...
> and again, shipping charge amount and promotions amount have a special
> role in tax calculation...
> Is it a good design for tax calculation in context where each adjustment
> has to be taxed? I do not think so.
>
> I am looking for an elegant solution to fix my problem.
> Thanks.
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4127264.html
> To unsubscribe from Tax calculation for all order adjustments, click here<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4119597&code=YmlsZXRuaWtvdkBnbWFpbC5jb218NDExOTU5N3wyMDcwNzk3NDQ4>
> .
> NAML<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
Best regards,
Sergei Biletnikov
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4127318.html
Sent from the OFBiz - User mailing list archive at Nabble.com.