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
