Tax bug --or-- The best way to override a single java file.

[Mike Z]

I found an odd behavior with the tax handling in ofbiz.  If you need
to charge local sales tax based on ZIP-4 (like in WA state), I found
the following:

1) User enters exact ZIP-4 zip code (which is in ofbiz), local sales
tax is charged correctly.
2) User just enters ZIP (which is in ofbiz), local sales tax is
charged correctly.
3) User enters ZIP-4, but "4" is incorrect/typo, local sales tax is
*NOT* calculated.

I would like ofbiz to do one of the following:

1) Reject the bad ZIP-4 code and ask the user to re-enter.
2) Strip the "+4" and try to match on just on the ZIP.
3) Even better, try to match on ZIP+3, or ZIP+2.

Regarding #1:  Since all potential ZIP codes (WA state-only) are in
the database, this should be possible.  I'm not aware of a flag/config
item that forces a check.  For other states, don't care because I'm
not (yet) required to charge local sales tax.

As it stands, a clever user could try to fake out ofbiz by entering a
bogus ZIP+4, is ONLY charged state sales tax (no local tax), and let
the post office sort out or "fix" the ZIP+4, which they would.

Back to the subject:  I'm probably going to try to fix this, and
probably the best way is to hack:

applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java

Is there a way that I could leave the orignal
TaxAuthorityServices.java in it's place, and place a modified version
in hot-deploy?  Can this be done for just a single java file?  What
would be the directory structure for this?

Thanks

[BJ Freeman]

I would suggest a ECA this allows others to not be effected by your
changes like VAT.
the ECA can check the Locale to see if it needs to run.
since not all countries use zip.

Mike Z sent the following on 9/17/2010 3:51 PM:

> I found an odd behavior with the tax handling in ofbiz.  If you need
> to charge local sales tax based on ZIP-4 (like in WA state), I found
> the following:
>
> 1) User enters exact ZIP-4 zip code (which is in ofbiz), local sales
> tax is charged correctly.
> 2) User just enters ZIP (which is in ofbiz), local sales tax is
> charged correctly.
> 3) User enters ZIP-4, but "4" is incorrect/typo, local sales tax is
> *NOT* calculated.
>
> I would like ofbiz to do one of the following:
>
> 1) Reject the bad ZIP-4 code and ask the user to re-enter.
> 2) Strip the "+4" and try to match on just on the ZIP.
> 3) Even better, try to match on ZIP+3, or ZIP+2.
>
> Regarding #1:  Since all potential ZIP codes (WA state-only) are in
> the database, this should be possible.  I'm not aware of a flag/config
> item that forces a check.  For other states, don't care because I'm
> not (yet) required to charge local sales tax.
>
> As it stands, a clever user could try to fake out ofbiz by entering a
> bogus ZIP+4, is ONLY charged state sales tax (no local tax), and let
> the post office sort out or "fix" the ZIP+4, which they would.
>
> Back to the subject:  I'm probably going to try to fix this, and
> probably the best way is to hack:
>
> applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>
> Is there a way that I could leave the orignal
> TaxAuthorityServices.java in it's place, and place a modified version
> in hot-deploy?  Can this be done for just a single java file?  What
> would be the directory structure for this?
>
> Thanks
>

[BJ Freeman]

to help:
the user input should be dealt with in the module it comes from.
party zip code is  dealt with in the party component.
It should be resolved by the time it gets to TaxAuthorityServices
So the ECA should be in the componet that has the first service that
deals with the user input that contains zip information. the service,
called by the ECA, that actually deals with the zip should be in the
party component.

BJ Freeman sent the following on 9/17/2010 7:00 PM:

> I would suggest a ECA this allows others to not be effected by your
> changes like VAT.
> the ECA can check the Locale to see if it needs to run.
> since not all countries use zip.
>
> Mike Z sent the following on 9/17/2010 3:51 PM:
>
>> I found an odd behavior with the tax handling in ofbiz. If you need
>> to charge local sales tax based on ZIP-4 (like in WA state), I found
>> the following:
>>
>> 1) User enters exact ZIP-4 zip code (which is in ofbiz), local sales
>> tax is charged correctly.
>> 2) User just enters ZIP (which is in ofbiz), local sales tax is
>> charged correctly.
>> 3) User enters ZIP-4, but "4" is incorrect/typo, local sales tax is
>> *NOT* calculated.
>>
>> I would like ofbiz to do one of the following:
>>
>> 1) Reject the bad ZIP-4 code and ask the user to re-enter.
>> 2) Strip the "+4" and try to match on just on the ZIP.
>> 3) Even better, try to match on ZIP+3, or ZIP+2.
>>
>> Regarding #1: Since all potential ZIP codes (WA state-only) are in
>> the database, this should be possible. I'm not aware of a flag/config
>> item that forces a check. For other states, don't care because I'm
>> not (yet) required to charge local sales tax.
>>
>> As it stands, a clever user could try to fake out ofbiz by entering a
>> bogus ZIP+4, is ONLY charged state sales tax (no local tax), and let
>> the post office sort out or "fix" the ZIP+4, which they would.
>>
>> Back to the subject: I'm probably going to try to fix this, and
>> probably the best way is to hack:
>>
>> applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>>
>>
>> Is there a way that I could leave the orignal
>> TaxAuthorityServices.java in it's place, and place a modified version
>> in hot-deploy? Can this be done for just a single java file? What
>> would be the directory structure for this?
>>
>> Thanks
>>
>

[Mike Z]

Thanks BJ.  I was thinking that I probably need to force WA state
customers to enter ZIP+4, and perform a DB lookup.  I'll have to
figure out how to do an ECA.

On Fri, Sep 17, 2010 at 7:00 PM, BJ Freeman <[hidden email]> wrote:

> I would suggest a ECA this allows others to not be effected by your changes
> like VAT.
> the ECA can check the Locale to see if it needs to run.
> since not all countries use zip.
>
> Mike Z sent the following on 9/17/2010 3:51 PM:
>
>> I found an odd behavior with the tax handling in ofbiz.  If you need
>> to charge local sales tax based on ZIP-4 (like in WA state), I found
>> the following:
>>
>> 1) User enters exact ZIP-4 zip code (which is in ofbiz), local sales
>> tax is charged correctly.
>> 2) User just enters ZIP (which is in ofbiz), local sales tax is
>> charged correctly.
>> 3) User enters ZIP-4, but "4" is incorrect/typo, local sales tax is
>> *NOT* calculated.
>>
>> I would like ofbiz to do one of the following:
>>
>> 1) Reject the bad ZIP-4 code and ask the user to re-enter.
>> 2) Strip the "+4" and try to match on just on the ZIP.
>> 3) Even better, try to match on ZIP+3, or ZIP+2.
>>
>> Regarding #1:  Since all potential ZIP codes (WA state-only) are in
>> the database, this should be possible.  I'm not aware of a flag/config
>> item that forces a check.  For other states, don't care because I'm
>> not (yet) required to charge local sales tax.
>>
>> As it stands, a clever user could try to fake out ofbiz by entering a
>> bogus ZIP+4, is ONLY charged state sales tax (no local tax), and let
>> the post office sort out or "fix" the ZIP+4, which they would.
>>
>> Back to the subject:  I'm probably going to try to fix this, and
>> probably the best way is to hack:
>>
>>
>> applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>>
>> Is there a way that I could leave the orignal
>> TaxAuthorityServices.java in it's place, and place a modified version
>> in hot-deploy?  Can this be done for just a single java file?  What
>> would be the directory structure for this?
>>
>> Thanks
>>
>

[BJ Freeman]

this is some what dated but gets you going
http://svn.apache.org/repos/asf/ofbiz/site/docs/services.html#ECAs
plus look at
framework\service\dtd\service-eca.xsd
for current implementation.
do a search for <eca service
to see how it had been implemented.

=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Mike Z sent the following on 9/17/2010 7:58 PM:

