SUMMARY OF THE INVENTION

[0037] The present invention discloses systems and methods for the provision of shipping labels for use in returning parts distributed to field service technicians. A system is disclosed that processes a service parts order request against one or more rules and generates return shipping labels that are printed and enclosed in packages with service parts. Field service technicians use the appropriate return shipping label to identify the status of the service part and insure the timely return of both used and unused service parts to a facility equipped to handle them.

[0038] In accordance with an embodiment of the present invention, a method of providing service parts to a field technician is described that includes the steps of receiving an order to ship a part to a field technician, the order including a part identifier associated with the part; querying a parts database with the part identifier to identify a warehouse that the said part in stock; processing the order against a rules engine to associate an outbound shipping label and one or more return shipping labels to the order, and to generate shipping label data for the outbound shipping label and for the one or more return shipping labels; printing the outbound shipping label and the one or more return shipping labels at the warehouse; enclosing the one or more return shipping labels in a package with the part; affixing the outbound shipping label to the package; and shipping the package to the field technician.

[0039] In another related embodiment, the method is described wherein the step of querying a parts database to identify a warehouse includes querying a parts database to determine whether the part is available and, if available, where the part is located. In another embodiment, the step of querying a parts database to identify a warehouse includes the steps of identifying a warehouse that has the part in stock; setting a flag in the parts database to reserve the part; and contacting the warehouse to have the part picked for shipment. In still another embodiment, the step of querying a parts database to identify a warehouse includes querying a parts database to determine whether the part is available and, if not available, backordering the part. In yet another disclosed embodiment, the step of processing the order against a rules engine includes the steps of converting the order into an order array for submission to an enterprise Java bean via an enterprise Java bean client; receiving the order array into the enterprise Java bean; creating a Java order object suitable for processing by the rules engine; and passing the order object to the rules engine.

[0040] In another related embodiment, the method is described wherein the step of generating shipping label data for one or more return shipping labels includes generating label data for a first and second return shipping label, the first return shipping label identifying a returned part as used, and the second return shipping label identifying the returned part as unused. In another embodiment, the step of generating shipping label data for one or more return shipping labels includes generating data for shipping labels that allow the field technician to ship a used part for at least one of repair, restocking, salvage and disposal. In still another described embodiment, the step of printing the outbound label and the one or more return shipping labels at the warehouse includes transmitting the shipping label data in an electronic format to a printing device located at the warehouse; and printing the outbound label and the one or more return shipping labels on the printing device, wherein the information printed on the shipping labels is based at least in part on the shipping label data. In yet another embodiment, the step of printing the outbound label and the one or more return shipping labels at the warehouse includes transmitting the shipping label data in an electronic format to a computer system associated with the warehouse; forwarding the shipping label data to a carrier application upon a manual activation of the warehouse computer system; assigning a package tracking number to the outbound shipping label and each of the one or more shipping labels; generating the outbound shipping label and the one or more shipping labels based at least in part on the shipping label data; and printing the outbound shipping label and the one or more shipping labels at the warehouse.

[0041] In another disclosed embodiment, the method described above also includes the step of assigning a package tracking number to the outbound shipping label and to each of the one or more return shipping labels. And in another related embodiment, the step of enclosing the one or more return shipping labels in a package with the part includes the steps of picking the part from a storage area within the warehouse; placing the part in a package; retrieving the one or more return shipping labels from a printing device; and enclosing the one or more return shipping labels in the package.

[0042] In accordance with another embodiment of the present invention, a service parts shipping system is described that includes an order entry application, the order entry application configured to receive order data from a user, the order data including at least one service part number; a parts management application in electronic communication with the order entry application, the parts management application configured to receive the order data and query a parts database with the service part number to determine an availability of a service part; a rules engine in electronic communication with at least one of the order entry system and the parts management application, the rules engine configured to receive the order data and process the order data against one or more rules; the rules engine further configured to generate shipping label data based at least in part on the one or more rules; and a printing device configured to print at least one shipping label based at least in part on the shipping label data.

[0043] In another related embodiment, the parts management application is further configured to identify a warehouse that has the service part in stock. In additional embodiments, the parts management application is further configured to reserve the service part and backorder a service part that is unavailable. In still another described embodiment, the rules engine is configured to process the order data against at least one of a carrier rule, a logistics rule and a user-defined rule. In another embodiment, the rules engine is configured to generate shipping label data for an outbound shipping label and a return shipping label.

