Posted by
Scott Gray on
Apr 27, 2006; 10:59am
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-tp167724p167749.html
I'm only talking about solving the problem of locales that you are obliged
to collect tax for e.g. you wouldn't want to setup a different store for
each EU country just to display the correct taxes while browsing.
Rather than displaying no tax you could always display your local taxes and
use my suggestion to display alternate taxes if the user wishes to do so.
But anyway that's my last comment because I really have no idea what I'm
talking about!
Regards
Scott
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]] On
Behalf Of David E Jones
Sent: Thursday, 27 April 2006 7:50 p.m.
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Mods to the TaxAuth services to display party's
taxes in prices instead of product store's one
Unfortunately for legal compliance this can be a problem...
The normal approach necessitated by commerce laws (and desire for more
effective localized content, practices and management) is often to have
separate sites for different locales, and in OFBiz that translates into
separate stores. I just don't see a good way around that for global
companies, but of course that is also from my somewhat limited experience...
-David
Scott Gray wrote:
> Hi
>
> I'm no expert on ecommerce but sometimes that can be a good thing if you
> know what I mean...
>
> My preference would be to see no taxes rather than the wrong taxes as I
> might be basing my purchasing decision on what I'm seeing while I browse.
>
> How about showing prices excl taxes by default and possibly having an
> 'include my taxes' link near the price where a user could be shown a
pop-up
> window where they can enter their shipping address or geoid or whatever.
> Perhaps if they are logged in they can select one of their shipping
> addresses. This is then stored for their session and prices are shown
> including the correct taxes.
>
> Regards
> Scott
>
> -----Original Message-----
> From:
[hidden email] [mailto:
[hidden email]] On
> Behalf Of David E Jones
> Sent: Thursday, 27 April 2006 10:08 a.m.
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - Mods to the TaxAuth services to display party's
> taxes in prices instead of product store's one
>
>
> Jacopo,
>
> 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...).
>
> Thanks for posting that stuff on the wiki, BTW.
>
> -David
>
>
> Jacopo Cappellato wrote:
>> 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
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev