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" <p...@cohsoft.com.au>
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: <c.schin...@googlemail.com>
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" <jacques.le.r...@les7arts.com>
Date: Wed, 2 Feb 2011 10:52:53
To: <user@ofbiz.apache.org>
Reply-To: user@ofbiz.apache.org
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" <jacques.le.r...@les7arts.com>
It's the same in trunk
Jacques
From: "biletnikov" <biletni...@gmail.com>
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] <
ml-node+3253480-393799844-170...@n4.nabble.com<ml-node%2b3253480-393799844-170...@n4.nabble.com>
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.