[0044] In another embodiment, the system is described such that the rules engine is configured to generate shipping label data for a first and second return shipping label, the first return shipping label identifying a returned part as used, and the second return shipping label identifying the returned part as unused. In still another embodiment, the rules engine is configured to generate shipping label data for return shipping labels that allow a field technician to ship a used part for at least one of repair, restocking, salvage and disposal.

[0045] In still another embodiment, the system is described to further include a warehouse application, the warehouse application configured to receive the shipping label data, the warehouse application further configured to transmits the shipping label data to a carrier system and receive a shipping label image from the carrier system; and a shipping label generation application residing on the carrier system, the shipping label generation application configured to receive the shipping label data and generate the shipping label image. In yet another embodiment, the shipping label application is further configured to transmit the shipping label image to the printing device, and the shipping label printed by the printing device is based at least in part on the shipping label image.

[0046] In accordance with another embodiment of the present invention, a method of monitoring the status of service parts that are shipped to a field technician is disclosed that includes the steps of receiving a service parts request, the service parts request including a request to ship a service part to a field technician; generating an outbound shipping label and a return shipping label in response to the service parts request; assigning a first service part tracking number to the outbound shipping label and a second service part tracking number to the return shipping label; storing information about the service parts request in a service parts transaction database, the stored information including the first and second service part tracking numbers; capturing package level detail information about a package that is shipped through a carrier, the package level detail information including a package shipment status and a package tracking number associated with the package; and updating the service parts transaction database with the package level detail information when the package tracking number corresponds to the first or second service parts tracking numbers.

DETAILED DESCRIPTION OF THE INVENTION

[0047] The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

[0048] Many modifications and other embodiments of the invention will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

[0049] The following paragraphs describe a service parts return system 10 in accordance with an embodiment of the present invention, the function of which is the provision of shipping labels for use in returning parts distributed to field service technicians.

[0050] In general, service parts are picked, packed and shipped from distribution centers and/or field stocking locations to the field service technicians who may or may not use the parts to effect repairs on products. The service parts arrive to the field technicians accompanied by one or more shipping labels, which the field technician will use to return unused service parts or, in some cases, used parts from a repair that needs to be returned. Typically at least two shipping labels are provided, one for the return of a new or unused part, and the other for the return of a used part. The return location for the service parts can vary based on a variety of order or part attributes. Used parts may or may not be returned at all. Used parts that are returned are preferably sent to a location equipped to refurbish, salvage and/or safely dispose of the part. An unused part may be returned to a distribution facility or field stocking location from which it was shipped, a warehouse experiencing a shortage of that part, or to a central location for later redistribution.

[0051] FIG. 2 is a high-level block diagram of the components of one embodiment of a service parts return system 10 . In this embodiment, a manufacturer 12 of a product employs one or more field service technicians 14 to service the product. When the manufacturer 12 receives a request for service, the manufacturer 12 contacts a field service technician 14 with a description of the problem. The field service technician 14 makes an initial diagnosis of the problem and sends the manufacturer 12 a service part list that may be required to effect the repair.

[0052] Upon receipt of the service parts list, the manufacturer 12 uses an order entry system 16 to have the service parts shipped to the field service technician 14 . The order entry system 16 may be a component of a manufacturer computer network in which case the manufacturer 12 inputs the service parts information into the order system 16 . Alternatively, the order entry system 16 may be at a remote location and service multiple manufacturers. In this alternative embodiment, the manufacturer 12 sends the service parts list to the order entry system 16 by any of several means that are well known in the art, including electronic data interchange (EDI), email, facsimile or via a phone call to a customer service representative that inputs requests into the order system 16 . In still another embodiment, shown in FIG. 2 with a broken line, the field service technician 14 communicates the service parts list directly to the order entry system 16 .

[0053] Once the service parts list is entered into the order entry system 16 , the parts list is transmitted to a service parts management system 18 . The service parts management system 18 queries a service parts database 20 to determine whether the requested service parts are available and, if available, where the requested parts are located. When the service parts management system 18 finds that the requested parts are available, a flag is set in the service parts database 20 to reserve the part. Information about the availability and location of the requested service parts is to the manufacturer 12 and/or field service technician 14 via the order entry system 16 .

[0054] If the user is satisfied with the availability and location of the service parts, an order is placed in the order entry system 16 and the service parts are pulled from their stocking locations and prepped for shipment. The order is transmitted to the service parts management system 18 and the service parts database 20 is updated to reflect that the requested service parts are being shipped to the field service technician 14 .

[0055] In an alternative embodiment, the order process is not a two-step process in which part availability is checked before the order is entered. Instead, when the service parts list is entered, an order is created and sent to the service parts management system 18 . The parts referenced in the order are then checked against the service parts database 20 and reserved for the order. If a part is unavailable the parts are either backordered or a search is made of supplier systems to have the part drop-shipped from the supplier to the field service technician 14 .

[0056] Once a service order is placed, the service parts management system 18 contacts the warehouse inventory systems 22 of the distribution centers and/or field stocking facilities that are supplying the requested service parts. Multiple distribution centers and field stocking locations may be involved in a single service parts order and each of the locations can have different warehouse inventory systems 22 . In one embodiment of the present invention, the service parts order that is sent from the service parts management system 18 to the warehouse inventory system 22 is sent electronically and the same format is used in every warehouse system 22 . In an alternative embodiment, different warehouse systems 22 require different formats for service part orders and the service management parts system 18 is configured to provide service part orders in different formats.

[0057] The service parts management system 18 then processes the service parts order against a rules engine 24 . The operation of processing an order against the rules engine 24 is described in greater detail below. In general, the rules determine whether and which service parts shipping labels will be generated for each of the requested service parts. In addition, several of the fields on the shipping label are user-definable and the rules determine the data that will populate these fields.

[0058] In a preferred embodiment, the rules processing occurs when a service part is picked. Shipping label information is output from the rules process and is stored in a shipping label table. In general, the shipping label information includes service parts return shipping label information for shipping labels that are packaged along with the service parts and used by field service technicians 14 to ship service parts back to the warehouse. Moreover, information for an outbound shipping label that is used to ship the parts to the field service technician 14 can be included in the shipping label table.

[0059] Updates to the rules engine 24 occur via a development workstation or via a maintenance application. A developer uses a rules development workstation to add or modify rules in the engine 24 . As modifications are made through the development workstation they are immediately stored in the master or production version of the rules engine 24 . In contrast, additions, deletions or modifications to the rules engine 24 made by non-developers are first stored in a quality control or test version of the rules engine 24 before they are moved into production. Whereas developers use a developer workstation to effect changes in the rules, non-developers use the rules maintenance application which, in a preferred embodiment, includes a more user-friendly graphic interface than its developer counterpart.

[0060] After the rules processing is completed and the service parts are picked and packaged for shipment to the field service technician 14 , a warehouse employee initiates the next step by indicating that the parts are ready for shipment. In a preferred embodiment, the employee will activate a ship function on a warehouse application to initiate the following shipping processes.

[0061] Upon activation of the shipment function, the shipping label information is sent to a package tracking system 26 where a package tracking number is assigned to each label. Package tracking numbers are well known in the art and comprise a unique identifier that allows parties to a transaction to track a shipment in a carrier system from pickup to delivery. In a preferred embodiment, a unique package tracking number is assigned to each shipping label and a package tracking database is updated accordingly.

[0062] Upon assignment of package tracking numbers, the service parts management system 18 passes the shipping information for each shipping label to a label generation application 28 , which generates the requested shipping labels. The shipping labels are then transmitted to the appropriate distribution centers and/or field stocking locations where they are printed and included in the package containing the service parts to be shipped to the field service technician 14 . In one embodiment, the shipping labels transmitted to the distribution centers and/or field stocking locations include the shipping label(s) required to ship the service parts package(s) to the field service technician. In addition, shipping labels are transmitted that will be used by the field service technician 14 to return used and unused service parts and these return shipping labels are included in the package containing the service parts.

[0063] In a preferred embodiment, the service parts management system 18 generates detailed information about the service parts that are being shipped and uploads this information to the package carrier. This information may include for example, the origination and destination addresses of the package, the size and weight of the package and the method and/or service level of the shipment. One of ordinary skill in the art will readily recognize that additional information about the shipment of the package is captured and uploaded in this step of the process. In one embodiment, a package carrier operates the service part returns system 10 and assumes responsibility for picking up the service parts from the various distribution centers and field stocking locations and delivering the parts to the field service technician. In an alternative embodiment, a service part returns system 10 may serve multiple carriers and the service part order may specify one of several package carriers. In still other embodiments, different package carriers may be used to deliver different service parts within a single service part order. For purposes of illustration, however, the following paragraphs describe a service part return system 10 in which a single package carrier is used for service part package shipping.

[0064] In a preferred embodiment, a package carrier receives the service part shipping detail and sends carrier drivers to the various distribution centers and field stocking locations specified in the shipping detail to pick up the service parts requested by the field service technician 14 . In this embodiment, the packages that contain the service parts also include the one or more return shipping labels that were generated as described above.

[0065] In the next step, the package carrier delivers the packages containing the service parts to the field service technician 14 . In a preferred embodiment, packages containing the service parts requested by the field service technician 14 are sent from a plurality of locations. Accordingly, the packages are sent to a local carrier facility and held there until the field service technician picks them up. In a preferred embodiment, the service part packages that are sent to the field service technician 14 are sent using a hold-for-pickup service such as is known in the art. With this service, as the packages containing service parts arrive at the destination carrier facility they are set aside and held for the field service technician 14 instead of being processed further through the carrier system. As is known in the art, a benefit of this service is that the field service technician 14 has earlier access to the packages that contain the service parts and can proceed immediately to the service call.

[0066] For purposes of illustration, assume that a field service technician 14 orders and receives five service parts for a given service call. In this example, the technician 14 uses three of the five parts to effect the repair and, in addition, obtains one used part from the product repaired. When the technician 14 opens the packages containing the service parts, the technician 14 retrieves the service part and the one or more return shipping labels that were packaged along with each service part.

[0067] In this example, three of the five service parts that were sent to the field technician 14 are used to repair the product and will not be returned. Two unused service parts and one used part will be returned. In a preferred embodiment, two return shipping labels are included with each of the two unused service parts. The first of the two return shipping labels indicates that the service part has not been used and has a destination address of a distribution center, field stocking location or other location that is equipped to receive and restock the service part. The second return shipping label indicates that the service part has been used and/or is defective. The destination address of the second return shipping label will typically be a facility equipped to refurbish, salvage or dispose of the used part.

[0068] With regard to the two service parts that were not used in the repair, the field service technician 14 repackages the service part and affixes the return shipping label that identifies the part as unused. Alternatively, if during the repair the service technician 14 discovered that one or both of the service parts were defective the technician 14 would affix the return shipping label that identifies the part as used to prevent a defective part from being re-shelved. In still another embodiment, a third return shipping label is available to the technician 14 that identifies the part as not having been used in the repair but nevertheless defective. The destination address of the third return shipping label can be the same destination as that of used parts or, alternatively, service parts identified as defective are returned to the entity that supplied the defective part.

[0069] The field service technician 14 also uses return shipping labels to return the used part obtained during the repair. If the used part is replaced by one of the service parts that were shipped to the technician 14 , the return shipping label enclosed with the replacement service part that identifies the part as used is affixed to the package containing the used part. In an alternative embodiment, additional return shipping labels may be provided to the technician 14 for any part under warranty. Thus, in the alternative embodiment, if a service technician 14 determines that a used part is under warranty, a return shipping label that identifies the good as a warranty return is affixed to the package containing the used part.

[0070] Once the field service technician 14 has repackaged the service parts to be returned and affixed the appropriate labels, the packages are delivered to a package carrier. In a preferred embodiment, the package carrier used for the return service part shipment is the same carrier used to ship the service parts to the technician 14 . In an alternative embodiment, however, the field service technician 14 can choose from several package carriers for a return shipment. However, if a choice of package carriers is available, the choice should be made prior to the various return shipping labels being generated as different package carriers use different shipping label formats.

[0071] The return shipping labels on the packages containing the service parts are scanned when the package carrier accepts the return package. Return shipping information is then sent to a central storage facility of the package carrier. In a preferred embodiment, the return shipping labels for the service part packages indicate that the packages are associated with the service part return system 10 . Accordingly, the return shipping information is transmitted to the service parts management system 18 whenever a service parts return package is scanned.

[0072] The service parts management system 18 receives the shipping information for the return service part packages and forwards the information to the manufacturer 12 . In a preferred embodiment, batches of shipping information are transmitted to manufacturers 12 at predetermined times during a day. One of ordinary skill in the art will readily recognize however that shipping information may be transmitted many different ways according to the needs or at the request of a manufacturer 12 . Because multiple manufacturers 12 can participate in the service parts return system 10 , the service parts management system 18 transmits only that shipping information that associated with a given manufacturer

[0073] In a preferred embodiment, the package carrier scan of the return shipping label captures sufficient information about the package that the manufacturer 12 can identify the service part contained within the package and the status of that part. Thus, the return shipping information provided by the package carrier to the manufacturer 12 identifies the service parts that are inbound and the status and destination of each part. And this enhanced visibility into the package shipping system provides the manufacturer 12 with greater accuracy in forecasting its service part inventory. In a preferred embodiment, a package carrier scans every package that is in transit in its system and identifies those packages that contain service parts by comparing the package tracking number against the package tracking numbers that were assigned to service part shipping labels and associated outbound shipping labels. The service part tracking numbers may be stored, for example, in a service parts transaction database, along with other information about the associated service order.

[0074] Another benefit of this greater visibility is the elimination of delays in billing for the repair. In the processes known in the art, service charges are often delayed several weeks until the manufacturer 12 receives the used and unused service parts and determines which of the parts originally ordered by the field service technician 14 were used in the repair. The present invention eliminates these delays by notifying the manufacturer 12 of the service parts that are in transit to its distribution centers and/or field stocking locations.

[0075] Still another benefit of this process is the accumulation of historical data about the movement of service parts between warehouses and field service technicians 14 . As will be readily apparent to one of ordinary skill in the art, a variety of reports can be generated from this historical data that will provide valuable tools to manufacturers 12 . In a preferred embodiment, the service parts management system 18 includes a reports-generation feature that provides manufacturers 12 and other users customizable reports about service parts movement.

[0076] In one embodiment, specific reports are available to users of the system 10 . In an alternative embodiment, some or all of the users have access to a service parts transaction database 30 that includes the historical data associated with each user. User access to the transaction database 30 allows users to formulate their own queries and generate custom reports. Some of the reports available to users are illustrated in FIGS. 3 A- 3 C and include an Aged Report, a Returns Report, and a Turnaround Report. One of ordinary skill in the art will readily recognize that additional reporting capabilities are provider to users having access to the transaction database 30 .

[0077] The following paragraphs provide additional detail about the system architecture of an embodiment of the present invention.

[0078] FIG. 4 illustrates the distributed application architecture of a service parts return system 10 in accordance with another embodiment of the present invention. In this figure, an application server 50 is represented as a single system; however, one of ordinary skill in the art will readily recognize that this server may be physically instantiated as a collection of servers with components distributed for scalability and redundancy. In a preferred embodiment, the application server 50 supports the Oracle relational database management system (RDBMS) though one of ordinary skill will recognize that the present invention is equally advantageous with other database systems known in the art.

[0079] A carrier shipping system 55 communicates with the application server 50 via the network 60 . In a preferred embodiment, the network 60 is an Ethernet network; however, other networks known in the art can be used as well. The carrier shipping system 55 generates package tracking numbers and the associated shipping data for the system and is responsible for uploading shipper end of day data to associated shipper host systems. In a preferred embodiment, communication with the carrier shipping system 55 occurs via a message queue series interface (MQSI) running over a MQSeries as is known in the art.

[0080] A warehouse management server 65 communicates with both the application and carrier shipping system 55 via the network 60 . Again, while represented as a single server, the warehouse management server 65 may be physically instantiated as a collection of servers with components distributed for scalability and redundancy. In a preferred embodiment, the warehouse management server 65 provides RF extensions to an Oracle enterprise resource planning system (ERP) and provides warehouse functionality. In operation, the warehouse management server 65 receives service parts order data from the application server 50 and exchanges shipping data with the carrier shipping system 55 via MQSI.

[0081] An ARS server 70 also communicates over the network 60 and hosts the rules engine 24 that determines which, if any, shipping labels are generated by the system 10 . In a preferred embodiment, the ARS server 70 deploys the rules engine 24 via an enterprise Java bean (EJB). Enterprise beans provide rules processing to the service part order data passed to the bean.

[0082] The developer workstation 75 and rules maintenance workstation 80 are interfaces that allow developers and other users to add, modify and/or delete rules. In a preferred embodiment, the rules maintenance workstation 80 is used primarily by non-technical users and, accordingly, greater limitations are placed on the modifications made to rules by these workstations. For example, in a preferred embodiment the criteria by which a rule is executed can be changed via a rules maintenance workstation 80 , but not the fundamental structure of the rule.

[0083] In a preferred embodiment, the developer workstation 75 and rules maintenance workstation 80 communicate with the system network 60 and other system components via a rules development network 85 . In a preferred embodiment, the rules development network 85 is an Ethernet network. But it will be readily apparent that other types of networks known in the art can be used with the present invention.

[0084] Packout stations 90 and label printers 95 are connected to the system network 60 via a warehouse network 100 . In a preferred embodiment, the warehouse network is an Ethernet network, but again other networks known in the art will provide the same functionality. The packout stations 90 represented in FIG. 4 provide the warehouse systems use by the distribution centers and field stocking locations. In a preferred embodiment, these systems represent a presentation only layer with browser-based connectivity to the other system servers, including the application server 50 and the warehouse management server 65 . The label printers 95 are the printers on which the shipping labels are printed. In a preferred embodiment, Eltron printers are used and provide label printing capabilities to support both outbound and service parts return shipping labels. A jet form server 105 (not shown) is also present to manage the print queues that enable the printing of shipping labels. In a preferred embodiment, shipping label drop files are recognized by the jet form server 105 and interpreted for the label printers 95 that renders the label that contains the data.

[0085] The following paragraphs describe the operation of a service parts return system in accordance with an embodiment of the present invention. The description is presented in a drill-down format in which greater detail is provided in succeeding paragraphs and associated figures.

[0086] FIG. 5 illustrates the highest-level process flow of a service parts return system 10 . At a high level, the function of the system is to receive an service parts order from a user and produce one or more outbound and/or service parts return shipping labels associated with the order.

[0087] FIG. 6 illustrates a first drill-down into the process. The processing lifecycle is the order itself. The process illustrated initiates with the input of a service parts order. Typically a field service technician 14 diagnoses a repair problem and orders the service parts that the technician believes may be associated with the problem. Order data may be entered by any of the field service technician 14 , a manufacturer 12 or a customer service representative acting as a user of an order entry system 16 . Order data entry is via the web, EDI or manual entry.

[0088] Upon entry, order data is replicated to an instance of Oracle. Again, Oracle is represented herein for illustrative purposes as Oracle is a well known database and application development software vendor. The present invention is equally advantageous with other database applications. Upon confirmation that the service parts are available, the order is released for picking. At pick release, the processing diverges with service parts order being electronically processed as the service parts are being physically picked at one or more warehouse locations. Processing converges again at the packout station where the service parts are packaged and shipping labels are printed. In a preferred embodiment, outbound and service parts return shipping labels are printed. The return shipping labels are placed in the package with the service parts for use in returning the parts, and outbound shipping labels are affixed to the package for shipment to the field service technician 14 . As illustrated, Oracle provides input to many of the processes and receives input from the processes.

[0089] FIG. 7 illustrates that the service parts return system 10 processes are invoked by an Oracle stored procedure. The Oracle procedure invokes a service parts stored procedure that resides in Oracle. In a preferred embodiment, the service parts stored procedure receives an order number from the service parts order data as its input.

[0090] FIG. 8 illustrates the process beginning from within the service parts stored procedure where order data is retrieved from Oracle using the order number passed as a parameter. The order data is pre-processed to identify the origin and destination zones for later use when the rules are applied. The data is then packaged and used to instantiate the EJB that serves as the rules processing engine. In a preferred embodiment, this instantiation of the EJB is via a java stored procedure (JSP) with the bean invoked on the rules server, which may or may not be remote to the Oracle instance invoking it.

[0091] Once instantiated the bean applies the designated rules to the service parts order data passed in, and additional Oracle data can be retrieved if necessary to complete the rules processing. After processing the order data against the rules, the EJB returns the shipping label data to the calling service parts stored procedure where post-processing occurs and Oracle is updated with the shipping label data.

[0092] FIG. 9 illustrates a retrieval and pre-processing operation in accordance with an embodiment of the present invention. As described above, service parts order data is retrieved from Oracle using the order number and passed from an Oracle pick release stored procedure. In a preferred embodiment, the retrieved data includes both header and line data as well as attributes of service parts. If the user whose order is being processed utilizes the idea of zones, then zones associated with the ship to and ship from addresses are determined. This updated data is then prepared in arrays for submission to the EJB via an EJB client.

[0093] FIG. 10 illustrates the invocation of the EJB client. In a preferred embodiment, the EJB client is a Java client that is implemented on the Oracle RDBMS system. The EJB client receives the arrays of service parts order data, creates a Java order object suitable for processing by the rules engine 24 and passes that object to the rules engine 24 . Following the application of the rules to the order data, the EJB client returns the order data to the calling Oracle stored procedure again via the arrays used to pass the data initially. In this embodiment, among the arrays that are passed back to the Oracle procedure is a new array that includes shipping label data, which is the result of the rules processing.

[0094] FIG. 11 illustrates the application of rules in accordance with an embodiment of the present invention. The application of rules is hierarchical in two ways, the order is examined at the header level first and, if necessary, at the line level. Initial rules look at the order header data to determine if service parts processing is require. If processing is not required, the order is flagged as having been processed but not requiring service parts shipping labels.

[0095] If the order data indicates that service parts processing is required each order line is processed. Carrier rules are applied for each. Carrier rules are sets of carrier-specific rules that a carrier applies to packages shipped in its system. Carrier rules can include, for example, a requirement that ground transportation be used for package shipments to or from certain locations. In the context of a service parts return system 10 , a carrier may require that service parts transactions be available only in certain areas or under certain conditions.

[0096] If the carrier rules processing indicates that no service part shipping labels should be created for this line item, the local order data is updated and the next order line item is processed. Assuming that the carrier rules do not preclude the generation of service parts return shipping labels, service part logistics rules are applied. Service part logistics rules can vary from carrier to carrier. In a preferred embodiment, the service part logistics rules include a check to confirm that the customer that generated the service order request has a valid billing account number. As will be readily apparent to one of ordinary skill in the art, additional checks may be performed in this step based on the user and/or the service parts order information.

[0097] In a preferred embodiment, one or both of the carrier rules and service part logistics rules may indicate that service parts shipping labels should not be generated for a given line item. Assuming neither the carrier or service part logistic rules preclude the creation of service parts shipping labels, the order line data is updated and user-specific rules are applied to the order line.

[0098] Each order line is processed according to the foregoing steps. When all order lines have been processed, the EJB returns the updated order data for use in populating Oracle with the shipping label data. This data is returned to the EJB client where it is packaged and returned to the service parts stored procedure.

[0099] FIG. 12 illustrates the process of receiving and processing the order object/data in preparation for updating the Oracle database. In a preferred embodiment, post-process shipping label data identifies the need to resolve address and receipt codes populated by the rules engine 24 . These codes are used as the key to look in the Oracle locations for complete address information and to determine what data will populate the user-defines areas of the service parts shipping label. The address and receipt information is used to populate a service parts shipping label table.

[0100] FIG. 13 illustrates the process of updating Oracle in accordance with an embodiment of the present invention. In a preferred embodiment, the Oracle database is updated with three types of data, including the address data, carrier data such as service level and reference fields, and user-specific reference values. Also in the preferred embodiment, all of these data elements are stored in a service parts label data table.

[0101] FIG. 14 illustrates the steps of a pick and ship order process. This process occurs at the distribution centers and field stocking locations where the service parts are stored. When an order is received at the warehouse, the referenced service parts are picked from storage and packaged for shipment. As part of the parallel processes described above, outbound and service part return shipping labels are generated and printed at the packout station within the warehouse. Service part return shipping labels are placed in the package with the service parts. Outbound shipping labels are affixed to the packages and the package is dispositioned.

[0102] The process of printing the shipping labels is illustrated in FIGS. 15 and 16 . The process occurs at the packout station of a distribution center or field stocking location. In a preferred embodiment, a warehouse employee initiates the process by activating a “ship” button (or analogous name) on a warehouse management server interface, which generates an XML print request document. This document is delivered via MQ Series and is processed mid-stream by MQSI. The XML data is then sent to the carrier shipping system 55 and the resulting ship data is returned to the warehouse management server 65 and updates the Oracle database. The update sent to the warehouse management server 65 is also via MQ Series as an XML document. In a preferred embodiment, the ship data returned from the carrier shipping system 55 is used to create a printer drop file. The drop file is subsequently deposited in the proper directory such that shipping labels are printed on an associated printer.

[0103] In a preferred embodiment, the ship request document received by MQSI contains data necessary to print both the outbound and service parts return shipping labels. MQSI parses the data and creates an XML document for each shipping label. These documents are identified as XML tracking request documents in FIG. 16 . Each XML tracking request document is then sent to the carrier shipping system 55 , which generates shipping data, including a package tracking number and routing code. The carrier shipping system 55 then formats the shipping data as an XML ship request document, which is returned to MQSI. MSQI buffers the XML ship request document and uses it to create a printer drop file. In addition, MQSI formats an XML print update document that is used to update the warehouse management server 65 with the new shipping detail. When all of the shipping label data has been processed, the data used to create the printer drop file is stored in memory.

[0104] FIG. 17 illustrates the process required to create a printer drop file. In a preferred embodiment, the creation of a printer drop file requires iterating the shipping label data buffered in memory. Each time shipping label data is encountered it is written to the printer drop file in the proper format. In this embodiment, the outbound label data is passed over until the end at which time it too is written to the printer drop file. The outbound label is saved until the last pass so that the outbound shipping label serves as an indicator to warehouse personnel that the last label for a given package has completed printing.

[0105] FIGS. 18 and 19 illustrate service parts return shipping labels 110 in accordance with an embodiment of the present invention. Each shipping label 110 includes a ship from address 112 , ship to address 114 , Maxicode™ 116 , post office code 118 , post office bar code 120 , package tracking number 122 , carrier bar code 124 , package weight 126 and service level identifier 128 . The shipping label also includes specific fields that identify the label as part of a service parts return system 10 . These fields include a part number 130 , a customer reference field 132 , a service part condition identifier 134 , order number 136 one or more user-customizable areas 138 .

[0106] In a preferred embodiment, the part number 130 identifies the service part that the field service technician 14 is shipping and the service part condition identifier 134 indicates whether the part is used or unused. In the case of a used part, the ship to address 114 may be that of the manufacturer, part supplier or other entity prepared to receive and handle used parts. In one embodiment, the handling of used parts is based at least in part on the part number 130 . For example, a first used part may be shipped to a facility to be repaired, while a second used part is shipped to a salvage area, and a third used part shipped to a disposal location. In one embodiment, service parts identified as unused in the condition identifier area 134 may be returned to the distribution center or field stocking location from which they originated or, alternatively, to a warehouse location that has a low inventory for that part.

[0107] The customer reference fields 132 of a service part return shipping label 110 can include one or all of an order number, part number, outbound package tracking number, or disposition number. Because the customer reference field 132 is user customizable, the information used to populate the field can differ from user to user and may include any additional information that a manufacturer 12 or other customer requests to be placed on a shipping label.

[0108] In addition, a plurality of user-customizable fields 138 is included on the bottom of the shipping label 110 . These fields 138 may include any additional information that a user wishes to be placed on the label. For example, a service part may be especially fragile and these fields may include special packing instructions whenever a shipping label is generated for the part. Alternatively, the user-customizable fields 138 may instruct the field service technician 14 on when and how to use the various shipping labels included with the service parts. One of ordinary skill in the art will readily recognize that individuals users may have specialized needs for these customizable fields 138 and that these needs are intended to be encompassed by the present invention.

[0109] In a preferred embodiment, a field service technician that receives service parts for a repair receives the shipping labels 110 illustrated in FIGS. 18 and 19 . Because the shipping labels 110 are alternative shipping labels for returning the same service part, many of the label fields will use the same information, including without limitation the part number, customer reference number, ship from address, package weight, service level and RCV reference number. In a preferred embodiment, the labels 110 have different package tracking numbers, which allows the carrier to identify which of the shipping labels is used for the return. In a preferred embodiment, the package tracking number is scanned by the carrier when the package is accepted and the package tracking number is compared against one or more service parts tracking numbers to identify the shipping label and contents of the package. This information thus becomes available to carrier customers and provides them with added visibility about service parts in transit, thus providing for increased accuracy and efficiency in parts inventory and timely billing initiation.

[0110] The shipping label 110 of FIG. 18 is used to return a service part that is not used in the repair. In this illustration, the condition identifier 134 and the ship to address 114 of the label identify the part as unused. Moreover, the user-customizable areas 138 of the label 110 provide the field service technician with instructions as to how and when to use the ARS label. In one embodiment, the ship from address may be the address of the originating warehouse for the service part. Alternatively, the ship to address may be an address of a location that is equipped to receive unused parts and/or a location that has a shortage of that particular service part. In a preferred embodiment, the field service technician also receives the shipping label 110 illustrated in FIG. 19 . In this example, the field service technician uses the shipping label of FIG. 19 if the part is defective, used, the wrong part in the box, or dead on arrival. In alternative embodiments, additional shipping labels may be used for some or all of these different situations.

[0111] The service parts return system 10 , which comprises an ordered listing of selectable services can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system. processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM or Flash memory) (magnetic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

[0112] Further, any process descriptions or blocks in flow charts should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.

[0113] It should be emphasized that the above-described embodiments of the present invention, particularly any “preferred embodiments” are merely possible examples of the implementations, merely set forth for a clear understanding of the principles of the invention. Any variations and modifications may be made to the above-described embodiments of the invention without departing substantially from the spirit of the principles of the invention. All such modifications and variations are intended to be included herein within the scope of the disclosure and present invention and protected by the following claims.

[0114] In concluding the detailed description, it should be noted that it will be obvious to those skilled in the art that many variations and modifications can be made to the preferred embodiment without substantially departing from the principles of the present invention. Also, such variations and modifications are intended to be included herein within the scope of the present invention as set forth in the appended claims. Further, in the claims hereafter, the structures, materials, acts and equivalents of all means or step-plus function elements are intended to include any structure, materials or acts for performing their cited functions.