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-tp167724p167728.html
Yeah, there is a difference in these based on the information known when they are run.
One way or another there is a potential difference in the tax because of information not known until checkout begins. I like the (b) option more than (a) because it is at least an attempt to use information available when the user is logged in, but it doesn't solve the problem as the user could have multiple shipping and billing addresses and if a different one is selected or entered during checkout that will change the tax terms anyway.
It would be interesting to hear from others, but I don't think the (a) option is a good idea because tax may be charged that shouldn't be... But it depends on the tax rules of the local government. If they require a VAT tax regardless of where the product is shipped or billed to, then this would be the case. This could be an option on the TaxAuthority itself so that it is configured. That would be more appropriate as the goal for this code is legal compliance according to information we know from the customer at the time, not really consistency throughout (as unfortunately compliance is not so simple and friendly...).
> 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