[OFBiz] Users - multiple tax authorities in same Geo

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[OFBiz] Users - multiple tax authorities in same Geo

cjhowe
If someone does have what you're trying to avoid writing code for, couldn't they just
use a custom Geo group that would credit a taxing pool and let them write the code to split it from there?
Assuming that it is an uncommon occurance

================Si Wrote==============

Each Geo (State) would have its own tax authority and gl account. So
that should work fine if there are multiple states.

Chris Howe wrote:

>Wouldn't you have this issue if you operated in
>multiple states? Or are you saying divying up only
>the sales tax for a single transaction?
>
>
>===================
>Hi. Working on some sales tax liability/expense
>stuff. Just wanted to
>check:
>
>Does anybody have business requirements where sales or
>use or VAT taxes
>are payable to multiple authoriti! es in the same Geo?
>(ie, Do you have
>special products that have separate sales and use tax
>authorities, or do
>you have to pay different levels of local
>governments?)
>
>If so, please say so NOW. Otherwise, we'll set it so
>that each Geo can
>only have one tax authority.
>
>(Note: in California, state, county, and city
>governments all have
>different sales taxes, but the taxes are paid to one
>state tax
>authority, the Franchise Tax Board. So, in this case,
>there is only one
>payable authority per Geo of CA. I'm asking about
>cases where you
>actually have to send separate checks to different agencies.)
>
>_______________________________________________
>Users mailing list
>Users at lists.ofbiz.org
>http://lists.ofbiz.org/mailman/listinfo/users
>
>
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Users - multiple tax authorities in same Geo

Si Chen-2
Yes.  That'd be a way to hack it. :-)

I'm just hoping if it were a common need, that we not make people have
to resort to such measures.  But it doesn't seem like anybody has spoken
up.  Which is a good thing, I guess--we all need more efficient government.

Si

Chris Howe wrote:

>If someone does have what you're trying to avoid writing code for, couldn't they just
>use a custom Geo group that would credit a taxing pool and let them write the code to split it from there?
>Assuming that it is an uncommon occurance
>
>================Si Wrote==============
>
>Each Geo (State) would have its own tax authority and gl account.  So
>that should work fine if there are multiple states.
>
>Chris Howe wrote:
>
>>/Wouldn't you have this issue if you operated in
>/>/multiple states?  Or are you saying divying up only
>/>/the sales tax for a single transaction?  
>/>/
>/>/
>/>/===================
>/>/Hi.  Working on some sales tax liability/expense
>/>/stuff.  Just wanted to
>/>/check:
>/>/
>/>/Does anybody have business requirements where sales or
>/>/use or VAT taxes
>/>/are payable to multiple authoriti!
>es in the
> same Geo?
>/>/(ie, Do you have
>/>/special products that have separate sales and use tax
>/>/authorities, or do
>/>/you have to pay different levels of local
>/>/governments?)
>/>/
>/>/If so, please say so NOW.  Otherwise, we'll set it so
>/>/that each Geo can
>/>/only have one tax authority.
>/>/
>/>/(Note: in California, state, county, and city
>/>/governments all have
>/>/different sales taxes, but the taxes are paid to one
>/>/state tax
>/>/authority, the Franchise Tax Board.  So, in this case,
>/>/there is only one
>/>/payable authority per Geo of CA.  I'm asking about
>/>/cases where you
>/>/actually have to send separate checks to different agencies.)
>/>/
>/>/_______________________________________________
>/>/Users mailing list
>/>Users at lists.ofbiz.org <http://lists.ofbiz.org/mailman/listinfo/users>
>>/http://lists.ofbiz.org/mailman/listinfo/users
>/>/
>/>/  
>/>
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Users mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/users
>
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Users - multiple tax authorities in same Geo

David E. Jones
In reply to this post by cjhowe

In a way it does make sense to model a taxation entity as a  
combination of the geographic boundary, and the tax authority. BTW, I  
was using the term "jurisdiction" before, but I like tax authority a  
lot better.

On the SimpleSalesTaxLookup perhaps it is best to have both a  
taxAuthorityGeoId and a taxAuthorityPartyId.

For the posting of sales tax for a sales order, or from a sales  
invoice rather, I'm starting to like Si's idea of adding an entity  
that would have a sort of TaxAuthorityGlAccount entity with a  
taxAuthorityGeoId, taxAuthorityPartyId, organizationPartyId, and  
glAccountId.

