Posted by
Jacopo Cappellato on
Apr 26, 2006; 6:30pm
URL: http://ofbiz.116.s1.nabble.com/Dev-Mods-to-the-TaxAuth-services-to-display-party-s-taxes-in-prices-instead-of-product-store-s-one-tp167724p167727.html
David,
ok, I've reviewed the two TaxAuthorityServices responsible for tax
calculations:
* rateProductTaxCalc
* rateProductTaxCalcForDisplay
The former is used during checkout, the latter is used to display the
tax with the price in the category and product details screens of the
ecommerce site (when the ProductStore.showPricesWithVatTax is set to Y).
I think that the main problem (but I'm probably missing something) is
that the product store's vatTaxAuthGeoId and vatTaxAuthPartyId are only
considered by the rateProductTaxCalcForDisplay service and not by the
rateProductTaxCalc service: for this reason the taxes shown in the
category pages are different by the taxes used in checkout.
I'm not sure what was the original design, however I think that there
are two possibilities:
a) we leave rateProductTaxCalcForDisplay as is (i.e. to only consider
the tax authority set in the product store); we patch the
rateProductTaxCalc service to not consider the tax authorities
associated to the shippingAddress of the client (but only the tax auth
of the product store) IF the ProductStore.showPricesWithVatTax is set to Y
b) we modify the rateProductTaxCalcForDisplay to work in the same way
the rateProductTaxCalc service works if a party with a shippingAddress
is available; if not available (i.e. anonymous user or logged in user
with no postalAddress set) the tax auth of the product store is used
What do you think of these?
Thanks,
Jacopo
Jacopo Cappellato wrote:
> David,
>
> thanks for the interesting information: I'll think a bit more about all
> this stuff and I'll comment on them later on.
>
> Jacopo
>
> David E Jones wrote:
>> Jacopo,
>>
>> I haven't reviewed your patches in detail, so this is mostly just a response to your comments...
>>
>> The changes for #1 should be good. Solving NPE problems is pretty much always a good thing.
>>
>> For #2 this brings up a difficult question that the current design avoids asking by just supporting the concept that different locales would have different ProductStores, even if those different ProductStores were used to sell the same Products.
>>
>> The hard question is when to charge a VAT tax. The rules for charging VAT taxes are often different from a sales tax, so the VAT to charge my not have anything to do with where the customer is having the order billed or shipped to, but rather where it is coming from. I think this varies in different jurisdictions according to their local tax policy. This was another the reason for putting it on the ProductStore, that tax would generally just be charged for the location of the business behind the store, or of the fulfillment center or what not.
>>
>> Even without considering what is in that last paragraph, and perhaps some sort of flag on each TaxAuthority record to specify how tax should be handled, and it is necessary to collect a VAT tax based on the customer's billing or shipping address, another things that should go into your list of things to check is if the "Company" selling the good (ie the one specified on the ProductStore) has a "nexus" or sufficient presence in that Geo to have a need to collect taxes there (this is already considered for other parts of the tax functionality, so using it here would just make it more consistent.
>>
>> -David
>>
>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev>
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev