Most of our clients face a uniform set of sales tax rates (i.e., one rate for parts and another for labor, regardless of locale) across their entire territory. This makes for nice simplicity, as typically the worst complication is having to deal with an occasional tax-exempt sale (see note 121 at page 167). However, we’ve had some clients who face the ugly dilemma of different tax rates in each of the various communities they service, and sometimes different rates for different kinds of customers too. This technical section contains information on how that kind of dilemma should be addressed from within ServiceDesk (if yours is not such a situation, obviously, this section may be ignored).
To start with, let us review the standard situation, where rates are uniform throughout a user’s territory. In that instance, it would be your job to first specify the applicable rates (for parts and labor) from within the Settings form. In consequence of this specification, the system would perform a verifying calculus each time a completed sale was entered from the SalesEnter form. Specifically, each time you entered the string of numbers that indicates constituents in the sale and total, it would do its own calculation to verify that, with appropriate tax amounts added (as inferred on the basis of rates indicated in the Settings form), the entered total reflected the proper summed amount. If the numbers did not balance, of course, the system would notify of the discrepancy and request correction.
So what can be done for the user that faces many different rates, depending on locale where the service was done? If, as is allowed by the Settings form, just one rate set were specified by this kind of client (i.e., one for parts and another for labor), the SalesEnter system would obviously not allow any sales to be reported—much less recorded—at any different rate. A real problem. Obviously, in solution we could create a more expansive mode for specifying tax rates (more expansive, in other words, than is currently offered in the Settings form)—perhaps a table, for example, that would allow you an unlimited number of rows where zip codes could be listed in the first column, and applicable parts and labor tax rates (for each zip area) in the second and third columns. However, and as mentioned, some of these same clients have faced rates that vary depending on type of customer, too. Setting up, additionally, with specifications for that would require a three-dimensional table, and who knows what kind of flexibility for other clients facing still different divergent tax needs. After all was considered, we thought it best to keep the specification system simple for the ordinary ServiceDesk user that faces just a single tax structure, and make separate allowance for the user with special needs. That is what we have done.
The solution is implemented via an option in the Settings form labeled ‘Allow for divergent sales tax rates depending on locality, type, etc.’ Once this option is enabled (click on it then save), you’ll find that the boxes for specifying a uniform tax rate are, logically, disabled. And now, when you go to enter completed sales from within the SalesEnter form, you’ll discover the system is much more permissive. Yes, it will still sum the entered constituents and compare that result to the entered total, but now it will allow an assumed tax rate (applied to all constituent parts) ranging from 0 to 15 percent. Thus, so long as the entered total is at least the sum of the entered constituents, and is no more than 15 percent above, the entry will be accepted and recording allowed. Whatever cushion it finds, if any (ranging from 0 to 15 percent), will be assumed as the tax amount that was appropriately charged on the sale.
All that is lost vis-à-vis the standard system, at this point, is that if the entering operator makes an error (or the person who added the invoice did) that nevertheless keeps the constituents and entered total within the allowable comparison/tax-rate range, that particular kind of somewhat smallish error (i.e., maximum of 15 percent either improperly credited, or not credited, to tax) will not be caught by ServiceDesk.
So far as operations that are integral to ServiceDesk, this describes the solution completely. With that and nothing more, ServiceDesk will accurately collect sales information, and stand ready to report on system-wide tax liabilities (among other figures) for any period wanted.
Of course, as the divergent-tax-situation user you’ll face an important further need. You still must separateyour tax liabilities between and among the various jurisdiction in which you’ve done service—so you can report on those liabilities and send payments as required. While the ServiceDesk SalesJournal will show the tax amounts you’ve calculated on each job (regardless of locality), it does not separately indicate the location where each job was done, nor is there presently provision within ServiceDesk (even if the SalesJournal did include such information) to break out sales and tax liability on the basis of locality. Again, we do not want complicate the general system unduly for the normal user.
Instead, as another consequence of specifying that ‘Allow for divergent sales tax rates depending on locality, type, etc.’ option in the Settings form, the system will silently create a mirrored SalesJournal file for your own special use. Specifically, each time you enter a completed sale via the SalesEnter form, the system will now make not only the standard entry into the ordinary SalesJournal, but also another entry into this separate file. And this entry, unlike those in the standard SalesJournal, will include the zip code for the job in question (along with department if you’re using that option). And, unlike the standard SalesJournal, this file is in a format you can easily access from any spreadsheet or database program (i.e., it’s in Ascii, comma-delimited format). You’ll find the file at c:\sd\netdata\slsjrnl.str (assuming c: is your FileServer; otherwise specify the appropriate drive in place of c:).
Thus, ServiceDesk collects all the raw data that’s needed for you to break out your sales tax liabilities between and among different jurisdictions, and compiles it in this one file. It’s left to you to import this file/data into an appropriate context (most likely a spreadsheet program such as Excel) and there create a system that, using the data, makes reports concerning each of your separate liabilities.
Some caveats. We do not use this system in our office, and have had little feedback to date from users. As presently written, entries within the secondary SalesJournal are created only via the SalesEnter system. If you make revisions to the SalesJournal from the SalesView form, they will not automatically be reflected in the secondary journal (if important, you should mirror them manually from whatever spreadsheet or similar context you’ve setup for manipulating the file). And entries made while reporting on payments to or changes in accounts receivable are not at this time programmed for addition to the secondary journal. If you find these operations are important to your use, please let us know and we’ll be happy to accommodate.