Akopia Akopia Services

[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date ][Minivend by thread ]

[mv] TaxShipping directive using zip codes in NYS



******    message to minivend-users from Ben Goldstein <bdg@endpointsecure.com>     ******

We are only charging sales tax for shipments within New York State.
New York State requires that sales tax be applied to shipping charges
as well.

I'm having difficulty getting MiniVend to properly Tax Shipping.  The
TaxShipping directive doesn't seem to work exactly as
documented...well, at least according to the way I'd LIKE to read it!

In New York State sales taxes vary by locality, hence our
"salestax.asc" file lists a large number of zip codes and the
sales tax rate that applies for that zip. We have 4518 lines
in the salestax.asc, all but the last two entries are zips. Hence,
a tail on the file looks like this:

14994   .0700
14995   .0700
14996   .0700
14997   .0700
14998   .0700
14999   .0700
14903   .0700
18847   .0800
NY      .0700
default 0

Concerning the above tail on the salestax.asc file: I've also tried
it without the "NY" and "default" entries, but it has made no difference.

Below are the directives from our catalog.cfg file that I believe
are (or should be) pertinent:

# szip is the shipto zip
# -- I've also tried just using "SalesTax    state" with no success
SalesTax        szip,state
TaxShipping          NY

I also have two other variables defined that I don't think have any
impact, but I've included them just because they were there in the
sample file and they say have "TAX" in them:

Variable    TAXAREA         NY
Variable    TAXRATE         NY=7.0

(Any insights as to whether these last two variables have any use would
be appreciated.)

==================================================
Ok, to get to the point:

I've at last been able to get MiniVend to charge Tax in New York State
on the shipping by altering the TaxShipping directive to include all
the zip codes in the salestax.asc file!

Hence, the directive now is VERY LARGE. Truncating it and adding an
ellipsis, it now looks like this:

TaxShipping          05743,06390,06830,10000,10001,...

(The file of zip codes that I've put into the catalog.cfg file is 27198
bytes.)

If this is just the right way to do it, then so be it.

It appears that Minivend reads the salestax.asc file, finds the first
entry matching the value of any of the values assigned to the SalesTax
directive, then it checks the values assigned to the TaxShipping
directive to see if any of them correspond the entry matched on the
salestax.asc file. This is sensible enough behavior, but not so
elegant as I'd like, and rather worrisome to me because of the large
size of the TaxShipping directive. I'm worried about the reliability
and performance implications.

In fact, since adding this directive to the catalog on a test server
running on the same machine as our production server it seems like
responses all around are bit erratic, i.e., sometimes a request goes
unanswered, while sometimes a request goes quickly as requests to the
server usually do...but this may be just an unrelated network problem.

I'd very much appreciate it if anyone would enlighten me as to a
better way of doing things and/or if anyone would let me know whether
or not I should in fact be concerned about using such an immense
directive in my catalog file to get the job done.

Incidentally, we are using MiniVend V3.14-5, Perl 5.005_03,
MySQL 3.22.27 and Linux Mandrake release 6.1.

Thanks much for any help!!
Ben Goldstein


-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list


Search for: Match: Format: Sort by: