City Tax Rate Hack for MS1 bug fix

This message was sent from: Features
http://forums.oscommerce.com/viewtopic.php?p=190297#190297
----------------------------------------------------------------

OK. I think I've found a solution for the bug I mentioned earlier in the "City Tax Rate Hack" contribution. I'm still working on it and testing it, but it seems as if it will do the trick.

I've made some changes to the tax functions in general.php and also to the references to them in classes/order.php. Since it seemed to me that a database query from within the functions was never going to work (since there's no way to know which address is this order's shipping address from within the function), I added the order's city and zone to the function calls in classes/order.php. The new lines look like this (additions/changes in red):

$products = $cart->get_products();
      for ($i=0, $n=sizeof($products); $i<$n; $i++) {
        $this->products[$index] = array('qty' => $products[$i]['quantity'],
                                        'name' => $products[$i]['name'],
                                        'model' => $products[$i]['model'],
                                        'tax' => tep_get_tax_rate($products[$i]['tax_class_id'], $tax_address['entry_country_id'], $tax_address['entry_zone_id'][color=red], strtoupper($shipping_address['entry_city']), $shipping_address['entry_zone_id'][/color]),
                                        'tax_description' => tep_get_tax_description($products[$i]['tax_class_id'], $tax_address['entry_country_id'], $tax_address['entry_zone_id'][color=red], strtoupper($shipping_address['entry_city']), $shipping_address['entry_zone_id'][/color]),
                                        'price' => $products[$i]['price'],
                                        'final_price' => $products[$i]['price'] + $cart->attributes_price($products[$i]['id']),
                                        'weight' => $products[$i]['weight'],
                                        'id' => $products[$i]['id']);

And then I added the order's shipping city and zone to the two (previously modified) tax functions in general.php and used those variables instead of the malfunctioning database calls:

function tep_get_tax_rate($class_id, $country_id = -1, $zone_id = -1[color=red], $shipping_city = '', $shipping_zone = ''[/color]) {
    global $customer_zone_id, $customer_country_id, $customer_id;

     if (([color=red]$shipping_city[/color] == 'SAN FRANCISCO') && ([color=red]$shipping_zone [/color]== 12)) {
          return 8.5000; // Input your custom tax rate here
     }

(function continues unchanged...)

and

  function tep_get_tax_description($class_id, $country_id, $zone_id[color=red], $shipping_city = '', $shipping_zone = ''[/color]) {
    global $customer_id;

    $tax_query = tep_db_query("select tax_description from " . TABLE_TAX_RATES . " tr left join " . TABLE_ZONES_TO_GEO_ZONES . " za ON tr.tax_zone_id = za.geo_zone_id left join " . TABLE_GEO_ZONES . " tz ON tz.geo_zone_id = tr.tax_zone_id WHERE (za.zone_country_id IS NULL OR za.zone_country_id = '0' OR za.zone_country_id = '" . $country_id . "') AND (za.zone_id IS NULL OR za.zone_id = '0' OR za.zone_id = '" . $zone_id . "') AND tr.tax_class_id = '" . $class_id . "' order by tr.tax_priority");

     if (([color=red]$shipping_city[/color] == 'SAN FRANCISCO') && ([color=red]$shipping_zone[/color] == 12)) {
          return 'San Francisco and California sales tax'; // Input your custom tax description here

(function continues unchanged...)

This is working for me so far, but I just did it so I guess we'll see if it stands up to testing.

Note: I did NOT change any other references throughout the program to these functions, so they may not work correctly in other places. Specifically, if you are showing products' prices with tax already included, you may have problems. Of course, you couldn't possibly calculate the correct tax rate at the shipping address before a customer has created an account and logged in anyway, so I guess that makes sense.

I believe that the way I've altered these functions will not break them in other instances where they would be called without the order's shipping city and zone, so I think the worst that would happen is it would calculate tax incorrectly until checkout.

Anyone see any obvious problems with this? Assuming it doesn't blow up on me in the next ten seconds, it seems as if it would be pretty easy to turn this into a useful contribution. The proper way to do it, I think, would be to have a new table in the database with cities, zones, and tax rates in it that could be modified from the Admin tool and then just loop through them in these functions.