As any software must tostay current, ServiceDesk has evolved over time. As features have been added, changed andimproved, we strived to keep the manual updated to the current state ofaffairs. Over time this has resulted ina manual whose structure and language is less straightforward and simple thanwe (and probably you) would like—for as things change it’s far easier to insertan explanatory paragraph here, a footnote there, change a description slightlyover there, etc., versus a complete re-write that, could we afford the time todo it, might describe the new situation more simply than by using suchcumbersome appendages.
One consequence is that early in the year 2000 werealized the main text contained much more technical detail than the averagereader would probably care to read. Realizing it would be better to keep the main discussion comparativelysimple, we’ve gradually been moving the more technical discussions into thisseparate appendix area, where they may be consulted as needed, or perhapsmerely made the knowledge of a resident “expert” in your company.
If you’ve used other CstmrDbase systems, you may have abit of un-learning to do before making full sense of the ServiceDesksetup. Ours is different.
In a typical system, theCstmrDbase consists of a master list. This list has one entry for each customer. Each such entry lists things such as acustomer’s name, address, telephone numbers, etc. The list of entries has no function except tobe a repository of this information, and a source from which such informationmay be drawn when needed. Typically, thelist involves a considerable amount of housekeeping work on part of the user—infirst creating the entries, keeping them up-to-date, eliminating duplicateentries, correcting for errors, address or telephone number changes, divorces,etc. These are complications we soughtto avoid in the ServiceDesk system. Howhave we done it?
Basically, we eliminated the master list. ServiceDesk has none. Instead, it simply uses the accumulatedhistory of past jobs (i.e., the one that will develop as you use the system). Each of these jobs, after all, has—as part ofits record—all the information that would likely be in any master list (andmuch more). The trick is simple. ServiceDesk maintains indexes to this mass of past jobs. By doing logic-based searches within these indexes, it can instantlylocate any name, address or telephone number that arose in any of those pastjobs, along with the full information set from each job that pertains.
So why do you need a masterlist? In fact, there are some potential benefits in moretraditional systems (such as that a master list may contain information of akind that would not normally be put directly into a job record, for example),but for a typical ServiceCall-performing operation, we think theirdisadvantages (especially as compared against the many benefits of a purejob-record-based system) outweigh any advantage. Regardless, please do not look for such adedicated master list in ServiceDesk, for there is none. In our system all customer information isfound, quite simply, in the actual record of past jobs.
At least, that’s thegenerality by way of background, but in fact there are several specifics it maybe helpful to know.
Utilities for doing so are found in two differentplaces. One is in the JobsCurrent form,another in the JobsArchived form. Thedifference is that, while the former is designed merely to update the indexes from time to time, the second creates a new set of indexes entirely fromscratch. Why are both functionsprovided? In fact, when you’re firstusing ServiceDesk either method would work fine for all purposes. However, after you’ve accumulated manythousands of job records, the process of making new indexes from scratchmay take many minutes of intense,no-other-use-possible computer time. Tominimize that inconvenience, you’ll more typically use the mere updatemethod. Yet sometimes you may still needthe MakeNew method because it’s possible, from time to time, that somecorruption will creep into these files, and it’s only by building virginindexes from scratch that it can be eliminated.
To be more specific in regard to the mere-update method, it’s provided in theJobsCurrent form as part of its Archiveutility. That utility, obviously,invokes the process of moving completed JobRecords out of the JobsCurrent fileand into the JobsArchived file. Thisevent necessitates updating of theindexes, because they reference the locationof these jobs (i.e., in which file and wherein), after all. Thus it’s logical to incorporate updating ofthe indexes into the same process that involves moving the underlyingrecords. In fact, during this routinethe process updates the indexes to reflect all records in the JobsArchived fileand all that currently exist withinthe JobsCurrent file. We make thedistinction as to those records that “currently” exist for this reason: Any new jobs that are added, after theCstmrDbase indexes are either updated or newly created, will obviously not bein the indexes. Thus, these particularjobs will not show up in any CstmrDbase search (although, remember they willstill be accessible from within the JobsCurrent form itself, based on any ofits built-in searches).
This last fact, incidentally(i.e., non-availability of post-index-created jobs via a CstmrDbase search)argues strongly for running the JobsCurrent form’s Archive utility with somefrequency—or better yet, letting theAuto-Archive utility do it for you automatically on a nightly basis (see page 209).
Regardless, there is a related detail that bearsexplanation. To absolutely maximize thespeed at which CstmrDbase searches are performed, we’ve designed it so thateach ServiceDesk station maintains its own local copy of the indexes (this waythey are not each simultaneously clamoring to access common files from theServer). Plus, each station keeps theindex files open during normal operation (rather than opening and closing asneeded with each use). This complicatesthe matter of making new or updated indexes from any particular station, forthe others must receive updated copies. Utilities are built-in to both procedures to assist in this (theAuto-Archive sequence takes care of everything for you), but with this word ofexplanation it may make more sense. Alsobear in mind that if you’ve failed to use the built-in utilities for updatingother stations, it’s easy to copy the relevant files over (from one station toanother) using Windows Explorer or other Windows utility (it’s simply all fourfiles that you’ll find in the ‘\sd\cstmrdbs’ folder that are relevant).
It’s criteria is fairlysimple. In regard to the CustomerInfo block from the job record,the system figures that any leading text in the name field must be a true,properly-index-able name, and any in the address field similarly index-able forthat purpose, and similar for the two telephone number fields. In regard to the LocationInfo block, however, these assumption seem considerablyless valid. On many jobs, after all, thecustomer and location will be one and the same, and presumably therefore you’llhave true customer information only in the first block. This leaves the second block free forextraneous notes, and if your office is like ours you’ll occasionally use itfor such purpose. So how can ServiceDesktell? Quite simply, it looks for anopening bracket (i.e., “[“) in theLocationAddress line (as would appear in conjunction with a grid reference, forexample, and should exist if you’ve used that block for true customerinformation).
In other words, if the systemfinds text such as “123 SOMERSET LANE[923E5]” in the LocationAddress line, it will include that and otherLocationInfo-block text in the indexes. If, on other hand, if finds something like “THEN TURN LEFT ON HALIFAX” (or even “123 SOMERSET LANE 923E5]”), it will not index any of that block’stext.
One more caveat in regard to what’s indexed: by design,we intentionally do not index name, address or telephone numbers that belong tothose customers that, within the QuickEntry system, are designated asHighVolume-type clients (see page 57). The reason is because, presumably, you’ll begenerating many, many jobs under these clients names. If each such job created its own indexreferences based on the HighVolume client’s name (or address or telephonenumbers), it would expand the indexes needlessly, plus be of no real use. Instead, these jobs will all be indexed(subject to the proviso explained in the preceding paragraph) based oninformation in the LocationInfo block of the job record, making any neededlookup very practical indeed.
But the JobsCurrent form islikewise designed to display job records, so you may wonder why we did not useit instead? Well, it’s an alreadyheavily-used form, doing many tasks, while the JobsArchived form was morelightly used. To impose additionalduties on it (and build-in the needed adaptations) was simply morelogical.
Of course, each form(JobsCurrent and JobsArchived) in their standard modes are designed to accessand display job records only from their own respective contexts (current jobsor archived, as the case may be). In theCstmrDbase context, we’ve had to adapt the JobsArchived form to allow it todisplay either archived (which is more normal for that form) or currentjobs. This has an important consequencethat may seem more logical if explained here. Specifically, you cannot edit a job record when viewing it from directlywithin the CstmrDbase context. Instead,if it’s a current job record (i.e.,it’s still in the JobsCurrent file) you must go to the JobsCurrent form andload exactly the same job record into it, for editing or other operationaltasks. If it’s an archived job record, you must reload it into the JobsArchived formwith that form in its standard, rather than CstmrDbase-display mode.
To simplify either task, we’ve built-in a very niceshortcut. Suppose you’ve looked up anyjob (current or archived) via the CstmrDbase system. The job is displayed for you in theabbreviated, CstmrDbase-displayed mode of the JobsArchived form. You want to do some real, operational work(such as editing, for example) within the record. What do you do? Simply press F7 if it’s a current record, or Ctrl-F7 if it’s an archived one. Ordinarily,of course, such action would load the forms with most recent records loaded into them (then, if wanting a specificdifferent record, you’d have to use some means to locate it). In this context, however, the system willload the respective form—with the record that you were already viewing in theCstmrDbase context loaded! (Actually, inthe case of an archived record it will convert the already displayedJobsArchived form into its full-use mode, and reload the same record as wasalready displayed). This is a very handytool, so don’t forget about its availability.
In our main discussion onuse of the StreetList (in Chapter 5), we described how to insert a street nameto a Callsheet (see page 64). A detail we did not mention is that, as youdo this, the label-text for thatsection of the Callsheet (i.e., either the Customer- or Location-Info block)will, in most instances, momentarily flash an informative message. Most frequently, it will change from itsnormal reading (such as “Customer Name, Address and Phone Numbers,” forexample) to show this statement: “ConfirmedAddress Number in Allowed Range.” You might wonder, what does this mean, and what exactly is involved inthe underlying mechanics?
Basically, as part ofyour custom package we’ve created two StreetLists. One is the normal list, and it’s what yousee (within the drop-down list) any time you’re typing a street name in aCallsheet. The other is hidden, andcontains somewhat different data. Specifically,each listing has a high and low number indicating the range of addresses that exitwithin a given segment of the street.
What happens is that, as you select any street forinsertion from the normal list, ServiceDesk consults this second list (we call itthe “BlockList”). Assuming it finds amatching entry, it checks to be sure the address number you’ve indicated fitswithin the indicated range. If so, thesystem flashes that nice, confirmatory message.
Of course, the system may find you’ve typed annumber that’s outside the indicated range. If so, there will be a warning message suggesting you reconsider. In fact, the system assesses how far from theallowed range your number is, and it adjusts the stridency of its warningaccordingly. Obviously, there is a verynice error-catching function implicit in this system. In many cases it will help you catch an errorin terms of the number you typed, and save your technician from costlyfrustration in seeking the house in question. In other cases it will help to catch the fact that, perhaps, you enteredthe number correctly but selected an inappropriate street from the list.
At any rate, there isstill another function provided by the BlockList, which may best be understoodby mentioning a detail about the StreetList (again, that’s the one you see). The StreetList is constructed to have asingle entry for each instance of a given street name that occurs under a givenzip code. Just one, no more. Thus, you may have several entries withinthis list of what is in fact a single street, for sections of that street thatpass through different zip areas. On theother hand, for all of that street’s length that exists within a zip area,there will be but one entry, even if that length falls across considerable spaceson your DispatchMap. The grid referencethat’s given for this section is targeted for the middle thereof, yet the jobin question may be at either end. Thus,absent some solution, you could end up with some jobs being displayed lessperfectly (in terms of position) than desired. Essentially, the standard, StreetList accounts for position of a longstreet on the basis of zip only, and with no more positional-specificity thanthat.
This is where that BlockList really comes in. We’ve described how, as you’re inserting astreet from the standard list, the system silently checks there for a match. Well, it so happens that when we build theBlockList we fictionally break up any long sections of a street intosegments. We then include separateentries for each such segment, and of course each includes a specific grid referencefor the block range it includes. Thus,when you pick a street and the system checks in this list, it may find multiple matches. If so, it searches from among those to find particular one that includes the addressnumber you’ve indicated. Upon so finding,the system inserts its gridcoordinates—rather than the presumably less perfect ones that were displayed inthe main list. When this occurs, you’llsee a different message as the corresponding Callsheet label flashes (in fact,in this instance it will literally flash off and on for a few seconds). It will now read “Grid Coordinates Honed for Greater Accuracy.”
By this means the system fully accounts for theaddress number as it creates a grid reference. That is one of the topics we wanted to discuss in this section. The other involves difficulties you may have(of one kind or another), along with the concern of how to handle gridreferences if your system (or any portion of it) was not keyed to an underlyingmap book.
Our first concern is if you can’t find the streetyou’re seeking.
So, you’ve got this great new system; you’re showing itoff to some visitor, and as you’re typing in their street name to show them howcool that drop-down list is, the list disappears, because there are no matchesto what you’ve typed. Dang! How do you deal with this?
Well, the first likelihood isthat the wanted street does exist inthe list, and it’s simply there in a somewhat different format (or spelling)than what you’ve typed. The standard,as-you-type search only works (i.e., it only shows matches) if there’s perfectcorrespondence between your text and entries from the StreetList as matched when comparing from the beginning ofeach such line. For such reason, ifyou’re typing “LILAC ST,” but the actual entry is in the list as “N LILAC ST,”you’re not going to get a match. Similarly, f the customer tells you they’re on “LA BOMBA” (so that’swhat you type) but the real entry is in there as “CALLE LA BOMBA,” you are(again) not going to see it—at least not via the standard, as-you-type searchmethod.
But there is a solution—basedon another kind of search. If you’re notseeing the street you want, try hitting F1 (you do need to be in that samecontext). At this point ServiceDesk doesa different kind of search. It takes whatever text you have as a street name,then looks for and displays any line from your StreetList that has that textexisting anywhere within itsline. Thus, if you’d typed “LILAC ST”but it was in the list as “N LILAC ST,” this search will find it for you.
Bear in mind, you’ll get more matches if your searchtarget is less demanding (“LILAC” would likely produce more matches then “LILACST” for example). And please realizethis kind of search may take (depending on factors) up to a few seconds. Probably about half the time that you don’tinitially see the street you want, you’ll be able to find it via this method.
So what about when the streetis simply not there at all?
As has been indicatedelsewhere, the raw data for your StreetList comes from a database developed andmaintained by the U.S. Census Bureau. This is the same data that's relied on by virtually all commercialstreet programs that map the entire country (regional map producers typicallyhave their own data sources). The datais quite good, having excellent (if perhaps somewhat dated) coverage of almostall incorporated areas, urban and suburban. For rural and unincorporated areas, the coverage may be less thorough.
A missing street presents achallenge, since at the least you need a grid reference so that a job on thatstreet can properly display in your DispatchMap. It’s obviously no great challenge to manuallytype in the whole address (just as you would in any non-ServiceDesk system),but how do you come up with that grid reference?
Well, as a first option (andassuming your system is keyed to an underlying map book), we suggest you keep amap book handy by your desk, and when this happens go to its index, manuallylookup the street, and type-in its reference on the Callsheet (between bracketsafter the street name, just as if ServiceDesk had inserted it). Sure, this is a bit of work, but you end upwith a good reference, and if you didn’t do the lookup now, your tech wouldprobably need to do it later.
But what if yoursystem is not keyed to an underlying map book, or (even if it is) the street ofinterest is outside the map-covered area?
If you go to your DispatchMap (F5) and hold down yourleft mouse button (on any space that doesn’t have a job reference), you’ll seean underlying grid. That’s the addresssystem ServiceDesk uses, internally, for positioning things (anything andeverything, really) on your Map. Everything you see has some position,essentially, on that grid. Indeed, ifyou’re using a map book and ServiceDesk needs to display a job based on a pageand grid reference that references it, ServiceDesk has to perform a littletrick first. Essentially, it looks in a translation table, which is one of theelements we custom created for you. Thattable tells it that, for a given page and grid combination from your book, thecorresponding on-screen position must be X (actually X and Y, where X is thehorizontal and Y is the vertical component), in terms of that underlying gridsetup that you see when holding down your mouse.
Because that underlying gridis what ServiceDesk always usesinternally (and any outside reference is merely translated to it), we call it the “NativeGrid.”
You need to know about this, in particular, if yoursystem was not keyed to an outside paper book, because that means in allinstances your references will be directlyto this NativeGrid, instead of having your book’s reference stand in as akind of go-between. And again, even ifyou have a book, you may have areas it does not cover, and this concern becomesequally important.
At any rate, suppose that thestreet you want has been proven (even via extended search) as absent from yourStreetList, and that finding it in an applicable map book’s index is also notan option (either because it’s not in the book or you simply don’t useone). Now, even though, most obviously,it’s little problem to type the address manually, how do you come up with anappropriate (and accurate) reference to the NativeGrid?
As a first solution, if uponexamining your DispatchMap you can formulate a really excellent idea of wherethe job should display, just click there. ServiceDesk will note the position you’ve clicked. Now, go back to your Callsheet, position yourcursor at the end of the street name, and hit Ctrl-V on your keyboard. ServiceDesk will now add the reference for you. It’s that easy (as you might guess,ServiceDesk is simply using the Windows clipboard; having inserted the grid-referencethereto when you clicked in the DispatchMap).
This is particularly theprocedure to use when you have that rare, distant job that’s not even in theterritory we drew for you. In thatinstance, it’s best to represent the job’s reference on the periphery, outsidethe drawn area, but in the direction toward which the tech’s going to have todrive in order to reach the job. Usethis click-at-wanted-to-display-positionmethod, and you can easily create the reference that will make the jobreference display right there.
There is a major shortcomingto this method, however, in that if you or your operators may have little idea,as they look in the DispatchMap, where a given address ought to display. And if youor they are inaccurate (especially if you’re grossly inaccurate), it may resultin very poor routing of the techs.
This shortcoming was addressed in late 2006 via creationof a new custom data file, along with programming to harness it. The new file is called a ZipsLocationList (it has a .zpc extension). Basically, it’s little more than a list ofyour zip codes, along with a references to the NativeGrid that indicate theweighted center of population within each.
To explain use of this newlist, let’s again paint the scenario. The street you want is not in the drop-down list, and use of a map bookreference is not (for whatever reason) an option either. Here’s what you do:
Just finish typing the streetname. Don’t worry about the gridreference. Just go the next line, wherenormally (at least if doing full-on manual entry) you’d begin typing a cityname. But don’t do that. Instead, just type the zip code. As you type the fifth digit, you’ll see someinstant magic. ServiceDesk will find thezip code in your ZipsLocationList, appropriately insert its NativeGridreference in the street address line, and change the city-name line to itsappropriate full text.
This is, by far, the easiest method of dealing with a missingstreet. It’s so easy, it’s fun. But bear in mind, the display location itcreates (being based on zip only) is but approximate. Depending on how big an area any particularzip covers in your DispatchMap (along with the vagaries of where a particularjob actually happens to fit within the zip), the relation between true anddisplayed location may range from exact (when lucky) to as much as severalgrids off.
So now I’ve fully entered info on a street thatwasn’t in my StreetList. Shouldn’t thatnow be added, so it’s available next time?
The answer is yes, of course, and ServiceDesk has themeans to make it happen.
The process, basically, isthat as you do the job/sale process from a Callsheet in which a new street nameassuming manually entered (and assuming you included a corresponding grid reference,properly enclosed in brackets), ServiceDesk will notice the fact, and ask forpermission to add the street to your main list. If needed, it will also query you for further information. Then it will transfer the information to aspecial file, where it holds added streets until you request a process thatsorts them into the main list (this is something you should do periodicallyfrom the Streets form, accessedeither from within the File section of the MainMenu or by pressingCtrl-F5).
By means of this as-you-work process, we expect yourStreetList to become increasingly complete—so the frequency of finding a streetname missing should be ever more rare. Additionally, as the Census Bureau updates their data every couple ofyears, it’s part of our ongoing-service package to re-do your data with thelatest from them. Their data, in itself,is becoming better and better.
Our final concern is that youmay find cities indicated that are either outright wrong or, at least correspondpoorly with local custom.
In compiling your StreetList we connect city namesto each street based on its zip code. Wedetermine the city name that’s applicable to a zip based on a master listthat’s provided by the Post Office. Toomany times, we've found this Post Office-provided data leaves something to bedesired (for a given zip it connects a city name that is very inappropriate). Of course, since we're not personallyfamiliar with your area, we don't know in which instances the connection isfaulty—although it will likely be very apparent to you. Accordingly, we've created an easy means foryou to correct any city-to-zip connections, as reflected in your StreetList,that may be faulty (for a list of city names that were pulled for the zip codesin your area and attached to each StreetList entry per Post Office data, seepage 323 in the Appendix; if interested in seeing thecity-to-zip connection per this data for any zip code at all, use the Zipsutility as discussed at page 218).
Suppose, for example, you notice that all entriesfrom your StreetList with zip code "92675" erroneously show a cityname of "MV" (which we'll assume is the abbreviation within yoursystem for "MISSION VIEJO"). In reality, you know this zip (and all its connected streets) actuallyfall within the city of "SAN JUAN CAPISTRANO." How can this be corrected?
Begin by loading yourStreetList form (either select it from the MainMenu of press Ctrl-F5). There click on the button labeled 'Change City Names'. Then simply follow the prompts. In a matter of seconds, you can haveServiceDesk correct all the entries pertaining to any zip that previouslyshowed an incorrect city name. Then inthat respect at list, your StreetList will be perfect forever thereafter.
Our last concern is for listings, as found withinyour provided StreetList that have no corresponding zip code or city referenceat all.
As you’re typing in a street name, you may occasionallysee a street listing that has nocorresponding city initials or zip code. It simply happens that the raw data (which we obtain from the CensusBureau) has a number of street listings that lack this information. Prior to August 2000, we did not includethese listings in any of the StreetLists we made. Typically, there are very few such listings,so little is lost by their omission. While creating a package for a client in a particularly rural area,however, we discovered that a large percentage of street listings for theirregion lacked zip and city data, so that if such listings were omitted from their list it would have been very muchpoorer for it.
For this reason we modifiedour production machinery to include these listings in the client’sStreetList. Having done so, we figuredthere might be some benefit in having such listings included for any client(i.e., better to have a listing with no zip or city than to have no listing atall), and so have maintained the machinery for all packages since.
If the street you are seekinghappens to fall into this category, it simply means you’ll have to manuallytype-in the city name, rather than depending on ServiceDesk to do it foryou. Of course this assumes that thelisting you’ve selected is genuinely for the street you want, which is lesscertain than normal because there is initially no city referenced to it. You’ll just have to verify by seeing that itdisplays the job to an appropriate location on your DispatchMap. If not, obviously, you may need to select adifferent listing or else enter the street to your Callsheet manually.
In the main chapter discussion regarding theDispatchMap, we explained that every scheduled appointment displays to the jobin its correct geographical position (see page 83). Actually, the display should always be atleast near the correct geographicalposition, but for several practical reasons, it may in fact be skewed slightly,from such an ideal position, in one direction of the other. For any that are interested, we want to hereprovide an explanation as to the particular reasons why.
The first and most important reason is because, you mayhave two jobs whose locations are so near one another that, if displayed withthe reference precisely over each location’s center, the references wouldoverlap, making at least one of the two illegible. For this reason, the map-displayintentionally avoids a scheme that involves precise centering of each referenceover the job’s putative, real-world location. Instead, the system references an invisible, on-screen grid(approximately 32 columns by 23 rows). For any job whose centerfalls anywhere within a given gridsquare, the reference is displayed squarely within that square. Thus if a job’s center was, say, toward theright side within such a grid square, it’s reference will end up displayingslightly to the left of a geographically perfect position. While this produces a slight compromise indisplayed positional accuracy, it helps to avoid having references write oneover the other.
Of course that in itselfdoesn’t guarantee that there won’t be write-overs, because you may have morethan one job that properly falls within a given grid (which, if each wasdisplayed with only the above-described allowances, would result in a completewriting over of one to the other). Oursolution in this instance is positional stacking. Basically, each reference is sized such thatit consumes the space of an entire grid horizontally, but only half a gridvertically. Thus, the first job thatfalls within a given grid is displayed in that grid’s top half. The second such job is displayed in it’sbottom half. The third (this is nottypically common) will be displayed in the top half of the next grid down, andso on in a growing stack as needed to accommodate as many jobs as are targetedfor a common grid section. Again, youcan see there’s a potential reduction in displayed accuracy here, but only asneeded to make each display reference legible.
Aside from the demands oflegibility affecting positionally-displayed accuracy, there’s also the factthat we don’t even have perfect positional information in the first place. We have a grid reference, and in fact thelocation may be anywhere within that grid. When the Dispatch goes to position its display reference for the job, itonly has that grid reference, and thus does not know (with any greaterprecision than that) where the job is located.
Then there’s a question of resolution. Ideally, we will have preferred to designyour system so there is a one-to-one relationship between grid sections in yourpaper source map (and the corresponding references connected to each job) andthe invisible grid built-in to our DispatchMap. However, if your territory is somewhat large, this may have beenimpractical (because if we did so scale it, you’d only be able to see a tinyfraction of your territory in one DispatchMap screen, and so would have to panridiculously to survey its entirety). Accordingly, there might be a two-to-one or even three-to-one relationship(meaning, in the last case for example, that one on-screen grid represents thesame territory as a three-by-three grid section in your paper map). We mention it because, if this is the case,you’ll find that even when two streets have different grid references, they maystill display in precisely the same location on the DispatchMap. As a matter of scaling, it simply is notpractical to do it in any other manner.
While all of this concerns the positioning of scheduledappointments (or rather their references) in the DispatchMap, there is another,unrelated matter of potential inaccuracy we want to address. It concerns the DispatchMap feature thatallows you to view past day's schedules.
Basically, though this functionshould be quite reliable, it may in some extreme circumstances fail accuratelydisplay all the appointments from particular days in the past. If you’re interested, we’ll explain why.
First of all, accomplishingthe purpose of viewing past appointments is not so easy as you mightassume. Until this feature was added,the Map derived all its data onlyfrom the current ScheduleList. If thislist is properly maintained, it contains only items scheduled for the presentand future. Typically, this will not bemore than several score of records at a time. Thus, to decide what to display for a given day (current orprospective), the machinery has only to review this small number of entries,and see what is applicable for that day.
To show past days, bycontrast, the Map must refer instead to the ScheduleList-Archive, and this is afile that eventually becomes very large, containing tens of thousands ofrecords. Because of this large size,it's not practical (in terms of promoting a prompt display) to have ServiceDesksearch through every record (as it does in the current list) to find itemspertaining the particular day that's requested for display. So another means is required. Basically, it’s this. As you page up or down among past day’swithin the Map, ServiceDesk searches forward or backward in the file, as thecase may be, only so far as seems necessary to probably account for all entriespertaining to the day in question. Thecaveat is that the algorithms by which we accomplish this are limited in scope,which means that in some extraordinary circumstances the system may fail toaccurately display all jobs as scheduled for days in the past..
You'll also notice that theDispatchMap can display jobs from past days only up to the date when the ScheduleListform's Archive routine was last run. This is because they have not yet been moved out of the currentScheduleList and into the Archive—and it is only from within the latter thatthe DispatchMap looks for jobs in the past (whether a day is past or not beingreckoned according to the computer's internal calendar).
There are many different ways inwhich a human operator might designate an appointment for a certain date andtime. Being intelligent as we are, weprobably could decipher the intent behind any format that makes reasonablesense in our own language. Unfortunately, computers and software are still not so smart as we whenit comes to matters seemingly so simple. It is fortunate in this regard that, in respect to much of what you typeinto a Callsheet or other form, there is little need for ServiceDesk to understand what's there: for the mostpart, it simply records what you've entered and transmits or displays it, asappropriate.
In regard to what's enteredin the 'Appointment Date and Time' box, however (and later transferred to ajob’s appointment reference in the ScheduleList), ServiceDesk must be able tomake a sensible correlation between what's entered and the actual calendarcontext of date and time. For thisreason, it’s necessary to use a format that ServiceDesk, being relatively dumbin such matters, is prepared to interpret.
Specifically (but with someexceptions, to be discussed), ServiceDesk is programmed to expect threeparticular "words" within any appointment reference. It defines words as adjoining groups ofcharacters, each separated by a single space (i.e., it would think "o8kl3 v9f drt" is threewords).
For the first word, ServiceDesk expects to findeither a single number referring to the desired day-of-the month (i.e., anumber in Arabic text between 1 and 31) or an ‘X/X’ –type of number/number combination that refers to the month and day-of-month (as in “12/31” or “2/19”).
For the second word, it expects either a weekdayname, or as many leading characters from such a name as you may choose to use(e.g., "MON").
Finally, for the thirdword, it expects any of the following:
No other forms of text (such as,for example, “1stCALL” areacceptable for this third-word position
Thus, a complete appointmententry could look like any of the following:
20THURSDAY 9:45
1 TU 3-5:30 C/F
7/15 MON 9-12
5 SUN 7:00 EMRGNCY
13 FRIDAY !
2 WED AM 1stCall
Notice that in some of theseexamples there are additional words after the first and magic three (we evenhave an example where “1stCall” is acceptable as a fourth word). ServiceDeskdoesn't mind such additional words (which you can use internally asnotes). It simply must see the magic first three words — each in one of thedescribed-acceptable formats.
To make things easier for you,ServiceDesk does manage some minimal intelligence in regard to interpretingthese entries. Notice, for example, thatyou are not expected to specify 'AM' or 'PM' in regard to the time (nor to usemilitary time). ServiceDesk will assumethat a 9-12 appointment must be for the morning, and that a 3-6 must be for theafternoon. It becomes more difficult forthis distinction, obviously, as your appointments reach the more extreme edgesof the day (is an appointment designated for "7:00" more likely to be am or pm, for example?), soServiceDesk establishes a simple dividing line. If the number designating a single time, or the average between a pairof times (i.e., 10:30 when "9-12"is stated) is 6:59 or less, ServiceDesk assumes it must reference a 'PM'time. If it is 7:00 or greater,ServiceDesk assumes you're intending 'AM' time.
Additionally, when allowing youto state merely a single number forthe day of the month, ServiceDesk must somehow deduce which month and yearyou're referring to. Essentially, itseeks and finds the last time when such a number arose in the calendar, ascompared to the present date. If thefound date-number was less than five days previous, it assumes that as the datereferenced. Otherwise it assumes thatyour number refers to the next time the number arises in the calendar.
While it’s convenient to be able to state a singlenumber for the date, you can readily see (based on the above) that if you’rewanting to specify a date that’s more than about 25 days hence (depending onnumber of days in the current month), it would be impossible, on the basis of asingle number alone, for ServiceDesk to accurately interpret your intent (thedescribed assumptions would fail). Forthat reason, and for those specific instances where you’re specifying anappointment further into the future than 25 days, you’ll find that bothauto-insertion methods will create a more complete reference (e.g., “12/31 THU” rather than merely “31 THU”). In this instance, obviously, there is stillthe need for ServiceDesk to infer the year. Roughly, it uses the same convention as when inferring both month andyear, but in this case will correctly decipher your intent so long as you’renot attempting to schedule more than about 51 weeks into the future (or again,more than five days in the past).
It may seem odd when firstconsidered to find we’ve set it up so that you need put in only a single,day-of-the-month number for the date, rather than a more standard format suchas “12/31/01 9-12”. The reason is because we also want a referenceto the day-of-the-week (for verification of intent as described in thefollowing paragraph, and related reasons), and yet we want to keep theappointment reference relatively short (a reference such as “12/31/01 MON 9-12” would obviously beunwieldy). Thus we find something like “31 MON 9-12” is generally mosteffective, particularly because the applicable month and year should invirtually all cases be obvious from context. Regardless, you’ll note that you can select an option in the Settingsform that will cause the month indication to be included in all instances, ifthat is your preference.
As for as the second-word,day-of-the-week portion of your entry, ServiceDesk uses it solely for thepurpose of verifying you have not, in some manner, goofed in regard to theintended day of the appointment (it checks on this during the Job Creationprocess). Thus, if you've specified"16 FRI 1-4", but thefollowing Friday is, in fact, the 17th, ServiceDesk will alert you to the errorand require correction—thus helping you avoid a very common mistake. Indeed, ServiceDesk checks the entire formatduring the Job/Sale process, and will coach you in making necessarycorrections.
If you become involved in making the formalizedFinished-Form documents that are part of the system described in Chapter 8C(see page 217), you may find it profitableto know some of the more technical details regarding how we’ve setup thesystem. Describing those matters is thepurpose of this section.
In general, it isServiceDesk’s job as part of this system to peruse through the various andsundry files it has compiled, in reference to a particular job, and attemptfrom there to glean what’s relevant for inclusion into each of the various textboxes of the form you are preparing. Itis further its job, obviously, to attempt to place each item of informationinto the particular textual format that you’re likely to want for the box intowhich the item is being inserted. If youknow some details about this process, it will help you understand the resultsyou see, and perhaps help you plan better toward getting the results youwant.
First, in regard to the name,address and telephone numbers, you’ll notice these are very straightforward,with information being pulled simply from text within the item’sJobRecord. The one complication is that,for the Narda form, there’s only spaces for one info-set (i.e., not separatesections for both the paying party and location info). As a convention for the Narda form,ServiceDesk places the name and address set here that’s found in the ‘LocationInfo’ section of the JobRecord. However,in the event it does not find you’ve used that section for an apparent name andaddress (a matter it deduces by looking for a comma in the LocationName lineand an opening bracket in the LocationAddress line), it inserts text from theJobRecord’s Customer-Info section instead. (Since the Generic form has boxes corresponding to both the Customer andLocationInfo section of the JobRecord, there are obviously none of these considerationsin reference to text inserting to it.)
In regard to the P.O. Number,if there’s one present in the item’s JobRecord, ServiceDesk will insert it tothe “Special Authorization #” space in the Narda form, and place an “X” in thecorresponding checkbox for you. The“Customer’s Request” information, as inserted to the form, is obviouslytransferred directly from the JobRecord’s corresponding “Problem to be solvedand/or Description of Customer’s Request” box, the “Date Call Received” text isbased on the ‘Origin Date’ for the JobRecord, and so on. Most of that is pretty straightforward.
For the inserted “CompletionDate,” ServiceDesk examines the History for the job and looks for an entry withthe phrase “job completed.” Assumingsuch an entry is found (ServiceDesk will have created precisely this kind ofentry on completion of any PostVisitReport in which the query “Is the jobdone?” was answered in the affirmative), the date of such entry will beinserted for you.
For the blocks describingtimes when the tech started and ended on each visit, ServiceDesk again examinesthe History for the job. Specifically,it looks for the kind of entry that’s created when, in conjunction with astandard, PostVisitReport, the technician indicates what the start and endtimes, during his visit, happened to be. Finding such appropriate descriptive text, the system gleans the actualtimes stated, and inserts them into the form for you. What it looks for, specifically, is an entrybeginning with standard date and time, then a tech’s initials followed by thekey word “ there “, then an appointment reference, a comma, then two timesseparated by the key word “ to “, then another comma and more text (as in “3/4/00 16:42: DS there 14 TUE, 11:40 to12:30, diagnosed bad valve . . .”). If you’ve made any manual changes in the job’s History and corruptedthis precise kind of format, you may find that ServiceDesk fails to winnow outthe start and end times as wanted.
It’s also by reading these particular entries inthe History, you should know, that ServiceDesk deduces which technician’s nameshould be inserted into the Narda form space that calls for one. At least, this is conditionally thecase. But in fact, you may have a job onwhich different technicians made separate visits. If that’s the case, ServiceDesk chooses thename of the technician on the last indicated visit (at least in respect to thelast entry it is able to successfully interpret as such). But it’s still conditional. If (as we figure will usually be the case)there’s a SalesJournal entry for the job, the system will choose the technicianindicated in conjunction with it (always bear in mind that, regardless ofwhat’s inserted for you, you can change any of the form’s text boxes to what isspecifically wanted at the moment).
Still another matter concerns the description ofwork performed (i.e., the space specifically labeled “Service Performed” on theNarda sheet). In this case, there may bemuch text in the job’s History that is not a specific description of work thetechnician actually did, and obviously ServiceDesk lacks the genuineintelligence that would be needed to separate and winnow out such completelydescriptive words from other text. Instead, it does the next best thing. Basically, it identifies entries made in a PostVisitReport by lookingfor the same key phrases as described above (i.e., it looks for references tothe times when a tech started and ended his visit). It then assumes that at least most of thelanguage following the preliminaries in such an entry is probably a descriptionof what the technician did, and so culls this specific text and places it intothe relevant box on your form. If therewere multiple visits, it includes the text from each, while placing a pipesymbol (i.e., “|”) between each one to help you see the separation. We expect this is one box (on the form thatis) that you’ll edit in virtually every instance, but it should be veryeasy. In most cases it will probably bea matter of using your mouse to highlight extraneous text, then hit delete, formaybe a two or three second operation overall.
The last major matter in regard to which the system reads the job’s Historyis in regard to parts used from stock. It depends entirely on descriptive language in the History for thispurpose, so be sure all stock-used is properly reported through the PostVisitReportsystem, so that such proper descriptions will be there for this purpose (andagain, bear in mind that if you’ve previously changed the ServiceDesk-inserted Historytext so that’s it’s now different from the expected format, ServiceDesk mayfail to glean the needed meaning). Specifically, to deduce that particular language in a History refers toparts-stock used, ServiceDesk looks for the word “used“, followed by any twowords, then the words “from stock“ (as in “ used1 3363394 from stock “). On findingthis kind of a phrase, ServiceDesk deduces the quantity and part number of itemused, and makes corresponding entries in the form for you (actually, there’smore work to do in figuring the prices that should be inserted for such parts,as described later in this section).
Several of the Narda boxesrefer to information specifically about the machine that was serviced (i.e.,make, type, model, serial, purchase date and selling dealer). As you might guess, this information is takendirectly from any UnitInfoSheet that’s attached to the job, with each such itemof information inserted to the appropriate box on the Narda form (or Genericform, for those boxes that are applicable).
The Narda form also includes, you might notice, boxes fora “Servicer Number” and “Servicer State Number.” For this data, ServiceDesk looks to theQuickEntry template for whichever client is in the CustomerInfo block of theitem’s JobRecord. In other words, if youhave a QuickEntry template for Whirlpool, say, and the job has Whirlpool listedas the client (i.e., it’s their name and address in the CustomerInfo block ofthe JobRecord), ServiceDesk will look to the QuickEntry template that you’vecreated for Whirlpool. If it finds thatyou’ve listed a Servicer ID and Servicer State # in the spaces there provided,it will insert those same numbers into appropriate spaces on the Nardaform.
Also on the Narda formthere’s a space for a “Service Agreement Number.” Basically, if you’ve indicated a “ContractNumber” in the item’s JobRecord (like many other items in the JobRecord, thiswill typically have first been entered from the job’s initiating Callsheet),that’s the number ServiceDesk will place into this box for you (see page 59). Also, you may note that besides its ownpre-printed Number in the upper-right corner, the Narda form has an open spacedirectly below. This is for your own,internal job-identification number—which of course in ServiceDesk we refer tosimply as the InvoiceNumber. Thus,ServiceDesk will place its own InvoiceNumber, for the job, in this location,and print it to the form. This will beuseful, obviously, to help you refer back to the job when a Narda claim isreturned, paid, or there’s any similar action.
There are some other,miscellaneous boxes on the Narda form which ServiceDesk makes no effort tofill. If they need filled, you’ll haveto do it yourself, manually—which should be little effort, considering how few areleft.
Aside from those manymiscellaneous boxes, there are of course two large, multi-box sectionsremaining, in both the Generic and Narda forms. These are: first, the set of boxes that describe parts used; and second,the set where charges are totaled.
In regard to parts used,we’ve already mentioned that, for parts used from stock, the system deducessuch usage by reading through the job’s History (see several paragraphsback). That, of course, explains how itdeduces how many of which kind of parts were used (which it sensibly placesinto the appropriate boxes on your form). It does not explain how it deduces what price, for the parts, should be inserted in boxes indicatingsuch. For this deduction, ServiceDesklooks into either: (a) your MasterPartsPlan; or (b) your Journal of StockTransfers (see page 144). Specifically, if loading info to the Genericform, the system figures you must intend retailprice for parts used, and so gets this price from the item’s entry (whichshould include expected retail price) in the MasterPartsPlan. If, on the other hand, it’s loading info tothe Narda form, we expect that you probably need to list your cost on the part (since, as a rule, that’s what Narda-typeclients demand to have listed). So in thiscase, the system finds the most recent Journal entry showing use of the part,and inserts the price paid (as indicated in that entry) for the part.
While that describes thesituation in regard to stocking parts used, it’s obviously a different matterwhen dealing with parts special-ordered for a job. Here, it’s actually a bit more simple. ServiceDesk simply checks the PartsProcessfiles (both Current and Archived) for entries that correspond with the invoicenumber of the job in question. For any suchentries that show a date in the ‘Date Received’ box, the system figures youpresumably must have used the part, and so inserts its description, part numberand so on into appropriate boxes of the form. For price to insert, it looks for a value in the same entry’s ‘$ Sold’box, and inserts this into the appropriate space on your form. For Distributor Invoice Number, it looks inthe ‘Notes’ section of the entry. If, asthe first “word” in this entry, it finds text that’s all numeric (i.e.,“1568556” as opposed to “C1568556”) it concludes that must be the invoicenumber on which you purchased the part, and inserts it to the NARDA assuch. Regardless and in any case, someediting may sometimes be required. Iffor example a wrong part was ordered and received, the system may erroneouslyinclude its entry, as though used, within your form. Alternatively, a part may have been ordered,used and received without the expected processing through the PartsProcesssystem. If this occurred, it’s entrywill not be found and inserted for you. You’ll have to be watchful for such possibilities, and edit from withinthe form accordingly.
Finally, we are concernedwith how ServiceDesk fills the various boxes in either of the forms’ totaleditems columns.
In the Narda form, you maynotice, there’s a box (under the column of prices for parts used) labeled “SubTotal”. Here, and with obvious logic,the system simply places the total of the various parts prices that are listed above.
Aside from that simplematter, and in its last reading of the job’s History, the system looks to seeif there’s an entry there, as is made by the system when the job is finallyrecorded to the SalesJournal (see page 167). Specifically, it looks for this precise text“, ttl $” (as appears as part of anentry such as “3/15/00 13:04 BN: rcrddblld cmpltn in SlsJrnl, ttl $117.54”). Assuming that it finds that little snippet, the system figures you’veindeed made a SalesJournal entry on the job, and that it should be able to findsuch an entry within your SalesJournal. Thus, it makes a search therein. Assuming that it finds such an entry, it pulls the amounts indicated andplaces them into appropriate spaces on the form.
A question, in this regard,is what should the system do if it finds a parts total, as indicated in theSalesJournal entry, that differs from the total as deduced by adding the pricesfor parts as listed? To which figureshould it give deference as values are inserted to the form? In the case of the Narda form, there’s a boxfor you to fill-in your “Handling” fee on parts used. Thus, for this form only we figured it wassensible to deduce that any difference, between parts total as indicated in theSalesJournal entry and parts total as derived by adding actual parts, must be ahandling fee, and that value, if any (i.e., the difference between) is insertedto this box for you. In the case of theGeneric form, no such assumption seems sensible (nor is there a separate box for a so-called handling fee). So, if there is a discrepancy in this case,the system alerts you with a descriptive warning, and for the time-being placesa row or asterisks in the form’s PartsTotal box.
As you edit in either theparts description boxes or the totaled item boxes, you’ll notice that thesystem automatically does the appropriate math to adjust the carryovers foryou. As we’ve indicated elsewhere,however, the system is new, so it will not be too surprising if you discoverimperfections. If so, please let usknow.
A final caveat concerns the searches that are donewithin the PartsProcess Archive (to find parts special ordered) and theSalesJournal (to find totals charged). In respect to the first (and to conserve time searching), the systemlooks back no further than 300 records deep into the Archive (of course itsearches the current PartsProcess file in full). In respect to the SalesJournal, it searchesno more than 1000 records back. Inconsequence, if you’re trying to load data into a form from a job that wascompleted some significant time ago, you may find the particular items of datawhich correspond with these searches do not automatically fill-in for you. Of course, you can still type-in the relevantinformation manually. It’s just not aseasy or convenient.
Most of our clients face a uniform set of sales taxrates (i.e., one rate for parts and another for labor, regardless of locale)across their entire territory. Thismakes for nice simplicity, as typically the worst complication is having todeal with an occasional tax-exempt sale (see note 121 at page 167). However, we’ve had some clients who face theugly dilemma of different tax rates in each of the various communities theyservice, and sometimes different rates for different kinds of customers too. Thistechnical section contains information on how that kind of dilemma should beaddressed from within ServiceDesk (if yours is not such a situation, obviously,this section may be ignored).
To start with, let us reviewthe standard situation, where rates are uniform throughout a user’sterritory. In that instance, it would beyour job to first specify the applicable rates (for parts and labor) fromwithin the Settings form. In consequenceof this specification, the system would perform a verifying calculus each timea completed sale was entered from the SalesEnter form. Specifically, each time you entered thestring of numbers that indicates constituents in the sale and total, it woulddo its own calculation to verify that, with appropriate tax amounts added (asinferred on the basis of rates indicated in the Settings form), the enteredtotal reflected the proper summed amount. If the numbers did not balance, of course, the system would notify ofthe discrepancy and request correction.
So what can be done for theuser that faces many different rates, depending on locale where the service wasdone? If, as is allowed by the Settingsform, just one rate set were specified by this kind of client (i.e., one forparts and another for labor), the SalesEnter system would obviously not allowany sales to be reported—much less recorded—at any different rate. A real problem. Obviously, in solution we could create a more expansive mode forspecifying tax rates (more expansive, in other words, than is currently offeredin the Settings form)—perhaps a table, for example, that would allow you anunlimited 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 andthird columns. However, and as mentioned,some of these same clients have faced rates that vary depending on type ofcustomer, too. Setting up, additionally,with specifications for that would require a three-dimensional table, and whoknows what kind of flexibility for other clients facing still differentdivergent tax needs. After all wasconsidered, we thought it best to keep the specification system simple for theordinary ServiceDesk user that faces just a single tax structure, and makeseparate allowance for the user with special needs. That is what we have done.
The solution is implementedvia an option in the Settings form labeled ‘Allowfor divergent sales tax rates depending on locality, type, etc.’ Once this option is enabled (click on it thensave), you’ll find that the boxes for specifying a uniform tax rate are, logically,disabled. And now, when you go to enter completed salesfrom within the SalesEnter form, you’ll discover the system is much morepermissive. Yes, it will still sum theentered constituents and compare that result to the entered total, but now itwill allow an assumed tax rate (applied to all constituent parts) ranging from0 to 15 percent. Thus, so long as theentered total is at least the sum of the entered constituents, and is no morethan 15 percent above, the entry will be accepted and recording allowed. Whatever cushion it finds, if any (rangingfrom 0 to 15 percent), will be assumed as the tax amount that was appropriatelycharged on the sale.
All that is lost vis-à-visthe standard system, at this point, is that if the entering operator makes anerror (or the person who added the invoice did) that nevertheless keeps theconstituents and entered total within the allowable comparison/tax-rate range,that particular kind of somewhat smallish error (i.e., maximum of 15 percenteither improperly credited, or not credited, to tax) will not be caught byServiceDesk.
So far as operations that areintegral to ServiceDesk, this describes the solution completely. With that and nothing more, ServiceDesk willaccurately collect sales information, and stand ready to report on system-wide tax liabilities (among otherfigures) for any period wanted.
Of course, as the divergent-tax-situation useryou’ll face an important further need. You still must separate yourtax liabilities between and among the various jurisdiction in which you’ve doneservice—so you can report on those liabilities and send payments asrequired. While the ServiceDeskSalesJournal will show the tax amounts you’ve calculated on each job (regardlessof locality), it does not separately indicate the location where each job wasdone, nor is there presently provision within ServiceDesk (even if theSalesJournal did include such information) to break out sales and tax liabilityon the basis of locality. Again, we donot want complicate the general system unduly for the normal user.
Instead, as anotherconsequence of specifying that ‘Allow fordivergent sales tax rates depending on locality, type, etc.’ option in theSettings form, the system will silently create a mirrored SalesJournal file foryour own special use. Specifically, eachtime you enter a completed sale via the SalesEnter form, the system will nowmake not only the standard entry into the ordinary SalesJournal, but alsoanother entry into this separate file. And this entry, unlike those in the standard SalesJournal, will includethe zip code for the job in question (along with department if you’re usingthat option). And, unlike the standardSalesJournal, this file is in a format you can easily access from any spreadsheetor 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’sneeded for you to break out your sales tax liabilities between and amongdifferent jurisdictions, and compiles it in this one file. It’s left to you to import this file/data intoan appropriate context (most likely a spreadsheet program such as Excel) andthere create a system that, using the data, makes reports concerning each ofyour separate liabilities.
Some caveats. We do not use this system in our office, andhave had little feedback to date fromusers. As presently written, entries withinthe secondary SalesJournal are created only via the SalesEnter system. If you make revisions to the SalesJournal from the SalesView form, they willnot automatically be reflected in the secondary journal (if important, youshould mirror them manually from whatever spreadsheet or similar context you’vesetup for manipulating the file). Andentries made while reporting on payments to or changes in accounts receivableare not at this time programmed for addition to the secondary journal. If you find these operations are important toyour use, please let us know and we’ll be happy to accommodate.
You’ll probably never have the slightest need forinformation in this section, and if you do it will have become apparent fromother contexts that will have cross-referenced you to here. So, if you’re just reading through, pleasedon’t bother reading further here.
The reason for this discussionis because we’ve occasionally had trouble getting various of theServiceDesk-intended right-click functions to operate when they involve atextbox. As an example: right-clickingin a Callsheet address box to Item-Locate to the DispatchMap. The reason: beginning with Windows 95,Windows itself uses the textbox-based right-click to enable a set of editingfeatures. This can potentially interferewith ServiceDesk using the operation for its own purposes. However, we believe we’ve solved the problemin all contexts that it formerly existed. We provide the explanation here, and discussion of possible alternativemethods, in case we are wrong and, in fact, you encounter any suchdifficulties.
In specific regard toright-clicking on a Callsheet address line to item-locate, you may insteaddouble-left-click thereon, or right-click on the label that identifies thetextual area which includes the address line (i.e., either on the label thatreads "Customer Name, Address and Phone Numbers" or on the onereading "Location Name, Address and Phone Numbers"). Any such action will produce the sameresult. Similarly, in the alternative toright-clicking on any of a Callsheet's telephone number fields to auto-dial,you may instead double-left-click thereon, or you may right-click in the openspace immediately below. The same holdstrue for equivalent actions within any JobRecord as viewed from the JobsCurrentform.
A trio of alternative methods for the same functions mayseem odd, but there's a historical reason for it. When first encountering the problem withintroduction of Windows 95, we quickly put in the double-click option. But we dislike the double-click for actionsthat are very frequent (it’s just more effort), so before long we added thealternative right-click methods that involve clicking on non-textboxareas. Then, over an even longer time,we developed solutions to make the original right-click-on-the-textboxoperations work. But still, we’ve keptthe alternatives in place just in case—and because there’s a number of clientswho learned ServiceDesk when double-clicking was the only method. We don’t want to force them into re-learningold methods.
As mentioned elsewhere, it is not intended thatServiceDesk will replace whatever system you have used (or, if you’re a newcompany, will use) for writingchecks, documenting miscellaneous operating expenses, figuring depreciation,and compiling financial reports such as Income Statements and BalanceSheets. It is not designed, in other words,to fulfill the functions involved in financialaccounting—at least not mostly. However,you should note that it does, nevertheless, collect and process and compileseveral of the items of information that will need to be inputted into whatevermethod of financial accounting you otherwise use (primarily it collectsinformation that’s associated with the revenueside of accounting). In particular, itcollects and compiles information on your sales, accounts receivable, fundscollected, sales tax liabilities and inventory (this last being an exceptionfrom its “revenue-side” focus). Thisinformation will need to be inputted into your system of financial accountingas often as you compile financial statements (most likely once every month, butperhaps only once per year, depending on your company’s preference and policy).
With but one exception, yourServiceDesk Sales Report (see page 172) collects and compiles foryou all the information that needs to be moved from ServiceDesk into yourseparate system of financial-accounting. It even blue-highlights, for you, the particular figures that need to beso moved:
As you can see, there areonly a few such figures. These figuresconcern, in particular, items related to the revenue side of your accounting, and exclude the one cost-side element that must be handled separately(specifically, cost-of-goods sold). Thefigures are such that, if you use an outside accountant and simply provide thisreport to him or her, he or she should understand precisely how to handleit.
Regardless of whether you dosuch a simple hand-off to another party or not, the general concept is you willrun this report at the end of each accounting period — so as to provide asummary of the activity that occurred during that period, for feeding into yourfull-accounting system.
If you do not in fact employan outside accountant, you will need to do thatfeeding-into-full-accounting-system process yourself. If your full-accounting system is QuickBooks,you may notice there is an “Export toQuickBooks” button (see above illustration, and look for the hot-pinkcolored button toward its lower-right). It’s designed to do that “feeding into” process for you. If you use some system other than QuickBooks,you’ll need to do the “feeding into” manually. Since there are only a few figures, there is little labor involved. However, you are likely to need conceptualassistance, which we’ll here provide.
Of course, there is thatother, expense-side element (cost-of-goods-sold), and it must be dealt with aswell. In the following sections, we’lldiscuss each of these matters in greater detail.
We’re discussing this first,because the vast majority of ServiceDesk users (and of North American smallbusinesses in general) use QuickBooks.
Aside from that single,expense-side, cost-of-goods element, integration with QuickBooks is eminentlysimple.
Entering the Standard “Revenue-Side”Data, into QuickBooks
Just run that SalesReport (as above described) at the conclusion of each accounting period, thenclick on the button to Export to QuickBooks. Then, from within QuickBooks, click on File, then Import, then pick the file you created by exporting fromServiceDesk.
In result of the above,QuickBooks will create a set of internal accounts, each designed toappropriately receive the same values as are blue-highlighted on the face of ServiceDesk’sSales Report. And it will make internalJournal entries, inserting values as applicable to each such account.
As an example, QuickBookswill create an internal account called “SD-TalliedSales.” When you then run anIncome-Statement report from within QuickBooks (and for a period that includeswhen you did such an export/import data movement), the report will show (as adirect-identified Sales-Income item) the appropriate amount from SD-TalliedSales.
For the main part of yourjoining ServiceDesk-to-QuickBooks work, all you must do is the above. It is truly that simple.
Entering Bank Deposits, into QuickBooks
One small detail involvesentering into QuickBooks when you’ve made a bank deposit — specifically, ofmonies that ServiceDesk managed the collection on (hopefully, you will haveindeed used ServiceDesk’s deposit-preparation machinery to manage building thedeposit tape, and to internally document each items’ disposition, etc., but thisdiscussion remains relevant to how the entry needs to be made into QuickBooks,regardless). When you enter a bankdeposit into QuickBooks, QuickBooks will demand to know the source of the moneybeing deposited (i.e., the “account” that should credited as the source). Where the money was indeed managed viaServiceDesk mechanisms, you should indicate the source as “ServiceDesk-Tallied Funds Received” (this is another of theaccounts that the ServiceDesk-to-QuickBooks export-import process will havecreated for you).
As you do the above, you maynote a small oddity. It stems from thefact that you will typically be making these deposits on a periodic basisthroughout any accounting period, yet the transfer of reckoning fromServiceDesk to QuickBooks (i.e., ServiceDesk telling QuickBooks what funds ittallies itself as having received during a period) will not occur until the endof that period. For example, supposethat in a given month you collect $40,000. In each of four Fridays of that month, you deposit $10,000 of that $40,000. Each time you make such a deposit, you claimthe funds came from “ServiceDesk-TalliedFunds Received,” yet it’s not until afterward that the entry of $40,000 ismade into that account. For this reason,it is normal that, during the course of any accounting period, your depositswill have the effect of drawing that account into the negative. It will naturally be brought back to zero byvirtue of the export-import transfer, at the end of the period. This is normal.
Entering Cost-of-Goods-Sold, intoQuickBooks
The cost of your parts used(and of merchandise sold, if you are also a dealer) is the one element offinancial accounting information (and as managed by ServiceDesk) that is not onthe revenue side, and which requires handling outside the Sales-Summary and/orits export-import movement of data to QuickBooks.
In fact, ServiceDesk does notmanage cost-of-goods-sold in any direct sense. Actual outflow of funds, to “pay” for these costs, is indeed manageddirectly by QuickBooks (or other separate system if you use something else), asyou write checks to your vendors, typically as dictated by month-endstatements, and usually paying for purchases as made in each precedingmonth. However, just because you arepaying for a part via QuickBooks does not mean you are simultaneously, via suchaction, registering a cost-of-goods sold. In a typical scenario, it is indeed quite otherwise. Most often, such a payment converts cash inyour bank account into an added inventory valuation in your inventoryaccount. Both are equal-value assets sofar as accounting is concerned, and the conversion has no effect at all on costof goods sold.
So, though the money is beingspent via QuickBooks, it does not mean QuickBooks directly possesses what itneeds, for the sake of calculating cost-of-goods-sold. For that (and at least if it’s to do so withprecision), QuickBooks needs information from ServiceDesk. Any of several methods may be used.
If you are using anyaccounting system other than QuickBooks, general principles remain the same asdescribed in the prior section. The oneand major difference is there will be no export-import facilitated transfer ofinformation for you, from ServiceDesk into your other system. So, you’ll need to make these entriesmanually, as opposed to automatically. Since there are only a handful (or so) of figures, this is notlaborious, and it only needs to be done at the conclusion of each accountingperiod. In principal, it’s particularlyeasy, since all but one of the relevant summary figures are nicely flagged foryou in the ServiceDesk Sales Report(please review the prior section for details on such flagging).
The one challenge you arelikely to encounter, if you are not an accountant, will be in understanding preciselyhow this handful of figures should be entered into your accounting system. The main purpose in this section is to assistyou in such understanding.
Particularly since we do notknow what other system you will be using, we cannot give you precisedetails. At best, we can assist you inunderstanding such general principals as are involved. Thus, what follows here is designed to giveyou at least minimal acquaintance with some general accounting basics.
Every accounting system has a“Journal” or “General Ledger” (terminology varies). This is where entries are made that describeeach event that changes the general accounting picture (e.g., earning money bycompleting a sale). Your basic purposewill be to make entries to this Journal (i.e., as exists in your own accountingsystem) to describe the summary information that needs transferred fromServiceDesk.
Whether it’s apparent fromthe surface or not, all modern accounting systems (“modern” here means sinceColumbus) have as their foundation what is referred to as “double-entry bookkeeping.” In this context, double-entry does not meanentering the same info twice. It refers,rather, to the fact that every accounting-significant event has an effect in atleast two different areas of accounting interest. When you earn money by completing a sale, forexample, you’ve added to your sales (one area of accounting interest), andsimultaneously have increased either your cash (if the sale was paid for at thetime) or have increased your accounts receivable. It’s possible you did even a little ofboth. All accounting events have thisdual-effect attribute (though, depending on circumstances, on different areasof accounting interest, and in difference ways). The double-entry system was developed toassure every entry properly balances across both sides of this inevitable dualeffect. It was a great invention.
Anyhow, we explain that as afoundation because, depending on the nature of your accounting system, you mayneed to make an entry in the general ledger where this double-entry mode isdirectly evident. Alternatively, yoursystem may offer you an interface that somewhat hides or disguises theunderlying double-entry foundation. Regardless, you’ll be better enabled to understand the ultimateinformation that needs to go in, by reading onward.
Suppose that in a givenaccounting period you produce a Sales Report with the following figures (theones underlined are the ones that need moved to your system of financialaccounting).
Again, though your systemmay have an interface that presents you with a different path for the purpose,the following are entries that will ultimately be going into its general ledger:
If you’re not an accountant,please try not to be troubled if some of the above seems mysterious. It may seem odd, for example, that an increase in cash is recorded as a“debit” rather than as a “credit.” Regardless, it’s how it works (in beginningaccounting classes they repeatedly drum into your head that the words “debit”and “credit” have no inherent meaning; they are simply titles given to the two different columns).
Now, for some explanation:
In the first rectangle/entry above, we are simplydocumenting the fact that $47,187.83 has been fed into our Cash on hand (whether in the bank or otherwise it does not matterso far as financial accounting isconcerned, please look at the example Sales Report to see where these figureswere pulled from), and that our AccountsReceivable has decreased (based on the net of amounts going in and out fromit) by the amount of $1,134.20.
Plus, we are indicating theamount of $44,854.30 should be credited to our Sales account, and $999.32 to our Sales Tax Payable account. Thus, with these four entries (all of which in sum balance) we’ve inputall the information that is directly related to our sales for the month.
Regardless, there are a fewother matters the ServiceDesk Sales Report compiles, besides those so directly-relatedto sales. This is, in particular,because it also manages your accounts receivable and your funds collected. In either area, other events may occur. For example, some of your Accounts Receivablewill prove to be uncollectible, and thus will need to be written off as baddebt. There’s provision withinServiceDesk for doing this (see page 177), but naturally, the fact ofhaving done so needs to be input to your system of financial accounting. Also, it will occasionally happen that you’vecollected funds, yet they turn up missing, or otherwise cannot ultimately becollected upon (rejected bankcard numbers, bounced checks that can’t beremedied, etc.). In such cases,ServiceDesk again provides an internal method for documenting such losses (seepage 158), and a summary of suchactivity is likewise included in its Sales Report. And again, the amounts in summary must beinputted to your system of financial accounting.
The second and third exampleentries, above, illustrate such needed entries. Again, you may compare the numbers shown to their source from within theexample Sales Report. In the first suchentry, basically, we are reporting having incurred $75.00 as a Bad Debt Expense, along with acorresponding reduction in AccountsReceivable. In the second such entry(last in the above examples), we are reporting having incurred the loss of$45.00 in Missing or Unreedemable Funds,and a corresponding reduction from our Cashaccount.
Again, regardless of thesystem you use, our point is these are kinds of entries that must ultimately gointo its general journal. Your systemmay present you with an interface, by which to provide the information, whichessentially hides that journal. But thisis the fundamental information it needs, regardless.
Other entries may be needed as well, depending oncircumstances. For example, if you grantdiscounts to some of your clients for more rapid payment (see page 158), theServiceDesk Sales Report will similarly highlight the amount thus granted (itsdesigned to show and highlight everything as relevant, on the revenue side). Suppose, for example, you’re looking at aninclusion which shows that, during the relevant period, you granted $158.32 indiscounts. A suitable resulting entry,to your system of financial accounting, would look something like this:
.png)
You should notice thesame principles apply, as with the other entries. We are indicating the simple fact we’veincurred an expense of $158.32 as a discount granted, and that it reduces ourcash in the same amount.
Again, there is nothing complex. The general idea is to get informationregarding these financial activities—as recorded and summarized by ServiceDesk(plus highlighted there for you)—into the particular system of financialaccounting that you use for everything else. Though particular principles of financial accounting might seem a littleweird, it’s just a few figures, and the basic concepts of simple informationflow are very simple.
There does, of course, remain the matter ofaccounting for cost-of-goods sold. Again, cost-of-goods-sold matters are not tabulated for you in the ServiceDesk Sales Report, and must behandled separately. In general, theoptions for such handling are precisely the same as if you were usingQuickBooks (see prior section). The onedifference, as relevant to the present discussion, is you may want tospecifically know how an entry reflecting cost-of-goods-sold would look, whenentered to the general ledger.
Suppose (using whichever basis is preferred), youhave calculated that within the accounting period cost-of-goods sold summed to $17,000. In such a case, your general ledger entrywould need to look something like this:
.png)
Again, it’s rather simple, at least if you avoidallowing it to intimidate you.
If it nevertheless feels even slightly intimidating,try to remember that accountants require four years of college. Also remember that, regardless, the items ofinformation that need transferred from ServiceDesk are very few andsimple.
If the accounting end in itself seems too difficultregardless, perhaps you should hire an accountant, to at least help you getsetup on the accounting end. He or shecan read this section to learn what ServiceDesk has to input on its end ofthings, and teach you the process that’s involved within your own accountingsystem. Once so taught, it should be avery easy (on a once-per-accounting-period basis) to make the entries needed.
If you are at home or on vacation and want todo work in ServiceDesk (or within anything else that’s installed-on or is otherwiseavailable from within your office desktop), it’s very easy. Just setup an account (these are eitherinexpensive or free) with LogMeIn.com, GoToMyPC.com or any similarservice. Then, within that account,setup your desktop to act as a host. Once that’s done, you can be at any computer anywhere in the world thathas internet access, and within about 60 seconds (via a rather simple loginprocess) find yourself with power to remote-puppeteer your office desktop — withpower and flair that’s virtually the same as if you were physically there.
It’s a truly terrific capability, and it’s hard forus to imagine why any owner or manager would not want to avail themselves ofit.
Beyond that, you may have particular employees thatwish to work from home. If any suchemployee is also equipped with an office computer, that computer can be setup(under your same LogMeIn or similar account) to also act as a host, credentialssetup for it, those credentials provided to the employee, then the employee canaccess that computer from anywhere, and do remote work. If it’s a person that doesn’t otherwise have anyphysical presence at the office (and therefore there is no computer thereassigned to him or her), it’s possible you might have a spare box that’ssitting around, and can be used for the purpose.
All the above is great, if your need for remote usedoes not extend beyond the kinds of circumstances described. However, many businesses wish to accommodateremote use on a larger scale. As aparticular example, some businesses wish to setup with multiple offices (e.g.,the main office, plus a satellite or two). Some may just want to have multiple remote users, and without eachrequiring a dedicated “slave” box at the office (i.e., which they canremote-puppeteer via something like LogMeIn). The remainder of this section will discuss the optimum strategy forachieving such a further purpose.
To start, let us state as a general principle: Justbecause multiple other persons are at one or more different locations (inparticular, as compared to your main office), it does not follow they should beunable to work within the same program and data set — as if they were in themain office.
Regardless, the situation is at least morechallenging than where everyone is working within the same premises. It requires a more extended solution, whichis our remaining topic here.
We will begin by contrasting the more typical,single-premises situation.
Where there is physical proximity of all direct workstations(i.e., same building or building complex), they will in almost every instanceby configured to “talk” within one and the same Local-Area-Network (akaLAN). This works great. Communication across a LAN is easilyconfigurable, and is super-fast. Whereall stations are in the same LAN, ServiceDesk setup is simple. You can go thick-client or thin (generally werecommend thin). To enhance yourunderstanding, let’s briefly discuss each.
In the thick-client scenario, you have ServiceDeskinstalled at each station. When youclick on the icon to run it, your local processor (CPU) finds the program fileon your own local drive, pulls its contents from there, loads the same into itsoperating memory, then proceeds to execute the program according to itsprescriptions. Much of this executioninvolves reading from and writing to data files that are contained on theparticular computer you’ve setup to act as a “data server.” This might be an ordinary PC. It could be a Linux box. It may or may not be additionally runningServiceDesk itself. For the purposedescribed here, it is simply a “box” that holds the desired data in a set offiles on its own hard drive.
The thin-client scenario is not very muchdifferent. Here, you simply don’t have alocal install. Instead, when you clickon the icon to run ServiceDesk, your local processor reaches to grab aninstance of the program file (again, to load into itself) that, instead ofbeing stored on your local drive, is instead stored on the very same machinethat’s acting as your data server. Justas in the thick-client scenario, that data server can be almost any kind of box(e.g., a plain PC, a Linux box or even a dedicated Windows server).
Hopefully, the above helps you form a good pictureof a standard, within-LAN setup. We needthat picture to distinguish from what’s practical when you have multipleoffices (or even just one or two remote users) that are not in close physicalproximity.
In this latter case, you don’t have the same advantagesas when within a LAN. Quite obviously,your communication between distant offices cannot be through a LAN, becauseLANs only extend across more limited spaces. It must instead be via the Wide-Area-Network(aka WAN) — which (and in case you did not know) is simply another title forthe Internet.
In comparison to a LAN connection, WAN connectionssuffer many comparative debilities:
Items 2 and 3 can be overcome by setting up what’scalled a Virtual-Private-Network (aka VPN). Essentially, it’s a way of configuring security and connection elementsat both ends of a desired connection (i.e., from within Office1 and Office2) sothat communications between them are as secure as in a LAN, and areindividually as easy to setup and manage (this is aside from the very largecomplexity as involved in first setting up the VPN itself).
Unfortunately, a VPN does nothing for Item 1above. In other words, even with a VPN,the speed of a WAN-dependent connection remains many times slower, as comparedto a LAN connection.
For many applications, this speed issue is not aproblem.
Suppose, for example, you are locally runningMS-Word, and you’re in an office that’s remote from the applicable datastore. When you open a document, thedata that describes the document will be pulled from the data store,transported across the WAN, and placed into RAM on your local machine, where itwill then be manipulated as you do your work. There will be no need for ongoing communication, with the data store, asyou work on the document. The next needwill arise only when you save the document, at which time your saved work willpass through the WAN, back to the data store, to there be saved. Unless it’s a rather large document, the timeas involved in these two movements will not be onerous.
Unlike MS-Word, ServiceDesk operation involves veryfrequent, repeated (indeed almost constant) back and forth access between theapplication and its data store (including a multitude of files that over timebecome rather large). Because of this, if the processor that’s runningServiceDesk is in fact across-the-WAN from its data store, you will seeServiceDesk crawl. It will be ugly. It will be virtually unusable. It is not practical.
So what’s the solution?
To be very specific, how can we make it so theparticular processor that’s running ServiceDesk has no less than a LAN-intimateconnection to its data-store, while still allowing some of its users to work ina remote office?
At first blush, it might seem it’s impossible toachieve LAN-intimacy, between a remote office where instances of ServiceDeskare evidently running, and adata-store that’s in fact at a distant location.
Did you notice our emphasis on the word“evidently?”
There’s a trick, and it involves a special thing“Server” versions of Windows are configured to do, that ordinary Windowsversions are not.
You’re likely familiar with the fact ordinaryWindows can be setup with multiple user logins, each with its own desktop thatplays its own set of applications. Ofcourse, an ordinary Windows setup will only “play” one such user desktop at atime.
Though “Server” versions of Windows have some otherdifferences, the most significant difference is they are not subject to thisone-desktop-at-a-time limitation. Indeed, a “Server” version of Windows can “play” many, many userdesktops simultaneously.
Typically, of course, even a server version ofWindows is direct-connected to but asingle user interface (i.e., mouse, keyboard and monitor). You might call this desktop the “standard” or“native” one. The others are generallycalled “Virtual Desktops.”
So, where are the user interfaces for thosemultiple “Virtual Desktops?”
Essentially, any other computer interface can pluginto any of a server’s virtual desktops by using a technology called “RemoteDesktop” (aka RDP). Remote Desktop isautomatically a part of every modern Windows system. If you’re on any such box and have the credentialsto login to any virtual desktop as being played by any Windows server anywhere,all you need is to run your own computer’s Remote Desktop utility, put in thecredentials, and inside of seconds you’ll be running that virtual desktopthat’s “playing” on a server elsewhere — in spite of the fact that server maybe located many thousands of miles distant.
And here’s what’s particularly great.
So long as that server is LAN-intimate with anydata-store that an application within your own virtual desktop is running(e.g., ServiceDesk), the application will perform superbly. Typically in these setups, indeed, thedata-store is on the server itself — i.e., the same machine, which makes iteven better than LAN-intimate.
So, that’s the trick. Essentially, ServiceDesk runs on the server(in multiple instances upon multiple virtual desktops), with workers in yourremote office remote-pupeteering it (indeed, not just it, but their entiredesktop environments as well). Indeed,they can do the same from their homes, or any location desired. Plus, there is no need for an underlying (andcomplication-causing) VPN. The RDPtechnology takes care of security.
How do you go about setting up this kind ofconfiguration?
Surprisingly, it’s not difficult. We have a number of users who’ve done itthemselves. We have others who’ve hiredprofessionals. There are a plethora ofcompanies that will lease you such server capacity, online. Even here at Rossware, we offer to providesuch online server services for you. Ourservice is called Rossware Server Solutions (RSS).
All in all, our purpose inthis document has been to help you understand the general concepts. We hope it has succeeded.
As a general matter, ServiceDesk should work with any network system that allows onecomputer to read and write data from/to another’s hard drive, and through aWindows-based interface. There are butthree complicating factors, each addressed in this section.
If you’ve newly setup a network, you may go to WindowsExplorer, look under ‘Network Neighborhood,’ and happily see that, sure enough,you can read what’s on the drives of every other computer in the network Very neat. You might think this is allthat should be needed in order for ServiceDesk (or any other Windows-based application)to access those other drives. In fact,you’d be wrong. While Windows Explorermay be able to “see” and show you the other drives without further work, thosedrives will remain invisible to most applicationsabsent a little thing called “Mapping.”
What is mapping? Basically (and in a nutshell), it’s theprocess of designating from one computer that all or part of its drive isavailable for “sharing” with others, giving that shared offering a “ShareName,” then, from another computer, linking to that shared offering with aDrive Letter Designation.
How do you do this?
As a short answer, we mightsay this is not a ServiceDesk topic; it’s a Windows topic, so don’t bother us;look in your Windows documentation instead. However, we’re a little nicer than that, and will here give you a brief“how to” (suitable at least for Windows 95/98; later Windows versions mayslightly vary) as follows.
As a beginning matter,remember there are two major steps: first, making the wanted drive availablefor sharing from the computer you'll be using as FileServer (we'll assume herethat it's that computer's Drive C:); and second, setting up any and everysecondary computer to read from that FileServer's Drive C:.
To accomplish the first step(making the FileServer's Drive C:available to other computers), click on the Networkicon in that computer's Windows ControlPanel (accessed by clicking on Start,then Settings). Under the Configurationtab, click on File and Print Sharing,and from there assure you're configured to allow others full access to yourfiles. Next, using either Windows Explorer or the My Computer utility of that computer,select Drive C:, then click on Properties in the File section of the Menu. Now, under the Sharing tab,provide a Share Name (something simple like "DRIVEC" worksfine). Finally, select Full access, then click on OK. Assuming your network is otherwisefunctional, your FileServer should now be ready to share the entire contents ofits Drive C: with other computers.
For the second step, your other computers need not justto see the FileServer drive from across the network (a basic assumption innetwork functionality) but, more critically, will need a Drive LetterDesignation with which to reference it. This is the same kind of designation as in 'A:' for your floppy drive, for example, or as in 'D:' for your CD drive—only here you'llbe using a different drive letter than any already used. To assign this Drive Letter Designation atany workstation, first run Windows Explorerfrom that station. In the left-handcolumn, locate the Entry labeled “Network Neighborhood.” Click on it to expand and look within itscontents. Once you have there locatedthe other drive that you wish to map locally (presumably the one being used asFileServer), right-click on it. In thelittle drop-down menu which then appears, select “Map Network Drive.” Windows will then produce alittle box in which you specify the particular drive letter you wish toassign. Make your selection (we use S: as a reminder for Server, but youcan select any letter not already used by an existing drive). Also check to true the box labeled “Reconnect at Log on,” then click onOK.
Under Path type in the actual path for the drive—as revealed when youshowed it expanded under Network Neighborhood over in Explorer's leftcolumn. When typing in this path, usetwo back slashes before the computer's name, then one before the share name,with no spaces between (e.g., as setup in our office, we use \\SERVER\DRIVEC).
With this accomplished, youshould now see the newly-mapped drive listed in Explorer's left column, in adirect line below (i.e., in the same hierarchy of listing) as My Computer. But here, as opposed to the computer's merename listing under Network Neighborhood,the description will include that all-important Drive Letter Designation. It's in parenthesis following thedescription, and it's proof you've accomplished your task.
As final proof, you may runServiceDesk, bring up the Settings form (Crtl-F1), and click the down-arrow inthe box labeled ‘Drive Designation forServiceDesk Network FileServer.” Themapped drive should appear in the list. Indeed, assuming that it was properly mapped, it must appear within this list.
Bear in mind this second part must be done on each and every computer that you’reusing a workstation (i.e., each that will be reading the common ServiceDeskdata files from elsewhere). Simplybecause you’re mapped the shared drive to one station, it does not mean thatthe next station is similarly ready. This work must be done on it too.
For security reasons, some users have not wanted to makethe entire contents of one computer’s Drive C: available to other stations inthe network. They’ve wanted, in otherwords, to limit the shared access to just the particular folder that containsthe common ServiceDesk data files, while preventing shared access to anythingelse. With the release of Version 3.8(74), this is now possible.
To setup for this, go throughthe mapping process just as already described, except instead of designatingall of Drive C: for sharing, designate only the \SD folder (which, obviously,will need to have been setup already on the applicable machine).
ServiceDesk copes with thisdifferent setup as follows. Normally,when a full drive is shared,ServiceDesk looks for a root folder within that drive called \sd, and then forthe various sub-folders (under \sd) that should be created when ServiceDesk isinstalled and first run. The differenceis, when you share the \sd folder itself, itdoes not show when ServiceDesk does it’s standard look for appropriate folderstructure. Instead, each of thesub-folders show as though they exist on a root level. The solution, if ServiceDesk does not “see”an \sd folder on the root level of whatever drive is designated as FileServer,it looks for what’s normally the sub-folders, but on an apparent root level. If itfinds these, it assumes that it’s dealing with a folder-only shared situation,and reacts accordingly.
Until release of the samerevision as mentioned above (3.8 (74)), it was always our expectation inServiceDesk that each station would keep and use its own, local copy of variousoperating files, including the program file itself (servdesk.exe), the filethat instructs the system in the wanted format for printing invoices(*******.prg), and each of the five CstmrDbase indexes. The reason for this strategy is to maximizeperformance. If a station has to go tothe server for each of these files (and if multiple stations are going to theserver simultaneously), there may be little delays and pauses as the serverworks to keep up with demand.
In general, the standardsetup works very, very well. However,the old-fashioned setup of having acomparatively powerful central computer with relative “dumb” terminalsconnected is making something of a comeback, and at least one client has beenfound flirting with the idea of adopting such a system. If this is the system, it becomes almost necessary to keep the operating files(as opposed to merely the data files) at one, central location.
Plus, there’s a practicaladvantage, for there’s some amount of overhead that goes into keepingup-to-date operating files on each ofvarious machines. Every time you updatethe main program file, for example, updated copies need to be transferred toeach station. When you create or revisethat *******.prg file, each station needs its own copy. When the CstmrDbase indexes are updated, eachstation needs its own set of copies. Andso on.
For reasons of these impetii,we’ve now made the system workable with a single set of Server-based operatingfiles. The trick to make it work is verysimple. From any station, simply run theparticular servdesk.exe file that’sfound on the server (rather than one that may or may not have been installedlocally). When started, ServiceDesklooks to see what particular drive it’s being run from. It looks to that drive for other operating files—even as it continues to looklocally for strictly localinformation, in particular the file that keeps track of each station’s local settings.
We do not yet know of anyoneusing this option. If you choose to doso, please let us know how it works.
The majority of ServiceDesk clients have ranged in sizeanywhere from one to ten trucks. If youbegin to get larger than this, you’ll probably have more than one dispatchercontrolling all those many techs. Asthese dispatchers contend with their respective tasks, they’ll likely noticethat the DispatchMap becomes so cluttered (having such a large quantity of jobsdisplayed) that its usefulness is compromised. To deal with this situation, we’ve developed what we call Focused Dispatching.
The general notion is very simple. You’ll likely want to have one dispatcherconcentrate on one portion of your territory and set of techs, while anotherconcentrates on a different area and set of techs.
The method we’ve designed forServiceDesk to accommodate this is, at this point in time, very basic. Indeed, the one accommodation it directlyprovides is that it allows you to define a focus-linkbetween a particular office person (probably a dispatcher) and a set oftechs. With this link established, whenthat office person goes go her DispatchMap, all the non-focus group jobs willbe, essentially, grayed out. This makesit easy for that dispatcher to focus only on the set of jobs and techs assignedto her.
To define this focus-link isvery simple. It’s all done within theSettings form. The idea is to place a“third word” after each applicable person’s name—that word being a number whichindicates the focus-group-number towhich that person is assigned.
.png)
More specifically, you canuse any number you want for each focus group, but if, for example, you’replanning to divide your staff into two such groups, it would probably make mostsense to call them groups ‘1’ and ‘2’ (though, so far as ServiceDesk isconcerned, it does not matter so long as you use any whole number).
When ready to place each ofyour techs into a focus group, you should go to the Settings form, and withinthe ListOfTechNames there (purple section, net-wide settings) append eachtech’s name with the focus-group-number that you wish to assign him to. Remember, this number must be arranged as thethird word in the name line (hisfirst and last name constituting the first and second words).
With that task having beenaccomplished, the next is to designate each of your dispatchers according tothe particular group they will focus on. For this purpose, you’d probably assume you could just go to each oftheir names within the ListOfStationNames, and similarly designate there, muchas we just did within the ListOfTechNames. While you could do that, itwould not have any operational effect within ServiceDesk. Instead, to designate that a particularoperator is assigned to a particular focus group, ServiceDesk looks at a local value: specifically, the localStationName as designated in the upper right-hand corner of the greensection. There (note that, since this isa local setting, it must be done atthe particular machine to which the dispatcher is assigned), you can append anumber, after the dispatching person’s name, matching the focus group that youwish to assign her to.
As you can see, the strategy for setting this up isindeed simple—and the result is simple too. The only thing, that occurs differently on an operational level is that,on a station where the operator is assigned to a focus group (as in the aboveillustration), jobs assigned to techs from any other focus groups will, asstated, be grayed out when viewed from within the DispatchMap.
In addition to the above, auser might choose to do other things. For example, you could setup each dispatcher’s station so that the“home” position on the DispatchMap is centered toward the geographic area thatis their focus (for instruction on how to do this, if wanted, consultRossWare).
Also, if the need shouldarise, we might in the future do other things to the programming itself. We might write code, for example, that wouldmake a job by itself default to one group or another, without requiring that itfirst be assigned to a particular tech within that group (note that at presentthat’s the only basis of designation for the job). We’ll welcome feedback on whether you haveany such needs.
The average service officelogs a lot of time in telephone conversation with customers. It’s a significant expense, and not very efficient —from either the customer’s or company’s perspective.
A few years ago we got tothinking, what if a lot of this could be automated? What if, instead of having to talk to someone in your office to handletheir needs, your customers could manage them independently, via interfaces onyour website? The concept was so great,we had to pursue it. Our CyberOffice set of functions is theresult.
In a nutshell, CyberOffice isa set of “plug-ins” for your website where customers can attend to much oftheir business with you, including such matters as:
All of these “plug-ins”automatically integrate with ServiceDesk within the office, so — whatever yourcustomer does online — the result shows in ServiceDesk. Plus, whatever you do within ServiceDesk thatis relevant to your customer needing to see online, ditto, it’s available therefor your customer.
The system also involves emails, auto-generated via mechanismswithin the office to link the customer to various of the website interfaces, asappropriate. After parts arrive, forexample, and email will generate (only with operator consent), informing thecustomer they are in, with a link that takes them to the “plug-in” interface onyour website where they are permitted to re-schedule. When you’ve worked out your appointments forthe next day, email reminders can then be automatically sent (again, with userconsent), and it’s these reminders that ask each customer to “link-to” another“plug-in” interface on your website, where they are able to confirm (orre-schedule, if need be).
The functions go on and on, andthe whole system is available at the minimum cost of just $10/month (total costmay be greater, depending on usage rate). We don’t think it makes any sense not to use it. Just call when ready, and we’ll send you asetup email.
The modern world is a great place, and we’re glad tolive in it.
Up until pretty much the endof the last century, if you were a consumer and called a manufacturer forservice, the rep would typically ask for your zipcode, type it into a computer,and get the contact info for a handful of independent companies who couldprovide the service within your area. She’d read off some names and phone numbers, you’d write them down, andit was then up to you to call one or more, seeking the needed service.
The first big change occurred in result ofcooperation between ServiceBench and Whirlpool. Together, those companies realized the consumer was not left feeling allthat well served when, after first calling the manufacturer, they then have tomake even more calls before finally receiving service. They got to thinking: “What if a manufacturercould schedule its consumers right off, during that first call, even if for anindependent servicer?” By and by, theyput together a system to make it happen. Basically, ServiceBench setup a web-interface for each of Whirlpool’sservicers. On this interface, the servicerswere supposed to keep ServiceBench informed of which zipcodes they still hadvacancies for on which days. Thisinformation passes to Whirlpool’s computer system, so its operators canactually see (when talking to a consumer) which servicers are available forscheduling — then go ahead and book the consumer for that servicer. The remaining element is, when that “booking”is created, it shows for the servicer on their ServiceBench web-interface.
The system was great fromWhirlpool’s perspective, but from that of the servicer, was a little lessso. How in the heck does a servicer findthe resources, every time they fill-up (or free-up) space as available for agiven zipcode, to update their ServiceBench settings to so indicate? And this is only to keep them informed. It’s quite aside from the fact it’s somethingof a burden to regularly check your ServiceBench web-interface to see if newdispatches have been created for you — and, if so, to read the information,then manually enter it into your ownlocal management system.
This was the state of affairswhen we (Rossware) came along, and we figured it should be fixed. Sure, Whirlpool and ServiceBench had achievedautomation between themselves. We figuredautomation was likewise needed with servicer.
We pitched the concept toServiceBench, they bought it, and in result built their “Real Time IntegrationSystem” (RTIS), to facilitate precisely the kind of automation we’drequested. From our end, we built alittle utility that (though functions have since expanded), initially had twotasks: (1) automatically keep ServiceBench informed of your real-timeavailability status, and (2) automatically grab dispatches, when created, andplug them perfectly into ServiceDesk.
Initially called the “WebBasedDispatchEnabler” (WBDE), thesystem was a hit from the very start – so much so that other entities asked usto work with them to achieve similar results. Soon, we had functional integration working with ServicePower, and, similarly,with LG too. Since each entity achievesits integration differently, it required separate utilities, from our end, toachieve the integration with each. Wecalled the new utility for ServicePower the SP-DispatchLink(SPDL), and the one for LG the LG-DispatchLink(LGDL). To maintain consistency withthis naming convention, we changed the name of our ServiceBench utility formWebBasedDispatchEnabler to SB-DispatchLink(SBDL).
So, that’s our present familyof DispatchLink utilities (we plan to add a Samsung-DispatchLinksoon). Each is available for the simpleusage fee of $17/month. Just let us knowwhen and if you want one, and we’ll email you a setup.