Wow, a bit complicated.... Of course, with any luck, we'll get some  
larger companies to drool over it a bit...

-David


On Jul 13, 2005, at 5:40 PM, Si Chen wrote:

> Yes, I understood. I was just wondering if you might have a case  
> where you have multiple authorities for the same geo. Like for  
> example, for the same state, a sales tax authority like the  
> Franchise Tax Board and a use tax or school tax authority that  
> decided it wants to collect its own taxes. Then you'd have to map  
> the same Geo (not sub-Geos) to multiple authorities.
>
> Do you want us to take a look at re-factoring some of the  
> SimpleSalesTaxLookup stuff while we're at it? It should be possible  
> to change it the way you suggested it. The downside is then  
> everybody will have to modify their installation if they upgrade.
>
> Si
>
> David E. Jones wrote:
>
>
>>
>> Si,
>>
>> When I said that a given Geo would only have only one tax  
>> authority I did NOT mean a Geo and all of it's regions, or sub-
>> Geos. In other words, we really should have separate tax setup for  
>> each state/ province, and where application county, city, country,  
>> etc...
>>
>> Note that the current simple sales tax calc stuff in OFBiz is  
>> POORLY DESIGNED. It has a countryGeoId and a stateProvinceGeoId.  
>> Those 2 fields should be ripped out and a "jurisdictionGeoId"  
>> should put in place instead. The current design is both confusing  
>> and inflexible when you consider real-world requirements for  
>> taxation.
>>
>> This is one of those pieces of code that, well, to put it  
>> politely, inspires negative feelings in me when I think about it,  
>> and I wish it was never written this way because it will have to  
>> be corrected as soon as someone wants to do anything realistic  
>> with sales tax through this. Which will be an unpleasant surprise,  
>> and I'll have people angry with me as I try to explain to them  
>> that if they want it fixed somehow resources will have to be  
>> dedicated to that.
>>
>> Anyway, I hope that clears up the general concept. Each  
>> OrderAdjustment that represents sales tax has a primaryGeoId on  
>> it, and that is the one that the tax will (should) be for. So, a  
>> given OrderItem may have various different sales tax adjustments  
>> for different jurisdictions.
>>
>> -David
>>
>>
>> On Jul 13, 2005, at 4:59 PM, Matt Penner wrote:
>>
>>
>>> Hi Si,
>>>
>>> I just went through some of this in my own research. CA actually  
>>> seems to
>>> be an exception. Some states not only have multiple tax  
>>> authorities such as
>>> Federal, State, and Local, but there are also special  
>>> propositions passed in
>>> some counties requiring that local agencies such as  
>>> transportation get an
>>> additional percentage.
>>>
>>> For example, in Riverside Co, CA, the tax is really 7.5%, but  
>>> there is a
>>> transportation authority that receives a .25% tax of all sales  
>>> tax, bringing
>>> the total to the 7.75% that Riverside locals are familiar with.  
>>> Since we
>>> only pay one agency, the Franchise Tax Board as you mentioned, it  
>>> doesn't
>>> affect us much, but this could easily affect others.
>>>
>>> Matt
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:users-  
>>> [hidden email]]
>>> On Behalf Of Si Chen
>>> Sent: Wednesday, July 13, 2005 2:11 PM
>>> To: OFBiz Users / Usage
>>> Subject: [OFBiz] Users - multiple tax authorities in same Geo
>>>
>>> Hi. Working on some sales tax liability/expense stuff. Just  
>>> wanted to
>>> check:
>>>
>>> Does anybody have business requirements where sales or use or VAT  
>>> taxes
>>> are payable to multiple authorities in the same Geo? (ie, Do you  
>>> have
>>> special products that have separate sales and use tax  
>>> authorities, or do
>>> you have to pay different levels of local governments?)
>>>
>>> If so, please say so NOW. Otherwise, we'll set it so that each  
>>> Geo can
>>> only have one tax authority.
>>>
>>> (Note: in California, state, county, and city governments all have
>>> different sales taxes, but the taxes are paid to one state tax
>>> authority, the Franchise Tax Board. So, in this case, there is  
>>> only one
>>> payable authority per Geo of CA. I'm asking about cases where you
>>> actually have to send separate checks to different agencies.)
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

smime.p7s (3K) Download Attachment