Tax calculation for all order adjustments
Locked
Tax calculation for all order adjustments
 
|
This post was updated on .
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.
Kind regards,
Sergei |
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
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Tax calculation for all order adjustments
|
|
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 inhttps://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] <[hidden email]> wrote: Hello Sergei, Best regards, Sergei Biletnikov
Kind regards,
Sergei |
Re: Tax calculation for all order adjustments
|
|
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
|
|
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 :
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:
On Sat, Dec 3, 2011 at 8:57 PM, BJ Freeman [via OFBiz] <[hidden email]> wrote: how does this relate to Best regards, Sergei Biletnikov
Kind regards,
Sergei |
Re: Tax calculation for all order adjustments
|
|
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] < > [hidden email]> 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< >> . >> 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
|
|
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 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 |
Re: Tax calculation for all order adjustments
|
|
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. > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |