Problems with initial tax setup

[justin.g.robinson]

I've read the recent stuff on the ml regarding tax/vat, and it seems
everyone with issues, have them further, down the line I can't even
get sales tax to be listed on order at all. The strange thing is that
it was being calculated, though incorrectly, before I removed the demo
data. The only difference between my data and the demo data is I have
no need for a hierarchy of tax authorities, tax is the same country
wide so I just set up one authority in the accounting manager,
expecting it to be applied since all the geoId's are the same.

Am not sure where it matches the geoId's is a table still needed if
there's only one? Is it based on the customer address?

So in accounting manager I've setup:
o Tax Authority - my single tax authority
o Categories - relevant product categories (if the match is based on
geo, am not sure why/if this is necessary)
o GL Accounts - SALES TAX COLLECTED that I'd set up (been wondering
how I'll balance purchase vat with sales vat with only one account
associated with the authority - but will leave such questions till
after the initial tax config)
o Associations - there aren't any because there's only one authority
o Product Rates - using type 'sales tax' since it seems vat handling
is under developed & would like to get my first pass tax simulation,
happening
o Parties - the company

Then in the catalog manger under stores:
Prorate Taxes: N
Show prices with VAT tax included: Y
Show Tax Is Exempt: Y
Vat Tax Auth Geo Id: ZAF
Vat Tax Auth Party Id: ZA_SARS

Is there prehaps some other place one needs to configure tax?

It did occur to me that perhaps there was some mismatch between, the
'sales tax' type in 'Product Rates' of accounting manager & the 'Vat
Tax Auth Geo Id' of store settings in catalog manager, but I tried
changing them with no effect.

The fact that most posts on the subject show issues furthure down the
line indicate I've missed something.
Please if anyone can make some suggestions?
Thanks.




--
Regards,
Justin
Venture-Net Research & Development

[Paul Foxworthy]

Hi Justin,

Yes, you do need the geo ID in your TaxAuthorityRateProduct (TARP). In some jurisdictions, sales within a given geo are taxed, and exports are not. You're right in thinking the address of the customer is checked to see if it is within the geo specified by the TARP. See https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true#to199, where we search for relevant tax authorities based on the shipping address.

How are you handling ProductStore? There's a ProductStore attribute in TARP, and when tax calculations are done, we are looking for TARP rows that match the ProductStore, or rows that have a null for the ProductStore (see line 283 in the same TaxAuthorityServices.java).

There are other problems with VAT for purchases: as you say, there aren't GL accounts yet, and TARP uses product stores which are irrelevant to purchases. One day...

Cheers

Paul Foxworthy

justin.g.robinson wrote

I've read the recent stuff on the ml regarding tax/vat, and it seems
everyone with issues, have them further, down the line I can't even
get sales tax to be listed on order at all. The strange thing is that
it was being calculated, though incorrectly, before I removed the demo
data. The only difference between my data and the demo data is I have
no need for a hierarchy of tax authorities, tax is the same country
wide so I just set up one authority in the accounting manager,
expecting it to be applied since all the geoId's are the same.

Am not sure where it matches the geoId's is a table still needed if
there's only one? Is it based on the customer address?

So in accounting manager I've setup:
o Tax Authority - my single tax authority
o Categories - relevant product categories (if the match is based on
geo, am not sure why/if this is necessary)
o GL Accounts - SALES TAX COLLECTED that I'd set up (been wondering
how I'll balance purchase vat with sales vat with only one account
associated with the authority - but will leave such questions till
after the initial tax config)
o Associations - there aren't any because there's only one authority
o Product Rates - using type 'sales tax' since it seems vat handling
is under developed & would like to get my first pass tax simulation,
happening
o Parties - the company

Then in the catalog manger under stores:
Prorate Taxes: N
Show prices with VAT tax included: Y
Show Tax Is Exempt: Y
Vat Tax Auth Geo Id: ZAF
Vat Tax Auth Party Id: ZA_SARS

Is there prehaps some other place one needs to configure tax?

It did occur to me that perhaps there was some mismatch between, the
'sales tax' type in 'Product Rates' of accounting manager & the 'Vat
Tax Auth Geo Id' of store settings in catalog manager, but I tried
changing them with no effect.

The fact that most posts on the subject show issues furthure down the
line indicate I've missed something.
Please if anyone can make some suggestions?
Thanks.




--
Regards,
Justin
Venture-Net Research & Development

[justin.g.robinson]

