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:

1. ‍A tech in SD-Mobile makes the request, via his Mobile interface;
2. A tech makes the request via a PostVisitReport, as entered (by him) directly within ServiceDesk;
3. ‍An office person creates the request, via a PostVisitReport, as performed on behalf of a tech;
4. ‍An office person creates the request via a POS operation; or
5. An office person creates the request via a button as provided within the JobsCurrent form, and as connected with the job then displayed.         

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-F8is 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 the next 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.

1. ‘All Items In File’:   Obviously, this category selects every item regardless of its content
2. ‘Items Needing Inquiry/Order’:  To show in this category, an item’s ‘Instrctn’ status must be set to other than “Declined’ and its ‘Request’ status to other than “Dormant,” plus its ‘Confirmed’ box must be empty.  In addition, it must not fit the criteria for Categories 3 or 4, as below described.
3. ‘Waiting for Info From Supplier’: To show in this category, an item must fit the criteria as described in the first sentence under Category 2.  Additionally, its ‘InquiryDate’ box must be filled-in with a date, while ‘Availability’ box remains empty.
4. ‘Awaiting Approval From Customer’:   To show in this category, an item must fit the criteria as described in the first sentence under Category 2.  Additionally, its ‘Instruction’ box must indicate “Tentative,” and the ‘InqjuiryDate’, ‘Availability’ and ‘$ Sell for’ boxes must be filled-in.
5. ‘On Order, Awaiting Arrival’:  To show in this category, an item’s ‘Request’ status must be set to other than “Dormant,” and its ‘Confirmed’ box must be filled-in, while its ‘Received’ box remains empty.
6. ‘Past-Due for Arrival’:  To show in this category, an item’s ‘Request’ status must be set to other than “Dormant,” and its ‘Confirmed’ box must be filled-in while its ‘Received’ box remains empty (same as above).  In addition, the “Expected” box must be filled in, and the present date must be beyond the expected date.
7. ‘In Need of Pricing by Manager’:  To show in this category, an item’s ‘Request’ status must be set to other than “Dormant,” and either: (a) its ‘Received’ must be filled-in while it’s ‘$ Sell for’ box remains empty; or (b) its ‘Instruction’ box must indicate “Tentative,” while its ‘InquiryDate’, ‘Availability’ and ‘Wholesale’ boxes are filled-in, with its ‘Confirmed’ and ‘Wholesale’ boxes remaining empty.
8. ‘Part Arrived, Process Complete’:  To show in this category, an item’s ‘Instruction’ status must equal “Declined,” or its ‘Request’ status must equal “Dormant,” or its ‘Received’ and ‘Sell-For’ boxes must both be filled-in.

At least it does so for the next 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 selectedThere’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:

Create an appropriate CORE-RETURN daughter band for any/every part that involves a core charge;Periodically review the above-shown categories, to assure that items within each are being expeditiously processed from one stage to the next; andAs items move from one stage to another, document such movements by appropriately filling in applicable boxes.            

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.