Hi Jacques, I do believe I'm in total agreement with you :-).
I have no objection to adding a note to the TaxAuthorityRateProduct maintenance screen to say that Tax Ship and Tax Promo should only be Y once for a given tax authority. In the long term, I think that will not be a complete solution. There are several order adjustment types. We cope with shipping and promotional pricing, but if other order adjustments are added to an order, they might also require a tax charge. 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 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. I have higher prioirities, so I don't expect to work on this anytime soon, and maybe there's a better design than the one I have thought of anyway. Comments anyone? Cheers Paul Foxworthy Jacques Le Roux wrote: > > Thanks Paul, > > I still wonder if we could not handle it a the UI level with the current > data model. Since promo and shipping are for the total > order (or ship groups for shipping, maybe have to check that, but I think > it's ok, the same apply to each ship group) we could use > the 1st simple solution you suggested and Sergei used. The UI would then > handle the fact that in TaxAuthorityRateProduct you can > have only one line with Tax Ship = Y or/and Tax Promo =Y. It's still a > hack but at least, with your patch, even without some > explanation (a simple line above the list shoud be enough) it would be > easy to use and does not need a lot of effort and > refactoring. > > Mmm, but yes the UI would still be misleading and Tax Ship = Y.N or/and > Tax Promo =Y/N should be done apart and note in > TaxAuthorityRateProduct since they are not at the OrderItem level but > OrderHeader and actually not related to any ProductCategory. > At this stage, I must say having had a quick look at rateProductTaxCalc > and getTaxAdjustments I have not a clear vision on how your > new proposed solution would work. > > Jacques > > From: "Paul Foxworthy" <[email protected]> >> Hi Jacques, >> >> The Jira is https://issues.apache.org/jira/browse/OFBIZ-4160 >> https://issues.apache.org/jira/browse/OFBIZ-4160 >> >> My patch is a simple fix for shipping and promotions in the situation >> where >> there's only one row for a given tax authority in >> TaxAuthorityRateProduct. >> >> Where there are multiple rows for a tax authority and different product >> categories, you can still end up with tax added only once to the >> shipping, >> but its a bit of a hack. See my discussion in the history below from Feb >> 2 >> for more on what the patch does do, and its limitations, i.e. what it >> doesn't do that would require more work. >> >> IMHO the patch is worth having until we manage tax for per-order shipping >> and promotions totally independently of product categories. I gather >> Sergei >> ran with it to fix his immediate problem. >> >> Since I wrote that on Feb 2, I've had one more thought about the >> long-term >> fix for the situation. How about creating a new entity something like >> TaxAuthorityRateProduct but mapping OrderAdjustmentType to tax rules? >> Then >> we would look at this new entity to make decisions about shipping, >> promotions and possibly other order adjustments. >> >> Cheers >> >> Paul Foxworthy >> >> >> Jacques Le Roux wrote: >>> >>> BTW, I vaguely remember a Jira and a patch have been created, should we >>> review? >>> >>> Thanks >>> >>> Jacques >>> >>> From: <[email protected]> >>>> Raj, Jacques, >>>> >>>> >>>> Thanks for your suggestions. I have found a config error >>>> I had taken over the _NA_ Tax Authority which was configured to add >>>> another 19 percent of VAT to my store prices. >>>> Clearing this away helped. >>>> >>>> Apologies for the long delay. It took a while :-) >>>> >>>> Regards >>>> >>>> >>>> Carsten >>>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland >>>> >>>> -----Original Message----- >>>> From: "Jacques Le Roux" <[email protected]> >>>> Date: Wed, 2 Feb 2011 10:52:53 >>>> To: <[email protected]> >>>> Reply-To: [email protected] >>>> Subject: Re: VAT is not applied for the shipping >>>> >>>> To be more clear, what have changed in trunk is the possibilit to have >>>> prices with VAT included and code was changed accordingly. >>>> So the ProductPrice and OrderAdjustment entities have changed but not >>>> The >>>> TaxAuthority data model, see >>>> http://svn.apache.org/viewvc?view=revision&revision=1042542 >>>> >>>> IIRW there have been some code amendements after >>>> >>>> Jacques >>>> >>>> From: "Jacques Le Roux" <[email protected]> >>>>> It's the same in trunk >>>>> >>>>> Jacques >>>>> >>>>> From: "biletnikov" <[email protected]> >>>>>> Hello Paul, >>>>>> >>>>>> thank you very much for your detailed explanation and solutions. >>>>>> I think the first way is the more appropriate for us for the first >>>>>> time, >>>>>> but I'm confused what we should do if we had in an order some items >>>>>> with >>>>>> shippable tax and some with free shipping tax? Also the each our >>>>>> product >>>>>> relates to the appropriate category. >>>>>> >>>>>> Is this problem actual only for 9.04 release, or the current trunk >>>>>> has >>>>>> it >>>>>> too? >>>>>> >>>>>> Best regards, >>>>>> Sergei >>>>>> >>>>>> On Wed, Feb 2, 2011 at 8:57 AM, Paul Foxworthy [via OFBiz] < >>>>>> [email protected]<ml-node%[email protected]> >>>>>>> wrote: >>>>>> >>>>>>> Hi Sergei, >>>>>>> >>>>>>> The trouble is that in the rateProductTaxCalc method, >>>>>>> getTaxAdjustments is >>>>>>> called once per product, plus once for shipping and once for >>>>>>> adjustments. In >>>>>>> trunk these are lines 218, 244 and 228 in >>>>>>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true >>>>>>> >>>>>>> When we call getTaxAdjustments for shipping and promotion, there's >>>>>>> no >>>>>>> product, so the product category matching won't work. My change was >>>>>>> to >>>>>>> look >>>>>>> for rows with taxShipping of Y when there's no product. >>>>>>> >>>>>>> If your shipping is always calculated for an order and not by >>>>>>> individual >>>>>>> order items, you could set taxShipping to Y for one row in >>>>>>> TaxAuthorityRateProduct (TARP) and N for the others. A bit of a >>>>>>> hack, >>>>>>> but it >>>>>>> would work. >>>>>>> >>>>>>> Another possibility is to define a new TAXABLE product category >>>>>>> independent >>>>>>> of any other, so you only need one row in TARP. The problem with >>>>>>> this >>>>>>> is you >>>>>>> need to assign a product to the TAXABLE category as you create the >>>>>>> product. >>>>>>> For me in Australia, pretty well everything is taxed, so most >>>>>>> products >>>>>>> would >>>>>>> need the category set. >>>>>>> >>>>>>> A third way, again a hack, is to create a dummy product category >>>>>>> that >>>>>>> no >>>>>>> product has, and add a row to TARP with taxShipping of Y. All other >>>>>>> TARP >>>>>>> rows would have taxShipping of N. >>>>>>> >>>>>>> A better fix would need more consideration and more work. >>>>>>> >>>>>>> Some possibilities I can think of: >>>>>>> >>>>>>> - Add a new column to TARP, perhaps called something like >>>>>>> taxRuleType >>>>>>> or >>>>>>> taxScope. It would have values PRODUCT, SHIPPING, PROMOTION. You >>>>>>> would >>>>>>> add >>>>>>> separate rows for tax rules for shipping and promotion. Each of the >>>>>>> three >>>>>>> calls to getTaxAdjustment would supply a parameter to say which >>>>>>> taxRuleType >>>>>>> to search for. >>>>>>> >>>>>>> - Define entirely separate entities for tax rules for shipping and >>>>>>> promotions rather than overload TARP >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> Paul Foxworthy >>>>>>> >>>>>>> ------------------------------ >>>>>>> If you reply to this email, your message will be added to the >>>>>>> discussion >>>>>>> below: >>>>>>> >>>>>>> http://ofbiz.135035.n4.nabble.com/VAT-is-not-applied-for-the-shipping-tp3234699p3253480.html >>>>>>> To unsubscribe from VAT is not applied for the shipping, click >>>>>>> here<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3234699&code=YmlsZXRuaWtvdkBnbWFpbC5jb218MzIzNDY5OXwyMDcwNzk3NDQ4>. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Sergei Biletnikov >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://ofbiz.135035.n4.nabble.com/VAT-is-not-applied-for-the-shipping-tp3234699p3253536.html >>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> -- >> View this message in context: >> http://ofbiz.135035.n4.nabble.com/VAT-is-not-applied-for-the-shipping-tp3234699p3302338.html >> Sent from the OFBiz - User mailing list archive at Nabble.com. >> > > > > -- View this message in context: http://ofbiz.135035.n4.nabble.com/VAT-is-not-applied-for-the-shipping-tp3234699p3303377.html Sent from the OFBiz - User mailing list archive at Nabble.com.