Hi Paul,
Thanks for your reply, having had to do a customization on the, 5000
lines of code ShoppingCart last month, I've been having nightmares
about this VAT issue all weekend. I added some debug statements and
rebuild & for whatever reason it's now calculating sales tax on orders
for my single tax authority. Obviously there is a god and he's down
with tax.
As for the lack of purchase related VAT infastructure, I was thinking
of using a dummy store for purchasing as they have done in opentaps.

In your email: Re: Display VAT on checkout pages

"To me, the tax types SALES_TAX and VAT_TAX are almost the same thing *for a
sale*. In both cases, we're collecting tax which is a liability that must be
paid to a tax authority.

The major difference between a VAT/GST tax and a sales tax is we also record
the VAT tax we paid on *purchases*, and that affects the overall liability
at the time we must pay the tax authority. There's no sales tax on
purchases."

I don't know much about tax, but based on what you have said here do
you think a feasible work around would be to set up a separate tax
authority with it's own gl account tied to the dummy purchasing store.
Then created a service that subtracts it's totals from the sales vat
total to give what we must pay to the tax authority.

Would this approach neglect any finner points of taxation I might be
unaware of or impact any other part of the system negatively?


On Sat, Apr 9, 2011 at 9:30 AM, Paul Foxworthy <[hidden email]> wrote:

> Hi Justin,
>
> Yes, you do need the geo ID in your TaxAuthorityRateProduct (TARP). In some
> jurisdictions, sales within a given geo are taxed, and exports are not.
> You're right in thinking the address of the customer is checked to see if it
> is within the geo specified by the TARP. See
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true#to199
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true#to199
> , where we search for relevant tax authorities based on the shipping
> address.
>
> How are you handling ProductStore? There's a ProductStore attribute in TARP,
> and when tax calculations are done, we are looking for TARP rows that match
> the ProductStore, or rows that have a null for the ProductStore (see line
> 283 in the same TaxAuthorityServices.java).
>
> There are other problems with VAT for purchases: as you say, there aren't GL
> accounts yet, and TARP uses product stores which are irrelevant to
> purchases. One day...
>
> Cheers
>
> Paul Foxworthy
>
>
> justin.g.robinson wrote:
>>
>> I've read the recent stuff on the ml regarding tax/vat, and it seems
>> everyone with issues, have them further, down the line I can't even
>> get sales tax to be listed on order at all. The strange thing is that
>> it was being calculated, though incorrectly, before I removed the demo
>> data. The only difference between my data and the demo data is I have
>> no need for a hierarchy of tax authorities, tax is the same country
>> wide so I just set up one authority in the accounting manager,
>> expecting it to be applied since all the geoId's are the same.
>>
>> Am not sure where it matches the geoId's is a table still needed if
>> there's only one? Is it based on the customer address?
>>
>> So in accounting manager I've setup:
>> o Tax Authority - my single tax authority
>> o Categories - relevant product categories (if the match is based on
>> geo, am not sure why/if this is necessary)
>> o GL Accounts - SALES TAX COLLECTED that I'd set up (been wondering
>> how I'll balance purchase vat with sales vat with only one account
>> associated with the authority - but will leave such questions till
>> after the initial tax config)
>> o Associations - there aren't any because there's only one authority
>> o Product Rates - using type 'sales tax' since it seems vat handling
>> is under developed & would like to get my first pass tax simulation,
>> happening
>> o Parties - the company
>>
>> Then in the catalog manger under stores:
>> Prorate Taxes: N
>> Show prices with VAT tax included: Y
>> Show Tax Is Exempt: Y
>> Vat Tax Auth Geo Id: ZAF
>> Vat Tax Auth Party Id: ZA_SARS
>>
>> Is there prehaps some other place one needs to configure tax?
>>
>> It did occur to me that perhaps there was some mismatch between, the
>> 'sales tax' type in 'Product Rates' of accounting manager & the 'Vat
>> Tax Auth Geo Id' of store settings in catalog manager, but I tried
>> changing them with no effect.
>>
>> The fact that most posts on the subject show issues furthure down the
>> line indicate I've missed something.
>> Please if anyone can make some suggestions?
>> Thanks.
>>
>>
>>
>>
>> --
>> Regards,
>> Justin
>> Venture-Net Research & Development
>>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Problems-with-initial-tax-setup-tp3436439p3438042.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

--
Regards,
Justin
Venture-Net Research & Development

[Paul Foxworthy]

Hi Justin,

I'm uncomfortable with using a dummy product store for VAT tax paid on purchases. If your organisation had two facilties in two different locations such that different tax rules applied, a dummy product store wouldn't solve the problem.

