ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Subject Re: Re: VAT is not applied for the shipping
Date Sun, 13 Feb 2011 09:12:55 GMT
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" <paul@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" <paul@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.schinzer@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.roux@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.roux@les7arts.com>
>>>>>> It's the same in trunk
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "biletnikov" <biletnikov@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-170824@n4.nabble.com<ml-node%2B3253480-393799844-170824@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.
> 



Mime
View raw message