Kanasas changed data source and module needs to change to use it

Thanks for this report. At the time the module was created, that was the correct site -- Kansas did not have their own site and they had contracted with taxwatch.biz to get tax data for businesses in Kansas needing to charge sales tax.

So, someone will need to figure out the new state lookup, and fix the code to use it. I'm assuming that just changing the URL in the code will not work.

And I'm sorry, but given that there are only 4 sites using this module, it is not my highest priority right now... Do you have the time/ability to take this on and make a patch? Meanwhile, I'll update the module's home page so it explains the situation.

The destination-based sales tax is expanding across the country. Moving to another state will likely only give your client a temporary reprieve, and besides most states will require you to charge sales tax in any state where your company has an office of any sort.

Anyway, regarding this module, all that probably has to be done is to figure out what the format needs to be to send the address information to the new URL, and how to parse the information that comes back. It shouldn't be too difficult... I guess I should change the status of this module to "not maintained" in the meantime.

Try this:

1)- Go: http://www.apigenerator.com/ and generate the class for the following SOAP WDSL URL:
http://jade.kgs.ku.edu/sstp/JurisdictionLookup.asmx?wsdl

2)- Then paste the class code into your module (or include it).

3)- Modify module code to do the following:

Comment out this

  $res = drupal_http_request($url, $headers, 'POST', $data);
  //  print_r($res);

  $ok = $res->code == 200 &&
    preg_match('|<intReturnCode[^>]+>0</intReturnCode>|', $res->data);

Add this:

	$tax_obj = new kansastax();
	$tt = $tax_obj->GetFIPSByAddress2($address, $city, $zip5, $zip4, date('Y-m-d'));
	$ok = FALSE;
	if ($tt->intReturnCode == 0) {
		$ok = TRUE;
	}

Then, inside if ($ok) {

Use this:

    foreach($tt->FIPSRecordList as $value) {
    	$tmprate = floatval($value->strGeneralTaxRateIntrastate) * 0.01;
    	$sumrate += $tmprate;
    	$loccode = $value->strCompositeSER;
    }

Replacing your original parsing foreach.

Forgot to attach my modified file. It's not cleaned-up but it works.

Thanks! If someone else wants to test this and verify that it works, I can add it to the module.

Module works great! thanks for your support. Cool staff apigenerator, bookmarked!

Hum... what am I missing? It didn't do anything for me :( If I put a default rate, I get that rate, but it isn't pulling any rates from anywhere that I can see, using the patch above...

On a side note, I'm considering having someone re-work this module to pull the rates from: https://www.kssst.kdor.ks.gov/weblookup.cfm as opposed to: http://jade.kgs.ku.edu/sstp/JurisdictionLookup.asmx which I don't know enough about this stuff to know why it's pulling from http://jade.kgs.ku.edu/sstp/JurisdictionLookup.asmx as opposed to https://www.kssst.kdor.ks.gov/weblookup.cfm, but anywho, the other thing I'm thinking about is having the rates put into the database where it can be cached. On a cron run, it will check against the database and update the database automatically if there is a change in the rate, speeding up the whole tax process not to mention I don't trust state run websites to be running 100% of the time...

Thoughts? Also, would anyone be willing to contribute financially?

Regarding default rates, that is what the 6.x-1.1 version of the module would do, since it is referencing a lookup site that doesn't exist.

Regarding which lookup site to use and caching rates in the database... I have no idea...

I really would like someone to completely take over this module as maintainer -- anyone willing?

@philsward:

The version i uploaded pulls the rates from a webservice published by https://www.kssst.kdor.ks.gov via SOAP call.

In fact, the method we're calling from this soap service is the same method that this module's author used to call. It's just a different url and the soap call is encapsulated into a class in my version.

A soap call is more reliable from my perspective than filling a form and parse results, since it not depends on parsed page formatting or form changes.

About caching the results, that would be great but i dont have a clue about Kansas Taxes and how's supposed to work (I live in Argentina). I think it's useless to cache every address lookup. I dont know if Kansas rates depends on street address with number, street address alone or county.

I totally agree about not to rely on an external website, but we have to know Kansas Taxes deeply to implement any cache strategy.

@jhodgdon:

I could set some time to make this patch as a final version, but i have 2 problems:
1)- As i said, i dont have a clue about Kansas Tax :) Just made this work to fix a website.
2)- This is my first upload to drupal.org, i dont know how the process of maintaining a module works.

If you like, i can clean up this code to restore your module's original functionality working (wich i did on the previous attachment, but it was a quick n' dirty fix) and upload here for you to review and attach to the project's page.

I can add cache if someone tells me how Kansas tax rates are calculated (What conditions depends on)

RE #11 - there is documentation on how to maintain a module if you are interested in taking it over... Definitely a cleaned up patch would be good. :)

I don't really think caching is a good option. The rates depend on an address lookup.

