Router utility for a parcel shipping system6571213Abstract A router utility and corresponding method for routing a load of one or more shipments of parcels, for use in a system for managing shipping parcels that includes a shipping database and a planning engine that provides load information for the load indicating a load identifier. The router utility includes: an input module for providing the load identifier included in the load information, and an analyzer for providing a carrier and service list. The planning information from the shipping database is organized as a set of tables of field records, including: an address table, for indicating an address and a route identifier based on an address identifier; a shipment header table, for indicating charge terms corresponding to a load identifier and for indicating at least one address identifier; rate shop group tables, for indicating one or more routes (a carrier and service); a route identifier priority table, for indicating priority for determining a route identifier based on charge terms; and routing instruction set tables, for indicating instructions for determining a route identifier or a rate shop group based on a route identifier. The routing instruction set tables can include condition fields which the router evaluates in determining what routing instructions to use. In addition, all records of the rate shop group tables applicable to a shipment are evaluated in combination and set logic can then be used in specifying a group of carriers and services to rate shop. Claims What is claimed is: Description FIELD OF THE INVENTION
Routing Both shipper
Instruc- and consignee
Rate Shop tions have routing
Carrier Service Group (Route ID) instructions Action
no no no no no Shop all carriers and
services in
system.
no no no no YES Use route priority table
to
determine whose
instructions are
to be followed.
no no no YES n/a Use route instructions
from
ShipHder Route ID.
no no YES n/a n/a Shop all carriers in the
rate shop
group.
no YES n/a n/a n/a Shop all carriers
supporting the
service.
Shop all services for the
specified
YES n/a n/a n/a n/a carrier.
YES YES n/a n/a n/a Use specified carrier and
service.
In the scenario, with the shipment routed and rated, the seller can print a label using the print label module of the interactive shipping module 17. The seller can print a carrier label (specific to a particular carrier including mail labels) or a regular shipper label. In addition, the seller can print a billing label, a bill of lading, or a hazardous materials label. Some of the labels can be printed from other interfaces besides those provided by the interactive shipment task processor 17, such as a shipment batch planner 13 and an end-of-day processing module (not shown). Finally, if the shipment of the scenario were for a foreign country, the seller could create export documentation using the prepare export papers module of an ancillary shipping management processes module 21. For monitoring the shipment in particular, or for monitoring more generally, the shipping manager 10 includes a reporting module as one of the ancillary shipping management processes module 21. The reporting module extracts report data from the shipping database 12. In the scenario, the seller interactively processed an order using the shipment processing module (FIG. 2) of the interactive shipment task processor 17. The shipping manager 10 also allows batch processing of orders after they are entered into the system by the order entry module 20 or by other means, including electronic downloading from remote order entry locations (not shown). To arrange for batch processing of an order, the seller uses a task scheduler 19 to indicate that shipping for an order is to be planned in batch mode, and then, still using the task scheduler, can prompt a shipment batch planner 13 to batch process any shipments in the shipping database marked for batch processing. (The shipping manager also allows the seller to use the shipment batch planner 13 to initiate the batch processing of any shipments in the shipping database 12 marked for batch processing.) The shipment batch planner performs the same functions for each shipment in a batch of shipments as the interactive shipment task processor performs for a single shipment, i.e. it performs routing and rating using the planning system 11. However, in batch processing mode, the planning system 11 also iterates in its planning to take advantage of opportunities to consolidate shipments in the batch. The planning engine 22 of the planning system 11 invokes a consolidator (module) 25 (also part of the planning system 11) to attempt to consolidate any or all shipments in the batch of shipments, unless there are instructions not to consolidate. If the consolidator 25 is able to consolidate a shipment with one or more other shipments, the planning engine 22 will then prorate the shipment by invoking a prorater 26, also part of the planning system 11. In attempting to consolidate shipments, the consolidator 25 searches the batch of shipments for all shipments having matching required properties. Usually these will include the shipper, consignee, and shipment date. However, it is also possible that other properties must match for a consolidation to be possible. For example, it is possible that a carrier is pre-specified. In all, the consolidator 25 can require that the following properties match in order for a consolidation to be acceptable: shipment date, shipper, consignee, bill-to, pre-specified carrier, pre-specified service, charge terms, inbound versus outbound, rate ship group, route ID, required delivery date, and hazardous commodity. Next the consolidator 25 creates a routing list of carriers-that can handle the shipment. Then it consolidates shipments based on either a least restrictive or a most restrictive bases. In the least restrictive basis, a carrier is selected from the routing list that can meet the earliest required delivery date specified on any shipment in the consolidation. In the most restrictive basis, a carrier is selected from the routing list that can meet the latest required delivery date specified on any shipment in the consolidation. The task scheduler 19 also allows scheduling any other kind of task performed by the shipping manager 10. Tasks that can be scheduled include: sending and receiving pre-defined electronic data interchange (EDI) transaction sets; emptying database tables; placing shipments in a group with pre-defined selection criteria; packing a group of orders with pre-defined criteria in batch mode; printing bills of lading with pre-defined selection criteria; printing pick tickets with pre-defined selection criteria; printing a pre-defined report; purging a pre-defined group and its loads and shipments; purging shipments and orders based on pre-defined selection criteria; running a batch or executable file synchronously; rating and planning a pre-defined group of shipments; and creating a small package manifest based on pre-defined selection criteria. Some of these tasks involve updating the shipping database 12 based on information in the host data sources 19, and in particular based on information in host text files (FIG. 2), as one component of the host data sources 19. For these tasks, the task scheduler 19 is used to schedule the data mapper (FIG. 2), of the interface 15 to host data source, to update the shipping database 12 based on information in the host text files. The data mapper then uses map templates (FIG. 2) to determine what data in the host text files maps into what field in the shipping database. The data in the host text files is often in a fixed format; then the map templates indicate (usually in terms of row and column) the beginning of a data item in a host text file, and by a format specification or other means indicate a length of the data item to be mapped. The interface 15 to host data sources enables a host application and the shipping manager to share various data. The sharing is enabled by dynamic data exchange (DDX) provided by a dynamic data exchanger; by an open data base connectivity (ODBC) exchanger, for exchanging data items maintained in the shipping database and in a host database; and by a data mapper, which acquires data from text files in a host environment and provides data to the host environment as text files. The data mapper is used in particular for acquiring business rules for guidance in routing, possibly expressed using conditional logic. As explained above, an order can be entered by downloading it from a host system file via the data mapper included as part of the interface 15 to host data sources. FIG. 2 shows that the dynamic data exchanger module, ODBC exchanger module and rule maker module of the interface 15 to host data source share information via a parameter table (parm table) 16. Other modules also use the parm table 16 to share data. For clarity, the parm table 16 is shown as several different blocks in FIG. 2, although each block represents the same physical parameter table. The Overall Routing and Rating Process Still referring to FIG. 2, in planning for the shipping of a parcel, the planning engine 22 first builds a load list template (a load list with some elements, such as costs, still to be determined), performs the planning for the load list template and so determines an actual load list, and provides the results of the planning either to a calling module (either the shipment event planner 14 or the shipment batch planner 13) or to the shipping database 12. As used here, a load list is a list of loads, each load including one or more shipments (parcels), and each shipment including one or more items included in a shipment, along with associated information, as described below. A load list can be built up from information in the shipping database 12, given a so-called Group identifier (ID), i.e. an index (key) indicating a group of items to be included in a shipment. Such an index would be provided by the shipment batch planner 13 either in response to being scheduled to perform planning for a batch of parcels, or in response to a user commanding the planning of a batch of parcels using the user interface provided as part of the shipment batch planner 13. Alternatively, in case of interactive one-at-a-time parcel shipping planning, a load list can be built up using shipment properties provided by shipment processing (of the interactive shipment task processor 17) via the shipment event planner 14. Still referring to FIG. 2, as mentioned above, the planning engine calls one or another of various utility modules in performing shipment planning. After building the load list, the planning engine must determine, for each load of the load list in turn, a carrier list (carriers and services) each of which would satisfy any existing requirements for shipping the load. To do so, the planning engine may or may not call the router 23, depending on whether a particular carrier and service has been specified to be used for shipping the load. Assuming not, i.e. assuming that a load is to be shipped based on considering various possible routes (each route being a carrier and service), the planning engine 22 calls the router 23, passing it the load list. The router returns a carrier list (including services) each of which would satisfy any existing routing requirements. Next, the planning engine calls the rater 24, passing it the carrier list determined by the router. The rater then determines a rate for each possible route indicated on the carrier list, and provides the planning engine rating results indicating a rate for each route. (As indicated above, in determining the rates, the rater module uses an associated data file, called rater data 24a.) Referring now to FIG. 3, a flow chart/data flow diagram of the overall routing and rating process is shown, assuming a particular carrier and service have not been specified for a load, as consisting of: first, the routing process performed by the router 23, accepting as an input (from the planning engine 22) a load (data item) 37 from a load list template, and providing as output (to the planning engine) a carrier and service list 38 for the load; and second, the rating process performed by the rater 24, accepting as input (from the planning engine) the carrier and service list 38, and providing as output (to the planning engine) a routed and rated load 39. In performing the routing of a load, the router 23 uses information in the shipping database 12; and in performing the rating of the load, the rater 24 uses information from the rater data 24a. The router 23 includes: an input module 23a, responsive to the load information from the load list template for the load being routed, for providing a load identifier for the load being planned; an analyzer module, responsive to the load identifier, and further responsive to planning information from the shipping database, as described below, for providing a carrier and service list; and an output module, responsive to the carrier and service list, for communicating the carrier and service list for use by the rater 24. The overall routing and rating process continues until each load in the load list template is routed and rated. For purposes of routing and rating according to the present invention, it makes no difference whether the load being routed and rated is a direct load (one shipment/parcel) or a consolidation (multiple shipments/parcels). The Router Utility As mentioned above, the router 23 is not called to determine a carrier and service list 38 for a load if a carrier and service are pre-specified for the load. Assuming that the router 23 is called, there are different levels of analysis that it will perform, depending again on what is pre-specified. Still referring to FIG. 3, based on the load identifier provided (in the load list template) for the load being routed, the router 23 will refer to the shipping database 12 to obtain the record for the load from a load table 36. Referring now also to FIG. 4, a record from the load table 36 has a field for indicating to the router 23 a particular set of routing instructions to be used (identified by a route identifier, which could aptly be called a routing instruction set identifier), and also fields for indicating a particular route (carrier and service), and a field (rate shop group identifier) for indicating a particular set of routes to be shopped. If the load table record (from the load table 36) indicates a particular route (carrier and service), then no analysis is performed by the router 23: the carrier and service list the router 23 provides is as indicated in the load table record. If the load table record indicates a rate shop group, then again, no analysis is performed; the carrier and service list 38 is simply constructed, as described in more detail below, based on records in the rate shop tables 35 (and in particular based on records in the rate shop list table 35b), using the rate shop group identifier indicated in the load table record. In the most general case, though, the router 23 will refer to the routing instruction set tables 31 to determine a carrier and service list 38. Before the router 23 can begin its most general analysis, however, it must determine a route identifier to use for the load be planned, i.e. it must determine an identifier of which instruction set to use in determining the set of routes (and possible associated penalties) to provide as the carrier and service list 38. Still referring to FIG. 4, there are two tables that can guide the router 23 in determining a route identifier, i.e. there are two tables that associate a route identifier with a load: the load table 36 and the address table 34. If the load table 36 specifies a route identifier, then the router 36 will use the route identifier. However, in the more general situation, the load table 36 will not specify a route identifier, and the router will then resort to the route identifier priority table 33 to determine a route identifier from the address table 34, as follows. Still referring to FIG. 4, the load identifier in the load table 36 is used by the router 23 as an index into a shipment header table 32, which indicates charge terms for the shipments of a load. In turn, the value of the field in the shipment header table 32 indicating charge terms is used as an index into the route identifier priority table 33, which sets out the priority to be given to route identifiers on file for shippers, consignees, ship-for entities, and ship-to entities. In the preferred embodiment, the charge terms are one of the following: prepaid (PPD), PPA, collect (COL), and third party (3RD), (Thus, there are only four records in this table, each having only five fields, the charge terms field, and four address record types, the first being the priority one address record type, and so on; each record type is one of the following: shipper, consignee, ship-for, or ship-to.) Based on the charge terms indicated in the shipment header record of the shipment header table 32, the router 23 obtains from the route identifier priority table 33 the priority one address record type, e.g. consignee. It then refers back to the shipment header record to find the address identifier for the priority one address record type. Thus, if the priority one address record type is consignee, then the router 23 will get the consignee address identifier from the shipment header record and use it as an index into the address table 34. If the record selected from the address table indicates a route identifier, the router 23 will use that route identifier. If not, the router will continue on to the priority two address record type, and so on. If no route identifier results from this process using the route identifier priority table (or if there are no routing instructions for the route identifier that results from this process), then the router 23 will provide as the carrier and service list 38 all carriers and services on file in the shipping database 12. Example of a Rate Shop Group Referring now to FIG. 5, a data entry screen for entering or displaying records in the rate shop group tables 35 is shown as including a record 52 from the rate shop group header table 35a and two records 53 from the rate shop list table 35b. Here the rate shop group identifier is LTLLESSRDWY, indicating "less than truckload" (LTL) excluding a carrier identified by carrier identifier RDWY. Correspondingly the description is, "LTL carriers excluding RDWY." The first two records of the rate shop list table 35b corresponding to the rate shop group identified LTLLESSRDWY are: (first) a record with no carrier identifier indicated and only a service LTL indicated; and (second) a record with a carrier RDWY indicated and the same service LTL indicated, but also a check mark in the field DoNotUse. Thus, the router 23 will interpret these two records in combination to express that all LTL carriers except RDWY are to be rate shopped by the rater 24. It is possible also that another carrier could be indicated and a penalty associated with the carrier, in which case the router 23 would append the penalty and the planning engine 22 would be less likely to select the penalty-bearing carrier. Having the router interpret a series of records in the rate shop list table corresponding to a same rate shop group identifier allows the use of set logic in indicating a rate shop group, i.e. in particular the use of and-logic to indicate that intersections of one or more sets of carriers and services are to be constructed to determine a rate shop group. Example of a Set of Routing Instructions Referring now to FIG. 6, a screen for entry of records into the routing instruction set tables 31 is shown including a record 62 from the route header table 31a and six records 63 from the routing instruction table 31b. Each field of a record of the routing instruction table 31b can be categorized as either a condition field, a go-to label field, a carrier/service field, or a rate shop group field. Thus, the fields of the various records from the routing instruction table 31b shown in FIG. 6 are shown partitioned into fields that are condition fields 64, or a go-to label field 65, or a carrier/service field 66, or a rate shop group field 67. One field, a line number field, is automatically assigned; it is considered part of the condition field partition. Each of the fields in the routing instruction table 31b corresponding to a given route identifier are evaluated by the router 23 to determine one or another rate shop group or particular carrier, service, or carrier and service to include in the carrier and service list 38. In the example shown in FIG. 6, beginning at line #1, which is the first record of the group of records associated with the route identifier KMART, if the shipment is between 1 and 100 lbs., and the service is GRD, then the router 23 will assign the rate shop identified by rate shop identifier GRDPKG. Thus, the router would refer to the rate shop group tables and select one or more carriers and services depending on the records corresponding to this rate shop group identifier. Going to line #2 of the instructions made up of the records corresponding to the route identifier KMART, if the shipment is between 1 and 100 lbs. and the service is not GRD, then the router will assign the carrier UPS and the service 1A. Going on to line #3, if the shipment is greater than 100 lbs., and the destination is in the Chicago area, then the router will assign the carrier RDWY, and the service LTL. Going to line #4, if the shipment is greater than 100 lbs., and the destination is not in the Chicago area, then the router will assign the rate shop group identified by the rate shop group identifier LTLLESSRDWY. Thus, based on the example indicated by FIG. 5, the carriers assigned would be all LTL carriers except RDWY. Example of a Route Priority Table Referring now to FIG. 7, a route identifier priority table 71 is shown in its entirety as consisting of four records, each record including a charge term and four priority address types, each address type being either one or the other of only four possibilities: shipper, consignee, ship-for (third party), and ship-to, as described above. Summary of the Routing Process Referring now to FIG. 8, a flowchart for the routing process of the present invention is shown including all levels of analysis, from determining the carrier and service list 38 based simply on the load record (from the load table 36) for the load being planned, to the full analysis based on instructions in the routing instruction set tables 35. In a first step 81, the load identifier for the load to be routed is obtained from the load list template. In the next step 82, the load record from the load table corresponding to the load identifier is checked to determine if a carrier and/or a service is specified. In a decision step 83, if a carrier and/or service are specified, then in a next step 84, the carrier and/or service are provided as the carrier and service list. Then, in a next step 85, either the next load in the load list template is examined or (if the load just examined is the last load) the routing process is complete. In decision step 83, if a carrier and/or service are not indicated, then in a next step 86, the load record from the load table is again checked, this time to determine if a rate shop group is specified. In a next step 87, if a rate shop group is specified, then in a next step 88 the corresponding group of routes (carriers and services) is provided as the carrier and service list 38. If not, then in a next step 89, the load record is once again checked to determine if a route identifier is specified. In a next decision step 90, if a route identifier is specified then in a next step 91, the routing instruction set tables 31 are analyzed, based on the route identifier, to determine the carrier and service list 38. If not, then in a next step 92, the shipment header is examined to determine what charge terms are to be used for the shipment. Then in the step 93, the route priority tables are referred to in order to determine whether to give priority to any routing instructions that might be on file for either a shipper, consignee, a ship-for entity, or a ship-to entity. Then in a next step 94, the address table is checked for a route identifier, based on the priority found using the route priority table. In a next decision step 95, if a route identifier is found in the address table, the routing instruction set tables 31 are examined using the same process that would perform the step 91 of analyzing the routing instruction set tables. The process of checking the address table is repeated for each entity (consignee, shipper, and so on), in the order indicated in the route priority table, until a route identifier is determined or all possibilities are exhausted. If no route identifier is determined in this way, then in a next step 96, all carriers and services on file in the shipping database 12 are output as the carrier and service list 38. SCOPE OF THE INVENTION It is to be understood that the above-described arrangements are only illustrative of the application of the principles of the present invention. Numerous modifications and alternative arrangements may be devised by those skilled in the art without departing from the spirit and scope of the present invention, and the appended claims are intended to cover such modifications and arrangements.
|
Same subclass Same class Consider this |
||||||||||