Need bid for adding sales tax rate and taxing district to BasketCharges table

[wajake41]

We are looking to integrate our checkout OSEL page with the
Washington State sales tax API. We will call the API when OSEL is rendered, This will
give us the location code for the taxing district, and the sales tax rate.
We will be passing these two values as hidden fields on the OSEL form.

Looking for a developer to do the following:
We would like to have the sales tax amount calculated using the tax rate received from our API call (from hidden OSEL form field).Plus, we would like to have these 2 values (tax rate and taxing district) included in the description column of the BasketCharges table during OSEL page processing. The format would be “WA Sales Tax: x.xx%^0605”. The existing sales tax row in the BasketCharges table is to be used.
Please contact me offline if interested in helping us with this.
Thanks, Larry

[Kent Multer]

Re: Need bid for adding sales tax rate and taxing district to BasketCharges table

Hi Larry --

I've written API-based tax modules for a few other clients. I can do one for you as well. Please drop me a line by email to discuss the project in detail.

Thanks --

[wajake41]

Re: Need bid for adding sales tax rate and taxing district to BasketCharges table

Kent Multer took on the job of creating our sales tax calculation module and this is really going to be kool!
Our OSEL page, on rendition, uses toolkit's callURL function and the ship to address to access and retrieve the correct tax rate for the customer's (only for WA sales) delivery location using the state's tax rate API. The page then puts that rate into a hidden field in the OSEL form.
When OSEL is submitted, Kent's module will use that rate (if it's present, otherwise the Miva admin rate will be used) to calculate the correct sales tax amount and places it in the BasketCharges TAX row amount column and puts the percentage into the column carrying the literal: "Sales Tax" followed by the tax percentage.

No need for us to now adjust sales tax charges when the customer is invoiced, Hooray!!

Kent's module is generic and can be used in any store in any state if the state has an API that can provide the customer's sales tax rate to OSEL.

IMHO Everybody who resides in a sales tax state where the ship to sales tax rate can be determined, should consider adding this feature to their store. Actually this should be a standard Miva feature.


Update
We are now live with Kent's module.
Thanks Kent!

Cheers, Larry

[wajake41]

Has Miva added the ability to dynamically assign sales tax rates to the latest release yet? If present, this dynamic rate would override the admin sales tax default rate.

[Rick Wilson]

I'm not sure what you mean? I can tell you, off hand that doesn't sound like something even on our plans, since I don't have any Sales Tax related items on the roadmap. Can you explain what you want and why?

[Bruce - PhosphorMedia]

I'm going to bet that every state, if they provide a rate via an API, is going to have a different format and structure of the call and returned data. For most store owners, they only need one rate for one state, so its not a huge deal to enter that as State based sales tax. As for being dynamic, again, most states don't change their rates very often (esp. cause like in WA it takes a 2/3rd majority to pass an increases, and we know how that goes.)

[William Davis]

I think that is a service provided by companies like Avalara.com. Some states have different sales tax rate for each county plus a state sales tax. Which makes it a nightmare for small merchants, that's where companies like this come in.

[wajake41]

Hi William: Actually in Washington state we have more than 100 different sales taxing districts and we are expected to charge the correct tax rate for products shipped to each of these. We receive an updated iif file for Quickbooks from the state every quarter (BTW our latest quarterly iif file contained more than 20 tax rate changes statewide). Our state's sales tax is comprised of a base state rate plus local taxing rates such as school bond taxes, city taxes, etc. So rate changes are quite common.

Working with Kent Multer, who I mentioned above, we created quite a simple solution to calculate the correct Washington sales tax for Washington sales on our sites. Kent wrote a module that retrieves the correct tax rate from a field in the OSEL page for in state sales. He uses this to calculate and update the correct sales tax charge in the BasketCharges table for the basket/order.
Using the Toolkit callURL during render of the OSEL page to call the state sales tax rate API, we retrieve the correct tax rate for the ship to destination using street, city and ZIP Code. The result of the callURL places the correct sales tax rate into the field that Kent's module requires.

Doing this has saved us a lot of work and hassle; avoiding manually calculating and updating QB with the correct sales tax amount for our customer's invoices, explanations to customers as to why the sales tax rate shown on their order is incorrect for their location, and explaining that they need to pay an additional amount because their locations tax rate is greater than the Miva admin default tax rate.
I'm surprised that no one else has seen a need for this!

[wajake41]

Bruce, we found that we could do this with a call to the state sales tax API using Toolkit's callURL function. I agree that this is something that would have to be done in the OSEL template by each merchant but in our case was not difficult. A lot easier that using the state's web page to get the correct rate and then updating the order in QuickBooks for every in state sale. Plus eliminating explanations to our customers about why the sales tax they were charged was incorrect.
Works great for us! Thanks again Kent!!

[William Davis]

Very interesting, will definitely look into it after we get acclimated from the launch of our new M9 store sometime this month, I hope.

Was the module expensive?

[wajake41]

Hello William:
You'd have to contact Kent to see what the cost of his module is. We found it very reasonable.
Installing Kent's module creates an entry in admin under logging where we can set some parameters for the module (on/off, etc.) as well as defining the variable name to be used in OSEL.

As far as the callURL part in OSEL that retrieves the rate, probably less than an hour of coding on our part to use the WA state API. This assumes that you have Toolkit and are familiar with the callURL function.

We highly recommend it! Plus we are incompliance with our state's laws regarding sales tax collection.

[wajake41]

Rick:
The part of this that I thought Miva might provide is the part that Kent did for us. That is; to allow an override of the admin sales tax rate if a sales tax rate is provided within the OSEL page input when tax amount is calculated. That is essentially what Kent did for us. Use our OSEL sales tax rate if present, else use the admin sales tax rate.
The merchant would have to obtain the rate to be used, that part wouldn't be required of Miva.

[Brennan]

While typically having a module built is the best approach to functionality like this, it is possible to achieve what your looking for via template code. This is probably not functionality we would ever build in because of that. And like previously mentioned, 3rd party services such as Avalara do a really good job in this area.

Here is some sample code for anyone who wanted to try this themselves.

1. Remove any previous tax charges

<mvt:do file="g.Module_Library_DB" name="l.ok" value="BasketCharge_Delete_All_Type( g.Basket:basket_id, 'TAX' )" />

2. Read in Custom Fields, Calculate Tax Rate - This would involve looping though the basket items, reading in the custom field for the tax rate and individually calculating sales tax for each product then adding all the individual sales tax calculations for each product up into a single rate

3. Finally, add the new tax rate to the basket

<mvt:assign name="l.basket_charge:basket_id"     value="g.Basket:basket_id" />
        <mvt:assign name="l.basket_charge:type"         value="'TAX'" />
        <mvt:assign name="l.basket_charge:descrip"         value="'Custom Description'" />
        <mvt:assign name="l.basket_charge:amount"         value="g.final_tax_calulation" />
        <mvt:assign name="l.basket_charge:disp_amt"     value="g.final_tax_calulation" />
        <mvt:assign name="l.basket_charge:tax_exempt"     value="0" />

        <mvt:do file="g.Module_Library_DB" name="l.ok" value="BasketCharge_Insert( l.basket_charge )" />

[wajake41]

Brennan: This is really powerful! I had no idea I could do MYSQL calls from templates.
Please direct me to documentation on this.

[wajake41]

Hello forum: Can anyone direct me to the documentation for the "g.Module_Library_DB"?
Thanks, Larry: