Specific Programming Question Regarding US Taxes (example: Zip+4 or City/State/etc.)

I'm not sure if this is the right place to ask this, but it's a general programming question and I'm sure quite a few of you that develop Enterprise applications have come across this before. The company I work for is currently using the "standard" model for gathering taxes for orders: city / state / zip (we could include County).

I've looked at several sites and they offer开发者_运维知识库 several different tax packages, which is great. However, the only one that seems to fit our requirement is Zip+4. We probably need this b/c some cities in Texas will have like 6 tax "districts", some of which overlap. So Zip+4 would be ideal, but after looking at the data, Texas alone has close to 300mb (multiplying this by 50 would make querying terrible in our database).

Unfortunately we cannot use web services for single calls and we cannot set up a SQL server (or any other) database. Our one system is a relatively obscure database+dev environment. So if, for any reason, our SQL server database or the web service went down, we can't process orders.

Has anyone else ran into something like this? Massive databases dedicated to just taxes seems like a ridiculous idea, but unfortunately I can't use web services.

Does anyone have any ideas? I'm really stuck on this one...

Thanks in advance!!!

Calculating taxes is non trivial for various reasons. You've already mentioned tax districts. Other reasons include:

1. Product-specific taxes. For example, New Jersey used to not tax clothing
2. Tax holiday weekends. Very common just before start of school, for example
3. Deductions driven by policy. Like deductions for high efficiency appliances

So it really would be a good idea to buy a package and integrate with it. And buy a maintenance license so you get the metadata updates annually or whatever.

But from a programming point of view, you can use a tree-like structure for computing taxes. Here's how I would set it up.

First, define some constructs like this:

public class AddedTaxes {
  public void add(double amount, double description) { ... }
}

public interface TaxAdder extends Serializable {
  void configure(Map<String, String> settings);
  add(double preTax, AddedTaxes taxes, Object productDetails);
}

Second, build up the necessary set of adders:

public class FixedRate implements TaxAdder {
  private double _rate;
  private String _description;
  public void configure(Map<String, String> settings) {
    _rate = Double.parseDouble(settings.get("rate%")) / 100.0;
    _description = settings.get("desc");
  }
  public add(double preTax, AddedTaxes taxes, Object productDetails) {
    taxes.add(preTax * _rate, _description);
  }
}

public class FixedProductSpecific implements TaxAdder {
  private double _amount;
  private String _product;
  private String _description;
  public void configure(Map<String, String> settings) {
    _amount = Double.parseDouble(settings.get("amount"));
    _product = settings.get("product");
    _description = settings.get("desc");
  }
  public add(double preTax, AddedTaxes taxes, Object productDetails) {
    if (_product.equals(productDetails)) {
      taxes.add(_amount, _description);
    }
  }
}

Third, I would capture the tax rules in one or more human consumable files:

// zip code range <tab> adderClassName <tab> parameters
// general texas taxes
75000.0000-79999.9999     FixedRate       rate%=8.25, desc=Sales tax
78700.0000-78999.9999     FixedProductSpecific  amount=2.00  product=LeadAcidBattery  desc=Lead acid battery sales
...

Will this data, you can go through a 'compile' step for your data, where you build a 10-way tree, for example. At each node (not just leaf), I would have a list of TaxAdders. In this case, the 7/5, 7/6, '7/7', ... would have the first adder, while only the 7/8/7, 7/8/8 and 7/8/9 nodes would have the second adder.

Once the full structure is assembled, serialize it out. Now your compilation is complete. At runtime, you would simply load the serialized computation structure, and for any given zip+4, traverse the tree to find every (possibly) applicable calculator can be found.

If you don't want to maintain the data, you can still undergo the kind of transform I am talking about, and build a 'compiled' computation structure.

I can add more detail if you like, but I'm holding off on that until I know this is going in a direction that interests you.