GB2394814A - Delivery management system - Google Patents
Delivery management system Download PDFInfo
- Publication number
- GB2394814A GB2394814A GB0325242A GB0325242A GB2394814A GB 2394814 A GB2394814 A GB 2394814A GB 0325242 A GB0325242 A GB 0325242A GB 0325242 A GB0325242 A GB 0325242A GB 2394814 A GB2394814 A GB 2394814A
- Authority
- GB
- United Kingdom
- Prior art keywords
- carrier
- delivery
- stage
- management system
- shipper
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Economics (AREA)
- Quality & Reliability (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Development Economics (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
A delivery management system for managing distribution of packages by carriers is disclosed. The system allows a shipper (an originator of packages to be sent) to use multiple carriers in an efficient and transparent manner. The system comprises a shipper stage, an allocation stage, a despatch stage and a carrier stage. A shipper' computer systems can interact with the shipper stage to execute a package delivery. This is typically a stage with universal application to provide a consistent interface. The allocation stage is operative to determine the preferred delivery mechanism for the package delivery procedure. The despatch stage generates specific carrier documents such as labels and manifests. The carrier stage (of which there may be several) serves to interface with a parcel carrier to send data to the carrier and receive data from the carrier relating to the delivery procedure.
Description
Delivery Management System 5 This invention relates to a delivery
management system. More specifically, this invention relates to a method and system for usmg multiple parcel carriers to support the transportation of packages between two distinct locations.
It Is widely recognised that the mass movement of packages presents a considerable problem for many businesses. For example, a business that sells primarily through mail 10 order or on-hne ordering may have to despatch several thousand packages each day to dt'l'erent addresses. Driven by perceived cost efficiencies rather than customer service, businesses have traditionally contracted with a minimum number of parcel carriers to .'. canry packages to stores or directly to customers' addresses. 'the goal was to maximise ., volume-re]ated discounts by offering as much volume as possible through a single I 5 carrier.
. . . Even where businesses do use multiple cancers, the cost and resources required to . integrate and manage the perfonnance of multiple carriers n1 a conventional distribution . :,,, system makes it difficult to modify the business strategy if they wish to change the carriers that they use. Each parcel carrier typically requires specific operating processes, 20 specific technology interfaces and specific label formats in order to perform a parcel delivery for a business. Mult-canier Interfaces are not standard in a typical currant warehouse management system (WMS) and use ol' multiple carriers tends to be an inefficient process for the user.
Moreover, because each carrier has its own approach for tracking and tracmg parcel 25 movements and providing management information, the business has to invest signil'icant time and resource into managing, momtormg and admimstenng to multiple carrier partners. Effective delivery management requires seamless track and trace across multiple partners.
There are significant potential advantages for the use of multiple parcel carriers and for having the ability to switch easily between parcel carriers.
For example, dfl'erent parcel carriers have: À their own service specializations at which they perform best and at lowest cost. For 5 example, some specialise in next-day delivery, or scheduled time slots, or prool'of delivery, package tracking, etc. À specific types of packages that they are best at delivering and at lowest cost. For example, insurance for high value goods, the ability to deal with heavy, fragile or hazardous packages, or the ability to perform installation, etc. 1() À difl'erent geographies where they perform best and at lowest cost. For example, a carrier may have an urban or rural focus, or have international delivery capability, etc. . EP-A-0 962 877 discloses a logistics chain to make a delivery according to a principal's desire. However, it does not include an allocation stage to one or many carriers, nor 15 does it tailor the communication process to multiple carriers.
. US-A-5 043 908 discloses a mail delivery system with arrival mowtorn1g. However, .,. ' this disclosure does not enable a btsmess to make use of multiple carriers, nor does it
allow the optimal routing of a consignment to be detennined automatically. Nor can .. i,,, such a system be integrated into an existing order dispatch system.
2() WO0()/65499 discloses an apparatus and method for delivering a parcel. A so-called "PUDO" (pick-up, drop-ofl) system. This disclosure relates to control of a parcel
within a physical delivery system and does not provide a user with the flexibility of use of multiple delivery channels. The package delivery systems and methods disclosed n US-A-2002/16726 have the same limitations.
25 Summary of the Invention
The aim of this invention is to provide a system whereby a business that distributes multiple packages can readily take advantage of the services that a range of parcel
carriers can offer without encountering the substantial technical and administrative dfEcultes normally associated with their use.
From a first aspect, the invention provides a delivery management system 1or managing distnbuton of packages by carriers, composing: a shipper stage with which a shipper 5 can interact with systems that execute a package delivery; an allocation stage operative to determine the preferred delivery mecllanisnl for the package delivery procedure; a despatch stage operative to generate where parcel carrier specific documents; and a carrier stage for interfacing with a parcel Carrier to send data to the carrier and receive data from the carrier relating to the delivery procedure.
10 From another aspect, this invention provides a distnbttion system for managing distribution of packages comprising a shipper stage with which a shipper can interact with systems that execute a package delivery; an allocation stage operative to determine the preferred delivery mechanism for the package delivery procedure; . . ., 15 a despatch stage where parcel specific carrier labels and manifests are generated; ... and . a carrier stage for interfacing with a parcel carrier to send data to the carrier and .... receive data from the carrier relating to the delivery procedure.
A shipper stage typically enables the receipt and transmission of standard messages 20 between a system embodying the invention and: front- end applications, such as a web site, call eentre application, or retailer EPOS system; warehouse management system (WMS); order management system (OMS); or 25 - any type of file, that can be imported by the distribution system.
This stage provides a standard layer for the above systems to Interact with the distribution system. Examples of such mteraetions are explained in the next section. Tt
is important to note that In some embodiments, the distribution system does not necessarily need these systems to manage a parcel delivery and can operate standalone, by Interacting with canters and using its own user interi'aces.
An allocation stage typically determines the preferred service chain for the package 5 delivery procedure. The allocation stage is typically operative to identify the optimum service chain for delivery of any particular package.
A service chain may include one or more dehvery legs or carrier services required to carry out a package delivery. Each carrier service constitutes a delivery leg, and can either be a simple service chain on its own, or it could combine with delivery legs to 10 I'onn a more complex service chain. There are key parameters associated with each service chain that may restrict their selection for a given package. 'I'hese include: À the lead-time for delivery using a particular service chain. For example, the firming maybe beyond the requested delivery date.
2. À tmling for final delivery. For example, if the package requires an evening .. 15 delivery, but the last carrier in a service chain does not do this, then the service .. chain cannot be allocated to the package.
. . . À carrier handling restrictions. If the package contains items that require special handling, for example, hazardous items, and a carrier in the service chain does i not carry hazardous goods, then that service chain cannot be allocated to the t 20 package. À the size and dhnensions of the package. For example, it maybe del'ined that a postal service is not able to deliver packages that cannot fit through a door or into a mailbox.
À the delivery address. For example, is that the postcode of the delivery address in 25 a no-go area'? À capacity of the carrier. It could be assumed that some carriers can carry an unlimited number of packages at any time. However, others may have finite capacity and their volumes may need to be better controlled. The allocation
s stage ensures that different carriers are allocated the correct number or correct proportion of packages to ensure that the package volumes are balanced, and the shipper is able to manage the commercial aspects of the relationship. For example, the shipper may have agreed with the carrier that they will carry a 5 certain amount of packages each day, in order to qualify for volume discounts.
Each service chain leg has postcodes or postal areas assigned to it, to Identity to where it can deliver, and those that it is not able to deliver to. For example, in the United Khigdonl, a service chain could be called "Royal Mail 2"0 Class". This service chain will only have one delivery leg, using a carrier called "Royal Mail" (r.t.m.) WtliC}1 has a 10 delivery service called 62,.ti Class Delivery", and it Is able to carry and deliver small packages to every postcodc in the UK. Another service chain could be called "Securicor Weekday Evening 5-9pm", using a carrier called "Securicor" (r.tm1.), a delivery service called "Weekday Evening 5-9pm" and it carries any package up to 25kg. It can deliver to every area in the UK, except postcodes In remote areas of the 15 country, and inner-city postcodes that have high crime rates. The final carrier or delivery leg in the service chain will detcnnine wYcther a service chain is capable of ' ' ". making a delivery to that delivery postcode and to the specified delivery date/time slot.
',: It Is important to note that the service chains are defined by the shipper, and are not an ,. lo,' optimization by the distribution system. The shipper may also allocate a preference . 20 ranking to service chains. In the case where the shipper offers the customer a choice of . ., which service chain to use, the most-preferred service chains would be presented. Other .. embodhnents of the invention (those which incorporate the allocation stage) will allocate only the most appropriate service chain to the package, rather than offer a selection to choose from.
25 The despatch stage typically includes a unique parcel identiler (UPI) number, the earner label and the dcspatch manifest, that is specific to each package. The despatch stage receives a message from a WMS or OMS, or in some embodnnents of the invention, a user interface is available to initiate print a label for a package. The invention uses a label template to create each carrier label(s) for a package, according to 3() the carrier that would be delivering it, and the delivery instructions. When the package is ready tor despatch, the distribution system will send an electromc manifest to the carrier system, and also punt a paper copy.
The universal carrier stage enables the receipt and transmission between the mventon, and carrot systems or any other parcel transport or control system, for example a PUDO (pick-up, drop-off) system. This stage Is typically configured such that it is aware of the protocols and interfaces required for communication with each of the 5 car iers.
A distribution system embodying the invention may further comprise a management information stage to record and/or analyse data on the performance of canters. The management mfornlation stage is typically operable to create reports to enable a user to monitor and analysc carrier perfonnancc. The type of information produced, enables a 10 user to reconlgure the system In response to changes in carrier perfomlancc, thus increasing the overall process efficiency.
Typically, information can flow through the system from a shipper to the canter and from the carrier to the shipper. Thus, a shipper can receive information about Individual deliveries handled by various carriers through the consistent interface provided by the . 15 universal shipper stage. Additionally, some embodiments of the invention may include a user interface to enable parcel enquiry.
. , From a further aspect, the present invention provides a distribution system for managing . distribution of packages by car iers, comprising: a) a user interface stage with which a i,.... user can interact to initiate a parcel delivery procedure; b) a processing stage operative 2() to determine the preferred delivery mechanism for the parcel delivery procedure; and c) ... a plurality of backend stages each for interfacing with a parcel carrier to send data to the . carrier and receive data from the canter relating to the delivery procedure n1 a format specific to that carrier...DTD: F,mbodimcnts of the invention will now be described in detail, by way of example, and 25 with reference to the accompanying drawings, in which: Figure I is a block diagram illustrating the architecture of a system embodying the invention. Three main classes of cmbodunents of the invention may be provided: 1. Shipper based, 2. CaTicr based, or 3. Hosted. A system embodying the invention may be used 30 by a shipper. A shipper is typically a business that dcspatches product to customers
using either a parcel or express carrier or their own fleet. Carrier computer systems are conventionally stand-alone, dedicated systems. This can create significant problems l'or shippers ii'they wish to use more than one carrier, because it is technically costly and time consuming to do so, and it also Increases the complexity of despatcl1 operations.
5 This is because the warehouse will have to support the vagaries of each carrier's processes, reducing the efficiency of the overall process. The universal shipper stage of the embodiments of this invention can, firstly, and very advantageously, be ntegratcd with an existing computer system used by the shipper, such as an order management system or warehouse nanagcment system. Secondly, the universal carrier stage 10 provides a common layer to communicate with all carriers, and consolidates all cattier related activity into a standard process, thus minin1ising process complexity.
A system embodying the invention may be operated by a carrier. A carrier user may use the universal shipper stage, universal carrier stage and allocation stage to optimism the flow ol'packages that enter their own transportation system. For example, a carrier who 15 has a contract to delivery electrical goods, and has a spccialisaton in delivering large packages to urban customers, may find that transporting small packages, or packages to "'. remote areas, reduces its overall service performance and increases their business costs.
The carrier user may allocate packages that do not fit in with their core competency, to . sub-contractor carriers who can delivery these packages snore ct'i'iciently...DTD: ''': 20 With reference first to Figure 1, a typical package delivery management system A. embodying the invention comprises the following principal components: a delivery options engine (DOE) 1(), a delivery execution engine (DEE) 12, a carrier integration module (CIM) 14, a UPI generator (UPIG) 16, a carrier label creation module (CLC) 18, a universal shipper adaptor 20 and a universal carrier adaptor 22. Three user 25 interfaces or screens are available, dcspatch manager 24, parcel enquiry 26 and management information 28.
Thc universal shipper adaptor forms the universal shipper stage; the universal carrier adaptor and CIM form the universal carrier stage. Thc DOE and DEE constitutes the allocation stage, and the CIM, UPI(] and CLC and the Dcspatch Management user 30 intcrI:ace together constitute a despatch stage. Thc basic function of these modules, which typically, but not necessarily, arc provided in embodiments of the invention, will now be described.
The dclvery options engine 10 provides algorithms to detcnmine the most appropriate service chain (and hence the carriers to be involved) to move a package from a despatch point to a delivery point. Potentially, this determination is made using a large number of d'l'ferent criteria. This depends on the sophistication of the embodiment, and in more 5 simple embodiments, where a great level of complexity may not be required. The source of the request for a service chain dctemlines the nature of the response. A new parcel request received by DEE 12 may require a service chain and the embodiment will automatically allocate an appropriate carrier. If the request for a service chain originates externally (e.g. from a front end appPcaton), DOE 10 presents a rea1-time, standardised 1() systemic response (via an APT) to respond to requests from the customer order interface.
The delivery cxecuton engine 12 enables an end user to receive information from and transfer information to carriers. Data such as delivery instructions, status updates and carrier service information are automatically transmitted between the systems to provide complete delivery visibility and certainty. Where a user does not request a particular 15 service chain, the embodiment will select the best service chain for the parcel based on the criteria. The end user is able to use DEE 12 to configure their delivery services and '. to manage the allocation of carrier services.
: The carrier integration module 14 receives information from DEE 12 on delivery units ,,,, that are to be moved and provides the translation processes that are required to be able 20 to interface directly with the carriers' systems 20. The CTM 14 also receives and .. translates infonnation back from the carrier for transfer to DEE 12...DTD: The UPT Generator 16 provides a single point for the end user to derive UPI numbers and barcodes according to the rules defined by the individual carriers. This information allows the tracking of each parcel or delivery unit by the carrier, the business or the 25 customer.
The carrier label creation module 18 provides a reference database that defines how each of the carrier labels is set up. Carriers have conformed to common label dimensions and a common physical label, which simplifies the shipper's operational processes and costs by using a single process to prmt labels for all canters. Multiple 30 labels can be printed for each delivery allowing product delivery to be achieved by a series ol' delivery legs, each which could represent a difl'erent carrier. For example, a
package being delivered to an international location, may have three labels: a first for the carrier to take it to the airfreight company depot; a second to manage the international airfreight transaction, and a third for the local country carrier to effect final delivery to the customer.
5 The universal shipper adaptor 20 provides a layer, which allows users systems to link to the embodiment.
The universal carrier adaptor 22 provides a method to communicate to all carriers to which the embodiment links. Each carrier may a different mode of linking, and this adaptor processes the messages accordingly.
10 The universal shipper adaptor 20 and the universal carrier adaptor 22 provide the shipper with a means to use the embodiment to make use of a range of carriers efficiently without radically altering their existing systems.
The despatch manager 24 is an interface that allows the shipper to directly use the I'', embodiment to print labels, manifests and to otherwise interact with the delivery i. 15 system. This facility is specifically used where the shipper's system functionality Is .. insuff cent.
. The parcel enquiry 26 is an interface that allows a user to view all parcel details in one place for all carriers. This is available where the systems that are attached to the delivery system do not have this capability.
. -. 20Management infonnation 28 provides an interface, which is available to produce reports, where the shipper does not have a reporting function.
The principle steps performed by the system to facilitate delivery of a package are as follows: Identifies how a delivery to a customer or collection from a customer can be 25achieved using one or many potential carriers; Manages a common despatch process for all integrated carriers Interfaces delivery instructions to multiple carriers
Receives parcel status tracking messages; and Manages the achievement of each carrier according to SLA.
In the above process, the DOE l 0, the following operations arc performed: Delivery services arc set up to match the sales channel rcquircments; these 5 rcquirerments may include specification ol a nominated day or scheduled
dclvery, scheduled timeslot for delivery, pick-up and drop off points (PUDO), collection by a customer or delivered by the retailer's own delivery systems; Service availability and carrier capacity is assessed; Product characteristics and business preferences are assessed in the DOE 10 and 10 these arc then matched to delivery services; Required delivery date is matched with serviced geographical areas; and The despatch date required to achieve the requested delivery date is calculated " once the delivery mechanism is chosen.
,, ' '.. The DEE 12 performs the following functions: 1 1 1
15 Receives parcel delivery instmctons from the business' systems; , Requests a earner be allocated to a package, il not already assigned; ,,, . Translates delivery unit delivery instructions into delivery unit leg Information; Receives UPI and barcode information from the UPT (] cnerator 16 (or retailer system); 20 Breaks information down to carrier level and passes it to the CTM 14; Performs periodic validation of delivery details during the order process including, order commitment, pre warehouse processing and post despatch; Receives parcel status update infonnation front each carrier via the CIM l 4 and transfers on to the retailer systems; and
Provides ongoing visibility of the progress of all deliveries.
The Cll\] 14 pcrfonms the following functions: Rcccving cancer instructions from the multiple DEE 1 2s; Reformats DEE delivery instructions to match carrier spccificatons and transfer 5 the instruction to the carrier; In addition, CIM 14 works with the Universal Canrier Adaptor to: o channel all communication between the system and carriers; o reccve parcel status update messages from carriers and reformats to a consistent structure; 10 Transfers rcfonnatted parcel updates to the correct DEE system; and Manages the relationship with all carriers.
' The UPI Generator 16 performs the following functions: '' Receives a request tor a UPI (Unique Parcel Identifier) and barcode for a parcel ", to be transported by a carrier , 15 Calculates the UPl and barcode according to the carrier specification
i, Translers the calculated intonnation to the DEE Optionally requests the Carrier Label Creation module to print the correct carrier label and manifest using the requested printer pool Responds to the calling module with the barcode 20 Receives and transfers on requests for the Carrier Label Creation module to reprint specific labels.
The Carner Label Creation stage 18 performs as follows:
Receives an instruction to print a label for a package using a specific carrier format on a printer Builds the hnage that is required and sends it to the printer Receives an instruction to print a manifest for a specific carrier on a printer 5 Builds the manifest image that is required and sends it to the printer.
While the above components cooperate to implement this embodiment ol the invention, they interact with existhlg components to provide a complete solution for a user. These components will be described to aid understanding, but it should be clearly understood that they arc not central to the invention.
10 Users typically communicate with the system through one or more fi-ontend applications 30. There are potentially many different types of frontend application, tailored to suit the requirements of particular users. For example, a conventional order-
taking desk within a store acts as a front-end application 30 taking order details from customers. Other such front-end applications 30 are implemented as active Tnternet web 15 sites that provide information about products, so enabling a customer to place an order for a product. Likewise, the front-end application 30 could include a conventional telephone call centrc, which either receive calls from or make calls out to potential customers, and then take down an order that a customer wishes to place. As a further , example, a front-end application might be implemented In a retailer post room, which ... 20 receives customers' orders through the post and transcribes then1 into the system.
. . An order management system (OMS) 32 receives data describing orders to the retailer 1, that have been placed by customers so as to purchase goods. These data may come from multiple sources, including, but not limited to, a front-end application 30 and the DOE lo. The data typically includes information describing from where the retailer 25 will supply the goods, when they will be despatchcd, which carrier will move them from the warehouse, when it is expected that the goods will be delivered, where they will be delivered to, the value of the goods, the price that the customer has paid, the payment details that were used, etc. The OMS 32 may also contain historical information about various customers and orders that they have placed.
The system also Communicates with one or more warehouse management system (WMS) 34. Each WMS 34 has as a primary purpose to maintain knowledge of products that could be stored withy one or more warehouses 021 behalf of the retailer. The knowledge about these products typically includes: their physical characteristics and 5 attributes; the number in stock (including a breakdown n1to multiple categories such as free stock, reserved stock, frozen stock, held stock, the number that are currently on order and their expected delivery dates); and the physical location of each of group of items of each product within the warehouse. Information about customer orders is passed from the OMS 32 into the WMS 34, which then determines the various 10 characteristics and dimensions before performing a cartonisaton process. At the end of the cartonisaton process all of the various products on a single customer order have been assigned to specific theoretical packages. The WMS 34 will then print picking tickets for warehouse staff to direct them to pick the various products that are required for each package. Once all of the items lor a package have been collected and a 15 physical container has been obtained for those products, an invoice is printed for the customer and the label Is printed for attaching to the exterior of the package. These tasks can in fact be performed in multiple permutations according to the desires of the retailer. The WMS 34 also manages the receipt back into stock of packages that are returned by the various customers.
20 The various components of the delivery management system produce large quantities of information about packages and their progress towards delivery to the customer. Data ". such as this is recorded in order to respond to queries from retailers or customers. The management information module 28 handles this. In the process of recording this . information, a large amount of control information is built up about the perfonnance of 25 the carriers who are delivering those packages, the warehouses that are handling the packages prior to despatch, and so forth. The management information module 36 . enables the retailer to drill down into the large mass of information and extract specific subsets that summarise the overall picture.
To illustrate the process by way of example, the typical lifecycle of a parcel is outlined 30 below. This Is relevant to a shipper embodhnent of the invention, which uses a wide range of functions of the embodiment.
Step 1. As part of the order-taking process, the front-end application 3() requests a delivery option from the system. This will occur via the "delivery options request" (A) message. The DOE 10 will respond with a "dehvery options response" message (B).
This provides a list of all service chains that meet that can meet the delivery 5 requirements, parcel requirements and the shipper's preferences as to how that type of parcel can be delivered. In some cases, a secondary delivery options request (A2) and delivery options response (B2) is issued where the next level ol delivery options are requested. This provides the additional level of information that is required by the customer to enable them to make a choice from the available selection. for example, 1() theprimary request could result in a choice of delivery options such as Next Day, Standard Delivery, PUDO (pick-up drop-off point) . If the customer chooses PUDO, the front-end application 30 may ask DOE 10 via the secondary request to provide a list of all PUDOs that are within a certain distance of the delivery postcode.
In some embodiments of the invention, Step I may not be required. In these cases, DEE 15 12 allocates the most preferred of all service chains to the parcel.
Step 2. The delivery system receives the "new parcel"(E) message from the WMS 34.
The details received on this message may include: delivery point name and address, contact details, requested delivery service, requested delivery date and special delivery instructions (SDI) - manual or system-generated. This enables the DEE 12 to manage .. 20 the parcel details. The DEE 12 also manages regular validation of parcel delivery tin1e and delivery service is appropriate. This is important in embodiments where the order is placed some time before despatch. The source of the validation requests may be À., internal to the system, or may cosine externally from the WMS 34 or OMS 32, via a ,,,, validation request (C). The validation response (D) types to the validation requests 25 include: I) yes the selection is still valid; 2) the selection of the service chain is valid but the delivery date cannot be achieved and here is the earliest date that can be achieved; 3) the selection of the service chain is not valid but here Is an alternative service chain which can meet the criteria and is of the same service; 4) the selection of the service chain Is not valid but here Is an alternative service chain which can meet the 30 product criteria although not the delivery date, and is of the same service and here is the delivery date that can be achieved; and 5) the selection of the service chain is not valid and there is no altematve service chain that can meet the cistern.
Step 3. The embodiment will respond with "parcel code response" (F), which provides a UPT number to the WMS 34. T his request may originate from the WMS 34 or 1rom the embodiment. This enters the UPIG 16, which reviews all of the infonnation provided by the WMS 34, and builds a barcode and UPI number for the carrier that will 5 collect the package from the warehouse, according to rules provided by the carrier, and returns these two fields to the WMS 34 for logging against that package.
Step 4. The WMS 34 may then request a label through the "parcel label request" (G) message. The WMS 34 provides information on the printer that Is to be used and either the WMS carton number, the barcode or a delivery partner idcutifier. UPIG 16 builds a 10 allocation of data that is passed to the CLC module, which provides all of the information required to print that label. A "label print" (H) message is sent to the printer to print labels.
Step 5. When the parcel is ready to despatch, the system fonnulates a message via the CIM 14 to send an "electronic manifest" (1) to the specific carrier system 36. The CIM 15 14 ensures that the message conforms to the requirements of the specific carrier's systems. The UPIG 16 will also collate all of the information that is required to build a paper manifest of all packages currently ready for despatch with that delivery partner.
The collated information will then be formatted appropriately and directed at the printer that was specficd on the message request Irom the WMS.
20 Step 6. The carrier sends back regular "parcel status update" (J) from their carrier ' system 36. This may occur as often as the carrier specifies it...DTD: ., Step 7. The embodiment then passes back (via the DEE) the translated "parcel status update" message (K) to the OMS 32. The DEE 12 builds messages for the OMS, which messages individually identify every package that has changed status as a result of information provided by the carrier. The contents of this message are the retaler's identifier for the package, the parcel barcode, the status code that the retailer uses to reflect the new position, the status codes provided by tile carrier to indicate the changed status, the depot id for the carrier that provided the status update and the date and tine at which the status update occurred.
In less sophisticated operational environments, the embodiments of the Invention may allow the shipper to manage the process without a direct link to a WMS or OMS, mu the dcspatch manager 24 and Parcel Enquiry 26.
. , À. I
Claims (13)
1. A delivery management system for managing distribution of packages by . . 5 ean-'ers, comprsmg: a. a shipper stage with which a shipper can interact with systems that execute a package delivery; b. an allocation stage operative to determine the preferred delivery mechanism for the package delivery procedure; c. a despatch stage operative to generate where parcel carrier specific documents; and d. a carrier stage for interfacing with a parcel carrier to send data to the cattier and receive data from the carrier relating to the delivery procedure. 15
2. A delivery management system according to claim I further comprising a management information stage to record and/or analyse data on the performance 0 I carriers.
. ...
3. A delivery management system according to claim 2 in which the management information stage is operable to create reports to enable a user to monitor and ' ' 20 analysc performance of carriers...CLME:
4. A delivery management system according to any preceding claim m which information can flow through the system from the shipper to the carrier and from the carrier to the shipper.
5. A delivery management system according to any preceding claim in which a 25 user can receive mfonnation about mdvidual deliveries handled by various carriers through the consistent interface provided by the carrier stage.
6. A delivery management system according to any preceding claim in which the shipper stage can be integrated with an existing computer used by the customer.
7. A delivery management system according to any preceding claim in which the allocation stage is operative to select an optimum caTicr for dehvcry of any 5particular package.
S. A delivery management system according to claim 7 in winch the carrier is selected on the basis of one or more of the dehvcry address the nature of the contents of the package the lead time by which the package is required the time of day required for delivery amongst other considerations.
109. A delivery management system according to any preceding claim in which the carrier stage operates to communicate with computer systems operated by one or more caTicrs.
10. A delivery management system according to any preceding claim in which the documents generated by the despatch stage include carrier labels and carrier 1 5manifests.
11. A delivery management system according to any preceding claim operating m cooperation with a front-end stage that receives requests to handle a package.
. . À
12. A delivery management system according to any preccddlg claim operating in cooperation with a warehouse management system that maintains intonnation 2()about products to be delivered orders that the products belong to and the stage . of processing in the warehouse environment.
,,
13. A delivery management system substantially as herein described with reference to the accompanying drawings.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0225180A GB0225180D0 (en) | 2002-10-30 | 2002-10-30 | Distribution system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| GB0325242D0 GB0325242D0 (en) | 2003-12-03 |
| GB2394814A true GB2394814A (en) | 2004-05-05 |
Family
ID=9946808
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB0225180A Ceased GB0225180D0 (en) | 2002-10-30 | 2002-10-30 | Distribution system |
| GB0325242A Withdrawn GB2394814A (en) | 2002-10-30 | 2003-10-29 | Delivery management system |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB0225180A Ceased GB0225180D0 (en) | 2002-10-30 | 2002-10-30 | Distribution system |
Country Status (1)
| Country | Link |
|---|---|
| GB (2) | GB0225180D0 (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5043908A (en) * | 1989-10-03 | 1991-08-27 | Pitney Bowes Inc. | Mail delivery system with arrival monitoring |
| WO2000046726A2 (en) * | 1999-02-05 | 2000-08-10 | United Parcel Service Of America, Inc. | Special handling processing in a package transportation system |
| WO2000065499A1 (en) * | 1999-04-27 | 2000-11-02 | Woorigisool Inc. | Apparatus and method for delivering a parcel |
| WO2001088805A1 (en) * | 2000-05-15 | 2001-11-22 | Catalog City, Inc. | Internet-based systems and methods for facilitating shipment of goods |
| US20020016726A1 (en) * | 2000-05-15 | 2002-02-07 | Ross Kenneth J. | Package delivery systems and methods |
| GB2368933A (en) * | 2000-11-08 | 2002-05-15 | 430Am Ltd | Delivery enquiry processing |
| US20020128924A1 (en) * | 2000-12-09 | 2002-09-12 | Walter Rosenbaum | Method of ordering and dispatching articles |
-
2002
- 2002-10-30 GB GB0225180A patent/GB0225180D0/en not_active Ceased
-
2003
- 2003-10-29 GB GB0325242A patent/GB2394814A/en not_active Withdrawn
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5043908A (en) * | 1989-10-03 | 1991-08-27 | Pitney Bowes Inc. | Mail delivery system with arrival monitoring |
| WO2000046726A2 (en) * | 1999-02-05 | 2000-08-10 | United Parcel Service Of America, Inc. | Special handling processing in a package transportation system |
| WO2000065499A1 (en) * | 1999-04-27 | 2000-11-02 | Woorigisool Inc. | Apparatus and method for delivering a parcel |
| WO2001088805A1 (en) * | 2000-05-15 | 2001-11-22 | Catalog City, Inc. | Internet-based systems and methods for facilitating shipment of goods |
| US20020016726A1 (en) * | 2000-05-15 | 2002-02-07 | Ross Kenneth J. | Package delivery systems and methods |
| GB2368933A (en) * | 2000-11-08 | 2002-05-15 | 430Am Ltd | Delivery enquiry processing |
| US20020128924A1 (en) * | 2000-12-09 | 2002-09-12 | Walter Rosenbaum | Method of ordering and dispatching articles |
Also Published As
| Publication number | Publication date |
|---|---|
| GB0225180D0 (en) | 2002-12-11 |
| GB0325242D0 (en) | 2003-12-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6571213B1 (en) | Router utility for a parcel shipping system | |
| US7725406B2 (en) | Systems and methods for international shipping and brokerage operations support processing | |
| US7536321B2 (en) | Estimated time of arrival (ETA) systems and methods | |
| US5758329A (en) | System for managing customer orders and method of implementation | |
| US8650132B2 (en) | System and method for distribution of single-product-type unlabeled packages | |
| US20030009396A1 (en) | Tracking and electronic signaling system | |
| US6970825B1 (en) | Planning engine for a parcel shipping system | |
| JPH1131177A (en) | Home delivery system | |
| US20050055260A1 (en) | Distribution management system | |
| JP3479881B2 (en) | Strategic Alliance Information Management System | |
| US6957197B1 (en) | Load planning tables for a parcel shipping system | |
| US20030009398A1 (en) | Computer system for goods management in a stock company | |
| US20030004839A1 (en) | Computerized automatic management system and method for logistics control | |
| EP1221668A2 (en) | System for matching clearance information and for managing cargo information | |
| KR20020052973A (en) | Delivery system, and various service request receipt and transaction method using network | |
| AU2003212308B2 (en) | Supply chain fulfillment coordination | |
| JPH1087036A (en) | Inventory allocation method in distribution system, and method of determining delivery form and inventory position | |
| US20060085241A1 (en) | Decentralized warehouse management | |
| US20200286027A1 (en) | System and methods for last mile delivery of goods | |
| GB2394814A (en) | Delivery management system | |
| KR102720233B1 (en) | System For Allocating Product | |
| Mallya | Demand-driven production and distribution: Seamless integration of downstream supply chain decisions using electronic data interchange | |
| CN115829507A (en) | Multi-informatization integration system | |
| JP2004262663A (en) | Network using delivery system and method for receiving request of delivery desire date | |
| JP2004269264A (en) | Network using home-delivery system and slip issuing method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |