IE20070146A1 - A field service work flow management and communications system - Google Patents

Abstract

A field service work flow management and communications system comprises distributed portable communication and data processing field devices (2) for field personnel, a local work flow processing engine executed by each field device; a host communications server (4), a host processor (5), a host work flow processing engine executed by the host processor (5), field service databases (9) for data related to field service work. Each field device local work flow engine captures data inputs in response to structured prompts generated according to work flow, and using said data to generate discrete event records. The device (2) automatically generates an email message (52) for each event record, in which the data is written in human readable format to a section (54) of an email and the same data is encoded and the coded data is written to a separate section (55) of the main body of the email. The host processor (5) automatically parses an email encoded section (55), and according to job status determined from said parsing. It also dynamically generates structured query language statements from the parsing. Each field device (2) comprises a writing interface, and the local work flow engine associated the image with an event record, and incorporates the image in an email.

Description

“A Field Service Work Flow Management and Communications System” Introduction The invention relates to automated aspects of field service management and communication.

Field service management is complex where there is a wide variety of jobs to be performed by the field personnel, of parts which are required, and/or of tasks to be performed. Another aspect which may add to complexity is the extent of geographical area to be covered by a team of field service personnel. For these reasons the level of automation achieved heretofore has been quite limited.

US2004/0202307 describes a system for tracking technician calls to a call centre.

Such a system appears to be limited in scope and flexibility, requiring voice calls to be made and data to be inputted by call centre personnel.

The invention is directed towards providing a technical system for improved automation in field service management and communication.

Statements of Invention According to the invention, there is provided a field service work flow management and communications system comprising: a plurality of distributed portable communication and data processing field devices for field personnel, a host communications server, Iflrra gogf b/oq , 1ΞΖΞΗΖ22-. ac+faa host processor, IE® 70 1 4® -2a host work flow processing engine executed by the host processor, field service databases for data related to field service work, wherein each field device local work flow engine comprises means for: capturing data inputs in response to structured prompts generated according to work flow , and using said data to generate discrete event records, automatically generating an email message for each event record, in which the data is written in human readable format to a section of the main body of an email and the same data is encoded and the coded data is written to a separate section of the main body of the email, wherein the communications server comprises means for receiving and logging emails from the field devices, wherein the host processor comprises means for: automatically parsing an email encoded section, and according to the parsing, automatically updating a host work flow database according to job status determined from said parsing, and dynamically generating structured query language statements for updating related field service databases according to the data gleaned from the parsing. ...

·* ’ ·** · In one embodiment, each field device comprises a writing interface and means for automatically generating an image for a physical signature written on the pen interface, and the local work flow engine is adapted to associate the image with an event record, and to incorporate the image in an email .3.

In another embodiment, each field device comprises means for saving the image to a local database on the field device, and for simultaneously write-disabling the event record.

In a further embodiment, each field device comprises means for saving the image in a record having an address incorporating an address of the corresponding event record address.

In one embodiment, each field device comprises means for automatically writing a time stamp to each event record.

In another embodiment, each field device and the host processor comprise means for maintaining synchronization by repeatedly polling a remote time server via the Internet, and the host processor comprises means for automatically checking when parsing a received message that the current time is not earlier than said time stamp.

In a further embodiment, the host processor comprises means for triggering an alert notification if current time is earlier than said time stamp.

In one embodiment, each field device comprises means for write-protecting its time clock values.

In another embodiment, each field device comprises means for maintaining a dynamic 25 linked library of programs and the writing interface of each device comprises means for using a dynamic linked library mechanism to call a program for processing the image.

In a further embodiment, the host processor comprises means for automatically 30 selecting rules from a rule base according to a message category, each message category being associated with a job state, and said selected rules are executed to automatically update the host work flow database.

IE 0 7 0 ί 4 Β -4In one embodiment, the host communications server comprises means for automatically logging all received emails before the processor accesses them, and for also writing the emails to a cache which is accessible to the host processor for parsing.

In another embodiment, the host processor comprises means for logging the category of all emails to an audit trail database.

In a further embodiment, the host communication server comprises means for automatically logging all signature images to an audit trail database before the host processor accesses them.

In one embodiment, the host processor comprises means for parsing a message by initially tokenizing message content of delimited sections, and subsequently processing the tokens to generate the structured query language statements.

In another embodiment, a message header is tokenized separately from tokenizing of a message body.

In a further embodiment, the tokenizing step is performed after recognition of a particular string in the message.

In one embodiment, the host processor comprises means for allocating each token to one of a set of strings for the message, each string being associated with a work flow parameter.

In another embodiment, the host processor comprises means for automatically determining a type of structured query language statement according to the category of message. ~ . I · · · ' ' ' Detailed Description of the Invention i j ί IE 0 7 0 ί 4 $ -5The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:Fig. 1 is a diagram illustrating a communication and management system of the invention; Fig. 2 is a flow diagram illustrating operation of the system; and Fig. 3 is a flow diagram for generation of a message, showing message coded and unencoded sections.

Referring to Fig. 1 a field service work flow management and communications system 1 of the invention comprises hand held devices 2 used in one example by technicians who perform maintenance work in response to service calls. The hardware configuration of each device 2 is a Pocket PC2000/2002™ handheld GSM mobile device.

The devices 2 communicate via a GSM mobile network 3 with a host system comprising a server 4 which receives and transmits data and implements a cache for incoming messages. A data analysis host processor 5 interfaces with the server 4, with a teleservices network 6, and with a stored rule base 7. The processor 5 performs database updates via a database server 8 linked with databases 9.

The devices 2 are used by technicians servicing cooling equipment in vehicles, warehouses, factories, and retail premises. However they could be used by service personnel of any other type, the invention concerning the underlying communication and work flow data processing infrastructure rather than the business nature of the data being handled. . ΐ The system 1 operates in a method 15, the steps of which are described below.

Create Event Record 16 IE v i o 1 4 e -6Each hand-held device 2 executes a software work flow engine with a relational database. The work flow engine is programmed with data defining jobs and possible job states. It captures user inputs in a structured format of the allowed jobs and job states and automatically captures data to a discrete event record for each job state. The work flow database stores both alphanumeric data and also images for signatures made with the writing interface of the device 2.

Record Real Time 17 Each device 2 automatically writes a real-time time stamp to each event record when it is created. Time synchronisation between the device 2 and the host system 4, 5 is ensured by individual telnet sessions to an Internet NTP Time Server which updates the device 2 and a host system inbuilt clock which is triggered at various stages of the handheld processes and the host system process activity. A rule base on the host processor 5 also ensures that data received from a device 2 does not have a time stamp later than that of the host - if such an event were to occur it triggers an alert to an operator that the device 2 needs to be checked. Manual updating of the time settings of the device 2 is locked down within the local device 2 program so that one can not change the time manually.

Edit Data, 18 Data is entered and saved into the event record according to job details.

The device 2 local work flow engine maintains a database of qualifying parts which may be installed, removed, or consumed during a job. The technician can retrieve a part identifier from the local database using a touch-screen menu. The part identifier is written to the event record where parts are involved. The part data adds to the job state data already written to the record' wheiiit was created.

Generate Email, 19 An email message incorporating event record data is generated. There are eight categories of messages a) - h) outlined below in the section describing message It'A /0 148 -7parsing. The technical aspects of message generation are also described below. An advantageous aspect of the invention is that discrete event records result in automatic generation of email messages which are uploaded to the host. This ensures near real time synchronisation of the field devices 2 and of the host processor 5. Also, data integrity is ensured because of the work flow structured manner in which the user is allowed input data.

Job Progress Decision, 20 According to progress made in the field job, steps 17-19 may be repeated in multiple interactions. For example, a work flow may be complete by simply transmitting a “Job Rejected” message, or it may go through several stages outlined below.

Signature Image Recording, 22 The writing interface of the device 2 is used to capture a supervisor signature for verification of a job. On completion of the job by an engineer, the device 2 prompts for a signature that is linked to the service call by the service call number. The signature is stored on the local device 2 on a non-volatile memory storage card which is date and time stamped.