Attached is the zip file containing your entire module with my modifications. I think it works like your original module is supposed to do.

You can run a diff on the .module file to see the changes.

Just tested, Please review and add it to project page if you like.

Thanks, I'll check it out when I can make the time.

Kansas taxes are handled from three levels: State -> County -> City
With that being said, there are certain entities that can also have their own separate tax (Ex. Hotel is issued bond for improvements, that hotel can charge a separate tax...)

From what I can tell, "most" cities do not have a tax imposed, they just go off of the county tax, however the city is allowed to charge their own tax.

Sales Taxand Compensating UseTax: Pub. KS-1510 (Rev. 1/11)
Sales & Use Tax Jurisdiction Code Booklet : Pub. KS-1700 (Rev. 7/11)

Excerpt from: Sales Taxand Compensating UseTax
In addition to the 6.3% state sales tax, counties and cities in Kansas have had the option of imposing a local sales tax since 1978. Before imposing a local sales tax, the governing body of the city or county must receive the approval of a majority of its voters. Cities may levy a local sales tax in five-hundredth percent increments (0.05%). Counties may levy a local sales tax in onefourth percent increments (0.25%, 0.50%, etc.). Cities are authorized to impose a maximum sales tax rate of 3 % (2% general and 1% special). Counties are authorized to impose a maximum 1% general sales tax rate. Legislative action is required for more than 1%.

----

With all of the above being said, the caching thing will work just fine if the zip code lookup is exclusively used. I don't know how that will work though if one zipcode covers two cities and one of the cities has a tax but the other doesn't. I have no idea how the state government deals with that, which is why the address lookup is the more granular choice but would make caching a bit of a nightmare...

----

I also have no idea why exactly I posted all the info above, but there it is. I look forward to testing your patch seaarg and I will report back on my results :)

Thanks -- looking forward to your testing results. Setting this back to "needs review" until someone other than seaarg (the author) tests the attachment in #13. Normally you don't set your own work to "reviewed and tested". :)

I changed status due comment #8 but you're right :)

However i think #15 is waiting for a .patch file. @philsward, just download zip from #13 and test that.

Hum... I just tried the #13 attachment and still can't get it to pull a Kansas tax... What would be a good way to enable debugging? I can use firebug, but don't really know how to make heads or tails out of it to know how to help...

Is there any reason to have a conditional action setup for it to work? I noticed in the code it does a check to see if the state is KS, so I would assume not...

---

On a side note, I would love to see function uc_tax_ks_menu() { changed to:

function uc_tax_ks_menu() {
  $items = array();

  $items['admin/store/settings/taxes/uc_tax_ks'] = array(
    'access arguments' => array('configure taxes'),
    'title' => 'Kansas sales tax settings',
    'description' => 'Settings for Kansas sales tax',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('uc_tax_ks_admin_settings'),
    'weight' => 5,
    'type' => MENU_LOCAL_TASK,
  );

  return $items;
}

Ideally, it would be better suited within the actual Tax rates and settings as a configured tax as opposed to it's own separate menu... no idea how to do that though :( Wish I could program...

Firebug debugging: I am not sure with the SOAP stuff.

The way the module used to be set up, you could do some debugging by going to the "Net" tab, finding the place where it makes the REST request, and looking at the headers and response to see what is sent/received.

But you will need to confer with seaarg on how to debug the new module. I haven't even looked at it yet.

Meanwhile, setting to "needs work" because it is apparently not working...

#18 @philsward,

It works flawlessly on your own site. First i tried with the "Northwest Kansas Technical College" Address, it give me your default 1%

Then i used "Wichita State University" address like this:

Street Address: 1845 Fairmount St.
City: Wichita
Postal Code: 67260

And obtained this:
Order total preview:
Subtotal: $2,278.00
2 Free: $0.00
Subtotal excluding taxes: $2,278.00
Kansas Sales Tax (SEDCO): $166.29
Order total: $2,444.29

I hope that helps you.

@jhodgdon,

There's no more i can do. The new url works and uses the very same method you used originally, in fact, your original module make a soap call too, but in another way and to another webservice url. (Altough now it's the same webservice just in another server)

This doesnt needs work to me, perhaps for some addresses webservice returns something and for others dont, i have no way to know that from here. Try the philsward's demo site or look at the code and you'll see it for yourself :)

I cannot provide you guys the url where i implemented it due client's privacy, i hope you understand that.

Yeah, I think that site is working. I used this address and got a sales tax rate that wasn't the default (see screen shot).

1500 Kansas Ave, Great Bend, KS 67530
(this is just some random but valid address I got from Google Maps).

I still need to review the code, and add it to the module. Thanks seaarg!

You're right, it is working. I was using my own personal address for testing and because I can interchange the city on account of the mail system, I was putting Wichita instead of the actual city where I live which apparently makes a difference for the way it polls the taxes. Sorry bout that... Why I didn't use an alternate address just to test is beyond me, I just figured mine would work.

I'll implement it on my main site, test it and make sure it looks good before writing it off as "fully tested and working". I'll get back to you once that's done. Thx again : )

Alright, got it going on my main site and as far as I'm concerned, it works :) Seems like the address look-up is extremely picky though which I realize is on the soap site, not the module...

Quick question, is there a way to set a timeout if it can't find the address? As it is, I want to say it sits for ~20 seconds before loading the default tax. If it can successfully look it up, I would say it's showing up within ~5 seconds. My fear is that people will go off clicking on stuff if the taxes don't quote within 10 seconds or so.

Thoughts?

@jhodgdon,

np Jen, i hope it helps. Thank you for this module. (Now i readed the status values link from the issue queue handbook ;) )

@philsward,

You can go to line 331 of my upload and you'll find:
$this->client = new SoapClient($this->soapUrl, $this->options);

Just before that line, add:
ini_set('default_socket_timeout', 10);

Where 10 is the timeout in seconds. You can try that.

Also, on line 321 there's:

var $options = array();

You can try replacing with this:

array('compression' => SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP);

Didnt try this myself but perhaps it helps.

when trying to add the options, I run into this similar error:

http://stackoverflow.com/questions/5672549/soap-compression-options-retu...

Looking at the PHP info on it, it looks like it "should" accept the | symbol, but for some reason isn't.

http://www.php.net/manual/en/soapclient.soapclient.php

----

Also, when setting the: ini_set('default_socket_timeout', 10);
I ran into the issue where it would keep the tax from showing up at all. Instead of "10 seconds" being the time given to do a lookup on the remote host and defaulting to the value set on the server, it was taking that 10 seconds and going ok, the remote host is taking too long so I give up altogether. Meaning, it wouldn't show any tax.

I'm not posting this to have you look into it, just getting the info out there. I will have someone look into it and get it fixed when the season begins to pick up.

SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP

This expression is a logic bitwise OR

you can echo both constants and make your own OR that will give you a single numeric result. You can then replace the expression with that number.

Unfortunately, "PHP Code = Greek" to me... I don't and can't code... I'm one of those folks who looks at it and if it works, great, if not I wait for an update or have someone update it for me.

In this case, you've done quite enough and I understand your situation that you don't directly support this module which is fine. I have someone who is looking into a slow performance issue with this module and I will post his fixes on here once they are completed. Thx for your fixes on getting it working to this point : )

As promised, attached is an updated version of the module, along with @seaarg's work and the initial build. In this build, some caching is done to make the tax lookup respond faster.

And, another updated version. (I wasn't expecting this update, otherwise I would have waited and not posted the previous version)

Posted from the developer making the changes:

I'm sending you an improved version, it should work the same way as the previous one, but I like this one better. Besides adding the cache, I made a few improvements in the module that I have not mentioned yet:

- When the tax server successfully returns the tax information, the result is stored in the Drupal cache, and the information is kept for a week.
- Fixed: infinite loop if "tax line" taxed, http://drupal.org/node/1203150
- Better error handling: errors are logged in the Drupal log, instead of printing out to the customer
- The module variables are deleted when the module is uninstalled

>Out of curiosity... what exactly get's cached and where is it stored? Is the taxed amount on an order stored? Or just the county code and tax rate for a particular address?

Short answer: the server response is stored in the Drupal cache, and yes, the taxed amount on an order is stored.

Long answer: the module sends a request to the tax server. It receives the information as an object that contains whether the request was successful, and it contains the various tax rates for the state and cities. This object is stored in the cache.
When the order is submitted, the "tax line item" is set to the value that this module calculates, and when the order is saved, this tax line item is saved as well. This means that when you view the order at some later point, the stored "tax line item" is displayed, so the tax is not calculated at this time.

Update: I do not think that Kansas has a viable lookup service at this time at all. Maybe the version in the zip files above works, and maybe it doesn't. But ... I've marked the previous release as "not supported".

If someone would like to take over maintaining this module, please do! But I have given up. Sorry.

Here's a 7.x version that I am using on a live site.

I "believe" it's pulling the data from: http://netservices.taxwatch.biz/wsdl.php?wsdl (I didn't program it)

taxwatch.biz appears to be a subscription-based service. Their web site only mentions Louisiana and has minimal information about costs, but if it's working for you, good. Probably it would make sense to start a new project called "Ubercart TaxWatch integration" or something like that, and put this module there.

Hi Philsward,

I have installed the module and am getting the following error...

Notice: Undefined index: product in uc_tax_ks_uc_calculate_tax() (line 139 of /home/mercato7/public_html/sites/all/modules/uc_tax_ks/uc_tax_ks.module)

Could you please help with this..?

Thank you!
Jaya