Already, before even fully concluding our discussion on ServiceDesk's call-taking and dispatch functions, we've ventured almost unintentionally into a new area of concern: tracking and managing jobs after dispatch. ServiceDesk would be a poor servant, indeed, if it did not have systems (at least as elaborate as those designed to help you secure jobs) to also help you assure their proper and efficient completion. These tools are the subject to which we now turn.
The first step in tracking job performance occurs the very moment you invoke the Job/Sale process from Callsheet. At this instant (assuming standard defaults, at least), ServiceDesk adds a new record to your JobsCurrent file. This record contains, as a start, a copy of all the information from the initiating Callsheet, along with a history section that has, as its first entry, a notation regarding the date and time the record was just created, and by whom. All this happens in the background, creating no cause for notice while you're going through the process. This JobRecord becomes the basis, however, for almost all of the tracking and managing of job performance that follows.
Your primary window into the contents of your JobsCurrent file (i.e., the file containing all current JobRecords) is the JobsCurrent form—accessed by pressing F7 or by clicking on the corresponding MainMenu command button. As the form displays you'll see that, unlike many forms (which show several records at once), this one is designed to display just one record at a time, each constituting a full page of display. Thus you're able to see a great deal about the history and status of any particular job, on its own unique page.
Of course, it's impossible to view even one job until it’s selected for display, so several locating features are provided. As you'll see upon viewing the form, you're initially shown the file's last page (i.e., the most recently-created JobRecord), and can instantly return to that page (assuming you’ve navigated elsewhere) by using the standard, Ctrl-PgDn command. Of course, you can similarly jump to the form's first page (i.e., your oldest still-pending JobRecord) using the standard, Ctrl-PgUp command. Upon selecting any particular record, you can use the PgUp or PgDn keys to display adjoining ones, or just browse. It's handy, for example, when you're in a Callsheet and want to check the record of an item that was among the last few printed, to simply hit F7, then hit PgUp a few times until you see the record you're looking for.
Of course while useful, browsing is often less than ideal (many users will have more than a hundred records in their JobsCurrent file at any moment). So more pointed search methods are provided, allowing you to find an individual JobRecord based on its InvoiceNumber, CustomerName, Address, or even P.O. Number (useful for those home-warranty type jobs that involve them). Just click on or use the indicated QuickKey to access the search option you want, and ServiceDesk will prompt you to enter the search target (or as few leading characters thereof as you wish). At your bidding, ServiceDesk will then search in the actual file, in the order from most recent record to most ancient, and will display the first match found. If this was not the item you were looking for, you can hit Enter and the search will resume. Once a record is loaded and displayed, you can view and/or edit it, just like in any other context.
In regard to conducting these JobsCurrent form-based searches, bear in mind you are only looking within the JobsCurrent file, and in fact there are many other ways of searching within your job records. If interested in archived JobRecords for example, you might instead conduct searches from within the JobsArchived form (see page 120). Or, if interested in both categories at once, it might be preferable to use the CstmrDbase system to perform an instantaneous search (see page 66 for a non-technical summary of that system’s methods, or page 283 for an in-depth description of how it works), though it does not offer some of the more targeted search methods that are available from within these two forms (such as searching under a specific P.O. number for example).
In specific regard to CstmrDbase-type searches, there is a very handy feature that’s available from directly within the JobsCurrent form (and this is, incidentally, not obvious on its face). Occasionally you may be looking at an existing job (or, rather, at it’s JobRecord within the JobsCurrent form) and be curious about what other jobs have been done for the same customer (or at the same location) in the past. Certainly, you could easily press F12 (for the dedicated CstmrDbase search utility, see page 209) and begin typing in a search target by way of name, address or telephone number. However, those very targets already exist in the JobRecord you’re already looking at. Why should you have to bother re-typing them? Instead, if you simply hit F1 while any job record is displayed in the JobsCurrent form, the system will instantly do a search on each of its search-able fields (i.e., customer and location names, customer and location addresses, customer and location telephone numbers). Or if you’ve put your cursor into a particular field and hit F1, it will search on that field only. You can then click on displayed list items to view the corresponding past job (or hit F1 again while the list is displayed) as in any other context.
Also in regard to searches, you should be aware of a still another utility that we call the JobsPerusal form. To understand its function, suppose you’re wanting to review all of your current jobs that are in ‘Working to Schedule’ status (perhaps it’s the time of day that you should be calling all such people in the effort to schedule with them, and so need a way of looking simply and solely at that particular set of jobs). That’s the kind of purpose that the JobsPerusal form fulfills. To access this form, press Shift-F7 on your keyboard (you may notice that we’ve tried to group all the various “Jobs” forms around the F7 key). One you’ve displayed it, you’ll find that use is pretty self-explanatory. Basically, you’ll just select the status category of JobsRecords you want to review. The form will then inform you of how many there are in that category, and allow you to scroll through each, one by one.
In regard to how each actual JobRecord is displayed, you'll notice that besides information that was copied from the initiating Callsheet, there is a section specifying the job's 'status' (i.e., it may presently be 'Dispatched to Tech', 'Waiting for Part', or in any of several other categories). These status settings are all done automatically on the basis of information gathered by ServiceDesk in other contexts, so there's no need for you to worry about keeping the settings up-to-date. They simply provide information to you (one detail you’ll notice is that the ‘Recorded to SlsJrnl and ‘Marked for Deletion’ status categories are somewhat set apart within the list; this is to emphasize that it’s only a record that’s in one of these two categories (unless certain Learning Mode options are set otherwise, see footnote 119 at page 166) that will be moved out of the JobsCurrent file when an ArchiveJobs routine is run).
Even more informative is the JobsCurrent form's History section, which documents every important event in a job's progress toward completion, whether concerning its initial creation and dispatch, a tech's time on the job, diagnosis and repair work there, ordering of parts, items used from stock, money's collected, re-scheduling efforts after ordering parts, eventual completion, etc. With minor exception, these entries are also automatic, created by ServiceDesk with no additional effort on your part, again in consequence of actions performed in other contexts. The power of this utility is enormous. At any moment you can instantly know the entire history and status of any job. No more need to go running for paper records, or pleading here and there to find someone in your company who knows what's happening. It's all there for you, ready for instant and sensible display with practically no effort.
Besides checking on a job's History, you may want to make your own, additional notes in it. Or you may want to edit notes already there. No problem. If merely editing, the procedure is obvious. If adding a new note, first click on the 'add to History' button (or press 'H'). This will insert a time and date stamp for your note, and position you to begin typing. This is particularly useful when, for example, you're wanting to document having called the customer in an effort to re-schedule after having ordered in a part. In such a case you can add notes much as in a Callsheet's MoreInfo section, and again the use of abbreviations (like "lmor" for “left-message-on-recorder”) will make it even easier.
Besides being used to review jobs, update historical events, and so on, the JobsCurrent form provides utilities for several kinds of actions that may be involved in furthering a job’s performance. If you’re simply wanting to call the customer on such a job, for example, you can auto-dial from here, just as from within a Callsheet or several other contexts (just right-click on any or the form’s telephone number fields). If wanting to schedule an appointment for the job, you can use a couple of different methods, as specifically discussed in the next section (it’s a sufficiently involved topic to warrant its own discussion). If you want to create a new service ticket for the job (perhaps the original was misprinted, mangled, lost, etc.), a formal claims presentation document, a work history or even export an Ascii file describing the job, there are options on the form for all such possibilities. Finally, if you want to attach a UnitInfo sheet (see page 180), enter the receipt of monies collected (see page 156), or create a non-stock part order (see page 122), these events may also be initiated from the form—but in these cases please bear in mind that most typically such actions will instead be initiated via the PostVisitReport process (see page 110). Essentially, they are available from within the JobsCurrent form for those particular occasions where, because of how circumstances arose, it simply did not fit (or perhaps someone failed) to do them more normally.
The last major function in the JobsCurrent form involves, as in so many other forms that manage major files, an archiving process. As jobs are completed and sales reported thereon, it's obvious they are no longer work-in-progress, and there's no longer a need for their records to be in the file where we keep track of in-progress items (i.e., the JobsCurrent file). At least once a week, therefore, it’s important to run the JobsCurrent form's Archive routine. Either you may invoke the procedure manually (click on the designated button or use its QuickKey), or you may use of the Auto-Archive feature (see page 209) to have it done for you—either automatically on a nightly basis or as part of an umbrella process invoked manually each morning (see page 221). In either case, ServiceDesk will run an internally-elaborate routine that involves, most obviously, moving those records that pertain to completed jobs out of the JobsCurrent file and into the JobsArchived file. It will also destroy any records you have marked for 'Delete' status, thus leaving your JobsCurrent file cleansed of all but jobs that, at the time the routine is run, genuinely represent jobs still in-progress.
Previously (see page 70), we discussed the process of scheduling as it occurs in the context where we’re typing a job’s initial order information into a Callsheet (essentially, we use any of several methods to create a notation, in the Callsheet’s ‘Date & Time’ box, describing our appointment, then ServiceDesk inserts an entry into the ScheduleList for us as the job itself is created). Now we want to discuss the other context, which occurs whenever we’re scheduling on a job that already exists (such as, for example, when wanting to make a new appointment after ordering in a part that was diagnosed on an already-created job’s first trip).
As you might expect, this process is initiated from the JobsCurrent form (the topic just discussed), with the relevant JobRecord (obviously) first loaded into it.
Upon first examining a JobRecord in this context, you may notice this form’s own ‘Date & Time’ box and logically think it reasonable to simply change the appointment notation there. However, this would have no beneficial effect. Operationally, the information in this box has no effect elsewhere in the system. To start with, in fact, the information there is a mere historical artifact of the text that existed in the corresponding box of the originating Callsheet, at the time the job was created. Even at the Callsheet, moreover, that box’s information was operational only to the extent that, during the process of creating the job, ServiceDesk pulled information from it and created an entry in the ScheduleList based thereon.
We mention this to emphasize an important point. ServiceDesk has a ScheduleList file (see Chapter 6). This consists of a set of entries that describe each appointment that exists at any point in time. Regardless of what other data as may exist either in a Callsheet or JobRecord, it’s not going to be recognized as a true appointment (i.e., displayed in your DispatchMap, etc.) until and unless a corresponding entry is inserted into this ScheduleList file. Again, the process is done for you when a job is created from a Callsheet that includes a useable appointment description in its ‘Date & Time’ box. But, from an existing item’s JobRecord, there is no further job-creating process to do (for, obviously, the job already exists). Therefore, the context is different, and must be handled differently.
In fact, in early versions of ServiceDesk the method was for a user to simply go to the ScheduleList form and there manually select its ‘New Item’ option, then insert a new appointment entry into the file, essentially from scratch (which included manually typing-in applicable invoice number, customer name, grid coordinates, etc.). Obviously, that was somewhat burdensome, but the strategy has not been completely abandoned. In fact, all existing-job appointment entries must still be created, ultimately, with the user actually within the ScheduleList form. The difference is that now we’ve added processes to make it much easier, shepherding you there and filling-in most of the spaces for you.
With that as an overview, we’ll now explain the specific processes (which are considerably more simple than the above explanation). Again, begin in the JobsCurrent form with the relevant JobRecord loaded. Then you can follow either of two paths.
First, much as if you were doing the same thing from within a Callsheet, you can right-click on the job’s address line to Item-Locate its position to the DispatchMap. Thus you’ll see the customer’s name flagged there in red, making it easy to determine an efficient appointment time. Then (still, just as though you were doing the same thing from a Callsheet), you can click on the customer’s flag, view the drop-down combo-box that’s shown, and with its use input the appointment reference, then and there, from within the Map. But now the result will be different from when a similar process was initiated in a Callsheet. There, if you recall, the appointment reference would be inserted into the Callsheet’s ‘Date & Time’ box for you (awaiting operative effect when a job was later created from the Callsheet). Here, the system will immediately take you to the ScheduleList form, where it will have directly prepared a new entry, awaiting only any additional polish you may want to provide (such as indicating an assigned tech in the appropriate box, for example), and your action (simply press Enter) to save it. When you do press Enter, obviously, the new entry will save—and the appointment is made, entered, done! Also (and incidentally), the system makes an entry in the job’s History describing the event.
As a second method for scheduling on an existing job, you can bypass the DispatchMap and use an option in the JobsCurrent form labeled ‘Scheduling’ (either click on that option button, click on the Date & Time box, or hit Alt-S on your keyboard). This will take you directly to the ScheduleList form. If there’s presently a pending appointment on the job, it will present you with an option box, asking whether you want to cancel that appointment, change it, or create a new one. Otherwise (and like the via-DispatchMap method) it will simply present you with a mostly filled-in proto entry. The difference is that here, since date and time were not previously indicated from the on-Map-Scheduling context, the actual appointment notation will not yet have been filled-in. However, the same tools are available here as are provided in a Callsheet’s ‘Date & Time’ box (i.e., DatePicker form, etc.).
All in all, it’s a very simple process (though to perceive it properly you must keep the concepts straight). Also, bear in mind there’s a whole chapter on scheduling and dispatch (Chapter 6) that describes many details in regard to manipulating and using schedule entries once they are created (either in this context or from Callsheets, as described beginning at page 70), along with many tricks in regard to special kinds of entries, and so on (see especially the section beginning at page 99). And, if needing to understand the technical details in regard to how ServiceDesk interprets appointment notations, don’t forget the Appendix discussion beginning at page 283.
If it is to keep a full history of each job (not to mention managing your stocking parts inventory, ordering in non-stock items, tracking receipt and deposit of funds, etc.), ServiceDesk obviously must have a means of collecting information regarding what happened on each and every appointment as dispatched to your techs (i.e., what was done in the customer's home, what parts were used from stock, what parts need ordered, what monies were collected, etc.). Thus, it follows that you must in some manner tell ServiceDesk what happened after every such appointment is filled.
We have a term for this process of informing ServiceDesk about what happened on any given appointment: we call it the “PostVisitReport.” You should understand how critical it is in the process for you to make these PostVisitReports—after each and every appointment is filled. Otherwise, ServiceDesk has no means of being informed—and keeping track for you—of what happened on the job (what the tech found, what he did, what parts he used from stock, what he needs to order, what monies he collected, and so on). Really, PostVisitReports are a critical element in the process. They tie a lot of things together; and are the primary means of collecting the raw data via which the system maintains job histories, inventory control, non-stock parts ordering, and funds control. They are the focal point of the interface between you and the computer in regard to the ultimate work of your business: what the tech did in the consumer’s home.
Given the central nature of these PostVisitReports, it’s important for you to understand the entire setup and context that’s been provided for you to do them in—which we’ll get to in a moment, but first a distinction. Within ServiceDesk, there are expectations that you’ll do certain things after the job has been completed (in particular, recording the completed sale that it entails to the SalesJournal, see page 165). But please note the words used there: “after the job has been completed.” Please note those words carefully, and distinguish them from the context that’s involved in making PostVisitReports—which, by contrast, are expected to occur after any appointment has been fulfilled. You see, there’s a difference between those situations. On any given job, you might have one, two, three, or who knows how many visits by the technician to a customer’s home (hopefully fewer, of course, but we all know how this business sometimes goes). The concept we want you to get here, the distinction, is that ServiceDesk expects a PostVisitReport to be made after every such visit—informing it about what happened when the tech was there. Other tasks, tasks that we refer as Post-Completion matters, are only done once in connection with any job, after the job is truly complete—complete because, essentially, all appointment/visits that were needed in its connection have been done. PostVisitReports, by contrast, are done after every single visit. Sorry to belabor the point, but sometimes new users have had a hard time getting this distinction. We hope you do now.
So, now that you get it, let’s talk about how these PostVisitReports are actually done.
As it happens, ServiceDesk offers you the option of following any of several strategies in this regard. In fact, since there are so many options in how it may be done, it becomes slightly complicated to explain how each of the alternatives work, relate to one another, and fit in with the greater whole.
The first complication arises because there are two different on-screen forms that are provided for the purpose, and they each accomplish exactly the same purpose: they just do it in a different way. You can use one or the other, depending simply and solely on your preference. Regardless of which you use, the end result will be the same. Specifically, we’re referring to two different PostVisitReport forms (which are the vehicle for PostVisitReports). One is the ‘PostVisitReport Form: Dialog Method’; the other is the ‘PostVisitReport Form: Fill-In the Blanks Method’.
If you’re curious, the main reason we ended up with two different forms—for the same purpose—is that historically the first was the only one that existed. In late 2002, however, we developed the second, as an improved method for certain situations. The first was still deemed superior for other purposes, however, so it did not make sense to do away with it. And thus, we now have the two alternative forms/methods, existing side-by-side, and you have the freedom to pick which you want to use in any context.
Speaking of “contexts,” that’s the other complicating factor in this area. That’s because (assuming you’re more than a one-man shop) you may want to have your technicians make their own PostVisitReports (as absurd as that may sound on its face, there are some very good reasons for doing it this way, and for some operations it will be very beneficial). Or, you may want to have an office person do it on behalf of the technicians. But even then, there are disparate possibilities, for on the one hand you may want to setup for the officer person to do the reports after the fact, probably on the day following, based on the tickets as turned in by the technicians from the previous day’s work. On the other hand, you might instead want to setup to have PostVisitReports done in real time, immediately upon the technicians’ completions at each job, based on telephone or radio communication with the office. Or, as still another possibility, if you’re a one-man operation, you might want to do PostVisitReports in real-time, as you finish each job at the customer’s home, based on input then and there to your laptop computer.
It’s because of all these disparate possibilities, basically, that our discussion can’t be quite as simple as we’d otherwise consider ideal. Still, we’ll try to get through it in as basic a manner as possible.
Two Different PostVisitReport Forms
Again, there are two different on-screen forms that are provided for the purpose of accommodating your report back to ServiceDesk regarding what happened at each and every scheduled appointment.
First is the PostVisitReport Form: Dialog Method. As earlier indicated, this is the older of the two forms. It’s generally accessed by pressing Alt-F7 on your keyboard. As you’ll soon see upon trying this method (and consistent with its name), this form takes you through kind of a dialog, asking you a series of questions via which it collects information concerning all the essentials about what happened on the job. Your task is simply (and rather easily) to answer each such question. As you’ll see, there are ‘Yes’ and ‘No’ buttons provided, upon which you may click in any given instance to so answer the question that’s presented. Please realize, however, that in the alternative to so clicking with your mouse you may simply hit “Y” or “N” on your keyboard (as the context suggests). Indeed, there are many conveniences provided in the dialog, and if you’re observant you’ll see that after a little practice it’s easy to make it through the dialog with great rapidity.
The second context for reporting, the newer of the two, is the PostVisitReport Form: Fill-In the Blanks Method. It’s generally accessed by pressing Shift/Alt-F7 on your keyboard. As it’s name obviously suggests, this context presents a more static form (rather than a dialog), allowing you at your leisure to fill-in the blanks that relate to the various aspects of what happened on the job (what was done, parts that were used, parts that need ordered, monies that were collected, etc.).
Regardless of which form is used, the very same information is ultimately collected from you. And regardless of which, this information is fed by ServiceDesk into each of the various contexts where it’s needed. In other words, the system will place narrative text into the Job’s History section describing what happened on the job, based on entries here. It will create PartsRequest records, via which the ordering of non-stock parts may be managed. It will adjust inventory levels in regard to stocking parts. And it will create money-received type entries in your FundsJournal, via which you can perfectly track all your items of incoming money, shepherd them through to deposit, make sure they square with sales, etc. It will do all this on the basis of information collected in these reports, regardless of which of the two forms you use, and regardless of which of the possible contexts for using them.
Speaking of contexts, that is the more specific subject to which we now turn.
In-Office Reporting: Following Day Method
Probably the most common method in use among present ServiceDesk users is that, on one day, the technicians go out with their set of jobs. That evening or the following morning, they turn in the tickets/invoices from that work. Upon those tickets, they’re written in pertinent information regarding what they did on the job. At this point someone in the office, someone assigned to the task, takes that stack of tickets, sits down in front of ServiceDesk, and makes the PostVisitReports, based on what the techs have written upon the tickets.
In terms of going through the sequence, there are several ways it can be done. If, for example, you’re using the newer PostVisitReport form, you can bring it up directly by pressing Shift-Alt/F7, then simply type in the invoice number of each job on which you’re reporting, as prompted. Of, if you’ve already brought up the JobRecord of interest within the F7 form, and then you hit Shift-Alt/F7, the system will assume that’s the job you want to report on, and load with that as the selected item. Or, if you’re in the DispatchMap and looking at the reference to any given appointment, you may from there do a Shift-Alt/Rt-Click, and the system will QuickLink to the newer PostVisitReport form, while pre-loading with the expectation that it’s the clicked-upon appointment on which you’re intending to make your PostVisitReport (if you wanted to use the older, dialog method, do a mere Alt/Rt-Click instead).
All in all, if you do have a stack of invoices on which you need to make PostVisitReports, it’s probably easiest to simply strike Shift-Alt/F7 and go through the sequence for each job, one after another (or do the mere Alt/F7 if you prefer the older, dialog method).
There’s nothing wrong with this method. It works very well. There’s also nothing jazzy about it. It’s pretty normal and typical, which is probably why it’s so popular.
Regardless of whether you decide to use this or the other In-Office Reporting system (about to be discussed), you’ll probably find that you prefer the newer method of making your PostVisitReports (i.e., based on the newer Fill-In the Blanks (Shift-Alt/F7) form, rather than the older Dialog (Alt-F7) method. But please try each regardless, so you have an understanding of the alternatives, and opportunity to consider which of the two you really prefer.
In-Office Reporting: Immediate Call-In Method
This method is solely of interest to multi-tech operations, so if you’re a one-man shop, you won’t need to concern yourself with its possibilities.
The concept is simple. You just have your technicians call-in to the office as they finish each job. An office-person, speaking with the tech, brings up the preferred PostVisitReport form (whether Dialog or Fill-in-the-Blanks method), and completes a report based on the information he gives her.
We have a number of clients using this system, and they positively swear by it. To glimpse just part of its advantage, suppose Mrs. Jones calls your office ten minutes after the tech has left. Within two seconds, you can have the technician’s full report in front of you—allowing you to speak with her intelligently (rather than saying, for example, I’ll have to get back to you tomorrow after I’ve had a chance to speak with the tech). Suppose it’s one of those calls where she’s saying “He was only here five minutes, and blah, blah, blah.” With the benefit of real-time information, you can instantly reply: “Well actually, Mrs. Jones, I see here that he started at 12:10 and finished at 12:55, which by my calculation makes 45 minutes, not just five.” (I’ve personally had almost precisely that conversation several times.) Of course, that’s just one kind of benefit. If parts need to be ordered, the process can be initiated that much sooner. If you’re doing work for home warranty companies and need to get authorization, that can also be expedited, and so on. Overall, it allows you to provide a significantly higher quality of service to your customers—on top of giving you the serenity of knowing in real time what happened on each job.
If you’re already investing in the employee-time that’s involved in having your tech’s call in as they arrive and/or depart from each job, and are doing so solely for the purpose of keeping tabs on where they’re at (see page 87), it would be almost silly not to add the major benefit of real-time PostVisitReports, based on just a little more employee-time than you’re paying for already. Even if you’re not, it may well be worth making the investment.
To implement the system, you should first go to the ServiceDesk Settings form (Ctrl-F1) and, in the purple section, check the option titled ‘Do Immediate PostVisitReports as Techs Call In’. This lets ServiceDesk know this is the procedure you’re using. On that basis, ServiceDesk knows to assume, when a PostVisitReport is begun, that the current clock time is, in fact, the technician’s completion time on the job. Thus, it knows to fill-in that time, and not force the operator to do so.
You should then consider whether you’re going to have your technicians call-in only as they complete each job, or both on completion and upon arrival. You can do it either way. The advantage of adding arrival-call-in is that the system can use this event to log the technician’s start time (based on the computer’s then current clock time). This saves effort when the technician later calls in his completion, because now the system is able to deduce for itself both start and end times, and can place them both into the history with no separate input from the operator. Regardless, there’s no requirement for you to be consistent on the matter. Just make sure, if and when your technicians call in their arrivals, that the call-taker knows to check it off as such within the DispatchMap (i.e., do a Ctrl/Left-Click on the job’s reference there; see page 87 for a more complete discussion of this function)
Regardless of whether you’ve separately checked-in the technician’s arrival on a job, when he calls in his completion, DO NOT so check it within the DispatchMap (as you would, in other words, if that was your only purpose). Instead, initiate the PostVisitReport. You can do this in any of the standard ways (i.e., bring up the form directly and type in the invoice number, or first locate the applicable JobRecord in the F7 form then hit Shift-Alt/F7 for the PostVisitReport-Type2 pre-loaded with that particular record). However, for this purpose it’s likely easiest to Quick-Link in each instance from the DispatchMap. From there, you can simply locate the job’s applicable reference (List or Graphic), and do a Shift-Alt/Right-Click on it). In result, the system will instantly display the PostVisitReport interface, pre-loaded with applicable job, appointment, and start and end times. Thus, it doesn’t typically take very long for your office person to collect the rest of the needed info from your tech, and for him to be on his way. Another benefit when using this method is that, if anyone in the office has addressed email to the tech who’s calling in, there’s a button on the right-hand side of the PostVisitReport form (Type 2) that will show itself conspicuously in red (otherwise, if no email is pending, the button will be dim and disabled). The purpose is to catch the operator’s eye, alerting her to the fact that some message needs to be brought to this tech’s attention (perhaps regarding a cancellation, request from the boss to speak with him, or whatever). She can then simply click on the button, peruse the email, and inform the tech in regard to its contents. She could even type a reply back on his behalf, if he so requested.
Still another benefit concerns ServiceDesk’s Arrival On-Time Sentry. This feature continuously monitors each technician’s progress within his route (based, of course, on your work in checking off his arrivals and taking PostVisitReports upon each completion). If at any point it appears he’s threatening to arrive late on a job, the system will put that job’s DispatchMap references in to a flashing/blinking mode. The purpose is to bring the peril to your attention in the office, so you can take appropriate remedial steps. It’s a very powerful and important tool.
You may notice, when you’re doing PostVisitReports via the immediate call-in method, the DispatchMap becomes even more of a command central—at least for the office person who’s managing dispatches and the techs’ call-ins. He or she will center almost all work from there, while keeping perfect and easy track throughout the day of the status on every job, and the position of every tech. Also, the manager at various points in the day the manager/owner can glance at the DispatchMap at quickly get a sense for how the techs are doing: how they’re faring within their schedules, their ration of completions to non-completions, and so on.
All in all, we highly recommend this immediate call-in method for doing your PostVisitReports—if you can make the necessary personnel available in real-time, as required for taking the calls from the techs. Do be assured in this regard that when done properly, the time investment is quite moderate. Most PostVisitReports, done this way, should be completed within less than a minute.
Having Techs Make Their Own PostVisitReports, Locally:
Although somewhat less sexy, there is a typically underappreciated method that we think has great merit. It’s what we did in our own former service office, and it worked very, very well. Most people, we’ve found, think they could never get their techs to go for such a method (or that their techs would do a horribly lousy job), but we urge you not to sell them short. Another concern is security. People fear letting the technicians into the system. But, as you’ll soon see, we have fully met those concerns.
Some of the benefits in having techs make their own PostVisitReports are as follows. First, communications with them are enhanced: by logging in every day, they have perfect access to E-Mail communications, and can respond in turn. You can easily post specific messages to a particular tech, or general messages to all of them. It's easy, and somehow carries more impact than mere notes left for them to read. Second, when they need information about a past job, there's no longer a need for them to ask you or another office person to look it up: they'll simply find it themselves in the CstmrDatabase. Third, because of the query-dialog format of the PostVisitReports process, they're forced to answer questions which, if merely filling-in blanks on an invoice, they might have failed to respond to. And fourth, all problems with office personnel attempting to decipher a technician's handwriting (when reading critical items like Model and Serial Number) are ended: the techs enter such info directly by keyboard, ending all ambiguity.
Anyway, assuming you’re persuaded of the benefits in having your techs make reports on their own behalf, you'll first need to assure there's a computer station they can use for this purpose (i.e., one no one else in the office is needing at the same time). Typically, it’s beneficial to set aside a machine that’s exclusively for their use in this regard. An excellent choice would be an older computer that's not quite up to the performance levels wanted for other ServiceDesk applications. To setup this station, run ServiceDesk just as you would from any other networked computer (or use any networked computer on which ServiceDesk is already running). Then, from that computer's main Callsheet interface, press Alt-W (for Window/tech-mode). At this point, ServiceDesk will switch itself into a mode that is specially tailored for direct interface with your technicians.
More specifically, it shows a full screen displaying the ServiceDesk logo. When any key is pressed from this window, the TechInterface form appears, and from it ServiceDesk queries for the initials of the operating technician. When acceptable initials are entered, the technician is greeted by name, and invited to read any pending intra-office E-Mail. In the absence of (or at the conclusion of reading) E-Mail, ServiceDesk displays the PostVisitReport form (in this case, it is exclusively the older, dialog-method, for it’s simply much more appropriate for technician usage), and the technician is urged to report on each of his jobs. Upon exiting from the PostVisitReport form (hit Esc), the technician is informed if there are any outstanding items he has failed to report on, and if so, is urged to go back and make the reports.
Both before and after making his PostVisitReports, your technician is able to take advantage of a few other utilities. First, in addition to reading his own E-Mail, he can compose and send E-Mail to others within the office or technical staff. More significantly, he has the ability here to use the CstmrDatabase, looking up past or current jobs, just as you may do. Thus, without bothering you, he can learn things about the history and status of jobs that he may need to know (though he’s locked out from doing any edits). Plus, he can personally review (but is, again, prohibited from editing) the DispatchMap, thus allowing him to see his day's route graphically, preview what's on the schedule in coming days, review past day's schedules, and so on. Also, if your technician is paid on an hourly basis, he can use ServiceDesk's TimeClock feature, to clock-in or out of work. The procedure for these functions is straightforward, and obvious on the form itself.
When your technician is done conducting his business, he should repeatedly hit Esc until exiting all the way back out to the logo screen (i.e., with one Esc he exits from the PostVisitReport form, with the next from the TechInterface form, and so on). At this point he's essentially logged out from his session, and ServiceDesk is ready for the next tech.
As another security feature, incidentally, you should know that once switched into its TechWindow mode, ServiceDesk will resist any and all efforts to move back into the main ServiceDesk environment—except by use of your Owner/Manager Password. The reason is to keep technicians out of mischief in areas they have no business, and to assure they don't even inadvertently switch out of the mode, which, if it happened, might prevent subsequent technicians from having access to the mode they need. Thus, even while giving technicians the access they need to report on their own jobs, you’re able to maintain your own data security.
You might think technicians would object to having to do this little item of work, but it’s our experience that if they simply understand it’s a part of their job—specifically, that their own work on any particular job assigned is not done until they make this report—there’s little or no problem. Indeed, even if you pay them solely on a commission basis, if they simply understand that they’ve not earned their commission until and unless they make this report, you should find there’s little problem.
Having Technicians Make Their Own PostVisitReports, Remotely
Still another option is for your technicians to make their own PostVisitReports, remotely, from their own home computers or laptops. To do so, obviously, they’d need to log into your network via Dial-Up Networking or via the Internet (see page 310). This situation is especially ideal for technicians that live somewhat remotely, and don’t come into the office every day, but may even handy for the owner/tech who just wants to report on his own jobs from the convenience of his own home. Once again, security concerns are obvious, but there are effective ways of handling them (if interested in this method, please read the above-referenced section in the Appendix, and if more questions remain, contact us).
An Option in terms of Operating Setup: To Integrate PostVisitReports in a Seamless Sequence with Post-Completion Tasks
In a typical office setup, many items of work are done in a batch manner. If you’re using the most typical method for handling PostVisitReports, for example, you’ll have an office person sit down with the stack of invoices as turned in by the techs from the previous day’s work. She’ll go through the whole stack, making PostVisitReports on each, one after another. Either at the beginning or end of this effort, she’ll separate the tickets on which the job’s are done from those on which parts need ordered (or return visits are otherwise still needed). The latter stack will go to whatever place you’ve set aside for those purposes, while the former will now feed to another batch process. In particular, if you’re a servicer doing warranty work, that stack will be reviewed by someone for any warranty claims that need to be made, and that person will then go through the stack, making such claims—doing that added step, for all such invoices, again as an entire batch. Then, and finally (or perhaps this step would be done before the one just described; it’s optional), the stack of invoices will be run through still another time, again by someone in the office, for the purpose of recording each, as a completed sale to the SalesJournal.
That’s typical, and is probably best for a larger office, where specialization of tasks, separating different areas of responsibility/accountability, and so on, can result in increased efficiencies. If yours is a smaller office, however (where it’s essentially the same person doing all the above tasks anyway), you’ll may find another option preferable. The difference, essentially, is that instead of doing Step1 on a batch of invoices, then (when that’s done) doing Step2 on the whole batch, and then (again, when that’s done) doing Step3, you’ll instead do Steps 1 through 3 on a single invoice, then the whole sequence on another invoice, and so on.
Facilitating this kind of integration was one of the reasons we created the new PostVisitReports form. The integration is available exclusively form it (not from the old dialog-method form).
To make the integration work, all you have to do is check-off an option box within the new form that’s labeled “when job is done, link automatically to post-completion tasks.” With this done, the system will watch as you save every PostVisitReport. If you’ve indicated (as part or the PostVisitReport) that the job has been completed, the system will at this point query as to whether you’d like to link immediately to either the FinishedForms (appropriate for making warranty claims) or SalesEnter (needed to close-out the completed sale) contexts. Regardless of which you choose, the system will link you immediately to that context, with the maximum possible quantity of information carried there for you, from the context you were just in. This saves effort because, among other things, there’s no need from within those contexts to separately indicate the item you are reporting upon. Instead, the system advance loads data for you, since it knows in advance what you want.
Also, if you’ve linked first to the FinishedForms context (as needed, for example, to make warranty claims, or perhaps if you simply prefer to print a final invoice with every detail included), the system will, upon completion of your work there, offer to link further (and automatically) to SalesEnter context, where in this case it’s able to fill-in the entry line for, in its entirety, in advance. All that’s left for you is simply to confirm by hitting Enter.
If suitable for your office setup, this method of integrating the PostVisitReport with Post-Completion tasks can be very powerful, adding enormously to the ease and convenience of completing these processes. You’ll simply have to decide whether the approach is best for you.
The One-Man Shop: “Has Laptop, Will Travel”
A final possibility (or at least the last we’ve thought to write about here), is if you’re a one-man shop, and if you wish to essentially carry your office with you, via mobile electronics. For this situation, we highly recommend the integrated approach just discussed. Indeed, we’d suggest going further, in a sequence you might call “Integrated-Plus.”
Specifically, we’d suggest not even printing advance ticket/invoices, like most organizations do. Instead, from the DispatchMap in your computer, identify the next job on your schedule. Do a quick-link to the JobRecord (Ctrl/Rt-Click), to get the full address and particulars, then drive there. Upon arriving, press Shift-Alt/F7 (from that same JobRecord, still displayed), to bring up the new PostVisitReport form, pre-loaded with the present job. Hit Enter to confirm it’s the present appointment you’re reporting on, then (since the system will at this point have already placed you in the ‘Start Time’ box, simply type in “now,” and the system will insert the correct time for you. Then go into the house and do the job. When you finish, return to your truck and again type “now” (in the ‘End Time’ box, where the system will have already placed your cursor). Then fill-in the rest of the form, and save. After that’s done (and assuming the job itself is also complete), you can link automatically to the various Post-Visit activities (as above-discussed), and (on your mobile printer) instantly print a perfect, finalized invoice for your customer. Wala, yippee, hurray. Couldn’t be more efficient or easy.
For the Future
We’re guessing that in a very few years the vast majority of technicians will carry wireless “Palm”-type devices, via which they can type-in their own PostVisitReports while finishing each job, for immediate and direct transmittal to the home office—where the information will then be available, in real-time and with no separate office effort required. Here at Rossware, we intend to be on forefront of this development. Watch for it in future upgrades.
A Bit of Reflection
In designing ServiceDesk, we've been mindful of the fact that many software systems require the input of data you would never otherwise have bothered with. In result, they end up creating even greater office burdens than they were supposedly designed to eliminate. Being determined to avoid this error with ServiceDesk, it's with a little sadness that we must admit there is a small amount of new work in the PostVisitReporting process. Even so, if you'll try the process, you'll find the amount of effort is minimal, and the payoffs are absolutely immense.
In result of the data it collects from your PostVisitReports, ServiceDesk is able to keep a complete on-line history of every job, a history that is instantly accessible to any person in your office, at any time, and at the press of a few keys. Thus, ServiceDesk is able to assist you in tracking your jobs, to assure their proper progress and completion. It facilitates the process of ordering non-stock items, logs their receipt and so on. It keeps an up-to-the-minute inventory of precisely what items of stock are on each truck (and in the shop) at every point in time. It keeps perfect track of your funds collected, facilitates deposits, and on and on. All this is based on just a little effort in entering information regarding what happened on each dispatched job.
Almost from its inception, one of our purposes in designing the WorkInProgress system was to create an automatic sentry that would in some manner monitor each of our outstanding jobs, and alert us if some item began to fall through the cracks because of inadequate attention. There is, as you know, already a means to do something similar in regard to Callsheets (i.e., the Callsheet alarm system, see page 68). However, that particular sentry is designed to help you avoid neglecting things like returning someone's call, getting a dispatch scheduled, or acting on a simple 'To-do" note for which you've created a Callsheet. It does not pay attention to WorkInProgress (i.e., actual pending jobs and their status).
Indeed, a sentry that would perform this latter task is considerably more complex in concept, and had to await development until most the other features in ServiceDesk had been invented. It is, therefore, one of our more recent additions. We call it, simply, the WipAlert system.
To implement this new sentry, you must select a particular computer station on which you wish to have it operate (your head secretary's station is probably the best choice). Designate this station (so ServiceDesk is aware of your choice) by going to its own Settings form. In the LocalSettings section, you'll see an option titled "Send WipAlerts?" Check this and then save your settings (remember, only do it from this one station—unless, of course, you want to have multiple copies of the alerts sent elsewhere).
Within about one minute of turning this feature on, an invisible routine will run, checking every item in your JobsCurrent file. For every item that appears to be past-due for attention, the routine will create a Callsheet informing you of the fact. In response, you may then inspect each such item's JobRecord, to see what kind of attention is due.
As you give each such matter the processing attention it needs, simply document the fact in its History.
Suppose, for example, that in response to a WipAlert in connection with some job, you've checked on a part that is long overdue in coming, and called the customer to assure you are doing everything you can to expedite its arrival. Simply append a note in the item's History indicating this action. Or, if it was simply an item that was past-due for its PostVisitReport, or for recording to the SalesJournal following its completion, or some other such thing that automatically updates an item's History when finally done, simply take that specific needed action (which again, the WipAlert will have helped you avoid failing to do). In either case, with the job so updated, the sentry system will now be satisfied that it's not being neglected, for some time at least.
The amount of time the sentry system allows you, before again thinking there's neglect and therefore creating a new WipAlert, depends on the Status the job is in. If it's in "ATTEMPTING TO SCHEDULE" status, for example, the system figures you ought to be making at least daily attempts to contact the customer, and of course documenting such attempts in the item's History (this refers to scheduling after a part's come in, or after you've been stood up and therefore need to re-schedule, or something similar, since initial scheduling of every job is managed and policed from within its originating Callsheet). Therefore, if the last History entry of an item in such status is more than about a day old, you'll get a WipAlert on it. If an item is in "WAITING FOR PARTS" status, on the other hand, the system figures that at least three days might be an appropriate wait before an alarm needs created. Each status has its own such alarm period, as seemed appropriate to us in designing it. In figuring the number of days in a period that elapses across a weekend, incidentally, only Saturday is figured (thus, while Monday to Thursday counts as 3 days, Friday to Monday, the same actual number of days apart, counts as only 2).
After the WipAlert routine first runs, it logs the fact that it's run for the present day, and will not run again until it detects a new date. If you keep the station running overnight, therefore (we think this is most convenient), the routine ends up running itself precisely at 1:00 am the next day, and you (or whoever works at the station involved) will have fresh WipAlerts waiting when you come in later that morning. This has been working very well in our office.
Actually, it worked very well until our primary secretary got a little lazy (or perhaps just too preoccupied with other work). At any rate, for a month of more, she simply deleted her WipAlerts, without properly using them as reminders to do necessary follow-up work. One afternoon, in consequence, the boss got a call from an angry customer. On reviewing the JobRecord pertaining to this customer's job, he saw that more than a month had gone by (waiting for a part) without any of the necessary reminder calls, to the customer, indicating that we were doing all we could to further the job along. Yet, the secretary had received daily reminders (specific WipAlerts pertaining to this very job), essentially telling her such calls needed made. After appropriate scolding, the boss decided he needed something that would alert him, should his staff every again disregard the WipAlerts in such manner.
Thus, as a monitor on the monitor (so to speak), we now have a WipAlert-Supervisor feature, which can similarly be "turned on" (it too is a 'local' setting) from the Settings form. Essentially, at 1:30 am each morning it runs the same checking process as does the standard WipAlert feature, but allows two additional days idle time before generating an alert (thus, the person who responds at the primary alert level would have to fail to respond, for at least two days, before this next-level alert is generated). And, of course, this alert sends its notifying Callsheets to the desk of the person who has this feature turned on (not to the subordinate), and the alerts themselves have text alerting to the higher degree of warning. Our secretary knows of this new feature, and knows the boss has it "turned-on" at his desk. He has yet to receive an alert.
Obviously, if you're not interested in the WipAlert system, there's no necessity for you to use it, but we think you'll find it a most valuable tool. During the 18 month period our office used a beginning WorkInProgress system that lacked any WipAlert function, we found ourselves accumulating a large number of old JobRecords where performance had simply been dropped, somehow ignored, the invoice lost or misplaced, perhaps completed but never billed and recorded to sales, and similar failures. Back in the old days, before there was any JobRecords, these jobs would have been lost entirely, without our even knowing it. And with a basic, un-sentried system, they accumulated in our JobsCurrent file, with little attention being paid (the file was began to bulge from such items before we even realized it). Now, however, we're happy to know that whenever even a single item even begins to slip through cracks, we'll know about it rapidly, and almost be forced (the system can be a pest until satisfied) to deal with it quickly.
Like many other complex systems, ServiceDesk has evolved since its initial creation and in the process has sometimes retained vestigial remnants of older parts, even while they were largely supplanted by newer creations. The JobsArchived form (press Ctrl-F7) falls somewhat into this category, for while it was initially created to provide search and review capability in regard to archived JobRecords, the CstmrDbase feature now fulfills this need more ably and easily—at least for standard searches. You may, therefore, find there’s seldom need to use the form’s own, built-in lookup features (at least the standard ones, though they are still are there and can be used if when wanted).
However, it may be useful for you to know that, even in the CstmrDbase context, you will be continuing to make at least ancillary use of the JobsArchived form, for it is in fact an abbreviated instance of this form that ServiceDesk uses to display each of your CstmrDbase findings, even when conducted from other contexts. More importantly, you should know about a few utilities, accessed from the JobsArchived form, that are not available elsewhere—ones you'll find useful on at least limited occasion.
Again, you may still search for a job within the JobsArchived form by customer name, address or telephone number, but these functions are much more powerfully addressed from any of the various CstmrDbase methods (see page 66 for a summary). Another advantage of a CstmrDbase search is that the JobsCurrent file is searched and accessed at the same time (except items added since the most recent index update, see page 283 for a technical explanation). For reason of these differences, we think you'll rarely wish to use the JobsArchived form for its more limited version of such functions. For those other functions discussed, however, keep it in mind as a most useful tool.
One possible cause, for example, would be if one of the users in your system archived the JobsCurrent file (remember, ServiceDesk updates the CstmrDbase indexes at this time also, see page 123), but failed to follow ServiceDesk's instruction in copying the resulting new indexes to other stations. The problem would be compounded further if one of those non-updated stations, say a few days later, performed a ArchiveJobs routine of its own. With its own indexes out-of-date to begin with, the new revisions would result in an index set that's in even worse shape—which the station user might then dutifully (but unknowingly in regard to the defect), copy to all other stations.
It may be that some service companies have little burden in regard to ordering non-stock parts. For the rest of us, however, the burden is frequent and substantial. Please be assured, ServiceDesk has a well-polished system to manage this activity.
First, a definitional distinction: stocking parts (aka “inventory,” and as specifically discussed in the next major sub-chapter section) are items you acquire and hold with the expectation you’ll likely use them on some future job (i.e., when first acquired, they are not for any particular job, and you have no specific immediate use for them). By nature, they are speculative. Special-order parts, by contrast (and as discussed in this major sub- section) are never held as “inventory.” They are acquired for specific jobs (or perhaps to fulfill particular POS requests)—specifically, when it’s realized, on any such particular job (or POS request), that said part is needed, and further realized that, because it’s not a stocking item, it must be specifically ordered for immediate need.
The first thing that must happen, in managing a special-order part, is for an internal “request” to be generated. This request can be created via any of several mechanisms:
Regardless of how created, each of the parts requests you have pending, at any moment in time, are stored in a particular location, and can be accessed via a particular form. Sensibly, this is called the PartsRequest form (Alt-F8 is the shortcut). Besides being a place where requests can be viewed and/or edited, it’s more typically used as the interface (in some but not all of the above-enumerated contexts) where requests are actually created.
So, the simple idea is, before we can manage a special-order part, we first have to have an underlying, internal request to form its basis. This request is an internal record that describes details about the request. It relates only to special-order parts, and not to stocking inventory. It’s an internal record that says, essentially: “Hey, here’s an item we don’t stock that we need to get, because it’s needed on XYZ job.” And, it provides the underlying, request basis for initiating the processes of making inquiries to suppliers, actually placing an order, keeping track of the order, checking in the part when it arrives, etc.
The request is the foundation. For parts connected with jobs (as opposed to POS-based requests), it’s typically created via any of mechanisms 1 through 3, as above-listed (i.e., in a PostVisitReport of some kind, whether via Mobile or internal PVR Types I or II). All three PVR contexts have their unique methods to collect what is, ultimately, the same result: an internal parts request, representing an item that needs to be ordered—or, at least, inquired upon.
In regard to this latter, the system recognizes that sometimes an item simply needs to be researched, to determine price and availability, pending a decision as to whether an order is desired, or not. The underlying “request” accommodates this via an option to indicate whether the order is “Definite” (meaning just get it regardless) versus “Tentative” (meaning research-only for now).
So, you’ve got several mechanisms to create a PartsRequest, plus a form (the Alt-F8 PartsRequest form) that holds each such request, reviewable on a page-by-page basis (i.e., each page of display in this form represents a separate underlying request). But, obviously, giving birth to these requests and storing them does not accomplish the ultimate purpose. We also need a basis to perform the underlying, needed work (i.e., looking up the parts, getting them ordered, etc.).
The PartsRequest form, in itself, would be a lousy tool for facilitating these further purposes. It’s not designed for them.
For perspective, consider an old-fashioned, paper-and-ink managed office. In that “old days” scenarios, it’s typical that each part-request is represented on a sheet of paper (often it’s the service ticket itself, but some old-method offices use other forms). It was also typical that, at some point in the day, the person responsible for parts-processes would gather each of the slips representing new parts requests, and lay them out on a large flat surface. Essentially, he wanted to get a “feel for the territory,” sort of assembling and re-assembling the slips, saying to himself: “Okay, these three items I’ll go to Vendor X for, and these four to Vendor Y,” etc.
In an all-electronic system such as ServiceDesk, the same guy (or perhaps gal) is going to want something equivalent to that “large flat surface.”
That equivalent, in ServiceDesk, is called the PartsProcess form (shortcut is F8).
Please notice, between the two shortcuts so far described (Alt-F8 and F8), the PartsProcess form has the easier one. We gave it the easier shortcut because it’s your main, operative form—the one where you really do the bulk of your parts-process work.
The general idea, in the F8 PartsProcess form, again, is to provide the electronic equivalent of that large flat desk—or, actually, several of them.
If you’re an average size shop, you’ll likely have a few scores of parts-request items pending at any moment in time. Some of these requests will be brand new, with no process work (inquiring with vendors, placing orders, etc.) having yet been performed. Others may be in a state where you’ve made inquiries with particular vendors, and are waiting for a response back. Still others may be in a state where an order has been placed, and you’re waiting for the shipment to arrive. There are still more possibilities—such as that you’ve looked up and got price and availability, and are waiting for the customer to give you a yea or nea.
What if, in a paper-and-ink system, you had a separate large tabletop on which to spread the tickets holding parts requests that fit each such category (i.e., one for requests on which nothing’s been done at all, one for requests where you’re waiting for a response back from the vendor, and so on)?
That’s the general concept behind ServiceDesk’s PartsProcess form. It gives you several “virtual” tabletops—one for each category of progress in which your underlying parts request may lie. On its first-display/menu page, you pick the particular “tabletop” you want to work on.
In other words, when you pick a particular display category, you get the specific “tabletop” that pertains to the kind of work you’re presently interested in performing.
What happens behind the scenes, when you pick a particular “tabletop” (aka “display category”) is the system goes through each of the pending requests (again, depending on your size operation, at any time there may be several scores of them), and determines if it should properly be deemed to belong within the category (i.e. upon the “tabletop”) you’ve selected. For any item that’s determined should fit that category, it’s added to the “tabletop” display.
So, you pick your display category (either mouse-click on the menu item or keyboard-strike the indicated shortcut), and, instantly, ServiceDesk does the behind-the-scenes categorization, and presents you your tabletop.
The surface of this variable “tabletop” is arranged so that up to 18 requests can display within a single page view. If you’ve picked a category that involves more than 18 requests, the ones beyond 18 simply fall to subsequent pages (use your keyboard’s PgUp and PgDn keys to navigate).
So, here’s the concept. Each request appears along and within what we call an info-band. Each info-band stretches horizontally from the left-edge to right, and holds two lines of text:
The entire left-third of each band (green text) brings in information directly from the underlying PartsRequest form, which serves as its anchor. This request-specific info is somewhat abbreviated—so as to allow space to fit more process-related work-info to its right. If you’re working on an item and need greater detail about the underlying request, a simple right-click on the item’s reference number (top-left textual item in each band) quickly displays the full/underlying PartsRequest form, with applicable record loaded in it.
Please notice the colorful label area at top of this PartsProcess form. It’s intended that the labels there help you identify the information that’s intended, within each actual info-band, for the info that goes into each equivalent-position space. So, to know what each operative space is for, just line it up visually with the equivalent position label in that colorful section at top. That’s what will tell you.
In regard to the remaining right two-thirds of each info-band, they’re to fill-in details that pertain to all continuing processes, as performed in conjunction with fulfilling the underlying request. If you check the label areas, you’ll get some idea of their flavor.
In such regard, the first element of added information may well be the particular part number that’s needed, in conjunction with the request. Or, perhaps not. The fact is, some offices have their techs lookup the needed part numbers before creating the underlying requests. Others leave the lookup to someone in the office. For now, let’s suppose yours is in the latter camp.
So (we’ll at least pretend), you’re the parts guy. You not only do the ordering; you do the lookup too. You reach the point in your day where it’s time to perform the daily ritual. You need to gather up all the requests, as generated by your techs since you last did this task (probably yesterday). There may be other requests, too, such as those from guys at a parts counter. Anyway, instead of gathering paper slips, you instead go to the F8 form. There, you pick the display category “Items needing inquiry/order,” and see a list of info-bands where only the left-third is filled in. You look at the first, note the type and make of machine, what’s wanted, and determine how best to look up the requested part (if you’re in appliances, please don’t neglect to consider SmartParts (Alt-F10) as a good candidate for the easiest and fastest method).
At any rate, using whatever method is easiest, you determine the correct part number. Now, click in the info-band, and type it in the indicated box:
Or, we may suppose your tech already identified the number upon creating the underlying request. If so, you’d of course not need to look it up. Instead, you would have seen it automatically pop into the appropriate box for you, just as soon as you clicked within the info-band to display its editing boxes (pulled for you from the appropriate place in the underlying request).
Another possibility would be that you use your vendors to do the lookups (why expend your labor for the purpose when they’re willing to do it for free?). The system accommodates that, as well.
More specifically, it accommodates a plethora of methods for conveying requests to your vendors—whether the requests are for lookup, pricing and availability, or simply to place an order.
The most old-fashioned method of connecting with a vendor, of course, is to simply call via telephone, and you can certainly do that here. Suppose, with respect to each item, you call an appropriate vendor. You can ask for the lookup if it was not already done in-house, and upon receiving the part number back, type it into the appropriate space (along with other sensible info into appropriate boxes, such as an indication of availability and quoted price). Or, if you already did the lookup, you can simply ask about price and availability, and type that info into appropriate boxes, as it’s provided. Or, maybe you’re simply telling your counterpart at the vendor’s desk that, in fact, you’re placing an order. If so, fill-in the added appropriate boxes to indicate that.
Of course, we all know that, to place inquiries and/or orders via telephone is very inefficient. Instead, you may be going to a vendor’s website to perform these functions, and, if so, you can fill-in appropriate boxes to indicate info received (and actions performed)—much the same as if you’d spoken with a human (there’s even a box to indicate the particular method used).
Or, you can go for greater automation. Specifically, you can have the system itself generate either a fax or email request for you, one appropriate to each vendor of interest. Here, the general notion (reaching back to sorting slips on a large desk for those requests that will fit best with one vendor, versus those that will fit better for another, etc.), is to eyeball-peruse the current/new requests, and make precisely that kind of evaluation. As you do so, use simple mouse actions to assemble requests as applicable to each vendor.
This process is simple. Begin, for example, by noting that you have one or more items that will best fit for Vendor X. Then tell yourself, “Okay, I’m assembling a request for Vendor X.” Now scan down through all the open requests, and for each that should be included in Vendor X’s request, do a simple Ctrl/right-click on its info-band. You’ll notice, as you do this action, it changes the info-band’s background to yellow. That’s to designate it’s been marked for inclusion in the particular request you’re now preparing.
So you simply look through the list, designating each item you want to include in Vendor X’s request. When done, hit Enter on your keyboard. This invokes a dialog whereby you can choose whether to email the request, fax it, etc.
The basic idea is, by this means you can easily create a request for each vendor, and easily convey it to each (at least each that is amenable to receiving requests in this fashion). ServiceDesk will do the underlying work, to formulate the request to fit the circumstances, according to how you’ve prior filled-in applicable boxes (for example, if you’ve not done the lookup to provide a part number, it will ask the vendor to provide that lookup; if the request is tentative, it will ask the vendor for price and availability (P&A-only); if the order is definite, it will be asking the vendor to ship, etc.).
Of course, conveying the request does not complete the process. Each request is formulated in a manner that asks your vendor to respond with appropriate answering information (such as, for example, the part number if the vendor was asked to do the lookup, price and availability in all instances, and whether the part is in fact being shipped, if shipping was requested). The expectation is, once you’ve made the inquiry/request, the vendor will respond back with these elements of information. And, of course, there’s likely to be something of a wait before that happens.
So what do you do during that wait?
Let’s go back to considering the paper-and-ink, multiple tabletops notion. When you write on each slip of paper to indicate that at such and such date and time you made a particular kind of inquiry and/or request with a particular vendor, you’re not likely to keep those slips on the same work-area/tabletop. No, you’ll much more likely move them to another space—a space where you keep slips on which you’re waiting for a response back from vendors.
It’s the same in ServiceDesk—except ServiceDesk does the moving for you. Once particular boxes for an info-band have been filled-in in a manner that indicates the initial request was made (hint: this is done for you when you go through the above-described process), the band get moved from the “Items needing inquiry/order” category of display. Specifically, if the box which indicates order confirmation remains blank (while other boxes indicate the inquiry went out), the info-band is moved to the “Waiting for info from supplier” category of display.
The idea with this category is simple. In response to your faxed or emailed request, the vendor contacts you back with the requested answers (depending on circumstances, that “contact back” might be by fax, email or even telephone call). Regardless of method, when such info comes back, you need to go to the “Waiting for info from supplier” category of display, and fill-in the provided-back data. This fill-in process, properly performed, will take the items out of that category of display (off that tabletop), and move them appropriately to new ones.
As an example of this process, if you’d indicated the order was “Definite,” and if the vendor replied that he was shipping, you’d fill-in the box indicating the order was confirmed. You’d likely also fill-in the box indicating an expected arrival date, based on how long it takes to receive shipments from that vendor (please note that each of these boxes have tricks to make filling-in dates super easy; float your mouse pointer over each for tips). Bottom line is: any fill-in that sensibly indicates an info-band belongs on a different tabletop sensibly moves it to that tabletop.
At least it does so for thenext time a particular tabletop is loaded. You’ll notice the immediate response, however—if you’ve filled-in boxes in a manner that should remove an item from the current display category—is that the info-band turns grey. This is to prevent you from being worried or confused, as you might otherwise, be if an item that you were working on suddenly disappeared. Don’t worry; any item that’s turned grey within a particular display category will not appear within that same category next time it’s selected.
Since ServiceDesk is studying how boxes have been filled-in to determine which display category each process item belongs in, it may be helpful to understand the precise criteria it’s using for this determination. To the greatest extent possible, we’ve designed it to closely mirror what human logic would be, as follows:
There’s something else about that colorful label area, too. In other contexts, we’ve described contextual “Cheat-Sheets” — excerpts from the Command Summary as applicable to a particular work context. Like Callsheets and the DispatchMap, your PartsProcess interface is laden with otherwise hidden commands and tricks — powerful tools that, early-on at least, you’ll need as a handy aid to remind you. Since the colorful label area at top is otherwise un-operative (i.e., it’s only a label), it fits the rule that, if you right-click within an otherwise un-operative space (and in a context that offers a Cheat-Sheet), it will produce the Cheat-Sheet as applicable there. You can right-click elsewhere within the PartsProcess form too, so long as the spot where you’re clicking has no operative purpose otherwise.
So (and to take stock of where we are in this discussion), we’ve discussed how to perform appropriate work on your “nothing-has-yet-been-done-on-these-requests-and-we-need-to-do-it” table (aka “Items needing inquiry/order”), We’ve further discussed how, when you did this first work in a manner that produced the expectation of a later response back from your vendor—and when that response came back—you then moved to a new table, to appropriately type-in the responding-back information.
At this point, all your requests are likely to be in one of three states: (a) the part is on order; (b) you have price and availability info to pass on to the customer (for his yea or nea as to actually placing an order); or (c) the initial vendor’s response was not acceptable (e.g., price was too high, part was not in stock, NLA, etc.). Please notice, the system provides further display categories (e.g., tabletops) for items (a) and (b), which we’ll discuss shortly.
In respect to item (c), if the initial vendor’s response was not acceptable, it’s apparent we need to inquire with another vendor, and perhaps even make a succession of other inquiries. We do not want to create a new “Request Item,” because it’s the same and original underlying request that we’re still seeking to fulfill. Nor do we want to replace information, in the first info-band that we’ve typed regarding the first vendor’s response. We need to keep that there, so we know there’s no need to inquire from him again. Instead, there’s a very handy solution. We call them “daughter” bands. From any original info-band, you can make up to seven “daughter” bands—to facilitate further inquiries (and or actual orders), with other vendors, but still as tied to the same and original underlying request. We’re not going to tell you here how to create daughter bands (though we’ll reveal it’s a simple, modified mouse-click)—because we want you to practice using the PartsProcess form’s contextual Cheat-Sheet. You should use it whenever you need to learn (or remind yourself) of specific commands for specific actions. Go ahead: go to the F8 form’s Cheat-Sheet (right-click in the colorful label area at top), and look (under “MANIPULATIONS” and “General”) for the entry that reads “Request New Info Band.” That will tell you how to use this method.
So that’s how to deal with the occasional need to make multiple inquires (or orders) as connected to a single, underlying request. What about dealing with items where the customer wanted you to first acquire price and availability, then call them back?
As a rule, it likely makes most sense for the parts person himself to call the customer back, for a yea or nea, immediately upon acquiring the information. It’s easy to bring up the underlying JobRecord (with all appropriate contact info)—by doing the right-click on any info-band’s item reference number (this brings up the underlying request form, where you may then click on its “ShowJob” button). But, of course, sometimes the customer will not be available for immediate discussion. We suggest adding a note to the JobRecord’s history indicating the effort was made. Additionally, it makes sense to periodically review the F8 form’s “Waiting for approval from customer” tabletop, and, for any items where a yea or nea has not been received, renew the effort (try, in other words, to keep that “tabletop” cleaned up—just as you do all the others).
When and if you get a yea, of course, you can appropriately change applicable boxes to indicate the request is now “Approved,” and place the order with a vendor, much as you would have had the request initially been “Definite.” If you get a nea, you can simply change the request status to “Declined” (at such point, ServiceDesk will figure your work on that item is complete, and once again appropriately move it to a different tabletop). If your customer never responds and you finally tire of the effort, there’s another put-this-item-to-bed category called “Dormant” (look for it; you’ll see it).
Finally we are left with the general subject of how to deal, after the fact, with items actually ordered.
In terms of immediate response, this is perhaps the most simple. The parts come in, and you fill-in boxes to indicate the circumstances of their arrival. Essentially, you’re “checking-in” the parts (bear in mind, we’re talking about special-order parts here, and not stocking parts, which are “checked-in” through a totally different process). This is done, obviously, as shipments are received (or any equivalent event).
More specifically, as you open a box of just-received special-order parts, you’re going to open your F8 form, and pick the “On order, awaiting arrival” category of display. This will show you all items you’re expecting to receive. So, the general idea is, you pull an item from the box, then look within the displayed info-bands (use PgUp and PgDn to move between multiple pages, if applicable) to locate the one that pertains to the item in your hand. Once you’ve located that info-band, fill-in boxes to indicate date received, the vendor’s invoice number, and so on—as applicable to the circumstance.
The above method works just fine if you’re handling a relatively small quantity of special-order parts. If you’re handling more (so that, for example, at any point in time you have many pages in the “On order, awaiting arrival” display), perusing through so many items (to find the request that matches an item as just pulled from the box), is too laborious. For that situation, you can make the display-selected items more specific to what you’re likely pulling from a particular shipment. Specifically, you can narrow the selection criteria by applicable vendor, and even PO Number (see the face of the F8 form’s first-display/menu page for instructions).
Upon filling-in boxes to indicate an item has been received, you’ll often have your work interdicted with a message. The message will indicate that it appears no more parts are on order for the underlying job, and will ask for your consent for the job’s status to be changed into “Working to Schedule.” This change facilitates other office processes in achieving the re-scheduling purpose (assuming, of course, the job wasn’t already scheduled for a return visit in anticipation of receiving the part).
The interdicting message may make further offers.
If you have the customer’s email address (i.e., within the underlying JobRecord), it will offer send an email to the customer, informing parts have arrived, and requesting a telephone call to book the return visit.
Even better, if you’re using SD-CyberOffice, it will offer to make it an email that includes a hyperlink—on which the customer can click, and be taken to an interface on your website to re-book, day or night, and without other human intervention. That’s true space-age stuff, and you’d better believe it impresses the customer.
At any rate, once the part is checked in, part-process work on the item (as such) is essentially done. The underlying request and its connected process info-band will be moved to the PartsProcess archive (contents accessible via Ctrl-F8), thereby leaving the current work-area uncluttered by the work that’s already one.
From here forward, operations in the office (as connected with any job that had one or more special-order parts) resume with job- and schedule-management processes.
—At least, special-order parts-processes are done for the most part.
Why the qualifier?
In answer, read the next section.
Until approximately the 2006 to 2008 era of development, there was very little further done with PartsProcess items, beyond what’s been described. Basically, if you checked in a special-order part, ServiceDesk assumed it was used on the underlying job. It simply assumed so. There was no mechanism to assure it actually happened. There was no mechanism to verify if it happened. There were no mechanisms to assure, if the part was not used at all, some other appropriate action was taken—such as returning to the vendor for credit, or a deliberate decision to move the item into stock, etc.
To use a metaphor, we were good at giving birth to special-order requests, and at managing their matriculation through to graduation from normal finishing school (assuming normal graduation occurred). But we had no mechanisms for dealing with (or even counting) dropouts.
Documenting Usage of S/O Parts, When Usage Occurs:
The first element of change involved creating a method to check-off, when a special-order part is actually used on a job, that it was used. We added a box in the Type-II PostVisitReport form that displays items prior-ordered for the job, and invites the reporting person to indicate (via a simple checking action) whether each such item was in fact used.
When creating SD-Mobile’s PVR interface, we provided a nearly identical function there.
From either context, if an operator “checks” a listing to indicate the part was used, ServiceDesk inserts text in the underlying PartsProcess item’s BinLoc box. This text is a particular form, to signify usage. This BinLoc box seemed sensible for the purpose because, once the item has been used, it can’t be sitting in any bin waiting to be used. The particular text that’s inserted consists of the applicable technician’s two-letter abbreviation, followed by hyphen, then date (e.g., “GR-10/15”)—thus signifying use by that technician on that date.
Not long after creating this check-off method, we realized there was no corresponding method to check-off use (or, in this case, receipt by the customer) of items that were special-ordered in the POS context. So, in the FinishedForm windows where parts are listed (specifically, as applicable in a POS operation), we added a simple notation to indicate if any special-order item has not been checked as having been “placed” with the customer (I’m using the word “placed” instead of “used,” because, in this context, an item could be picked up by a customer, shipped to her, etc.). The notation is a double-caret symbol next to the part number, within the listing of items being sold.
Given this structure, the parts-counter/POS guy has a simple task to perform when either the customer comes in to pickup a POS/special-ordered part, or if he ships it. He needs to do a double-click on the part number that has the double-carets.
This tells the system the item was placed with the customer (i..e, “used”). In response, the system inserts similar text (as described above for special-order items being used on the job) in the underlying PartsProcess item’s BinLoc box. Plus, it changes text within the FinishedForm/POS interface to show usage (i.e., it removes the double-carets).
With the above explanation, we’ve described how special-order items get checked-off as having been used. That’s all well and good, but what happens if a parts does not get used? That is the subject to which we now turn.
Documenting any Other Final Disposition:
The primary question in this segment is: How do you document any non-usage, final disposition of a special/ordered part (such as, for example, returning to the vendor for credit)?
The simple answer is, much as each PartsProcess item’s BinLoc box is used to indicate actual usage (when such occurs), you’ll use precisely the same box to indicate any other particular disposition.
More specifically, when you are working directly in the PartsProcess form (regardless of whether in its F8/Current or Ctrl-F8/Archived mode), you’ll use a built-in dropdown from the BinLoc box to pick one of the dispositions offered:
As you can see, there are six options to choose from. The first is the same as is inserted by the system for you when, from any of the applicable contexts, you simply tell it the parts used as per original intent. You could select it here manually, if in fact the part was used, but the insertion had not been made via normally-intended means. The other’s speak somewhat for themselves:
RARqstd (to signify you've requested Return-Authorization from your vendor) RtToVndr (to signify you've returned it, with expectation of receiving credit) CrdtRcvd (to signify credit was in fact received) MvdToStk (to signify a deliberate decision was made to move the item into stocking inventory) WriteOff (to signify a deliberate decision was made to count the item as a loss)
You might notice that placing an otherwise unused part into these other disposition categories is a hand-on process. There are some things that, simply, humans must do.
You might also notice, if you use the system as above-described in a very simple manner (e.g., you simply select “RtToVndr” when you’ve returned the item, and change to “CrdtRcvd” when that event occurs, etc.), there is no inherent documentation as to when such events occurred. The only indication of such fact is a single, naked status indicator. This may be fine for some operations, but others will want more explicit documentation of what’s involved in the sequence of events. This is where you’ll want to take a further step.
We prior discussed “daughter-bands,” as adjunct info/process-bands that may be created to underlie a primary PartsProcess item request. In that discussion, added daughter-bands were described as useful when on the basis of a single request you need to place inquiries (or actual orders) with more than one vendor. For the present context, we’re revealing another use. Specifically, from the Ctrl-F8 Archived-PartsProcess window, it’s possible to create a special variety of daughter-band, configured for the particular purpose of managing return of the primary underlying part (i.e., as received within the main band). The idea is that this special variety gives you added places to put in dates, and such, as applicable to particular return effort (and credit received) events.
To create this special “manage-return” specie of daughter-band, just right-click on the primary item of interest (i.e., the info-band for the item you want to return), from within the Ctrl-F8 window. In response, you’ll get an option box:
As you can see, in regard to creating the wanted new info-band, you have two options: one is obviously applicable if the part has already been retrieved from the tech; the other if it has not. Make the appropriate selection, and you’ll instantly see a new daughter-band appear under the primary item, with some boxes already appropriately filled-in for you:
So now you have spaces where, much as you filled-dates on the parent band to indicate when you’d ordered a part, when you expected its arrival, when it arrived, invoice number on which it arrived and price on the invoice, you can use equivalent-position boxes to indicate then the part was returned, date by which you’re expecting credit, date credit was actually received, invoice number and amount of credit, etc. (Just as in any other context, of course, you’ll see such editing boxes actually displayed when you click on the item for editing.)
So mechanisms exist to enable meticulous documentation of what happens on every special-ordered part, whether used, returned or otherwise. But such mechanisms are worthless if not used. Indeed, even if there’s an effort to use them, they remain nearly worthless if not combined with a system that allows you to review and police, to assure all items eventually reach a proper end-disposition. This is our next topic.
Assuring All Corpses Are Buried:
Again, our overriding concept is “cradle-to-grave” management of special-order parts. In the prior two segments, we discussed how items ultimately go into the grave (i.e., either by use or some other deliberated end-disposition). The problem is, service offices are extremely busy places, and even well-meaning employees may, if not well-policed, let at least some parts fall-through-the-cracks, never appropriately being used or brought to other appropriate disposition. It’s not as though, after all, (like real corpses) they emit a nauseating stench that advertises their need to be buried. Instead, they sit quietly on a shelf (or kicking around in a technician’s truck), costing the business serious money.
What you need, therefore, is some mechanism via which you can regularly canvass the field, illuminating such corpses as need to be buried. And, of course, once they are illuminated, each needs to be buried (as per descriptions in the prior segment). That canvassing method is the subject of this segment.
In a nutshell, the Initial-Menu in the PartsProcess form’s Archived mode (Ctrl-F8) has a section listing particular functions designed for this canvassing:
The main options, as you can see, are either to examine the items on-screen in their native/actual context, or to create a separate document that contains the information. You’re likely to also notice there are filtering options (i.e., so you can limit your canvassing to items that apply to a particular tech and/or to a particular vendor). Regardless of which option you pick, you’ll be presented with a set of sub-options, as follows:
As you can see, the options allow you to get rather specific. The main idea is you need to regularly open the review in particular sensitive above categories, to assure there are no rotting corpses there.
And, of course, you’ll use your native intelligence in doing so.
For example, parts in the “Usage Pending” and “Awaiting Credit” categories are generally of much less concern (and hence merit less frequent and concerned canvassing) than parts in the “Expected Back” and “Past-due for Credit” categories. Regardless, it should be a daily ritual for someone in the operation to canvass at least most of the categories, to assure none has members that are due to be moved to the next station (and, of course, to invoke appropriate underlying work to assure that it happens).
By using these tools, you will reduce your “parts-leakage” cost (referring specifically to special-order parts that fail to reach a proper end-destination) to near zero. It’s important. Most service company owners have little idea how much they are losing via such leakage. Most lose a lot. And, it’s a double-edged sword. You not only lose via the direct money-outgo from never used parts, you also lose via the burden they then impose by taking up space in your building and trucks (where they also add weight, fuel expense, etc.). By harnessing just these tools alone, you’ll make significantly more money.
Managing Core Returns
Sometimes you order a part on which there is a “Core Charge” — meaning, besides the direct-quoted price on the part, you’re also required to pay a temporary fee that’s designed to assure you return the old part that’s being replaced. If you don’t return that old part (i.e., the “core”), you won’t receive any refund on the extra charge. Instead, you’re out of pocket for it, and sometimes core charges are very substantial (in the Consumer Electronics industry in particular, they are often hundreds of dollars). Given this, proper management of core charges and credits can make the difference between business success versus failure – making it imperative to assure that, for each “core” that should be returned for credit, the needed return in fact occurs (plus verify appropriate credit is received, etc.).
ServiceDesk’s system for managing this relies on a feature that will now be discussed for the third time: Daughter Bands. As you may recall, these are generally designed to deal with situations where the vendor that you initially check with, on an underlying F8 request, either does not have the part in sufficient quantity, can’t ship soon enough, or if his price seems too high (i.e., you need to shop elsewhere). In such a case, you simply open new info/process bands (daughter bands), and use them to document other inquiries and/or orders as placed with other vendors (yet still pursuant to the same underlying request). In all, you are permitted to use up to eight info bands as connected with a single request (the parent plus seven daughters).
Our strategy for managing cores mainly depends on using — in respect to any part that’s ordered and which involves a core — one such daughter band, but in a special way.
Specifically, when ordering and/or receiving the part (it can be done at any point, really), you should create a daughter band in the normal fashion (right-click within the right two-thirds of a parent that’s not enclosed within editing boxes). Once this daughter band is created, click in the Rqst box to expose its dropdown, then select the bottom listing, labeled “CORE.” Upon such selection, ServiceDesk will insert that word to the Rqst box, and insert the word “RETURN” in the Avlblty box. This serves to setup the daughter in a manner that makes it so: (a) it’s visibly apparent (to you as the user) that its purpose is to manage the core return, and (b) ServiceDesk itself can treat that as its purpose.
Once this special variety of daughter band is created, you should use its boxes in a manner that is analogous to what you do with a part that’s ordered (i.e., filling-in particular boxes as applicable to various progress events). But here, of course, the meaning of the boxes as filled-in will be changed — to fit the actual and specific circumstances as applicable to getting a core sent back to the vendor. In other words, the meaning of the fill-ins will be different for this context: somewhat similar, but not the same.
On the following page, we provide an illustration with notations to show, specifically, how we believe boxes should be differently used in a Core-Return situation (again, via a “daughter band,” as applicable to a parent via which the replacement part was actually ordered and received).
Please notice that items 1 and 2 (as labeled in the illustration) fill-in for you, on the basis of your selection of “CORE” from the Rqst box dropdown.
Item 3 will also auto-fill for you — specifically, when you “check-in” the part to which the Core-Return daughter-band applies.
Item 4 will auto-fill (for ModeA, as there labeled) if your tech is using SD-Mobile, and if when queried via Mobile he confirms having retrieved the old part, upon replacing with new. By contrast, your parts management person should manually change to the ModeB designation upon receiving the underlying core from the tech.
Items 5 through 10 should each be manually filled-in by your parts management person, at appropriate steps in the return process. By such filling-in, you may easily keep track of each element in the process, to assure ultimate and timely completion.
But the above is not all.
The PartsProcess form also possesses a viewing/filter option designed specifically to assist in monitoring Core-Return items in each of several categories.
If you look at the illustration of the F8 form’s MainMenu display as shown on Page 124 (near this chapter section’s introduction), you should notice that, compared to the actual menu as currently offered, it’s out of date. The current menu features an option — not shown there — labeled “Core return items.“
If you select that option, you’ll next be presented with the following dialog box:
In some respects, these options parallel the operative purposes as existing for reviewing actual parts as not yet placed in-the-grave, reviewed (with a somewhat similar-looking options box displayed) a few pages back). Just as there, there are choices to allow your parts operations person to review particular categories, for the sake of review/policing, and assuring that all items keep moving appropriate toward their proper end destination. The difference: there we were referring to actual new parts, as purchased but not used, being returned, and here were talking about the old replaced-parts/cores going back to a vendor. Regardless, the similarity is there are display categories to aid the review/policing process, and they should be used on a regular (likely daily) basis.
To summarize, the general strategy for managing cores is as follows:
Security is ultimately found in the fact that, once a Core-Return daughter band is duly attached to a parent PartsProcess request, the entire request bundle will refuse movement to the archive until the Core-Return daughter band is appropriately marked to show proper membership in Category 6 (“credit received and process Done”). In fact, it will pester you by virtue of its very, not-yet-processed-as-it-should-be-presence within your current work area, until and unless you certify that the ultimate step (receiving credit after return) has been accomplished.
We believe, by following the above prescriptions, you can easily assure proper processing on 100 percent of your core charges. We further believe it’s absolutely what you should do. If your operation involves cores at all, please figure implementation is an essential necessity.
There is probably no service company that does not find it prudent to maintain a minimum stock of parts and/or supplies. Nor would you expect to find any that do not need a systematic method for tracking precisely what they have purchased and entered into stock, what they have used out of it, what they presently have left (including where those quantities are located), and how the latter values compare with minimums needed before re-stocking. Many companies already have systems in place to meet these needs; some do not. Regardless, ServiceDesk provides the system you’ll now want to use—designed as elsewhere for maximum effect with minimum effort, and taking advantage of information already garnered from other aspects of operation.
We’ll begin our description of this system with a broad, conceptual overview. In such regard, it may first help to know that ServiceDesk maintains four principal files in conjunction with its InventoryControl function:
Bear in mind that while these files underlie the various processes involved in InventoryControl, you do not have to know their names, nor should you confuse this description of files with the forms you’ll use to access their information. It may simply help to know these are the kinds of information the InventoryControl system uses to serve your needs.
In regard to forms themselves, there are primarily two dedicated to this system: the MasterPartsPlan form and the InventoryControl form.
The first (as its name implies) is used to create and maintain your MasterPartsPlan (sometimes called the “MasterList or just List”). Having such a task, it’s a form that you’ll become rather intimate with when first setting up your system (press Ctrl-F10 to access it). After that, you’ll use it only when needing to revise the MasterList, and so you may go for many months at a time without ever touching it. In such a sense (at least to the extent you find it unnecessary to revise your MasterList), you might say this is a “use and forget” form.
The “InventoryControl form” is also aptly named, for it’s function is to access and manage the item-by-item listing of (and record of movements among) actual items in your stocking inventory, to facilitate re-stock to each truck, re-order when inventory is low, and so on (press F10 to access it).
As you might guess, there’s interaction between the kinds of information that’s gathered by these two forms. It’s based on information created in the MasterPartsPlan form, for example, that the InventoryControl form deduces how many of a given item should be on each truck, and knows when restock is needed, etc.
A final point to remember concerns the conceptual and functional distinction between what we’re describing here (described within this manual as either the “InventoryControl” or “InventoryControl” system) and the PartsProcess system described in the last section. The two are very, very separate. In regard to the present topic we’re a discussing a comprehensive system for managing every item of stocking-type part that you intend to maintain in inventory. With the PartsProcess system, by contrast, we intend to manage functions associated with non-stock parts (i.e., items you do not intend to maintain in inventory, and so acquisition of such items essentially involves a “special” order). The PartsProcess system, you may also note, is not at this point as comprehensive. While it very ably facilitates the ordering process, it does not presently keep track of what happens to such parts (or of how many you have sitting around at a given moment) once they are received. Regardless, please be very mindful of the distinction. Stocking items and non-stocking items are handled very differently.
Again, this initial description has been intended as a broad conceptual overview—regarding the InventoryControl system. We’ll next discuss specifics, but first let’s note one added matter.
Of all the systems in ServiceDesk, this one requires the most work—by far—in terms of setting up for use. Indeed, it requires quite a lot of pretty hard work (not complicated or hard to figure out, just tedious), and can’t be used, for the most part, until that work is done (afterwards, thankfully, continuing maintenance is a delightful breeze). We mention this because, for a new user, we think it probably makes most sense to delay use of this system until after you have other, more basic elements of ServiceDesk operating. It’s true that you won’t immediately enjoy its benefits, but presumably you’ll be no worse off (in specific regard to InventoryControl) than you were previously. If you do so delay, there’s one thing you’ll need to remember in terms of running the rest of the system without this InventoryControl portion yet setup. When doing PostVisitReports, one of the queries is whether the technician used any parts from stock. Until you’ve setup this system, it will be necessary to lie in response to that query. Even if a part was used, claim “no.” The reason is because the system will have no way of properly responding to a “yes” response until after inventory information is finally setup.
As your very first task in setting up an InventoryControl system, you must describe the parts you intend to maintain in stock (make a list, in other words). That is, of course, where the MasterPartsPlan form comes into play. Press Ctrl-F10 to access the form.
For the most part, we think this form is self-explanatory. It lists 39 items to a page (once you create them at least), allows you to move between pages using the PgDn and PgUp keys, and employs the common ServiceDesk convention of allowing you to make edits to any item by first left-clicking on it, following which it is enclosed in editing boxes. To delete an item, right-click on it (also a common ServiceDesk convention). To add new items, either click on the first empty space, or select the form's Add-Item command.
Of course, you should know something about the types of information ServiceDesk expects you to list in respect to each item you'll be describing. Go ahead and bring up your MasterPartsPlan form, then hit Alt-A to add your first item to the list. Immediately, you'll see a row of editing boxes into which you're expected to enter information.
The first three boxes, you'll see, are all for PartNumbers. Why three different PartNumbers? In our experience, we've found that a given kind of stock item can often go by several different PartNumbers, and it's helpful to have more than one, of these alternatives, at your ready grasp. Thus, we've allowed up to three. They are permissive, which is just another way of saying there's no requirement for you to use all three. The possibilities are simply there if you want to use them. The only requirement is that you list a unique number (or other identifying equivalent) in at least one of the three spaces.
Organizationally, we do have some specific intent about what kind of numbers you might most beneficially use in each box (though this is not required; you can use each in whatever manner you please so long as that minimum requirement is met). Our thinking is that, ideally, you may want to use the first box for an OEM (i.e., original equipment manufacturer) part number, if applicable. If yours is an appliance repair company, for example, and you're entering a part used in Whirlpool dryers, we suggest entering Whirlpool's part number here. The second space, more typically, we think should be used for an Industry PartNumber if applicable (in many cases there's a number that's recognized within an entire industry as referring to some product generically, for example, such as “R22” for that kind of refrigerant). The third space, since many service companies buy a large percentage of their stock from Johnstone Supply, we've intended for use with a Johnstone part number (it's six spaces long, while the others are 16 and 10, respectively). Of course, you may again use it for whatever kind of identifying information you wish, or for none at all if that's your preference.
Following these first three PartNumber spaces (remember you must have a unique identifying number in at least one), are two very small spaces, allowing only two characters each. The first of these is for an abbreviation indicating the brand of machine or fixture the item is used with (if it's use is not limited to a particular brand, we suggest using the letters "AL" to denote applicability to all makes). The second is for an abbreviation indicating the kind of fixture or appliance the item is used with (i.e., you might use "DR" in reference to a dryer part).
The very next space, far longer than the others, is for your description of the item. Obviously, descriptions are exactly that, and can take whatever form you prefer. However, we have a specific suggestion in their regard. For the first word in the description, consider using a term that's as general as possible, then a comma, then more specific details. The reason is because ServiceDesk will sort your list alphabetically, by description. If you were to list one item as "1/3 HP CONDENSER FAN MOTOR," for example, another as "BLOWER MOTOR," and still another as "FASCO BRAND UNIVERSAL MOTOR," the items would all end up in rather different places on your final list, making it much less organized and clear. Instead, it would be smarter to list the above examples as "MOTOR, CONDENSER FAN, 1/3 HP," "MOTOR, BLOWER," and "MOTOR, UNIVERSAL, FASCO BRAND." In this way, all three listings will end up being together after ServiceDesk alpha-sorts your list, and it becomes much easier for you to review each motor you've included in the list, or to locate any just by looking alphabetically under "MOTOR."
Following the Description block, there are two spaces for you to insert the price, or prices, you intend to sell the item for. The reason for two price spaces is because you might have one price for regular customers and another, discounted price for home-warranty or other special clients (if not wanting to offer any second category of special prices, just leave the second field blank).
Finally, there are two remaining, and very small spaces at the end. The first is for the quantity of the item you intend to keep in stock on each standard truck, and the second for the quantity that will be considered the minimum for your stock room before ServiceDesk prompts you to reorder.
In regard to these last two quantity spaces, there's an important option which allows you to insert something other than a quantity. There are many kinds of stock, obviously, where a little bit of some bulk supply will be used at a time, but typically not the entirety (like one clamp out of a box of clamps, for example, or a little freon out of a jug, etc). For such items, it makes a lot more sense to simply document having placed that supply into stock, and then to assume some supply remains until there's a report that it's been exhausted—rather than attempting to constantly quantify how much of the box or container remains. If this is the kind of item you're listing, don't put a quantity in either of its two quantity boxes. Instead, type-in the letters "SU" (abbreviation for "supply"), and ServiceDesk will subsequently interpret the item accordingly (when any item is so listed, the quantity value that's kept in inventory will refer to the number of such supplies (i.e., boxes, jugs, etc.), rather than to the amount of material left within any specific box or jug.
It does involve some amount of work, obviously, to create this list of the various items you intend to maintain in stock—not a huge amount, but considerable nonetheless. Within our own service business, we’d developed an effective list that worked very well for us (we were getting approximately 75 percent first time completions with about $3K in inventory on each truck). If yours is likewise an appliance service business, we invite you to use our list (and reduce or possibly eliminate the work of setting up your own). A copy is provided on the installation CD (using Windows Explorer, look for ‘StckList’ in the ‘OtherFls’ folder and copy into the ‘c:\sd\netdata’ folder on whichever computer you are using as FileServer). At the very least, you might find it easier to start with our list as a foundation, and add or delete entries to taste rather than starting from scratch. And, even if you’re in another trade (in which case our list would probably not suit your needs at all), you can, if wanted, load our list and look at it as an example (just delete the same file when wanting to replace it with your own list). Also and incidentally, if any of you in other trades are particularly proud of whatever list you ultimately develop—and are willing to provide us with a copy—we’d be happy to make it available to other ServiceDesk users on future CDs (along with the one oriented toward appliance service that’s currently there).
In regard to other features on the MasterPartsPlan form, you'll notice there's a command button for doing a Sort/Index routine (sorts items alphabetically and makes the MasterPartsIndex that ServiceDesk needs in other InventoryControl contexts; be sure to run it before otherwise using the form’s data), and also a button for printing a copy of your list (it’s useful to take a printout of item-types when counting your beginning inventory). Naturally, there’s also a ‘Search’ button, which allows you to quickly find listings based on any of the alternative part numbers, or even description. Finally, there's a command button that's less obvious in purpose, labeled "Make Ascii File." Its function is to create a version of your list that can be loaded into your word processor, and there edited or formatted for whatever separate purpose you might like to make of it. Most companies will equip each of their technicians with a catalog-type listing of stocked parts, for example (based on the MasterPartsPlan). With the special formatting that can be done in a word processor, you can setup to print your list in multiple columns on a single page, or on both sides of a single page, or whatever else is the handiest format for your technicians to use and keep in their clipboards (as needed for them to correctly price parts, know what they’re supposed to have on their trucks, etc.).
Again, bear in mind that the MasterPartsPlan form has one primary function: it's the tool you use to create and maintain your own MasterPartsPlan (additionally it creates an index that ServiceDesk uses in related stock functions, and you can use it to create a version of your catalog-type listing in Ascii format, but these are peripheral to it's main function).
After you've created your MasterPartsPlan, you'll be ready to begin informing ServiceDesk of what items you already possess, at the point where you begin using this system. Unless you're a spanking-new company, you're obviously going to have lots of inventory that’s accumulated during previous years of operation. Whatever it takes, you're going to need to come up with a listing of every item (or every separate container of supply, see page 147) in existing intended stock. If the system is going to keep track of what you’ve got, after all, it’s got to know what you’re starting with. You may already have such a list, or may need to physically go through everything—both in your storeroom and on all the trucks—and count it.
The easiest way to perform such a counting is to have a sheet of paper that lists each of the items that need counting at each location (we’ll call it an Inventory-Counting-Sheet). Then go to each such location (with its own respective Inventory-Counting-Sheet in hand) start with the first listed item, count the quantity found, then write it in. Proceed to the next item in the list, count the quantity found, write it in, and so on.
The best way to make these Inventory-Counting-Sheet is from the F10 form. From there, select the option to ‘Review Existing Inventory’ then ‘List of Pt#s, showing total Qty each’. Now select the location you want to make a list for, then click on the ‘Print List/Labels’ button. At this point select the option for ‘an ordinary List’ and select your printer. You’ll find the system makes a very nice printout that’s perfectly suited for going to the location to perform the counting and write-in of found quantities (it even includes a space next to each listing to write-in in the quantity found). The best idea is to print such a sheet (it likely will consist, in actuality, of many pages) for each location that needs counting (i.e., one for your office storeroom and one for each truck).
With these sheets prepared, you’re ready to do the actual counting. Just go to each location with its appropriate Inventory-Counting-Sheet, and do it. We know it may be a lot of work, but it’s got to be done (and just think, if you haven’t previously had an accurate and comprehensive accounting of intended stocking-type inventory, finally you’ll have it).
Once you've filled-in each of these sheets with actual counted quantities, it's time to input the information to ServiceDesk. Remember here that when you setup item descriptions in the MasterPartsPlan, you were not in any way indicating items actually possessed; you were only describing a plan, what you intended to possess. Now it’s time to do the real thing: check in actual items, tell ServiceDesk you have 2 of these, 3 of those, and so on.
There are couple of different ways this can be done. The normal way is that items are “checked-in” when received in a shipment (or otherwise purchased from a supplier). You’ll see the F10 form has a nice facility for this, which we’ll discuss shortly. But there’s also another potential way. It stems from the fact that, in any inventory system, you’ll sometimes find yourself with a quantity on hand that’s different from what the system had reckoned. To deal with that, we also have a facility in the F10 form to “adjust indicated quantities.” In established operation, that latter function’s purpose is solely to correct for differences between what’s actually found and what the system formerly reckoned. In the initial setup situation, however, the facility can be used to do a kind of pretended “checking-in” of actual quantities.
As it happens, the best overall strategy for inputting your initial quantities of stocked items into ServiceDesk is a combination of these two methods. In regard to the office storeroom, you should pretend you’re receiving a shipment into stock (of all the items you already have there), and use the method (within the F10 form) as provided for that ostensive purpose. Then, to input the quantities found on each truck, you should use the ‘Adjust indicated quantities’ method.
Here follows a brief overview of each such step.
For your office storeroom inventory, put its completed Inventory-Counting-Sheet in front of you on your desk. In ServiceDesk, bring up the InventoryControl form by pressing F10. As the form displays, you'll see that it offers several options, including one labeled "Receive items into stock." Select this option and you'll instantly be presented with a query as to which supplier sent the package of items you're checking in. Here, of course, you're dealing with a “package” consisting of everything you already have in stock in that storeroom, but the system insists you name a supplier, so make one up. In particular, it’s a good idea to make the name helpful for the circumstances by calling “Initial Stock” (or something similar). So, in the space provided, type in "Initial Stock". Now ServiceDesk will note that you have no supplier in your list by such name, and will ask if this is a name you want to add. Indicate yes, and ServiceDesk will then add a category of supplier (supposedly) by that name.
Now you can begin checking-in actual storeroom quantities. As you'll note, the system works in something of a dialog fashion, asking you first to enter the part number you're checking in, then the quantity, then the price paid for it. In regard to price paid, it may be difficult to come up with exact historical costs, and unless you’re personally a stickler for such matters, we don’t recommend sweating over in fact. In fact, for our purposes we thought it was best to use the W.A.G. principle. This is the method that’s used by sophisticated engineers when they need to calculate something less critical than the chord width for the beam supporting an airplane wing; it stands for Wild Ass Guess. The idea is to get the information as quickly and easily as possible. In probably won’t matter much, in the long-haul, if you use the W.A.G. principle exclusively in this initial valuation of parts.
You'll notice there's a drop-down list to assist you in selecting the item being entered (you can type the description or any of the three alternative part numbers and matches should appear in this list). To select an item from the list, you can click on it, cursor down to it then hit Enter, or keep typing until it's the top item in the list, then hit Enter—whatever is easiest. Enter as many items as you wish in a session (but do not exceed 99, for that’s the most the system can absorb in a single session-sequence), then hit Enter with nothing in the box to conclude a particular entering session (as instructed, incidentally, by an instructional note in the form). You'll then be asked to confirm if you're concluding the present set of entries, and if so will be queried as to the shipping cost of the package (not easily applicable in the case where it's initial stock, so report "0").
When entering these initial storeroom quantities, there will likely be many, many entries to make. It will probably be best to do 10 or 20 entries at a time, then conclude and begin a new session, repeating until all is eventually entered.
Once this portion of the process is complete, ServiceDesk will now “know” about all the items of intended stocking inventory in your storeroom. Now it needs to know what’s on your trucks.
Again, the method we’ll use for “checking-in” initial truck inventory is the “Adjust Indicated Quantities” method.
For reasons we’ll not bother to explain here, make sure you do the storeroom first, as described above. Then, for each truck, take its completed Inventory-Counting-Sheet, put it on the desk in front of you, and within ServiceDesk bring up the InventoryControl form by pressing F10. Now select the option to ‘Adjust indicated quantities’ then ‘by reviewing entire List’. Select the applicable truck, as prompted, then you’ll see you’re presented with an on-screen list, showing each item description in the same sequence as the Inventory-Counting-Sheet that’s on the desk in front of you. All you have to do is look at the first written-in quantity (as physically counted on the truck), type it on your numeric keypad, hit enter, then the next, and so on. In such fashion, you can rip through literally hundreds of items very quickly. As the instruction prompts, you can simply hit your keyboard’s Esc key when ready to record, then follow any added prompts. It’s that easy. (It wanted, you can break this up into multiple sessions as well.)
With all of this having been accomplished, you’ll have everything in place for what will—from now on—be an almost effortless basis for maintaining near perfect and constant control of your stocking inventory. Yahoo!
When the above preparations are all complete (and assuming you do the counting/input portions over the course of, say, one very long and busy weekend), you will possess what is essentially a snapshot image of your inventory situation at a given point in time. However, we know inventory is not a static thing. It’s changing all the time as parts get used and new ones are shipped in. To keep the picture accurate, the system obviously must be informed of all movements, in or out.
In such regard, let us first consider movements of items into your inventory (now referring to items actually being added physically, as opposed to merely registering items already there, per the last section). Indeed, and even more specifically up front, let us consider that, before any items are moved into your inventory, you probably need first to order them.
Ordering restock of depleted inventory is obviously no trivial matter (and again, should be contrasted with the process of ordering non-stock parts, as discussed beginning at page 122). However, ServiceDesk makes it easy—and it can all be done electronically, if wanted. All you must do is select the InventoryControl form’s ‘Order stock replenishment’ option. The system will soon (after a bit of searching) display a list showing every item on which it finds fewer items in stock than the MasterPartsPlan-specified minimums. The list identifies each item and shows how many are in stock compared to specified minimums. It further deduces and displays the difference (i.e., how many are needed to restore minimums), and indicates the quantity that should (assuming no pilferage, etc.) be on your storeroom shelf. It invites you, quite simply, to specify how many of each such item you want to include in a particular order. All you must do, in regard to each such item, is hit a number (i.e., quantity) on your keypad, then Enter.
In this manner, you’ll quickly formulate a restock order (it might take a few seconds). If your company is like most, there are probably some items that you prefer to purchase from one supplier, and some from another. That’s easy. Just formulate one order for the first, specifying quantities for the items you want to order from it. Formulate a different order for the second, and so on (and as often as you prefer to place restock orders, whether weekly, monthly or “whenever you get around to it”).
After formulating any restock order, the remaining task is to transmit it to the supplier. We do this, essentially, by “printing” it—with the verb there having something of a broad meaning. On the one hand, you can literally print a sheet having all the order information on it (simply follow the prompts to do so). You could take this sheet and mail it, telephone the supplier and read off of it, or much more probably put it in your fax machine and send its image to the supplier. Alternatively, you can specify your computer’s internal fax as the “printer” and fax the “order sheet” that way, so that you never even need touch paper. In our office we prefer to “print then fax,” because we automatically then possess a hard-copy version of what the supplier (presumably) received.
At any rate, as operations continue, you’ll undoubtedly soon be placing orders for restock, and receiving shipments in response. With each shipment received (or even if someone drives to a supplier’s warehouse and picks stuff up), it’s imperative that you inform ServiceDesk of each and every item entered into inventory. This is essentially the same process as described for entering initial inventory, except that now we’ll be checking in a genuine shipment (rather than pretending to be checking in a shipment as a means of checking in our initial stock). And here, of course, we’ll be using a real supplier’s name, real, on-the-invoice costs, and so on.
One of the features you’ll notice when checking in parts is that ServiceDesk asks if you'd like to print labels for the items received. These labels can be rather useful, carrying much information that may not otherwise be on the parts. If you’d like such labels, simply indicate ‘Yes’ when queried. The system is configured to print individual labels for each part onto Avery # 4013 labels (sometimes listed as # 04013). These are sized 3.5" X 15/16" (spaced one label per vertical inch), and arranged in a single column on tractor feed paper for maximum printing convenience. A printed label will look something like the following:
WD15X93 563
K35175 FILL VALVE
GE DW Rec'd 10/11/98 from JS .16.154.
1 per trck, 3 min strg, $24.84 ()
Here you see the three alternative PartNumbers arranged along the top line. In the second line, you see the item Description followed by your own MasterPartsPlan abbreviations for ApplicableMake and MachineType. In the third line, ServiceDesk prints an abbreviated note regarding when the item was received and from whom, followed by a moderately disguised code which indicates the price you paid for it. Finally, in the last line is an indication of how many of this item each truck should maintain in stock (according to info you've input to the MasterPartsPlan), the minimum you should have on hand in storage before re-ordering, your standard retail price, and (in parentheses) your preferred discount price, if any (no dollar sign is included here).
Besides new items going into your inventory, there’s obviously old items going out (i.e., being used and sold). These movements must also be registered. However, and contrary to what you might expect, this is not a task that’s normally performed in the InventoryControl form (although, should the odd need arise, it can be done from there). Instead, it’s done much more conveniently in the PostVisitReport form, as part of the PostVisitReporting process (see page 110). As part of the dialog in that process, the system asks if any stocking parts were used on the job. If the query is answered in the affirmative, it collects information about which parts were used, and from which location. It then makes appropriate entries and adjustments in your inventory files (not to mention a narrative-type report within the job’s History).
Of course, as parts are used from each of the trucks, they need to be restocked. Again, we’re back to using the InventoryControl form, and again the process is basically the same as when we “transferred” initial inventory to the trucks, except in this case we’ll be using the system to inform us about what actually needs restocked, and reporting on what (at the moment) we are actually transferring, physically. Again, there are alternative methods for registering transfers (‘Review needs and disburse to truck’ versus ‘Disburse without prior review’), and you may use either depending on preference.
In our office, the habit is that each tech arrives at staggered times in the morning to report on jobs from the day before. Upon concluding (meaning that, among other things, he’s made entries regarding all items used from stock), and before taking a stack of new jobs and heading out for the day, he asks for restock. An office person then strikes an appropriate sequence of keys in ServiceDesk (‘F10’ to bring up the InventoryControl form, ‘T’ to select the ‘Transfer to/from trucks option, ‘N’ to select the ‘review Needs and disburse to truck’ option, and finally the tech’s initials), and quickly sees list showing all items that need restocked. If it’s one or two items, we may simply make a mental note, go to the storeroom and pull the items. If more, we hit Alt-P to print the list, then go to the storeroom with paper in hand. At any rate, we then return to the screen and report on how many of each item were transferred to the tech. Typically about a one-minute operation, this keeps all trucks constantly replenished with the stock they are supposed to possess, and everything is recorded for future reference if and when needed!
As you can see, the system is very easy (after initial setup, at least), and in terms of what it accomplishes, most powerful. Indeed, there are many other features on the Inventory form that we’ve not bothered here to describe, for they are largely self-explanatory (simply review and explore the options provided, and you should quickly gain an understanding). There are just a few items that bear further explanation.
First, occasionally it may happen that one of your techs report using an item, then they realize it was entered incorrectly, and it’s really something else they used. To try to keep things straight, they inform you. That’s where the bottom two options on the InventoryControl form come into play. First you’ll need to cancel the incorrectly indicated usage. There’s an option specifically for that purpose, and so labeled. Then you’ll need to enter the correct item, for which there’s an obvious counterpart option.
Second, unless you’re very lucky, you’ll probably lose one of your techs, from time to time, and have to replace him with another. You may notice that the system identifies each truck according to the initials of the tech it’s assigned to. Correspondingly, all of the parts checked out to a truck are identified by that tech’s initials. This means, if you remove one tech’s name from your roster and replace it with another, you’re going to still have a bunch of parts assigned under the old tech’s initials—even though, presumably, the new tech probably has taken over the old tech’s truck and all its associated inventory. What we need, therefore, is an easy means of changing the assignment references, for each of the parts formerly assigned to the old tech, to the new tech’s initials. There’s a utility of this specific purpose (review the options) on the InventoryControl form.
Finally, it’s inevitable in any inventory system that inaccuracies will eventually creep in. This may happen because someone uses a part and forgets to report on it (or perhaps returns an item and forgets to report it). There may be pilferage, inaccurate reporting on parts received, or any of several other possibilities. Regardless, when you find a discrepancy between what the computer claims and what you actually find on the shelf, it needs to be corrected (the system needs to be informed, in other words, of what’s really there). ServiceDesk provides two alternatives for this information.
In the most typical case, you’ll find yourself wanting to enter corrective information on a piece-meal basis (say you've noticed that one or two items are indicating an erroneous quantity when performing restock to a truck, for example, and you want simply to correct these). Here, the best method (after choosing the 'Adjust indicated quantities' option) is to further select the 'by Selected item' sub-option. At this point, a drop-down list appears, from which you can select the item whose quantity you wish to correct. Upon selection, you'll be prompted to indicate the correct quantity, and the system will indicate how many additions or deletions are necessary to make the indicated quantity match. If it's additions that are needed, ServiceDesk will search to find the most recent cost of such items, and propose the additions be valued similarly (if it's unable to find any exemplars of cost, it asks for input from you).
If, on the other hand, you're wanting to do a complete and thorough recount of all items (whether in regard to office stock or what’s on any particular truck), the alternate method will be easier. In this case, you should begin by printing out a listing which shows the quantities of each item, as presently indicated. To do this, select the InventoryControl form's 'review existing Inventory' option, then its 'List of Prt#s, shwng qty of each' sub-option. Request a viewing of items in the pertinent location, then request a physical printing by clicking on the 'Print list' command button. This will give you a long printout which you can then take to the relevant location, using it as the prompt, counting each item off the shelves in the sequence listed, and writing in the correct quantity if it differs from what's indicated.
After finishing this exhaustive counting, you must next return to the InventoryControl form, select its 'Adjust indicated quantities' option, then the 'by reviewing entire List' sub-option. Now you'll see the entire listing on-screen, and have the opportunity to easily indicate correct quantities (should they vary from indicated) next to each. At conclusion, you'll be asked to confirm the intent to save alterations to the file.
One thing you should be aware of in regard to these procedures is that, besides adding items to or deleting from the InventoryList to make quantities accurate, ServiceDesk also makes entries (as with all other transfers) in the InventoryJournal (“IJrnl”) to document the process of transfer. If you review this journal from time to time (select the InventoryControl form's 'Review Purchases and Usage' option), you'll see that, using two-letter initials, it indicates transfers from a supplier to the office, from the office to a particular truck, from a truck to a sale (indicated by the '$$' symbol), and so on. In the case of correcting quantities indicated in office stock, it will show items as being transferred either from or to 'SC', indicating 'Stock Corrections'. Thus, if you are in the future interested in knowing how many adjustments have been needed to maintain an accurate indication in inventory, you can simply look at the IJrnl for all items going either to or from 'SC'. If there are too many ‘SC’ references to stock removals (i.e., more than could reasonably be expected to result from mere inaccurate reporting), obviously, you may deduce that you have a problem with pilferage.
There are, as mentioned, several other features which are quite self-explanatory upon examination (just explore the possibilities, you’ll see what they are). On the other hand, there are a few reporting-type features that we’ve not yet developed, but of course intend to in the future. There's no inventory-aging feature yet, for example, and no provision for tracking frequency of use among items, or for tabulating values of input and output over a given space of time. Please let us know if you feel an urgent need for such capabilities, and we’ll give them higher priority in our development schedule.
The foregoing has described the basic InventoryControl system as originally developed. For most operations, those basic-level features should prove more than adequate, and to the extent they do there will be no need for you to read further in this section. If, however, you want to list more information in conjunction with each part item than is allowed within the main section of the MasterPartsPlan form (such as additional part numbers, preferred vendor, expected purchase cost, bin locations, etc.), you’ll want to consider the advanced capabilities that we’ll here discuss.
In particular, you may notice that the basic system is setup with the assumption that you’ll be stocking all your service trucks with the same identical inventory set. The reason is because this keeps things simple, and is what the majority of service companies do. If, however, you’ve setup your operation so that different trucks are specialized for distinct purposes (such as, for example, having one or more trucks setup for refrigeration work, another setup for servicing laundry equipment, etc.), this section is especially for you.
All of these advanced features are accessed from via the MasterPartsPlan form, and from two contexts therein.
First, if you want to setup different stocking plans for different trucks (or other alternative locations), you’ll manage initial setup via the InventoryLocations form, which is accessed by first clicking on the MasterPartsPlan form’s “Other Housekeeping” button, then by picking the “Manage Locations/TruckTypes” option. This exposes a two-section interface. In one section (to this form’s left), you are allowed to create up to six different kinds of specialized stocking plans (these are in addition to what may be considered the “standard truck” and “standard office” plans, which exists by default and get their planned minimums from the “Trk” and “Offc” columns within the face of the main list). In the second section, you are allowed to explicitly list actual inventory locations. This may or may not be needed, depending on circumstances.
Second, you’ll notice that on the MasterPartsPlan form itself there is a green vertical stripe, located just to the right of where the part items are listed. The general idea is that if you want to list any extra information for an line-item in the list (such as the quantity that you wish to maintain on a particular specialized plan, for example), you may simply click adjacent to it upon this green stripe. At this point you’ll see a nice little window that allows you to add all the various kinds of information you may want—including even notes about the part if wanted. You can think of this, in a sense, as a “MoreInfo” form in regard to part listings—only this one we refer to as the Supplemental-Info window.
Using the Supplemental-Info Window is quite straightforward. Most functions should be obvious, but one element requires explanation. Suppose you’ve just created a specialized plan type (from the InventoryLocations form), and now need to indicate, for each part line-item, the quantity you want as minimum under that plan. If you have several hundred line-items in your overall list, this can be a lot of work. Happily, there’s a shortcut. To illustrate, consider a client who (and as is typical) had a bunch of trucks all setup for the standard/default plan (with intended minimums appropriately filled-in within the intended column on the face of the MasterPartsPlan form). This client had a special need, though, in that on two particular trucks he wanted to stock several score more items, oriented for high-end work. It’s for those trucks that he needed a specialized plan, but the plan as needed overlapped with the standard plan, but added more. Why should he have to directly populate each such item’s specified quantity (within that plan’s minimum-quantity box in each line-item’s Supplemental-Info window)? This is where the shortcut comes in. If you look at each specialized plan, minimum-quantity box, you’ll see it has an asterisk (“*”) next to it. If you click on any such asterisk, the system will offer to set all quantities under that plan type the same as for “standard” trucks. It’s to give you a potential head-start in populating for quantities as particularly wanted for the specialized plan.
Upon having entered any information into a parts listing’s Supplemental-Info window (and exiting back out of that window), you’ll notice there’s now either or both of two single-letter references listed adjacent to that part listing within the green vertical stripe. If there’s a ‘T’ it means there’s quantities given (that’s intended stock quantities) for one or more kinds of specialized Trucks. If there’s on “O” it means there’s Other kinds of additional info.
In regard to the specialized plan function, the idea is you’ll still use the one master list of parts, just as when using the basic system. You simply must include within this master list an entry for any and every kind of part you intend to maintain in stock, even if for many listings a particular item will perhaps be stocked within only one kind of location. For any such item, you’ll indicate through this advanced feature how many you want maintained as minimum. For any standard location use the indicated column in the main list, etc. Via this system, you can explicitly structure up to eight unique stocking plans (one for the office, one as the default truck type, and six more as added/specialized types).
As important as it is to keep track of your stocked-parts inventory, there's just one ultimate reason why: to facilitate the proper and efficient completion of jobs—which is done, obviously, so you can collect money upon completion—money that produces the income that is your raison de etre for being in business. It would be a shame, to say the least, if while carefully regimenting every other aspect of your business, you then failed to positively account for, and track, every item of incoming money.
It is a reality that many small businesses lose shocking sums, without even knowing it, because of undiscovered employee embezzlement or simple misplacing of incoming funds. Obviously, a means is needed to document and track each item of receipt, whether consisting of check, credit card draft, or sum of cash—to assure each reaches deposit to your bank, or at least to a deliberate disbursal.
The primary venue for this purpose is the FundsForm, accessed by pressing Ctrl-F9. Among its many other functions, the FundsForm displays the FundsJournal, a file designed to contain a unique and separate entry for every check, bankcard draft, or sum of cash your business takes in. Of course, for it to have all these entries, there must be a means for it to acquire them.
In this regard, ServiceDesk recognizes two broad contexts in which a typical service company collects funds. First, is where moneys are collected either before or concurrent with job completion, as is always the case with COD jobs, and may happen to some extent even with billed jobs (as when collecting deductibles on a home-warranty type job, for example). In this context, the funds are usually collected by a technician, and it's similarly him who brings them to the office. The second context is where the job was completed with funds still owing, so the job is billed, and payment is received thereafter. Here, payment usually comes by mail, and is received directly by the office. Depending on the context, the processes for making entry of the receipt within ServiceDesk (and assuring that all appropriate entries are made) are considerably different.
The first context is addressed, for the purpose of entering funds received, via the PostVisitReporting process (see page 110). As you may recall, one of the queries you (or your reporting tech) must answer, during this procedure, is whether any funds were collected from the customer, if so what kind, how much, and so on. Based on your answers, ServiceDesk will make an appropriate FundsJournal entry for you, regarding all details of the fund received. This reporting venue is used, for funds received prior to or concurrent with job completion, for several reasons. One is convenience. Since most collections in such context are done in the course of a technician's actual visit to the home, it follows that you'll be making a PostVisitReport, in such cases, regardless. Thus, no separate effort is required to report on the money received; it's simply done in consequence of other procedures you're doing already (for those few items collected separate from a scheduled visit—yet with a job still pending—you can still use the same PostVisitReporting context). This venue also allows ServiceDesk to make a redundant recording of the collection within the job's History, making the narrative there, as it pertains to the particular job, more complete and informative.
In the second context, when payment is received after a job has been completed and recorded to your SalesJournal (in this case it will have been recorded as ‘billed’), you should note that its JobRecord will have already been closed out. Thus, the PostVisitReporting process will no longer be available as a venue for making reports on the job. Thus, a different ServiceDesk venue is needed for recording payments that come in on a job that was formerly completed and billed. Here, we simply use a feature, directly within the Funds form, that’s specifically provided for the purpose (press Ctrl-F9 to access the form, then select its 'rcv Payment on frmrly billed job(s)' option).
Basically, the system will walk you through a procedure in which it collects info about the particular item of money received (most always either a check or credit memo for parts used, in this context), then asks about each invoice the payment should apply toward, in what portion, and so on. In consequence of your answers, it makes entries in several files. First, it makes a single entry to the FundsJournal regarding the particular receipt you've reported. Second, it makes as many entries as are needed (some checks obviously apply to more than just one invoice) to a file called the ApplicationsJournal (press Alt-F9 to access it). Here, ServiceDesk keeps a running record, solely for your benefit, of how you instructed it to apply every portion of every check received for such purpose. Third, it makes an entry to every relevant AccountsReceivable record, showing application of the indicated amount. And finally, if such application satisfies the total due on a receivable (most often the case), it makes a PayCode 3 entry to your SalesJournal, which of course documents the fact of final and complete payment (see page 169 for an explanation of PayCodes). Thus, a lot of entries are made in various files for you, based on your execution of a single, simple procedure.
To recap, there are two general methods by which we report on each item of money received. For items received in connection with jobs that are not yet recorded to the SalesJournal, we use the PostVisitReporting process (each such report results in a narrative description in the job's History, as well as the all-important FundsJournal entry). When receipts come in after a job's been recorded to the SalesJournal (meaning such receipts must be in payment on billed jobs), we use the specific function, provided for this reporting purpose, in the FundsForm (in result, an appropriate and specific entry is again made to the FundsJournal, together with corresponding entries in plethora of other files).
Now that we know how ServiceDesk collects information for its detailed record concerning every item of money received, the next question is how it uses this data to insure you never lose any such item of money without knowing it, nor that you ever mistakenly credit yourself with receiving a fund when in fact you haven't, nor that you ever record as ostensibly paid a sale that in fact wasn't, nor that you ever initiate a job that doesn't end in a properly documented sale with funds collected, etc.
Let us first examine the last-mentioned security need: how do we assure that for every job created, there is an internally-documented resolution showing its proper conclusion and sale amount? This purpose is met, most conveniently, by the WorkInProgress system. Quite simply, once any job is initiated in ServiceDesk, its newly-created JobRecord goes, unavoidably, into the JobsCurrent file—and there it stays, inexorably, until it is finally released by the act of it's recording to the SalesJournal. If some tech absconded with a job you initiated and called it his own, therefore, or if he simply lost it, the result is that the invoice doesn't come back for recording to the SalesJournal. And without this act, the job's record remains in the JobsCurrent file, attracting attention as it gains quickly in age (particularly if you use the WipAlert system, see page 118).
For our next security need, let's consider how ServiceDesk assures that no sale is ever recorded as paid, unless in fact it has been paid. This security need is provided somewhat differently depending on whether the job is being recorded as already paid at time the sale is recorded, or as being first recorded as billed, then later paid.
In the first context, ServiceDesk fulfills its automatic sentry function by making its own little check each time your operator attempts to make a PayCode 1 sales entry (the type indicating a job is already paid). Quite simply, it peruses the FundsJournal to assure adequate receipts can there be found, for the indicated invoice number, and matching the amount indicated for the sale. If it cannot find such amounts, it simply disallows the entry (if too much is found, on the other hand, it provides notice of the fact so corrections can be made).
In the second context, it should be understood that ServiceDesk automatically creates a unique Accounts Receivable record, for each and every billed job, each time a billed sale is recorded (PayCode 2 in the SalesJournal). Significantly, this A/R record can never be credited with any payments (absent use of the owner/manager password, at least) unless it's done, by ServiceDesk, through the specific process that's provided, in the FundsForm, for reporting on billed funds received (see description several paragraphs back). Of course, this process in itself results in appropriate and matching entries being made (reflecting receipts adequate for any A/R credits) to the FundsJournal. And further, a billed item can't be finally recorded to the SalesJournal as paid (a PayCode 3 entry) absent the same process. In consequence, in both this context and the first, it's impossible for any non-password-equipped staff member to credit any sale with payment, in any context, unless in fact there are entries in the Funds Journal reflecting at least ostensive receipts in an adequate amount.
An incidental concern involves the fact that many times billed jobs are already partly paid when the sale is initially recorded (particularly in the case where you've received home-warranty deductibles). As an item's Accounts Receivable record is created via the SalesEnter system (see following section), it must show that partial payment. At the same time, we want to assure that no greater partial payment is shown than has actually been received (or at least as is shown for claimed receipts in the FundsJournal). This is done, quite simply, by ServiceDesk performing the same kind of perusal as when a paid job is initially entered. It checks the FundsJournal and will not allow the entering operator to claim more, for recording as partial payment in the item's Accounts Receivable record, than is reflected there.
By these various means, we assure with great certainty that we'll know about any job which doesn't make it to final and proper recording via the SalesEnter system. And further, for all jobs that are recorded as having been paid before or at time of completion, we assure they cannot be so recorded unless there are corresponding entries, reflecting adequate receipts, in the FundsJournal. And, for all jobs that are recorded as being billed, we assure they cannot be so recorded absent creation of a specific Accounts Receivable record for each (which cannot show even partial payment absent adequate receipts showing in the FundsJournal). And, before any Accounts Receivable record is credited with subsequent payments and then closed (with corresponding final entries being made to the SalesJournal), we again assure that the FundsJournal must show at least ostensive receipts adequate for the specific application.
Thus, and in consequence, the FundsJournal becomes the place where we maintain record of, and verify, the adequate collection of funds in connection with every sale. At least, we should say, it's where we have entries reflecting claimed receipts that are adequate for such purpose. Whether you actually have the ostensive funds in possession or not, of course, is quite another question, involving still another step in the verification/security process.
This additional step is achieved without the slightest additional effort on your part, as a built-in aspect of the last thing you typically must do, regardless, in specific reference to funds received: depositing them.
Specifically, within the Funds form ServiceDesk provides a dedicated process for preparing your bank deposits (whether consisting of cash, check or bankcard). To use this procedure, begin by loading the form (press Ctrl-F9), then select its 'Assemble deposit/items report' option. At this point, you'll be asked what type of money you wish to make a deposit on, then shown a list of all such items that are awaiting deposit, and asked to click on those you actually intend to deposit at present (or you can simply enter a name or check number and have the item selected for you). At conclusion of the sequence, ServiceDesk will print a deposit document for you, listing each of the items and total, with a statement at top indicting your business name, date, and bank account number. Typically, it's a good idea to print two such copies, one for the bank and another to provide a hard copy in your own records.
Security flows from at least two factors here. First, because your operator sees a listing of all pending receipts during the deposit process, it's immediately obvious if any are physically missing (of course, she should immediately bring this to your attention). Second, because no item will check-off in the FundsJournal as having been deposited absent its journey through this process, it follows that its listing will remain in there, under 'undeposited' status, until and unless the process is actually completed for it. Thus, if the process is not completed for any particular item of claimed receipt, it will continue to show there, attracting ever-more attention as it gains in age—refusing to die until someone pays proper attention to the fact that you have, as a claimed item of receipt, an item which never has made it through even ostensive deposit/disbursal.
Of course, absent still additional measures, it would be conceivable that an unscrupulous operator might go through the deposit-preparing process itself (thus checking-off several receipts as having been supposedly deposited), without actually taking the money to the bank (or even that the bank might itself lose the deposit). Thus, still more verification is needed.
This last purpose is achieved by virtue of the fact that, when your operator completes that deposit-preparing process within the FundsForm (with ServiceDesk simultaneously checking-off each included receipt as having been supposedly deposited), at the same time it makes still another FundsJournal entry. Specifically, it makes a 'deposit' entry: a line indicating that on such and such a date so many checks (or other kind of receipt item) were deposited, totaling such and such amount. This new entry then becomes something else that must be checked-off, or else it will attract attention as it gains in age. And significantly, a mere operator does not have the power to check this item off. On the contrary, this process requires use of the owner/manager password.
Specifically, it is the responsibility of the owner (or other completely-trusted person) to periodically run, from within the FundsForm, the procedure labeled 'Confirm deposit/item reports'. Typically, you should complete this ritual on a monthly basis as part of the process when reconciling your monthly bank statement. Quite simply, ServiceDesk will display a list (within any category, whether cash, check or bankcard) of all claimed deposit/item reports that an operator has ostensibly made, and which has not heretofore been confirmed by you. You can simply look at your statement and confirm if, in fact, that item was received by the bank (or received by you, if that's how it was disbursed). If so, indicate the confirmation. The item will then be checked-off (only with use of the necessary password), and of course will not re-appear during subsequent procedures. The beauty is that if any claimed deposit process didn't actually get where it was supposed to go, you won't be checking it off, and thus will see the fault right away during completion of this process.
Thus, we have complete security, assuring there are actual funds for all ostensive collections listed in our FundsJournal, and that all these are properly deposited—or we'll know about. Of course (and by virtue of other measures described), we also are confident that, once initiated, all jobs will eventually be recorded to our SalesJournal—or we'll know about it. And, naturally, we’re also certain there will be entries within our FundsJournal adequate for each sale recorded—or we'll know about it.
It would be difficult, to say the least, for an unscrupulous employee to find a way around these means (providing you keep the owner/manager password secret), or even for losses by carelessness to go unnoticed. That's security very few small businesses possess (at least in the absence of an owner who personally, and with great care, handles every item of money, every deposit, every claimed sale for adequacy of payment, and so on). Indeed, since even a careful owner might lapse into occasional oversights, security would still be less complete, in such a case, than ServiceDesk automatically provides.
The above was a broad overview, and will provide sufficient knowledge for most of the situations you’ll encounter when managing your funds. Even so, there are some abnormal situations you may sometimes need to deal with. If so, you’ll need to know how.
As one complicating factor, for example, you may have a client that routinely pays amounts different than you've billed (G.E.'s home-warranty administration is infamous for this). Sometimes they might pay too little, sometimes too much. You may find you're able to apply excesses on some invoices toward deficiencies on others, and keep a tally that's approximately adequate, at least, for overall needs. It may be, indeed, that it's much easier to simply keep a tally of their overall pluses and minuses, and check-off each item as though paid for the right amount, so long as the net position stays reasonable. ServiceDesk accommodates this need with what it calls an Errors and Discrepancies account. The process is self-explanatory, in the FundsForm, from the context of reporting on payments received on a billed job (an EDA account can be viewed, for any client on which you're created one, from the Applications form, accessed by pressing Alt-F9).
Aside from customers that simply "goof up" on the amount paid, you may have some to whom you routinely grant a discount in return for rapid payment (AHS, for example, offers more rapid payment in exchange for a 2% discount on each invoice's face amount). This complicates the process of reporting on payments received, because you'll be wanting to check-off each applicable invoice as "Paid In Full"—even though, in fact, you've received 2% less than its face amount. The solution: When reporting the check's amount, simply include a plus sign (i.e., '+') after the entered number (as prompted on the form during the procedure). This tells ServiceDesk the payment is a discounted one, and in response it asks you the discount rate. Then, for purposes of crediting each applicable item with payment, it pretends the check was for the full, non-discounted amount. Following this, as you conclude reporting on each item to which the check should apply and approve recording the transaction, ServiceDesk makes an entry in your SalesJournal reflecting the discount you granted the customer. This is a PayCode 5 entry. When you generate a SalesReport later on, the total of such discounts, if any, will be included as part of the report. How you handle this figure within your own financial accounting is up to you (see page 302 for tips on how to input such information to your own separate system). Simply be sure it's factored in.
Another complicating factor arises when you're working on two invoices for the same customer at once, and they pay for both simultaneously with just one check. Or, you might be finishing one job and at the same time open a new invoice for something else, and they pay for both the completion and a deposit on the second invoice with one check. In either case, you've got one check that needs applied in part to one invoice, and in part to another. While there are easy, built-in provisions for dealing with multiple fund applications in the post-completion, billed job context, nothing is inherently built-in to handle such realities when the appropriate fund-entering context is via the PostVisitReporting system. Of course, in this context the need for multiple application of a single fund happens only rarely, so we get by with a mere Band-Aid approach.
Specifically, we create a supplemental pair of FundsJournal entries. The first is labeled "MoveAppFrom" and the second "MoveAppTo." Essentially, if a single receipt applies to two invoices (remember, we're only talking about the context of non-billed, COD jobs here), we'll have one FundsJournal entry that credits it, initially, to just one of the two—then, in addition, this pair of adjusting entries that transfers an appropriate portion of the receipt's application from the first invoice to the second. These "MoveApp" entries will be made automatically in result of queries made at the time the receipt itself is entered through the PostVisitReporting process, but can also be added, should the need become apparent, directly from the FundsJournal. You’ll see an option provided there for the purpose (this is another operation, incidentally, that requires use of the Owner/Manager password).
Another special situation arises when you’ve made refunds to customers. Obviously, you’ll want to document having done this. The Funds form provides an option for the purpose, and it too is self-explanatory.
Still another situation arises when some item of money proves to be uncollectible. Perhaps you attempt to run a charge against someone’s bankcard, for example, and the charge is denied (and you’re unable to get the customer to give you a better number). Or maybe a check bounces irretrievably, or an item of cash is physically lost. In any such case, you need a means to document the sad outcome. As in many other ServiceDesk contexts, you can delete an item in the Funds form simply by right-clicking on it. Of course, if writing-off a bad fund, mere deletion is not adequate. While we don’t want the item to remain in our list demanding deposit, we don’t want it removed, either, without documenting the fact that we’ve incurred such loss. For this reason, when you right-click on an item from in the Funds form, you’ll see three options. One, as in other contexts, is for simple deletion of the item (see following section for explanation of circumstances where you might want this). In the alternative, you may “Write-off the item as Uncollectible,” or to write it off as “Missing.” If you choose either option, the item will be marked as requested—plus the system will make an entry in your SalesJournal indicating the loss. This is a PayCode 6 entry, and the total of such losses is another matter that will be reported, for use in your accounting, whenever you compile a SalesReport.
A final situation involves the occasional need for entry of some fund receipt, into your SalesJournal, absent any of the more automated means previously described. Perhaps, for example, you received a bad check which was replaced either with a new check or some other form of replacement money. This new item needs entered to your FundsJournal (for proper tracking and deposit), yet neither of the normal entry-creation venues (see section I, this division) are appropriate. For this and any other miscellaneous need to manually create a new receipt-of-fund entry, you’ll find facility in the Funds form for such purpose (a command button in lower-right corner labeled ‘Add items’). If you’re adding a new entry in replacement of an old, incidentally, be sure that you also delete the old entry.
For the most part, keeping your FundsJournal neat and tidy will involve nothing more than routine use of the operations described above. However, you should understand that doing this involves something of an ongoing housekeeping task. It’s something you have to pay attention to.
In particular, and in addition to attending to the various processes already described, you’ll probably notice the same thing we have: occasionally spurious entries will appear in your FundsJournal. These are not spurious in the sense that they came out of nowhere. Instead, what typically happens is that someone is making a PostVisitReport. They report on a fund received, then realize they did it wrong, so report again. In consequence, the Journal ends up with two entries for the fund receipt, one accurate and one spurious. When your processing person prepares a deposit, she’ll find an actual fund item that corresponds with one entry, but not with the other. In the context involved, it will be fairly apparent to her that one entry is a spurious duplicate, and she’ll logically not attempt to include that one in her deposit. If she’s clever, however, she’ll add some notation to its text. indicating her conclusion (as in many other contexts, left-click on any item in the list to edit it). In consequence of not being included in the deposit, naturally, the item is not so checked-off. Thus, until something more is done, the item remains in the list as (supposedly) needing to be deposited.
This is why, as the password-equipped owner/manager, you should periodically check the listings in your FundsJournal for such items, and remove any that are verified as being spurious duplicates. To do this is fairly self-explanatory. First select the ‘View/Edit Items’ option, then ‘All’ as the Kind of Fund to be viewed, then ‘Receipts,’ then ‘Undeposited/Unverified’. Look toward the top of the list (spurious items will eventually migrate there as all contemporaneous and older items get moved out of the category by virtue of having been deposited) for items that should have been included in previous deposits but were not. Hopefully, your deposit preparer will have added some notation indicating he belief that the item is a duplicate or otherwise in error. You’ll want to verify the conclusion before deleting the entry. To do so, you’ll want to see what other entries have been made in connection with the same job. Just note the invoice number the payment is connected to (part of the entry information), then do a “search” in the form to find all entries pertaining to that number. Maybe, for example, you’ll see there’s two entries of $40 each. If you then hit SHIFT-F3 and search on the same InvoiceNumber in your SalesJournal, you may confirm that the total sale was only $40. Thus you’ll know that the second of two entries must have been a goof by the entering person, and you can go back to its listing, and right-click on it to invoke a deletion.
On the other hand, of course, you might find there are older items in the listing, that should have been deposited already, that are legitimate entries. This, obviously, will incite a prompt discussion with your deposit preparer. What’s the deal, you’ll ask? Why is that item still lingering there, without showing deposit? Preferably, if there was cause for any legitimate item to linger (for us, it’s sometimes been a missing check and the preparer has been trying to get a replacement from the customer, or maybe a bankcard number that wouldn’t clear, and she’s still hoping for eventual success), your deposit preparer will have informed you already, so there’ll be no surprises. However, you can see that it’s important for you to go through this inspection process, periodically, just to make sure.
At any rate, you may note that several ServiceDesk contexts have systems for policing you, attempting to cajole (and sometimes coerce) you into keeping on top of various tasks. The Funds form (and its associated FundsControl system) is no exception, except here it’s as a mere incidental byproduct of how the system is setup. As in many other systems that keep track of records over time, there is also the need here to separate the newer, actively working area of records from that which is merely historical. In this case, however, rather than having separate files (i.e., a current file for active records and archive file for historical ones), we thought it more convenient to use a single file and moveable partition. Basically, the system tries to keep track of how far back, in the list, is the oldest unresolved (i.e., not checked-off, written-off, deleted or otherwise disposed of) item. All entries more recent than that are considered current area, and all older considered, well, old area. It helps the system perform many tasks more quickly than otherwise when it knows that any current items must be on one side of the dividing line.
The reason this system helps to police you is because, if you allow older and older items to accumulate without resolution, the system will not be able to move the Current-Area Partition forward as it would like to. Every time you attempt to load the Funds form, in consequence, it will inform you the CurrentArea has grown to large. It will ask for permission to attempt to move the Partition forward. If you’ve left old items back there, however, it will be unable to, and will so inform you. Thus, next time you go to load the form, it will inform you again. This gets to be very annoying, and should prompt you to start cleaning out those old, unresolved items (perhaps it’s simply deposits you haven’t confirmed yet; regardless, it’s easy to find out by designating the appropriate display).
We are, quite frankly, proud of how our FundsControl system ties together so many other elements in ServiceDesk, providing such positive security, along with convenience for your funds control. We hope you enjoy it too.