When the engineer indicates on the keypad that the job is complete a DLL is called to activate a signature file. This generates a display for writing of the signature and at the same time disables further write access to the event record. The signature image is saved to a separate file, but with the same record address as the corresponding event record, and an added extension, .SIG.

Message Generation and Transmission, 26 The completed job details are transmitted via email to the host 4, 5. In generation of the email in step 26, there is image compression as the signature file is UU encoded into the body of the mail message before transmission, allowing for transmission via all intervening mail systems which handle the message. The UU encoding of the data ||0 7C 1 ο -8and the signature bitmap provides a transparent format which is not affected by intervening servers en route to the server 4.

Referring to Fig. 3, in the device 2 a UU encoding function 51 generates code from the data and image. This is written to a coded section 55 of a message 52. The message 52 also comprises a wrapper 53. Further, the original human-readable data and bitmap are separately written to a section 54 of the email 52.

Thus, all of the data and the image are represented twice in the body of the email message itself, but there is no need for an attachment. This greatly assists with reliability of transmission to the server 4, and also reduces required bandwidth.

Message Retrieval 28, 29 The messages are received by the host communication server 4 and saved to a cache. The devices 2 poll the server every 15 minutes to send (server port 110) and receive (server port 80) emails. Emails from the devices 2 are received via SMTP on port 110 by the communications server 4 every 15 minutes. The server 4 processes the messages using a rule base. Each message is automatically saved into a cache in a database 9. The host processor 5 polls the cache at a frequency of 60 seconds and writes messages to its memory.

All original messages received by the server 4 are also stored in their original format in database storage space allocated for traceability and re-processing of the message should it be required. Logging of all messages allows full traceability of when the information was received. Also, all signature images are stored indefinitely in their original .SIG file format, thus removing possibility of tampering.

Message Parsing and SOL Generation. 30-34 A very advantageous aspect of message parsing is that the processor 5 extracts (step 30) data for downstream storage and work flow processing, but also dynamically chooses (step 31) rules from the rule base 7 and executes (step 32) the rules to IE0 70 1 O -9generate SQL statements (step 33). Thus, the database updates can be performed in a manner which is applicable to the particular data and message.

All messages are first checked for a valid sender email address, and valid subject content by the mail system and are then decoded by the host processor 5 into categories of message by the contents of the subject header of the message. This determines (step 31) the rules to be applied.

Incoming messages can be one of the following categories. a) Job received b) Job Accepted c) Job Rejected d) Engineer In Transit e) Engineer On Site f) Engineer Left Site Temporarily. g) Job Complete h) Standby Job Used The categories are indicated in the message. This is one example, but of course the nature and number of categories depends on the business aspects of the field service management, not the subject of the invention. From the perspective of the invention, it is important to note that there is an email providing near real time notification of an event, and these messages are automatically processed as described.

Messages of type a), b), c), d), e), and f) are status messages from which the processor 5 automatically creates SQL Statements to update the current status of the job, whereas messages of type g) contain a completed job with signature image and thus trigger other message rules to update the status of the job and decode and extract the signature. ..... ..... — i The processor 5 then creates SQL statements to update separate SQL tables for worksheets, labour and parts, and then updates the relevant Service Call Job Record and Service Departments Call Status records for generation of supervisor display IE?7014« -10screens. Messages of type h) create a New Service Call Job that the Engineer has instigated, and not having been sent from the Service Department (for example, weekend standby calls for which the engineer receives customer calls directly). This updates the service department’s Call Status records to show that the engineers had used Standby Calls, but also the host system generates a new Standby Service Call Number and sends it to the device 2 for future use - thus keeping a float of Blank Service Call Numbers assigned to that engineers’ device 2.

In response to a message of type c) the processor 5 generates a notification to a supervisor indicating that the particular service call cannot be attended to by that engineer and the reason which the engineer gave, and thus allow the supervisor to reassign the service call to another engineer.

Thus, the email allows the processor 5 to automatically update the host work flow engine database, and to automatically generate SQL statements for updating various database tables. Thus, the categories a) to e) trigger automatic work flow engine updates and SQL statement generation in a single pass.

