Thanks Paul,
For now, I will do the simple one with an explanation on the screen, but will not commit before having also a js script enforcing
the rule
Jacques
From: "Paul Foxworthy" <p...@cohsoft.com.au>
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" <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.
--
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.