> Thanks BJ.  I was thinking that I probably need to force WA state
> customers to enter ZIP+4, and perform a DB lookup.  I'll have to
> figure out how to do an ECA.
>
> On Fri, Sep 17, 2010 at 7:00 PM, BJ Freeman<[hidden email]>  wrote:
>> I would suggest a ECA this allows others to not be effected by your changes
>> like VAT.
>> the ECA can check the Locale to see if it needs to run.
>> since not all countries use zip.
>>
>> Mike Z sent the following on 9/17/2010 3:51 PM:
>>
>>> I found an odd behavior with the tax handling in ofbiz.  If you need
>>> to charge local sales tax based on ZIP-4 (like in WA state), I found
>>> the following:
>>>
>>> 1) User enters exact ZIP-4 zip code (which is in ofbiz), local sales
>>> tax is charged correctly.
>>> 2) User just enters ZIP (which is in ofbiz), local sales tax is
>>> charged correctly.
>>> 3) User enters ZIP-4, but "4" is incorrect/typo, local sales tax is
>>> *NOT* calculated.
>>>
>>> I would like ofbiz to do one of the following:
>>>
>>> 1) Reject the bad ZIP-4 code and ask the user to re-enter.
>>> 2) Strip the "+4" and try to match on just on the ZIP.
>>> 3) Even better, try to match on ZIP+3, or ZIP+2.
>>>
>>> Regarding #1:  Since all potential ZIP codes (WA state-only) are in
>>> the database, this should be possible.  I'm not aware of a flag/config
>>> item that forces a check.  For other states, don't care because I'm
>>> not (yet) required to charge local sales tax.
>>>
>>> As it stands, a clever user could try to fake out ofbiz by entering a
>>> bogus ZIP+4, is ONLY charged state sales tax (no local tax), and let
>>> the post office sort out or "fix" the ZIP+4, which they would.
>>>
>>> Back to the subject:  I'm probably going to try to fix this, and
>>> probably the best way is to hack:
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>>>
>>> Is there a way that I could leave the orignal
>>> TaxAuthorityServices.java in it's place, and place a modified version
>>> in hot-deploy?  Can this be done for just a single java file?  What
>>> would be the directory structure for this?
>>>
>>> Thanks
>>>
>>
>

[Scott Gray-2]

You can also just create a create a new calcTax (I think it's called) service definition that invokes a custom implementation.
Or you could reject invalid zip codes when the shipping address is created.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 18/09/2010, at 2:58 PM, Mike Z wrote:

> Thanks BJ.  I was thinking that I probably need to force WA state
> customers to enter ZIP+4, and perform a DB lookup.  I'll have to
> figure out how to do an ECA.
>
> On Fri, Sep 17, 2010 at 7:00 PM, BJ Freeman <[hidden email]> wrote:
>> I would suggest a ECA this allows others to not be effected by your changes
>> like VAT.
>> the ECA can check the Locale to see if it needs to run.
>> since not all countries use zip.
>>
>> Mike Z sent the following on 9/17/2010 3:51 PM:
>>
>>> I found an odd behavior with the tax handling in ofbiz.  If you need
>>> to charge local sales tax based on ZIP-4 (like in WA state), I found
>>> the following:
>>>
>>> 1) User enters exact ZIP-4 zip code (which is in ofbiz), local sales
>>> tax is charged correctly.
>>> 2) User just enters ZIP (which is in ofbiz), local sales tax is
>>> charged correctly.
>>> 3) User enters ZIP-4, but "4" is incorrect/typo, local sales tax is
>>> *NOT* calculated.
>>>
>>> I would like ofbiz to do one of the following:
>>>
>>> 1) Reject the bad ZIP-4 code and ask the user to re-enter.
>>> 2) Strip the "+4" and try to match on just on the ZIP.
>>> 3) Even better, try to match on ZIP+3, or ZIP+2.
>>>
>>> Regarding #1:  Since all potential ZIP codes (WA state-only) are in
>>> the database, this should be possible.  I'm not aware of a flag/config
>>> item that forces a check.  For other states, don't care because I'm
>>> not (yet) required to charge local sales tax.
>>>
>>> As it stands, a clever user could try to fake out ofbiz by entering a
>>> bogus ZIP+4, is ONLY charged state sales tax (no local tax), and let
>>> the post office sort out or "fix" the ZIP+4, which they would.
>>>
>>> Back to the subject:  I'm probably going to try to fix this, and
>>> probably the best way is to hack:
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>>>
>>> Is there a way that I could leave the orignal
>>> TaxAuthorityServices.java in it's place, and place a modified version
>>> in hot-deploy?  Can this be done for just a single java file?  What
>>> would be the directory structure for this?
>>>
>>> Thanks
>>>
>>