However category g) involves detailed parsing of the UU encoded section 55 of the received message. This section is in delimited text format. The work flow engine on the hand-held device 2 generates prompts for user selection of options. These options mirror the work flow structure of the job. User selection of an option causes the device 2 to automatically insert delimiters and codes into the event record. Each activity is allocated a line, and there is a “pipe sign” symbol “|” delimiter for each data value. This structure is also generated in response to user selection of a part - the part identifier and quantity being automatically inserted into the event record with the necessary delimiters and work flow codes.

Category h) for Standby Calls Used also results in processing the message differently as it contains the customer name/details and nature of service call, which are assigned to a Fixed Miscellaneous Customer Account. The Standby Calls Used are highly visible to the supervisor so that they can attach the Service Call to the relevant Customer Account for billing purposes. -11This structure which is imposed in the hand held device 2 allows very efficient parsing by the data analysis processor 5. The processor 5 tokenises the email data after decoding the UU encoded section 55 (cfr. Fig. 3). The email message is read by the parser, and translated into its original raw format as created by the device 2. The email data is tokenized into meaningful data by splitting the message using the pipe delimiter symbol |. There are two sections to the tokenizing, one for the header of the message and one for the body of the message. In the header of the message the tokens parsed relate to data such as the Service Call No, Service Call Status, or Date of Service Call. If the body of the message contains particular text such as parts: or WS: or “labour: the data following that text is tokenized specifically for that type of data up until it reaches a Carriage Return Linefeed (CRLF) sequence of characters.

The tokens are then assigned to a string of data for a record such as a parts record, a worksheet record, or a labour record. On reaching a CRLF sequence it then loops back through the process reading the next line of email data. Each of these tokens is then used in the step 33 to build the required SQL Statements.

The parsing step 30 extracts the information sufficient to update the host work flow database and to generate the appropriate SQL statements. Typically, ten to twenty SQL statements are generated. Advantageous aspects are as follows: - The ability to translate the UU encoded section 15 indicates an initial validation of the received message.

- The UU encoded section is much less likely to be corrupted by intervening servers than the human readable section 54.

- The email can be validated by an operator due to existence of the section 53. The processor 5 generates a visual display of both the decoded data and of the signature image.

The following code section of the procedure rules parse the email message in step 30 and determine the type of email message received and thus determine the WFP updates to make and SQL statements to generate. Εβο 7 0 -12Identify Sender and Check Content Sub parseline(parsethis As String) Dim s_accountno As String Dim s_cdname As String Dim msgtype As String Dim y saccountno = scalllogno = 0 s_cname = msgtype = If MidS(parsethis, 1,12) = Return-path: Then Me.tsender.Text = Mid$(parsethis, 15, Len(parsethis) - 15) Exit Sub Elself Mid$(parsethis, 1, 5) = From: Then Me.t_sender.Text - Left$(Mid$(parsethis, InStr(l, parsethis, <, vbTextCompare) + 1), Len(Mid$(parsethis, InStr(l, parsethis, <, vbTextCompare) + 1))-1) Exit Sub Identify Customer Elself MidS(parsethis, 2,14) = CUSTOMER CODE: Then s accountno = Mid$(parsethis, InStr(l, parsethis, «<, vbTextCompare) + 3, (Len(parsethis)-(InStr(l, parsethis,«<,vbTextCompare) + 3)) - (Len(parsethis) InStr(l, parsethis, >», vbTextCompare))) MsgBox s accountno Identify Category , ---•—η '7 ,. „· -γνΎ'' ' Elself Mid$(parsethis, 1, 8) = Subject:· Then y = Split(parsethis, |) Me.t_subject.Text = Mid$(parsethis, 10, Len(parsethis) - 9) If UBound(y) = 2 Then -13Me.t_eng.Text = y(2) End If If Mid$(parsethis, 10,13) = ENG ACCEPTED: Then s_calllogno = Val(Left(Mid$(parsethis, 23), InStr(parsethis, |))) Me.t_calllogno.Text = scalllogno msgtype = Y Elself Mid$(parsethis, 10, 13) = ENG REJECTED: Then s calllogno = Val(Left(Mid$(parsethis, 23), InStr(parsethis, |))) Me.t_calllogno.Text = scalllogno msgtype = R The following code section of the procedure rules parse the email message and generate dynamic SQL Statements depending on the contents of the decoded email message.