I think the right answer is to change TaxAuthorityRateProduct so it holds the geographical location of both the buyer and the seller. Then TARP rules could be applied to both sales and purchases.

Cheers

Paul Foxworthy

justin.g.robinson wrote

Hi Paul,
Thanks for your reply, having had to do a customization on the, 5000
lines of code ShoppingCart last month, I've been having nightmares
about this VAT issue all weekend. I added some debug statements and
rebuild & for whatever reason it's now calculating sales tax on orders
for my single tax authority. Obviously there is a god and he's down
with tax.
As for the lack of purchase related VAT infastructure, I was thinking
of using a dummy store for purchasing as they have done in opentaps.

In your email: Re: Display VAT on checkout pages

"To me, the tax types SALES_TAX and VAT_TAX are almost the same thing *for a
sale*. In both cases, we're collecting tax which is a liability that must be
paid to a tax authority.

The major difference between a VAT/GST tax and a sales tax is we also record
the VAT tax we paid on *purchases*, and that affects the overall liability
at the time we must pay the tax authority. There's no sales tax on
purchases."

I don't know much about tax, but based on what you have said here do
you think a feasible work around would be to set up a separate tax
authority with it's own gl account tied to the dummy purchasing store.
Then created a service that subtracts it's totals from the sales vat
total to give what we must pay to the tax authority.

Would this approach neglect any finner points of taxation I might be
unaware of or impact any other part of the system negatively?


On Sat, Apr 9, 2011 at 9:30 AM, Paul Foxworthy <[hidden email]> wrote:
> Hi Justin,
>
> Yes, you do need the geo ID in your TaxAuthorityRateProduct (TARP). In some
> jurisdictions, sales within a given geo are taxed, and exports are not.
> You're right in thinking the address of the customer is checked to see if it
> is within the geo specified by the TARP. See
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true#to199
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true#to199
> , where we search for relevant tax authorities based on the shipping
> address.
>
> How are you handling ProductStore? There's a ProductStore attribute in TARP,
> and when tax calculations are done, we are looking for TARP rows that match
> the ProductStore, or rows that have a null for the ProductStore (see line
> 283 in the same TaxAuthorityServices.java).
>
> There are other problems with VAT for purchases: as you say, there aren't GL
> accounts yet, and TARP uses product stores which are irrelevant to
> purchases. One day...
>
> Cheers
>
> Paul Foxworthy
>
>
> justin.g.robinson wrote:
>>
>> I've read the recent stuff on the ml regarding tax/vat, and it seems
>> everyone with issues, have them further, down the line I can't even
>> get sales tax to be listed on order at all. The strange thing is that
>> it was being calculated, though incorrectly, before I removed the demo
>> data. The only difference between my data and the demo data is I have
>> no need for a hierarchy of tax authorities, tax is the same country
>> wide so I just set up one authority in the accounting manager,
>> expecting it to be applied since all the geoId's are the same.
>>
>> Am not sure where it matches the geoId's is a table still needed if
>> there's only one? Is it based on the customer address?
>>
>> So in accounting manager I've setup:
>> o Tax Authority - my single tax authority
>> o Categories - relevant product categories (if the match is based on
>> geo, am not sure why/if this is necessary)
>> o GL Accounts - SALES TAX COLLECTED that I'd set up (been wondering
>> how I'll balance purchase vat with sales vat with only one account
>> associated with the authority - but will leave such questions till
>> after the initial tax config)
>> o Associations - there aren't any because there's only one authority
>> o Product Rates - using type 'sales tax' since it seems vat handling
>> is under developed & would like to get my first pass tax simulation,
>> happening
>> o Parties - the company
>>
>> Then in the catalog manger under stores:
>> Prorate Taxes: N
>> Show prices with VAT tax included: Y
>> Show Tax Is Exempt: Y
>> Vat Tax Auth Geo Id: ZAF
>> Vat Tax Auth Party Id: ZA_SARS
>>
>> Is there prehaps some other place one needs to configure tax?
>>
>> It did occur to me that perhaps there was some mismatch between, the
>> 'sales tax' type in 'Product Rates' of accounting manager & the 'Vat
>> Tax Auth Geo Id' of store settings in catalog manager, but I tried
>> changing them with no effect.
>>
>> The fact that most posts on the subject show issues furthure down the
>> line indicate I've missed something.
>> Please if anyone can make some suggestions?
>> Thanks.
>>
>>
>>
>>
>> --
>> Regards,
>> Justin
>> Venture-Net Research & Development
>>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Problems-with-initial-tax-setup-tp3436439p3438042.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>



--
Regards,
Justin
Venture-Net Research & Development