WO2000021010A9 - Systeme de gestion d'expedition - Google Patents

Systeme de gestion d'expedition

Info

Publication number
WO2000021010A9
WO2000021010A9 PCT/US1999/023176 US9923176W WO0021010A9 WO 2000021010 A9 WO2000021010 A9 WO 2000021010A9 US 9923176 W US9923176 W US 9923176W WO 0021010 A9 WO0021010 A9 WO 0021010A9
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
information
order
host
dispatch
Prior art date
Application number
PCT/US1999/023176
Other languages
English (en)
Other versions
WO2000021010A1 (fr
Inventor
Larry D Bass
Original Assignee
Dealers Transport Ltd
Larry D Bass
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Dealers Transport Ltd, Larry D Bass filed Critical Dealers Transport Ltd
Priority to CA002345113A priority Critical patent/CA2345113A1/fr
Publication of WO2000021010A1 publication Critical patent/WO2000021010A1/fr
Publication of WO2000021010A9 publication Critical patent/WO2000021010A9/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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

Definitions

  • the present invention relates generally to managing collection and delivery of vehicles, and particularly to collection of vehicles from multiple locations for disposition through a dispatching system.
  • a system and method of managing the collection and delivery of vehicles can include one or more of the following features: providing a dispatch management system using a computer and software for maintaining and updating information on the status of the vehicles identified for disposition through the system; providing for coupling terminals to the dispatch management system from remote locations, such as order entry terminals at remote customer locations coupled by a communication link such as the world wide web; recording time stamps for one or more transactions in the process, such as a time of initial identification of a vehicle for collection, a time at which a vehicle is ready for collection from a remote location, a time at which a dispatch request for a vehicle was made, a time of actual dispatch of a vehicle, at time of arrival of a vehicle at a destination location, etc.; providing one or more identifiers for a vehicle being processed through the system, such as a transaction number and/or a waybill number, etc; defining a dispatch status for a vehicle that is indicative of the status of the vehicle, such as
  • a dispatch management system maintains information on the status of vehicles.
  • the system includes a host and at least one terminal coupled to the host for the entry of an order for the dispatch of a vehicle.
  • a method for maintaining information on the status of vehicles includes providing a dispatch management system host and at least one terminal coupled to the host for the entry of an order for the dispatch of a vehicle.
  • the at least one terminal includes at least one order entry terminal.
  • the information includes a time stamp for indicating when a transaction is ordered by a customer. Additionally illustratively, the information includes the status of the order.
  • the information includes whether placement of the order by the customer is complete. Further illustratively, the information includes whether the vehicle can be driven.
  • the information includes whether the vehicle must be towed.
  • the information includes whether a key for operating the vehicle is available.
  • the apparatus and method include apparatus for, and the step of, generating machine-readable code and/or scanning machine-readable code for correlating vehicle information and/or updating vehicle information.
  • the apparatus and method include apparatus for, and the step of, creating at least one of a waybill, a bill of lading, an invoice, and an identifier for the vehicle.
  • the at least one terminal is coupled to the host for the entry of an order by a customer.
  • the information on the status of a vehicle includes at least one of: a transaction number; a waybill number; who authorized the order; who placed the order; the orderer's account number; the orderer's reference for the transaction; where the vehicle is located; where the vehicle is to be delivered; when the order was sent to dispatch; when a driver was dispatched to pick up the vehicle; the driver's identity; the vehicle's identity; information on the vehicle's fuel; information on the vehicle's lubricant; vehicle odometer data at the point of origin; vehicle odometer data at the destination; when the vehicle was delivered to the destination; the identity of the recipient; and, the dispatch status of the vehicle.
  • the vehicle's identity includes at least one of: a vehicle identification number; the year of the vehicle; the make of the vehicle; the model of the vehicle; and, the color of the vehicle.
  • the terminal for the entry of an order for the dispatch of the vehicle includes a terminal for updating the dispatch status of the vehicle.
  • the information on the status of the vehicle includes the assignment of a driver for collection of the vehicle.
  • the terminal for the entry of an order for the dispatch of the vehicle includes a terminal for at least one of generating order confirmation and transmitting order confirmation.
  • At least one of the host and the terminal includes means for generating at least one of statistics and reports from information collected by the system.
  • the host includes information from which a driver can be assigned.
  • the host includes a host for at least one of creating a visual indication based on a criterion and displaying a visual indication based on a criterion.
  • the host includes a host for automatically changing information based on a criterion.
  • the host includes a host for searching for information based on a criterion.
  • the host includes a host for identifying individuals who modify stored information. Further illustratively, the host includes a host for controlling access to the system for changing information stored in the system.
  • Fig. 1 illustrates a screen which is generated by a computer on which a dispatch management system according to an embodiment of the invention is run and displayed on a monitor associated with the computer
  • Fig. 2 illustrates another screen which is generated by a computer on which a dispatch management system according to an embodiment of the invention is run and displayed on a monitor associated with the computer
  • Fig. 3 illustrates a process flow for order entry according to an embodiment of the invention
  • Fig. 4 illustrates a process flow for dispatch according to an embodiment of the invention.
  • the illustrated system is able to run on Windows NT version 3.51 or 4.0 and Windows 95.
  • the illustrated system is designed to be fault tolerant for continuous operation. It is capable of displaying all dialogs within twenty seconds of activation. As configured, for maximum performance it requires 32 MB of RAM and an Intel Pentium processor.
  • Actor means any agency that interacts with the system. All actors are provided with security privileges appropriate for the duties performed within the dispatch management system by each actor. The actor represents a role played by a person or other system component. In order to act within the dispatch management system, an actor must have first logged onto the dispatch management system and navigated to the main control window of the dispatch management system. "Dispatch management system” means the software application itself. To start the dispatch management system, an actor must run the file DMSDTL.exe. A "dispatched screen" contains two tables, illustrated in Fig. 1 as grids. The upper table displays the orders sent to dispatch. The lower table displays orders that have been dispatched but are not yet completed.
  • a “generate reports form” display is a display of all available reports to preview or to print.
  • a “main control window” is a window that is opened after an actor runs the software and logs onto the dispatch management system. The main control window contains the menu bar and toolbar that permit users to initiate all major system activities.
  • a “maintain accounts form” contains all related information for customer accounts.
  • a “maintain users screen” contains all related information for the user system accounts, such as user name, password, security access rights, and so on.
  • a “maintain DMS settings form” contains all options available for dispatch management system configuration and permits the system administrator to modify and save system parameters.
  • An “order form” contains all related information for an order. An illustrative order form according to the invention is illustrated in Fig. 2.
  • An “order search form” contains a grid view of the orders list with columns that display searchable fields.
  • a “pre-condition” of a use case is the state in which the system must be prior to performance of a use case.
  • a “post-condition” of a use case is the state in which the system will be immediately after performance of a use case.
  • a “requisitioner” is an entity that places a pickup request. The requisitioner's name is captured in the "order by" field of an order form. An actor selects a requisitioner from the stored list that is maintained by the system administrator.
  • a “special requirement” is a non-functional requirement that is specific to a use case but is not easily or naturally specified in the text of the use case's event flow.
  • a "splash screen” is the screen that appears for a brief interval, illustratively three seconds, after an actor has launched the dispatch management system.
  • a "supplementary requirement” is a non-functional requirement that is common to all use cases in a dispatch management system. Examples of supplementary requirements include performance, usability, reliability and supportability requirements.
  • a "use case” is a sequence of actions that a dispatch management system performs that yields an observable result of value to a particular actor. The following actors may interact with the dispatch management system.
  • a "dispatcher” receives orders from order entry personnel, reviews the orders, and has the ability to sort orders.
  • a dispatcher may sort orders by, for example, date and time ordered, vehicle identification number or NIN, point of origin including address, destination, drivable or tow status, and date and time dispatched.
  • the dispatcher is capable of making updates to order data.
  • the dispatcher assigns a lead van driver.
  • the dispatcher prints bills of lading in appropriate quantities, one for each vehicle, for lead van drivers.
  • the dispatcher receives the valid order after the order entry person presses the save button or presses a shortcut key to save an order, or after the order entry person presses the "send to dispatch" button on the order form.
  • "Order entry personnel" receive pickup requests from vehicle sources, such as vehicle factories, vehicle dealers, and the like. Order entry personnel enter order data. Order entry personnel verify with vehicle sources that vehicles are ready for pickup.
  • Order entry personnel transmit confirmations, for example, by facsimile, to vehicle sources of their orders. Order entry personnel send orders to dispatch. Order entry personnel can initiate the basic flow and all alternative flows of the "manage orders" use case.
  • a "lead van driver” accepts a quantity of bills of lading from a dispatcher and assembles an appropriate number of drivers.
  • a "system administrator” maintains all configuration parameters of the dispatch management system and user accounts.
  • the use case model is described by the following descriptions.
  • the "manage orders" use case is initiated by an order entry person to create a new order, review an existing order, modify an existing order, cancel an existing order, find an existing order, send confirmation of an order to a vehicle source, and send an order to dispatch. Actors can initiate the basic flow and all alternative flows of the "manage orders" use case.
  • the "manage orders” use case starts when an order entry person opens an order form.
  • the order form contains the status of the order. It indicates whether the call placing the order is completed. It indicates whether the vehicle is drivable, whether keys are available, and whether data on the vehicle has been ordered.
  • the order form identifies the transaction number and the waybill number.
  • the order form indicates who authorized the order, who placed the order, the orderer's account number and the orderer's reference name/number.
  • the order form indicates the origin, that is, where the vehicle is, including a contact name, telephone number, and the name and address where the vehicle is to be picked up.
  • the order form indicates the destination, that is, where the vehicle is to be delivered, including the name, address and telephone number.
  • the order form also identifies the date and time the order was sent to dispatch, the date and time a driver was dispatched to pick up the vehicle, the driver's identity, typically by a driver number, the last eight characters of the NTN, and the year, model and color of the vehicle.
  • a field is provided on the order form for comments.
  • the order form indicates how much fuel is in the vehicle, whether it has sufficient lubricant, the odometer mileage at the point of origin, the odometer mileage at the destination, the date and time the vehicle was delivered at its destination, and the identity of the recipient. If no activity is selected by the order entry person, the order form displays the current saved order for review. When the order form is opened, it displays the first saved order, or a blank order if no orders have been saved. The order entry person can navigate to the first, last, next and previous orders using toolbar buttons and shortcut keys.
  • the dispatch management system displays the available activities and permits the user to select: “add new” (to create a new order); “edit” (to modify an existing order); “find” (to locate an existing order); “cancel” (to cancel an existing order); “fax confirmation” (to facsimile transmit to a vehicle source confirmation of an order); and “send to dispatch” (to transmit an order to dispatch).
  • the dispatch management system disables all other action selection until the transaction is completed. The user is able to save or cancel an order.
  • the dispatch management system generates a waybill number, or transactional sequence number, and date ordered. These fields are read only.
  • the dispatch management system enters the name of the user who is logged on in the "authorized by" field of the order form, and enters the default destination's full address. The user can edit the default destination's address field.
  • the user must then complete the "order by" field by selecting from the requisitioners list, the reference name, the account number, the origin fields including contact name, and search for the origin phone number in the account table. If the account exists in the account table, the dispatch management system fills in the name and address fields. Otherwise, the user must fill in the name and address fields, after which the dispatch management system adds a new origin account record when the order is saved on the dispatch management system.
  • the user adds the last eight characters of the NIN, and the year, make and model of the vehicle.
  • the user can edit or update the "is call required" field, the "status” field, the "drivable” field, the "keys” field and the color field. The user then chooses either to save the order or cancel it.
  • the system validates required fields, adds a time stamp, and saves the order information. The order appears on the dispatch screen. The "manage orders" use case begins again.
  • the dispatch management system informs the user that one or more required fields have been left blank. The user can then enter the necessary information and save the order or cancel the order. If the value of the "is call required" field is "yes” or the value of the "status” field is not “ready” or the value of the "drivable” field is null or the value of the “drivable” field is null or the value of the "keys” field is null, the order status is set to pending. The user is informed that the order has been saved as pending, and the system displays the order on the pending screen. If the user wishes to cancel an order, the user presses the cancel button or shortcut key. The system asks the user to confirm the cancel order instruction. If the user confirms, the order status is changed to "canceled.” The "manage orders" use case begins again.
  • the user may modify an order by clicking either the modify button on the order form or on the toolbar, or by using a shortcut key.
  • the dispatch management system inhibits editing of: the destination address fields; the reference name; the account number; the contact name; the phone number; the last eight characters of the NIN; the year, make and model; the "is call required” field; the "status” field; the “drivable” field; the "keys” field; and the "color” field.
  • To update the order fields the user places the cursor in the field to be updated using the tab key or mouse.
  • the dispatch management system permits editing when a valid editing field is selected. After editing, the user presses the save button or a shortcut key.
  • the user may find an order by clicking either the find button on the order form or on the toolbar or by using a shortcut key.
  • the order search form opens as a modal dialog window containing a grid view of the orders list with columns that displays searchable fields.
  • the searchable fields are: waybill number; date ordered; origin name; reference name; account number; and last eight characters of the NIN.
  • the user can change the sort order by pressing the tab key and selecting an active column.
  • the user can navigate back and forward by pressing arrow up and arrow down keys or using the mouse.
  • the user can do incremental searching on the active field by typing on alphanumeric keys.
  • the "manage orders" use case begins again.
  • the user can send facsimile confirmation by clicking the "send fax" button on the order form.
  • the dispatch management system generates a text file that contains waybill number, date ordered, "authorized by,” “ordered by,” full address of origin, lead driver, full address of destination, reference name, account number, contact name, last eight characters of the NIN, year, make, model and color, and special instructions. This file is then printed to the facsimile printer.
  • the facsimile printer can be a fax modem with a printer driver, or a printer assigned as the facsimile printer by the system administrator.
  • the "manage orders" use case begins again. Order entry personnel can send an order to dispatch by clicking the "send to dispatch" button on the order form.
  • the dispatch management system validates the required fields, changes the order status to "ready,” adds a date and time stamp, and saves the order information. If the system detects the field “is call required” set to “yes,” the order status is "not pending,” the “drivable” field is empty, or the “keys” field is empty, it disables the “send to dispatch” button, and the "send order to dispatch” button is disabled.
  • the system permits the "send order to dispatch” action if the order status is "pending,” the field “is call required” is set to "no,” the field “drivable” is set to "drive” or “tow,” and the field “keys” is set to "has keys” or “no keys.” The valid order appears on the dispatch screen. The "manage orders" use case begins again. Order entry personnel can cancel an order by clicking either the
  • Fig. 3 An illustrative process flow for order entry is illustrated in Fig. 3.
  • Pickup requests are received from various factories and other entities and might include activities such as facsimile receipts for orders, computer generated orders, courier service-delivered orders, and so on.
  • Information entered in the order form is derived from these pickup request documents.
  • the availability of one or more vehicles is verified with the vehicle's (s') source, for example, an automobile dealership, by telephone contact with the source. Specific information is elicited during such telephone contact, for example, is the vehicle ready, is it drivable, must it be towed, are keys available, and so on, as well as the identity of the person who is providing the information concerning vehicle readiness.
  • s' vehicle's
  • Specific information is elicited during such telephone contact, for example, is the vehicle ready, is it drivable, must it be towed, are keys available, and so on, as well as the identity of the person who is providing the information concerning vehicle readiness.
  • the order form includes fields for the entry of the reasons why, and the request is characterized as "pending,” and cannot be dispatched until resolution of all of the readiness criteria.
  • the dispatch management system premits a facsimile confirmation to be provided to the source of the order. This confirmation is intended to reduce wasted effort dispatching personnel to pick up vehicles which cannot be picked up.
  • the facsimile confirmation includes specific language relating to the readiness of the vehicle and confirms the telephone conversation between dispatch management system personnel and the contact who ordered the pickup. This facsimile confirmation is believed best achieved using a fax modem in order to make it as effortless as possible.
  • Orders are sent to dispatch by order entry personnel after completion of the required fields of the order and confirmation between dispatch management system personnel and the contact who ordered the pickup that the vehicle is ready for pickup.
  • the paperless order is sent to dispatch by clicking on a designated command.
  • the command to dispatch is date and time stamped.
  • the "dispatch" use case is initiated by a dispatcher to assign lead drivers, review orders and enter delivery times for completed orders. This use case is initiated by the dispatcher opening the dispatch form illustrated in Fig. 1.
  • a dispatcher can initiate the basic flow and all alternative flows of the "dispatch orders" use case.
  • the dispatch form contains two table grids. The upper grid displays the orders that have not been dispatched. Order status is "ready" or
  • the grid contains columns assigned to: transaction number; address of origin; whether the vehicle is drivable; the time ordered; the destination address; the make; the model; comments; the identity of the lead driver; the time dispatched; and the status. Orders that have "pending" status and having less than seventy-two hours since the transaction was initiated are displayed with grey background. Pending orders having seventy-two or more hours since the transaction was initiated are highlighted. Orders having "ready” status are displayed with white background. The lower grid displays orders that have been dispatched but have not yet been delivered. These orders have "dispatched" status. This grid contains the same columns as the upper grid, and includes a "time delivered” field. These orders are displayed with white background.
  • the dispatcher places the cursor in the "lead driver” field to enter a driver number.
  • the dispatcher can then select the next record using the mouse or an arrow key, and enter a driver number again.
  • the dispatch management system enters the "time dispatched” field with the current date and time and updates the "status” field value to "dispatched.”
  • the dispatcher clicks on the "save” button.
  • the system commits the changes to the "order” table and refreshes the order form.
  • the orders that have been dispatched are displayed in the lower grid. New orders that have been entered since the last transaction appear in the upper grid.
  • the "dispatch orders" use case begins again.
  • the dispatcher can change the sort order of the "not dispatched" orders by selecting one of the following options: origin name; destination name; or, time ordered.
  • the dispatch management system refreshes the data in the grid and changes the sort order of the order records by the selected field.
  • the "dispatch orders" use case begins again.
  • the dispatcher can change the sort order of the "not yet delivered” orders by selecting one of the following options: origin name; destination name; time ordered.; time dispatched; or, lead driver.
  • the dispatch management system refreshes the data in the grid and changes the sort order of the order records by the selected field.
  • the "dispatch orders" use case begins again.
  • the dispatcher can enter the delivery date and time by selecting the order to be edited in the lower grid and entering the date and time when the vehicle was delivered.
  • the dispatch management system updates the status field to "completed.”
  • the dispatcher can double click on the "delivery time” field to fill in the current date and time.
  • the dispatcher clicks on the "save” button.
  • the dispatch management system then commits the changes to the "order” table and refreshes the form. Orders that have been delivered are not displayed. Orders that have been dispatched since the last transaction appear in the lower grid.
  • the "dispatch orders" use case begins again. To close the dispatch form, the dispatcher clicks on the "close” button on the form or uses a shortcut key.
  • the dispatcher is asked to save changes. If the dispatcher selects "save,” the dispatch management system commits changes to the database before closing the form. Otherwise, the changes are not saved.
  • the "dispatch orders" use case ends.
  • the dispatcher may assign drivers to orders with pending status.
  • the dispatch management system discards unsaved changes and sets the unsaved driver status to zero.
  • the dispatcher may revoke a driver assignment on an order that has been dispatched but has not yet been committed by changing the driver number to zero.
  • the system resets the order status to "ready" and the time dispatched to null.
  • the "dispatch order" form can be closed by the dispatcher clicking on the "close” button or using a shortcut key.
  • the dispatcher is asked to save changes to the dispatch order form. If the dispatcher selects the "save” option, the system will save the updates before closing the form. Otherwise, changes will not be saved.
  • An illustrative process flow for dispatch is illustrated in Fig. 4.
  • a dispatcher received orders from order entry personnel. The order appears on the dispatcher's screen. The dispatcher reviews the dispatch screen on an ongoing basis, typically sorting orders by various methods, such as ordering entity, location, date of order, and so on. Dispatch information may be created for consignment orders. Information such as "call for residential pickup" may also be added.
  • the dispatcher assigns lead van drivers to pick up vehicles based on different criteria, such as van size, familiarity with a particular location or dealership, and so on.
  • the dispatcher will add this information to the dispatch screen.
  • the dispatcher will print bills of lading in appropriate quantities, one for each vehicle, for the lead van drivers.
  • the bills of lading typically will be provided with bar code decals for use in later identification and tracking of vehicles.
  • the lead van drivers travel to the vehicle points of origin, locate the vehicles to be transported, apply the appropriate bar code decals to these vehicles, note particular information on the vehicles themselves, for example, on the driver's side windshields of the vehicles, inspect the vehicles, leave copies of the appropriate bills of lading inside the vehicles, and assign drivers to transport the vehicles.
  • the drivers then transport the vehicles to the auction gate for check-in.
  • a remote bar code scanner located at the check-in station scans the code bars on the decal previously applied by the lead driver, the vehicle is entered into the auction's data base, and the entry is time and date stamped.
  • the driver returns a copy of the bill of lading for the vehicle he or she has transported to the billing clerk along with any ancillary charges such as fuel, oil, change in tow/drive status, and so on.
  • the clerk reviews the bills of lading and applies appropriate charges to approved accounts.
  • the billing clerk then prepares invoices. These typically will be prepared within twenty-four hours of delivery, and will include particular information, such as a summary of the vehicles picked up, delivered, vehicle identification numbers, and so on.
  • the dispatch management system permits the customer to determine online the status of an order. This ability results in significant time savings and permits customer personnel who otherwise would have to expend considerable effort tracking orders to engage in more productive activities, such as tracking soon-to-expire leases and so on.
  • the Internet version of the dispatch management system permits the customer to print reports on the current status of the customer's business. With a user i.d. and password, the customer can determine the status and disposition of vehicles in the customer's inventory essentially in real time. For example, at an automobile auction, dispatchers can monitor many orders which can be sorted by, for example, zip code, city or state. This permits dispatchers to work logistically much more efficiently than prior art manual systems would permit.
  • the Internet activity permits multiple auctions to reside within the same database through a server, thereby achieving the logistical efficiency of a single location.
  • a team of dispatchers for example, can study the dispatch management screens and watch multiple auctions for logistical efficiencies, so that resources such as people and trucks retrieving automobiles being auctioned can be utilized with minimum waste.
  • Dispatchers will be afforded many more opportunities to put together efficient runs to transfer automobiles.
  • the user can create databases of how vehicles move through the process and how buyers and sellers handle these vehicles.
  • a user can watch various auctions to determine how long it takes, for example, for a particular auction to retrieve vehicles as compared to other auctions, and correlate this data with, for example, auctions' locations. The user can then factor in other elements that may affect an auction's efficiency. This provides the user with a management tool that helps the user to know where to focus efforts to improve auction efficiency.
  • the dispatch management system also permits users to create their own reporting through the dispatch management system's reporting features. This permits users to respond and be proactive with their customers from a management standpoint. It permits users to compare the success of various auctions whose success they wish to evaluate, for example, according to a number of different criteria by which the dispatch management system is capable of sorting.
  • the dispatch management system also contemplates a scanning operation having multiple options.
  • a vehicle can complete its cycle in the dispatch management system software, by manually clearing the vehicle if user personnel have first-hand knowledge that the vehicle is there, or a vehicle can complete its cycle by scanning.
  • Scanning can be in the form of hand scanners stationed at various entry and exit points to and from an auction, or stationary scanners, to read bar codes applied to the cars.
  • a vehicle could trigger a bar code scanner to begin interrogating the vehicle for a bar code when the vehicle drives over, for example, an entry and exit coil or metal detector.
  • a vehicle could interrupt a beam of an infra-red system to trigger a bar code scanner to begin interrogating the vehicle for a bar code.
  • a computer running the dispatch management system would conduct a query whether the code is a valid code for that destination. This happens very quickly. If the code is a valid code, the driver would enter an identity, for example, by using a machine readable identification card, for example, a proximity card, or by entering a thumb print or the like. This would credit the driver for moving that car.
  • a light at the arm gate would change from red to green and a computer located in close proximity would send a signal to the arm gate.
  • the arm gate would open and permit the vehicle to pass through, after which the arm gate would close again.
  • the bar code also permits an entry/exit station i.d. to be transmitted so that a vehicle, once it is logged in to an auction, could pass through other stations having their own unique i.d.'s or bar code reading functions, such as hand scanners, at, for example, a body shop or a reconditioning shop. Amounts allocated to specific cost/price functions could then be fed to a central computer and posted as charges to a particular car. This feature can also be used for locating vehicles within a facility.
  • an auction can restrict lanes so that vehicles pass through the restricted lanes in facility parking areas and pass scanners of the general types previously described at various locations in the parking areas, providing indications of where the vehicles are within the facility.
  • An illustrative system thus permits a user to: view and edit shipment data; maintain a consignor database; keep records; provide instant access to records; virtually eliminate handwritten orders; provide immediate knowledge of the locations of vehicles; whether personnel have been dispatched to retrieve vehicles, and the status of those dispatched orders; obtain complete order entry, for example, account number, reference, orderer's name, and so on; obtain alerts concerning pending pickups and incomplete orders; have instant access to proof of delivery; virtually immediate confirmation of orders; print statistical reports; save labor in taking orders; and, provide checks on vehicle log-in, maintenance and inventory processes.
  • Illustrative hardware shares an existing network with OS NT 3.51 or higher. It can use a separate server and share existing lines. It uses code 39 bar code scanning equipment. It can use remote hard wired or RF scan guns. It has a 33.6 K or faster modem, an SVGA monitor with 600 x 800 resolution, and a backup tape drive of 2 GB or higher capacity.
  • An illustrative server has 64 MB RAM, 50 MB disk space and a 4.3 GB hard drive.
  • Illustrative clients have 16 or 32 MB RAM, 50 MB disk space and 2.1 GB hard drives.

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)
  • Traffic Control Systems (AREA)

Abstract

L'invention concerne un système de gestion d'expédition mettant à jour des données sur le statut de véhicules. Le système comprend un dispositif hôte et au moins un terminal couplé au dispositif hôte et destiné à permettre d'entrer une commande d'expédition de véhicule. L'invention concerne également un système de mise à jour de données sur le statut de véhicules, le système comprenant un dispositif hôte du système de gestion d'expédition et au moins un terminal couplé au dispositif hôte et destiné à permettre d'entrer une commande d'expédition d'un véhicule.
PCT/US1999/023176 1998-10-05 1999-10-05 Systeme de gestion d'expedition WO2000021010A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA002345113A CA2345113A1 (fr) 1998-10-05 1999-10-05 Systeme de gestion d'expedition

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10303998P 1998-10-05 1998-10-05
US60/103,039 1998-10-05

Publications (2)

Publication Number Publication Date
WO2000021010A1 WO2000021010A1 (fr) 2000-04-13
WO2000021010A9 true WO2000021010A9 (fr) 2000-10-12

Family

ID=22293038

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/023176 WO2000021010A1 (fr) 1998-10-05 1999-10-05 Systeme de gestion d'expedition

Country Status (2)

Country Link
CA (1) CA2345113A1 (fr)
WO (1) WO2000021010A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112449065B (zh) * 2019-08-30 2023-02-10 比亚迪汽车工业有限公司 复印设备、方法及车辆调度系统
CN113723675B (zh) * 2021-08-20 2024-03-26 深圳依时货拉拉科技有限公司 一种零担揽件自动调度方法和计算机设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5168451A (en) * 1987-10-21 1992-12-01 Bolger John G User responsive transit system
US5122959A (en) * 1988-10-28 1992-06-16 Automated Dispatch Services, Inc. Transportation dispatch and delivery tracking system
US5636122A (en) * 1992-10-16 1997-06-03 Mobile Information Systems, Inc. Method and apparatus for tracking vehicle location and computer aided dispatch
US5945919A (en) * 1996-05-30 1999-08-31 Trimble Navigation Limited Dispatcher free vehicle allocation system
US5953706A (en) * 1996-10-21 1999-09-14 Orissa, Inc. Transportation network system
US5973619A (en) * 1997-06-10 1999-10-26 Paredes; Alexis Automated vehicle dispatch and payment honoring system

Also Published As

Publication number Publication date
CA2345113A1 (fr) 2000-04-13
WO2000021010A1 (fr) 2000-04-13

Similar Documents

Publication Publication Date Title
EP0430540B1 (fr) Méthode et système informatisée de surveillance et de vérification d'inventaire
US6151531A (en) System and method for managing the alteration of garments
US5710557A (en) Computerized valet parking system
US6430496B1 (en) Fully automated vehicle dispatching, monitoring and billing
US6618504B1 (en) Business management system
US5717867A (en) Employee time entry and accounting system
US5253166A (en) Pre-ticket travel reservation record keeping system
US5950169A (en) System and method for managing insurance claim processing
US7113864B2 (en) Fully automated vehicle dispatching, monitoring and billing
US20050187833A1 (en) Automated equipment management and reservation system
US7802721B2 (en) Method and system for transferring captured identification data in selectable formats suitable for different recipients
US20040024711A1 (en) Method of and system for filing orders
CN106228357A (zh) 用于提供基于位置的内容传递的方法和设备
MXPA04001425A (es) Sistema y metodo para el manejo de inventario.
CA2348168A1 (fr) Systeme de gestion d'information e2 pour concessionnaire d'automobiles
JP6391800B2 (ja) 店舗管理システム、店舗管理システムの制御方法、店舗管理システムのプログラム及び記録媒体
JP2006082981A (ja) 荷物の配達完了通知方法
TW201712626A (zh) 配送服務系統、配送服務方法、配送服務用伺服器及配送服務用配送者終端
US20050149374A1 (en) Tow management system
US20050261917A1 (en) Electronic waste management system
CN115222336A (zh) 一种智能仓库的综合管理系统
US20010002464A1 (en) Scanner-based automated service scheduling, management and billing system
WO2000021010A9 (fr) Systeme de gestion d'expedition
CA3132703A1 (fr) Systeme et methode pour configurer un service de transport
US20060095272A1 (en) System for ordering, tracking and payment of goods and services

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA MX US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C2

Designated state(s): CA MX US

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

COP Corrected version of pamphlet

Free format text: PAGES 1/4-4/4, DRAWINGS, REPLACED BY NEW PAGES 1/4-4/4; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

ENP Entry into the national phase in:

Ref country code: CA

Ref document number: 2345113

Kind code of ref document: A

Format of ref document f/p: F

Ref document number: 2345113

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 09806794

Country of ref document: US

122 Ep: pct application non-entry in european phase