Sub readmessage(strQuestionFile) Dim decodedmsg As String decodedmsg = uudecoder(strQuestionFile) Call functions with Declaration of Variables (Dimensions) Dim sqlarray Dim strLine As String Dim ReadQuestionFilelD As Integer Dim msgstart As Integer Dim norecords As Long Dim msgend As Boolean Dim endofWS As Boolean Dim wsmsg As String Dim endofPARTS As Boolean .

Dim partsmsg As String..

Dim endofLABOUR As Boolean Dim labourmsg As String Dim endofSTANDBY As Boolean nW*»* -14Dim standbymsg As String Set Initialisation Variables msgend = False endofWS = True endofPARTS = False endofLABOUR = False endofSTANDBY = False ReadQuestionFilelD = 1 msgstart = 0 norecords = 0 Error Calculations On Error GoTo Readerr If Len(decodedmsg) > 0 Then Read UU Encoded Information Open strQuestionFile For Append As #ReadQuestionFileID Print #ReadQuestionFileID, Print #ReadQuestionFileID, Print #ReadQuestionFileID, decodedmsg Close #ReadQuestionFileID End If Me.StatusBarl.Panels(l).Text = Parsing Message: & strQuestionFile Open strQuestionFile For Input As #ReadQuestionFileID Read Header Do While Not EOF(ReadQuestionFilelD) norecords = norecords + 1 --------- . .1 ' £ ί ·.

' Start Parsing the Start of the Message Line Input #ReadQuestionFileID, strLine If Mid$(strLine, 1, 8) = Reply-Το Or Mid$(strLine, 1, 21) = X-MDaemonDeliver-To: Then ΙΕΟ 7 0 η 9 -15' Read a blank line Line Input #ReadQuestionFileID, strLine msgstart = 1 ' Elself Mid$(strLine, 1, 10) = -----Origi Then ' Me.currmsg.Addltem END OF MESSAGE FILE ' msgend = True ' Now to Parse the Original Message ' Elself Mid$(strLine, 1, 33) = Content-Transfer-Encoding: base64 Then ' Me.currmsg.Addltem END OF MESSAGE FILE ' msgend - True ' Exit Do ' Now to Parse the Original Message Else Calling Parser ' MsgBox msgstart If msgstart = 0 Then Call parseline(strLine) Me.currmsg.Addltem (strLine) Else Call parseline(strLine) If Mid$(strLine, 1, 3) = WS: Then endofWS = False wsmsg = strLine ' Keep reading until last 2 chars = chr(13) & chr(10) While Not endofWS Line Input #ReadQuestionFileID, strLine If Mid$ (strLine, 1, 3) = WS: Then wsmsg = wsmsg & Chr( 13) & Chr( 10) & strLine Elself Mid$(strLine, 1, 3) = (Chr(61) & Chr(48) & Chr(48)) Or Call Functions to Generate SOL Statements (e.g. “createwsfile”) Mid$(strLine, 1, 6) = ------ Then »ΕΛ 7 0 14 ί -16endofWS = True ' Now Parse wsmsg Call createwsfile(Me.t_calllogno.Text, wsmsg) Else wsmsg = wsmsg & strLine End If Wend ' MsgBox wsmsg Elself Mid$(strLine, 1,6) = PARTS: Then endofPARTS = False partsmsg = strLine While Not endofPARTS Line Input #ReadQuestionFileID, strLine If Mid$(strLine, 1, 6) = PARTS: Then partsmsg = partsmsg & Chr(13) & Chr(10) & strLine Elself Mid$(strLine, 1, 9) = SUPPLIER: Or Mid$(strLine, 1, 9) = QUANTITY: Then ' ignore it Elself Mid$(strLine, 1, 6) = ------ Then endofPARTS = True ' Now Parse wsmsg Call createpartsfile(Me.t_calllogno.Text, partsmsg) Else partsmsg = partsmsg & strLine Endif Wend Parse Checking Elself Mid$(strLine, 1, 7) = LABOUR: Then endofLABOUR = False labourmsg = strLine ΙΕΟ 7 01 Ο -17While Not endofLABOUR Line Input #ReadQuestionFileID, strLine If Mid$(strLine, 1, 7) = LABOUR: Then labourmsg = labourmsg & Chr( 13) & Chr(10) & strLine Elself Mid$(strLine, 1, 6) - ------ Then endofLABOUR = True ' Now Parse wsmsg Call createlabourfile(Me.t_calllogno.Text, labourmsg) Else labourmsg = labourmsg & strLine End If Wend SQL Statements Note Elself Mid$(strLine, 1,10) = STANDBYAT: Then endofSTANDBY = False standbymsg = strLine While Not endofSTANDBY Line Input #ReadQuestionFileID, strLine If Mid$(strLine, 1, 9) = CUSTNAME: Then standbymsg = standbymsg & Chr(13) & Chr(10) & | & strLine Elself Mid$(strLine, 1, 8) = PROBLEM: Then standbymsg = standbymsg & Chr(13) & Chr(10) & | & strLine Elself Mid$(strLine, 1, 6) = ------ Then endofSTANDBY = True ' Now Parse wsmsg ' Call createlabourfile(Me.t_calllogno.Text, labourmsg) sqlarray = Split(Replaee(standbymsg, ), |) If LDBNAME = cs3cool Then ssql = update dbo.calllog set & _ calldate = & Format(Replace(Mid$(sqlarray(0), 11), Chr(13) & Chr(10),), mm/dd/yy) & ', & _ ΙΕΟ 70 ί Ο -18call_time = ' & Format(Replace(Mid$(sqlarray(0), 11), Chr(13) & Chr(10), ), hh:mm:ss) & _ engineer = ' & Trim(Me.teng.Text) & _ received_by = 'STANDBY', & _ commentsl = ' & Replace(sqlarray(l), Chr(13) & Chr(10), ) & ' + Char(13) + Char(10) + ' & sqlarray(2) & ', & _ calltype = 'CHG' & _ where call_log = & Me.t_calllogno.Text & Else ssql = update dbo._call_log set & _ calldate = ' & Format(Replace(Mid$(sqlarray(0), 11), Chr(13) & Chr(10), ), nun/dd/yy) & ', & _ log time = ' & Format(Replace(Mid$(sqlarray(0), 11), Chr(l 3) & Chr(10), ), hh:mm:ss) & ', & _ engineer = ' & Trim(Me.teng.Text) & & _ receivedby = 'STANDBY', & _ commentsl = ' & Replace(sqlarray(l), Chr(13) & Chr(10), ) & ' + Char(13) + Char(10) + ' & sqlarray(2) & ' , & _ call type = 'CHG' & _ where call_log_no = & Me.t_calllogno.Text & End If Me.sqllist.Addltem ssql ssql = Else standbymsg = standbymsg & strLine End If The SQL Statements are generated by creating a string which is a recogniseable Structured Query Language (SQL) statement that will be processed against the underlying databases. The category of message determines the type of SQL statements to be generated. The SQL statements are created by appending tokenized data to string statements representing the data fields to be updated by the SQL ΙΕΟ 7 9 us -19statement. On the completed creation of a valid SQL statement it is then cached until all of the incoming messages in the queue have been parsed.

A routine then runs after all messages have been parsed which executes the individual SQL statements updating the relevant databases and then creating a log of the SQL statement processed, for example the string statements: below are a sample: ssql = Insert into dbo.xdaparts (pcalllogno, pworksheetno, ppid, ppartcode, pprice, pqty, pdesc, psupplier, potherinfo) values ( & _ eno sqlarray(O) & _ sqlarray(l) &&_ & sqlarray(2) & _ IIf(Len(sqlarray(3)) = 0, 0, sqlarray(3)) & _ IIf(Len(sqlarray(4)) = 0, 0, sqlarray(4)) & _ & sqlarray(5) & _ & sqlarray(6) & _ & sqlarray(7) & _ The SQL statement that would be generated for some sample tokens using the above would appear as follows: Insert into dbo. xdaparts (pcalllogno, pworksheetno, ppid, ppartcode, pprice, pqty, pdesc, psupplier, potherinfo) values (62431,72312,1,'BULB1',23.22,3, 2Ft Flourescent Bulb,EWB LIGHTING,RED|240V); where the tokens for Call Number was 62431 Worksheet No 72312 Part Item ID 1 PartCode BULB1 Price 23.22 ^“•Quarrtity^·-^·-- . 3. · .. 2Ft Flourescent Bulb EWB LIGHTING Colour was Red, and Rated for 240Volt ΙΕΟ 70 -20Description Supplier Other Info Database Updating 34 The SQL statements generated in step 33 are used to perform database writes. All SQL statements create records based on the Service Call Number.

All message categories received will result in creation of a log record of when, by whom, and to which call the message was related to. Messages of category a), b), d), e), and f) are used only to update the Current Service Call Status for the supervisor to view, with full history of when that action had been applied by the engineer. Messages of category c) trigger SQL Statements to notify the supervisor for a Rejected Call and Reason. Messages of category g) trigger SQL Statements to update the call status as complete, and update service call information with all data entered by the Engineer.

All SQL Statements generated are logged, thus allowing full traceability of how the work flow was recorded in the databases. This logging is linked to the work flow record for the job.

The following code section of the procedures are dynamic SQL Generators that create various insert/delete statements for the Worksheet, Parts and Labour Details that are contained on completed service calls (decoded parsed emails) received.

Private Sub readparts(cno As Long) Dim fname As String Dim partstr As String Dim partstr 1 As String Dim sqlarray Me.t_parts.Clear ssql = ' fname = attachpathname & eno & .pts IEO 7 0 1 4 -21fname = XDASAFE & eno & .pts Me.StatusBarl.Panels(l).Text= Reading Parts: & fname ' Me.sqllist.Addltem delete from dbo.xdaparts where pcalllogno = & eno & On Error GoTo partserr Open fname For Input As #10 ' Open file.

If Not EOF(IO) Then ' Loop until end of file. partstr = partstrl = Line Input #10, partstr' First Line is CALLNO If Not EOF(IO) And Mid$(partstr, 1, 6) = CALLNO Then Line Input #10, partstr' First Line is CALLNO End If Do While Not EOF(IO) Me.t_parts.AddItem partstr If Len(Trim(partstr)) = 0 Then Exit Do End If If Mid$(partstr, 1, 6) = PARTS: Then partstrl = partstr = Mid$(partstr, 7) If Not EOF(IO) Then Line Input #10, partstrl Do While Mid$(partstrl, 1, 6) <> PARTS: Me.t_parts.AddItem partstrl partstr = partstr & partstrl Line Input #10, partstrl If Len(Trim(partstrl)) = 0 Then Exit Do End If Loop sqlarray = Split(partstr, |) ,|0 7 $ ΐ -22partstr = partstrl End If ssql = Insert into dbo.xdaparts (pcalllogno, pworksheetno, ppid, ppartcode, pprice, pqty, pdesc, psupplier, potherinfo) values ( & _ eno & , & _ sqlarray(0) & _ sqlarray(l) & sqlarray(2) & _ IIf(Len(sqlarray(3)) = 0, 0, sqlarray(3)) & _ IIf(Len(sqlarray(4)) = 0, 0, sqlarray(4)) .....& sqlarray(5) & _ ’ & sqlarray(6) & _ & sqlarray(7) & _ Me.sqllist.AddItem delete from dbo. xdaparts where pcalllogno = & eno & _ and pworksheetno = ’’ & sqlarray(O) & _ and ppid = & sqlarray(l) & _ Η, It Me.sqllist.AddItem ssql End If Loop End If Close #10 Me.t_parts.Refresh Exit Sub partserr: If Err.Number = 53 Then Exit Sub End If ΙΕυ 7 0 ue -23GOTanERROR = True Me.elog.Addltem Format(Now(), dd/mm/yy) & Format(Now(), hh:mm:ss) & & msgfilename & & READPARTS: & Err.Number & & Err. Description Me.elog.Refresh Resume Next End Sub Responses 37-39 Only incoming messages of type h) for standby calls trigger generation of an outgoing message to the handheld device 2, assigning this new Standby Call reserved to that engineer’s handheld device.

By monitoring times for responses in step 39 the WFP can undertake further actions.

It will be appreciated that the invention achieves effective, reliable, and comprehensive integrated field service management and communication in real time. The field personnel have the flexibility of using portable devices which intelligently capture updates and transmit updates to the host in near real time. Because email is used, the devices do not need to execute proprietary messaging or data upload programs. Also, running costs are kept low as the system keeps data transfer to a minimum and uses data connectivity to send and receive data only. Typically the amount of data traffic is about 10K. (10000 bytes) per service call including the customer signature. Moreover, the system is not reliant on a constant GPRS data connection to a mobile network, thus allowing engineers to process data while out of network coverage or when the mobile network is temporarily unavailable.

The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims (1)

Claims

1. A field service work flow management and communications system comprising: a plurality of distributed portable communication and data processing field devices (2) for field personnel, a local work flow processing engine executed by each field device; a host communications server (4), a host processor (5), a host work flow processing engine executed by the host processor (5), field service databases (9) for data related to field service work, wherein each field device local work flow engine comprises means for: capturing data inputs in response to structured prompts generated according to work flow , and using said data to generate discrete event records, automatically generating an email message (52) for each event record, in which the data is written in human readable format to a section (54) of the main body of an email and the same data is encoded and the coded data is written to a separate section (55) of the main body of the email, wherein the communications server (4) comprises means for receiving and logging emails from the field devices (2), ΙΕΟ 70 1 4Ό -25wherein the host processor (5) comprises means for: automatically parsing an email encoded section (55), and according to the parsing, automatically updating a host work flow database (9) according to job status determined from said parsing, and dynamically generating structured query language statements for updating related field service databases (9) .according to the data gleaned from the parsing. A system as claimed in claim 1, wherein each field device (2) comprises a writing interface and means for automatically generating an image for a physical signature written on the pen interface, and the local work flow engine is adapted to associate the image with an event record, and to incorporate the image in an email; wherein each field device (2) comprises means for saving (22) the image to a local database on the field device, and for simultaneously write-disabling the event record; wherein each field device comprises means for saving the image in a record having an address incorporating an address of the corresponding event record address; wherein each field device (2) comprises means for automatically writing a time stamp to each event record; and wherein each field device (2) and the host processor (5) comprise means for maintaining synchronization by repeatedly polling a remote time server via the Internet, and the host processor (5) comprises means for automatically checking when parsing a received message that the current time is not earlier than said time stamp. A system as claimed in claim 2, wherein the host processor (5) comprises means for triggering an alert notification if current time is earlier than said time stamp; and wherein each field device (2) comprises means for writeprotecting its time clock values; and wherein each field device (2) comprises means for maintaining a dynamic linked library of programs and the writing interface of each device comprises means for using a dynamic linked library mechanism to call a program for processing the image; and wherein the host IEO 7 0 1ο -26processor comprises means for automatically selecting rules from a rule base according to a message category, each message category being associated with a job state, and said selected rules are executed to automatically update the host work flow database; and wherein the host communications server (4) comprises means for automatically logging all received emails before the processor accesses them, and for also writing the emails to a cache which is accessible to the host processor for parsing. A system as claimed in any preceding claim, wherein the host processor (5) comprises means for logging the category of all emails to an audit trail database; and wherein the host communication server comprises means for automatically logging all signature images to an audit trail database before the host processor accesses them; and wherein the host processor comprises means for parsing a message by initially tokenizing message content of delimited sections, and subsequently processing the tokens to generate the structured query language statements; and wherein a message header is tokenized separately from tokenizing of a message body; and wherein the tokenizing step is performed after recognition of a particular string in the message; and wherein the host processor comprises means for allocating each token to one of a set of strings for the message, each string being associated with a work flow parameter. A field service work flow management and communications system substantially as described with reference to the drawings.