The disclosed technology relates to systems and methods for an electronic transportation management system (TMS). Some embodiments of the disclosure provide a TMS that includes one or more server hardware computing devices or client hardware computing devices, communicatively coupled to a network, and each including at least one processor executing specific computer-executable instructions within a memory that, when executed, cause the system to: receive one or more load identifiers, provide one or more internal transporter indications and an open marketplace transporter indication for an open marketplace system, receive a user input to select a selected transporter indication among the one or more internal transporter indications and the open marketplace transporter indication, generate a first order based on the one or more load identifiers and the selected transporter indication, output the first order to an internal transporter corresponding to the selected transporter indication in response to the selected transporter indication being selected from the one or more internal transporter indications, and output the first order to the open marketplace system in response to the selected transporter indication being selected from the open marketplace transporter indication.
Other embodiments of the disclosure provide a TMS that includes one or more server hardware computing devices or client hardware computing devices, communicatively coupled to a network, and each including at least one processor executing specific computer-executable instructions within a memory that, when executed, cause the system to: receive one or more load identifiers. Each load identifier is associated with a pickup location and a destination location. The at least one processor further causes the system to: determine a transporter for the one or more load identifiers; generate a first order based on the one or more load identifiers and the transporter, generate a transportation task that is associated with the one or more load identifiers and that defines at least one trigger condition and a triggered action to be performed when the at least one trigger condition is satisfied, and execute the transportation task by performing the triggered action in response to satisfaction of the at least one trigger condition.
Other embodiments of the disclosure provide a system that includes one or more server hardware computing devices or client hardware computing devices, communicatively coupled to a network, and each including at least one processor executing specific computer-executable instructions within a memory that, when executed, cause the system to: receive one or more load identifiers, provide a group associated with the one or more load identifiers based on at least one of: a pickup location, a drop-off location, a delivery date, or a route of each of the one or more load identifiers, providing one or more internal transporter indications and an open marketplace transporter indication for an open marketplace transporter in an open marketplace system, receive a user input to select the group and a selected transporter indication among the one or more internal transporter indications and the open marketplace transporter indication, generate a first order based on the group and the selected transporter indication, output the first order to an internal transporter corresponding to the selected transporter indication in response to the selected transporter indication being selected from the one or more internal transporter indications, and output the first order to the open marketplace system in response to the selected transporter indication being selected from the open marketplace transporter indication.
Other embodiments of the disclosure provide a system that includes one or more server hardware computing devices or client hardware computing devices, communicatively coupled to a network, and each including at least one processor executing specific computer-executable instructions within a memory that, when executed, cause the system to: receive one or more load identifiers. Each load identifier is associated with a pickup location and a destination location. The at least one processor further causes the system to: generate a preorder based on the one or more load identifiers, provide a graphical automation definition interface including a plurality of automation rule templates, and receive a user input for a first automation rule template of the plurality of automation rule templates. The first automation rule template defines at least one trigger condition to perform a triggered action. The at least one processor further causes the system to: identify a first transporter of a plurality of transporters for the one or more load identifiers in response to the user input and generate a first order based on the one or more load identifiers and the first transporter by performing the triggered action in response to satisfaction of the at least one trigger condition. The first transporter satisfies the at least one trigger condition of the first automation rule template.
Other embodiments of the disclosure provide a system that includes one or more server hardware computing devices or client hardware computing devices, communicatively coupled to a network, and each including at least one processor executing specific computer-executable instructions within a memory that, when executed, cause the system to: generate a first transportation panel on a graphic user interface and generate a second transportation panel on the graphic user interface. The first transportation panel represents a first transportation function for the TMS, and the second transportation panel represents a second transportation function for an external ancillary system. The TMS is heterogeneous from the external ancillary system. The at least one processor further causes the system to: identify a first communication data format of the first transportation function and a second communication data format of the second transportation function, generate a transportation integration link on the graphical user interface between the first transportation panel and the second transportation panel to define a TMS integration application programming interface (API) by mapping the first communication data format and the second communication data format, and communicate, via the TMS integration API being executed by the electronic processor, between the TMS and the external ancillary system.
At least in some embodiments described herein, improved systems and methods are provided that may effectively integrate heterogeneous systems to provide a unified TMS, minimize system resource usage via distributed processing, and enhance data security by separate data management in the heterogeneous systems. The above features and advantages of the present invention will be better understood from the following detailed description taken in conjunction with the accompanying drawings.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the disclosure and, together with the description, serve to explain principles of the embodiments:
Electronic transportation management systems include software solutions to help companies manage their transportation operations. However, in some scenarios, the inhouse transporter of a transportation company in an existing transportation management system may not have enough capacity to transport loads. In other scenarios, using a transportation service of a third-party transportation company or an individual transporter who has a truck can be more efficient and more cost-effective than using the inhouse transporter. To use the transportation service of a third-party transportation company or an individual transporter, the personnel of the transportation company are required to search each third-party transportation company or a proper individual transporter, which is reputable and available. Even if the personnel can find a proper third-party transportation company or individual, the personnel are required to manage orders using the third-party transportation company's transportation management system and/or manually regenerate internal orders with possible clerical errors in the internal transportation management system. In some scenarios, separate transportation management systems may be used for managing different groups of transporters, where the separate transportation management systems are unable to communicate with one another. The lack of communication between systems can prevent a transportation management system from accessing relevant transportation data (e.g., regarding available transporters, transporter cost data, transporter reputation data, etc.) maintained on separate databases. Further, in some examples, transportation management systems may be rigidly constructed and unable to offer end-users the ability for customization and integration with other end-user software systems. The lack of interoperability of a transportation management system with other transportation management systems and other software systems can lead to inefficient transport management systems, transportation management systems with less functionality, overly manual processes, and errors and inefficiencies in transport management.
Some embodiments described herein provide solutions to these and other problems by providing improved systems and methods for an electronic transportation management system (TMS). For example, the disclosed systems and methods can provide a unified TMS platform or system to integrate heterogeneous transportation management systems (e.g., an TMS for the transportation company and an open marketplace system) and/or external ancillary systems (e.g., an external billing system, a load management system, etc.). In addition, the disclosed systems and methods can provide a unified transportation logistics operation information by dynamically obtaining the information from the inhouse transporter, other partner transporters using the same TMS platform, and the other external transporters using a heterogeneous TMS system (e.g., the open marketplace system). Furthermore, the disclosed systems and methods can reduce system resource usage and improve data processing via distributed computer processing in different transportation management systems. Moreover, the disclosed systems and methods can enhance data security by separate data management of transport orders in the heterogeneous systems. Finally, the disclosed systems and methods can provide optimized transportation logistics and streamline transport orders with automated operations using configurable transportation tasks and grouping features.
The server 110 can include one or more server(s) (e.g., cloud servers, data servers, computing devices, computers, etc. and collectively referred to herein as “the server 110”) and other components that may implement certain embodiments and features (e.g., the TMS or platform) described herein. Other devices, such as specialized sensor devices, etc., may interact with the server 110. In some examples, the server 110 can include one or more processor(s) 112 (collectively referred to herein as “the processor 112”). In some embodiments, the processor 112 can be any suitable hardware processor or combination of processors, such as a central processing unit (CPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a microcontroller (MCU), etc. In some examples, the processor(s) 112 retrieve and execute TMS software (e.g., stored in a memory of the server 110 or another accessible memory) to implement the TMS.
In further examples, the server 110 can further include a database 118. The database 118 can include any suitable storage device or devices that can be used to store suitable data (e.g., the TMS, load identifier(s), preorder(s), order(s), truck information, driver information, internal transporter information, automation rule template(s), system integration template(s), etc.) and instructions that can be used, for example, by the processor 112 to receive load identifier(s), provide internal transporter indication(s) and an open marketplace transporter indication, receive user input(s) to select a selected transporter indication, generate preorder(s), determine and providing group(s) based on load identifiers, generate order(s), output order(s) to internal transporter(s) and/or open marketplace system, determine partner transporter(s), display statuses of orders, obtain statuses of orders from the open marketplace system, generate transportation task(s), configure automation rule template(s), and/or configure system integration template(s). The database 118 can include any suitable volatile memory, non-volatile memory, storage, or any suitable combination thereof. For example, the database 118 can include random access memory (RAM), read-only memory (ROM), electronically-erasable programmable read-only memory (EEPROM), one or more flash drives, one or more hard disks, one or more solid state drives, one or more optical drives, etc. In some examples, the processor 112 can execute at least a portion of the computer program stored in the database 118 to perform one or more data processing transportation tasks described herein and transmit/receive information via the communications system 116, etc. In further examples, the processor 112 can execute at least a portion of process 400, 1900, 2100, 2200, and/or 2800 described below in connection with
In further examples, the server 110 can further include a communications system 116, also referred to as a network interface. The communications system 116 can include any suitable hardware, firmware, and/or software for communicating information over communication network 140 and/or any other suitable communication networks. For example, the communications system 116 can include one or more transceivers, one or more communication chips and/or chip sets, etc. In a more particular example, the communications system 116 can include hardware, firmware and/or software that can be used to establish a Wi-Fi connection, a Bluetooth connection, a cellular connection, an Ethernet connection, etc.
In further examples, the server 110 can receive or transmit information from or to client device(s) (e.g., company computing device 122A, 122N, driver computing device 124A1, 124AN, 124N1, 124NN and collectively referred to herein as “the client devices 122, 124”) in the transporter(s) 120A, 120N (collectively referred to herein as “the transporter 120”) and/or any suitable system (e.g., the open marketplace system 130, external ancillary system(s) 150, etc.) over one or more communication network(s) 140. In some examples, the communication network(s) 140 can be any suitable communication network or combination of communication networks. For example, the communication network(s) 140 can include a Wi-Fi network (which can include one or more wireless routers, one or more switches, etc.), a peer-to-peer network (e.g., a Bluetooth network), a cellular network (e.g., a 3G network, a 4G network, a 5G network, etc., complying with any suitable standard, such as CDMA, GSM, LTE, LTE Advanced, NR, etc.), a wired network, etc. In some embodiments, the communication network(s) 140 can be a local area network, a wide area network, a public network (e.g., the Internet), a private or semi-private network (e.g., a corporate or university intranet), any other suitable type of network, or any suitable combination of networks. Communications links shown in
In further examples, the server 110 can further include an input/output subsystem 114. The I/O subsystem 114 can include one or more device controller(s) for one or more user interface input devices and/or user interface output devices, possibly integrated with the server 110 (e.g., integrated audio/video systems, and/or touchscreen displays), or may be separate peripheral devices which are attachable/detachable from the server 110. Input may include keyboard or mouse input, audio input (e.g., spoken commands), etc. As non-limiting examples, input devices may include a keyboard, pointing devices (e.g., mouse, trackball, and associated input), touchpads, touch screens, scroll wheels, click wheels, dials, buttons, switches, keypad, audio input devices, voice command recognition systems, microphones, speakers, digital cameras, digital camcorders, webcams, and the like. In general, use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from computing system 100, such as to a user (e.g., via a display device) or any other computing system, such as a second computing system. In an example, output devices may include one or more display subsystems and/or display devices that visually convey text, graphics, and audio/video information (e.g., cathode ray tube (CRT) displays, flat-panel devices, liquid crystal display (LCD) or plasma display devices, projection devices, touch screens, etc.), and/or may include one or more non-visual display subsystems and/or non-visual display devices, such as audio output devices, etc. As non-limiting examples, output devices may include, indicator lights, monitors, printers, speakers, headphones, automotive navigation systems, plotters, voice output devices, modems, etc. In other examples, the input data and/or output data via the communication network(s) 140 from client devices 122, 124 or other system (e.g., the open marketplace system 130, external ancillary system(s) 150, etc.).
The one or more transporters 120A, 120N can include one or more client devices, and other components that may implement certain embodiments and features described herein. Other devices, such as specialized sensor devices, location tracking devices, etc., may interact with the client computing device(s). Each transporter 120A, 120N can include one or more processor(s), an I/O subsystem, a communications system, and/or a database, which are substantially similar to the components in the server 110. In some examples, a client computing device in each transporter 120A, 120N can be a company computing device 122A, 122N or a driver computing device 124A1, 124AN, 124N1, 124NN. Thus, each transporter 120A, 120N can include one or more company computing devices 122A, 122N and/or one or more driver computing device 124A1, 124AN, 124N1, 124NN. In some examples, the company computing device 122A, 122N can access the server 110 via the communication network 140 to perform transportation operations (e.g., providing load identifier(s), providing driver/truck information, assigning drivers to trucks, generating preorder(s), generating order(s), grouping preorders and/or orders, outputting order(s) to an internal transporter or an open marketplace system, etc.). In further examples, a driver computing device 124A1, 124AN, 124N1, 124NN can be carried by a driver and correspond to or be assigned to a vehicle (e.g., a Class 1 truck, a Class 2a truck, a Class 2B truck, a Class 3 truck, a Class 4 truck, a Class 5 truck, a Class 6 truck, a Class 7 truck, a Class 8 truck, an airplane, a vessel, or any other suitable vehicle having a capacity to carry a load). The driver computing device 124A1, 124AN, 124N1, 124NN can provide and update a transportation order status (e.g., available to perform an order, ready to pick up load(s), arriving at a pickup location, moving to a drop-off location, arriving at a drop-off location, completing an order, etc.). In some examples, the driver computing device 124A1, 124AN, 124N1, 124NN can be coupled with a location tracking device to provide location information of the driver computing device 124A1, 124AN, 124N1, 124NN to the server 110.
In some examples, when the transporter A 120A uses the TMS in the server 110, the transporter A 120A is the inhouse transporter while other transporters 120N using the TMS in the server 110 are partner transporters. Then, the TMS allows the transporter A 120A to use the internal fleet vehicles 124A1, 124AN, partner transporters' fleet vehicles 124N1, 124NN via partner transporters 120N in the same TMS, and/or open marketplace transporter 132A, 132N from a heterogeneous system (i.e., the open marketplace system 130). On the other hand, when the transporter N 120N uses the TMS in the server 110, the transporter N 120N is the inhouse transporter while other transporters 120A using the TMS in the server 110 are partner transporters. Then, the TMS allows the transporter N 120N to use the internal fleet vehicle 124N1, 124NN, partner transporters 120A to use partner transporters' fleet vehicle 124A1, 124AN in the same TMS, and/or open marketplace transporter 132A, 132N from a heterogeneous system (i.e., the open marketplace system 130).
In some examples, the open marketplace system 130 provides a transportation service solution by connecting load shippers and external transporters. The open marketplace system 130 allows shippers to connect with shippers' existing management systems to integrate load transportation services. For transporters, the open marketplace system 130 provides custom software solutions to find and manage transportation loads. In some scenarios, the TMS implemented via the server 110 and the open marketplace system 130 are heterogeneous in that the open marketplace system 130 is logically and/or physically separated from the TMS. In some examples, the open marketplace system 130 can have a logically or physically separated database from the database 118 in the server 110. In such examples, the server 110 outputs a transportation order of load(s) to the open marketplace system 130 and receives or obtains a status of the order from the open marketplace system 130. The open marketplace system 130 generates an open marketplace order based on the order from the server 110 by determining or assigning a transporter 132A, 132N in the open marketplace system 130. Then, the open marketplace system 130 provides or updates the status of the open marketplace order for the server 110.
In some examples, the external ancillary system(s) 150 can include an external ancillary payment system, an external ancillary transporter system, an external ancillary TMS, or any other external ancillary suitable system. In some scenarios, the TMS implemented via the server 110 and the external ancillary system(s) 150 are heterogeneous in that the external ancillary system(s) is logically and/or physically separated from the TMS. In some examples, the external ancillary system(s) 150 can be integrated into the TMS by generating transportation integration link using TMS integration application programming interface(s) (API) between the TMS and the external ancillary system(s). The server 110 allows users in the TMS to manage transactions for the external ancillary system(s) through the TMS. Thus, the users in the TMS does not need to independently access the external ancillary system(s).
In some examples, the GUI screen 200 can include information associated with an order. In some examples, the order indicates a transport order to ship one or more loads by a transporter (e.g., internal fleet vehicles of an inhouse transporter, partner fleet vehicles of partner transporters, vehicles of open market transporters) from a pickup location to a drop-off location for a shipper with/without other suitable conditions (e.g., pickup date and time deadlines, drop-off date and time deadlines, transport cost, etc.). For example, the GUI screen 200 can include transporter information 204, order information 206, location information 208, status information 210, activity information 212, and/or any other suitable information associated with the order.
In some examples, the transporter information 204 for the order can include a type of the transporter (e.g., an inhouse transporter, a partner transporter, or an open marketplace transporter), a name of the transporter, and/or any other suitable transporter information about who performs the order and ships load(s) of the order. GUI screens shown in
In further examples, the order information 206 can include one or more load identifiers. In some examples, a load identifier can be any suitable indication (e.g., vehicle identification number or any other suitable indication) to identify a load. In some examples, the load identifier is associated with load transportation information (e.g., pickup information (e.g., a pickup location, an estimated pickup time, pickup driver contact information, a pickup note, etc.), drop-off information (e.g., a drop-off location, an estimated drop-off time, drop-off driver contact information, a drop-off note, etc.), a real-time location of the load(s), a distance between the pickup location and the drop-off location, and/or any other suitable information associated with the one or more loads to transport). In other examples, the load identifier can include the load transportation information as well. In further examples, the order information 206 can further include an order status, and/or any other suitable information related to the order. In some examples, the order status can include an available status (e.g., with an assigned driver), an unassigned status (e.g., without an assigned driver), an unclaimed status (e.g., the order before being accepted by the assigned transporter), or any other suitable status. In further examples, the GUI screen 200 can also include preorder information. In some examples, a preorder indicates an order without an assigned transporter. The preorder information can include one or more load identifiers, load transportation information corresponding to the one or more load identifiers (e.g., pickup information (e.g., a pickup location, an estimated pickup time, a pickup note, etc.), drop-off information (e.g., a drop-off location, an estimated drop-off time, a drop-off note, etc.), a distance between the pickup location and the drop-off location), and any other suitable information related to the preorder.
In further examples, the location information 208 can show the pickup location, the drop-off location of the order, and/or a route between the pickup location and the drop-off location on a map. In further examples, the location information 208 can further show a current location of the load(s) and a traveled route of the load(s) on the map. In some examples, the current location of the load(s) can be tracked by a location sensor in a driver computing device 124A1, 124AN, 124N1, 124NN of the transporter 120A, 120N.
In further examples, the status information 210 can show an order timeline and where the order is located in the timeline. For examples, the order timeline can include a timeline bar with several fixed status points (e.g., new order, transporter accept, in transit, delivered, and completed). The order timeline can add or change indications (e.g., times, colors, marks, etc.) for corresponding fixed status points when the order completes transportation operations corresponding to the fixed status points. Thus, the user can easily identify the status of the order.
In further examples, the activity information 212 can show each activity with/without a time of the occurring activity related to the order. For example, the activity information 212 can show when the order is generated, when load(s) is ready for pickup, when the order is output to the transporter or the open marketplace system, when a transportation task message or notification is sent to the user, when load(s) is delivered, when the order is completed, and/or when any other suitable transportation operation is performed.
At block 402 of
In some examples, the server 110 can receive one or more load identifiers via client device(s) 122, 124 for a transporter (e.g., transporter A 120A or transporter N 120N). For example, a user using a client device 122, 124 for the transporter can manually input the one or more load identifiers for corresponding one or more loads to be shipped, and the server 110 can receive the one or more load identifiers. In other examples, when a customer of the transporter wants to ship the one or more loads, the customer can input the one or more load identifiers, and the server 110 can receive the one or more load identifiers. In further examples, a third-party system can transmit the one or load identifiers, and the server 110 can receive the one or more load identifiers.
In some examples shown in
In some examples, the server 110 can generate a preorder based on the one or more load identifiers. In some scenarios, the preorder indicates an order without an assigned transporter. The preorder can include at least one of: a preorder identifier, a preorder generation time, one or more load identifiers and/or associated load transportation information (e.g., a pickup location, an estimated pickup time, a pickup note, a pickup contact person's name, a pickup contact number, a drop-off location, an estimated drop-off time, a drop-off note, a drop-off contact person's name, a drop-off contact number, a distance between the pickup location and the drop-off location), or any other suitable information related to the preorder. In further examples, the one or more load identifiers for the preorder can share at least one of a pickup location, an estimated pickup time, a drop-off location, or an estimated drop-off time.
Referring again to
In further examples, the server 110 can receive one or more other load identifiers and determine a group of the one or more load identifiers and the one or more other load identifiers based on at least one of: a pickup location, a drop-off location, a delivery date, or a route of each of the one or more load identifiers and the one or more other load identifiers. Then, the server 110 can provide the group for the preorder. For example, the server 110 receives vehicle identification number (VIN) A to ship from Chicago to Milwaukee by March 1 and VIN B to ship from Chicago to Milwaukee by March 1. Then, the server 110 can determine a group to combine VIN A and VIN B to ship together and provide a message to generate an order or a preorder based on the group. In further example, the server can determine a group of two or more load identifiers by sharing at least one of: a pickup location, a drop-off location, a delivery date, or a route of each of the one or more load identifiers and the one or more other load identifiers. For example, the server 110 receives VIN A to ship from Indianapolis to Milwaukee (or Chicago) by March 1 and VIN B to ship from Chicago to Milwaukee by March 1. Then, the server 110 can identify that transportation of VIN A shares the route of the transportation of VIN B and can determine a group to combine VIN A and VIN B to ship together and provide a message to generate an order or a preorder based on the group. In further examples, the server 110 receives VIN A to ship from Chicago to Milwaukee by March 1 and VIN B to ship from Chicago to Milwaukee by February 29. Then, the server 110 can determine a group of VIN A and VIN B if VIN A can be transported by February 29 and provide a message to the user 202 to generate an order or a preorder based on the group.
At block 404 of
In some examples, the one or more internal transporter indications is indicative of an inhouse transporter or one or more partner transporters. In some examples, the inhouse transporter indicates a transporter having internal fleet vehicle(s) owned by the transportation company, which uses the TMS to manage the preorder(s) and/or the order(s). In further examples, a partner transporter is a transporter having external fleet vehicle(s) owned by a third-party transportation company, which uses the TMS. In some examples, the inhouse transporter and the partner transporters use the same TMS with different accounts. Thus, the inhouse transporter can share statuses of orders of the inhouse transporter with the one or more partner transporters within the same TMS. In some examples, the server 110 determines the one or more partner transporters among multiple partner transporters based on at least one of: a pickup location of the one or more load identifiers, a drop-off location of the one or more load identifiers, or a usage indication of the one or more partner transporters. In further examples, the server 110 can determine the one or more partner transporters among multiple partner transporters based further on reputation ranks, a number of timely deliveries, a number of timely placed on pickup locations and order progression, background/document checks, and avoiding fraudulent behavior of the one or more partner transporters.
Referring again to
In further examples, the server 110 can determine the order and the list of the internal transporter indications 902 based on how often the transportation company uses the internal transporters corresponding to the internal transporter indications 902. For example, when the transportation company used the inhouse transporter 15 times, partner transporter A 20 times, partner transporter B 5 times, and partner transporter C 1 times, the server 110 can determine the list of internal transporter indications 902 (the inhouse transporter, partner transporter A, and partner transporter B) when the transportation company uses an internal transporter more than a predetermined number of usage (e.g., 1, 5, or any other suitable threshold number of usage). Also, the server can determine the order of the list of the internal transporter indications 902 (e.g., partner transporter A, the inhouse transporter, and partner transporter B) based on the number of usage.
In further examples, the server 110 can also consider a period of time. For example, the server 110 can determine the order and the list of the internal transporter indications 902 based on how often the transportation company uses the internal transporters for the last one year. Thus, in the examples above, when the transportation company has not used partner transporter A for last five years, the server 110 can exclude partner transporter A in the list of the internal transporter indications 902. In further examples, the server 110 can determine the order and the list of the internal transporter indications 902 based on costs. In the examples above, when the cost to ship the one or more loads using transporter B is less expensive than that using other transporters, the server 110 can show transporter B at the top of the list of the internal transporter indication 902. In some examples, the server 110 can determine the cost 908 based on at least one of: a specific contracted price between the transportation company and the respective transporter, previous price data of the respective transporter, a standard price, or any other suitable factor. The GUI screen 900 can show the detail cost 910 to ship the one or more loads. In some examples, the cost 910 can be manually adjusted by the user.
In further examples, the server 110 can determine the order and the list of the internal transporter indications 902 based on reputation ranks or rates of the internal transporters corresponding to the internal transporter indications 902. For example, a rate of an internal transporter can be determined based on inspections, estimated time arrivals, timely delivery and order progression, background/document checks, avoiding fraudulent behavior, and/or any other suitable objective or subjective criteria.
Referring again to
In further examples, the server 110 can determine the order and the list of the driver indications 1002 based on reputation ranks or rates of the drivers corresponding to the driver indications 1002. For example, a rate of an internal transporter can be determined based on inspections, estimated time arrivals, timely delivery and order progression, background/document checks, avoiding fraudulent behavior, and/or any other suitable objective or subjective criteria. In some examples, the rates of the drivers and transporters provide the mechanism, which connects shipper expectations to the price the consumers pay to the expected quality of service based on the rates about drivers and transporters.
Referring again to
At block 406 of
At block 408 of
In some examples, an order is in one of various statuses. For example, the order can be in a transporter-claimed status (i.e., the order when the transporter accepted to transport the loads), a transporter-unclaimed status (i.e., the order when the transporter has not accepted to transport the loads), a driver-unassigned status (i.e., the order before a driver is assigned to the order), a driver-assigned status (i.e., the order when a driver is assigned to the order), a driver-accepted status (i.e., the order when a driver accepts the order), an in-transit status (i.e., the order after the departure of the loads before the arrival of the loads), an arrival status (i.e., the order when the loads arrives at the drop-off location), an on-hold status, and/or a complete status (e.g., the order when the server 110 receives a complete message from a person who receive the loads, the order when the server 110 receives a fare for the delivery of the loads, etc.).
For example, referring to
In further examples, the server 110 can assign the selected transporter indication to the preorder to generate the first order. Referring to
In further examples, the server 110 can receive one or more other load identifiers and determine a group of the one or more load identifiers and the one or more other load identifiers based on at least one of: a pickup location, a drop-off location, a delivery date, or a route associated with each of the one or more load identifiers and the one or more other load identifiers. Then, the server 110 can provide the group for the first order. Referring again to
In some examples as shown in
In some examples as shown in
In some examples, the server 110 can generate a second order based on one or more other load identifiers and can combine the first order and the second order based on at least one of: a pickup location, a drop-off location, a delivery date, a status indication, or a route from the pickup location to the drop-off location of each of the first order and the second order. Referring again to
In some examples, the server 110 can generates multiple other orders for the inhouse transporter, the one or more partner transporters, and an open marketplace transporter of the open marketplace system. The server 110 can dynamically access an internal database (i.e., the database 118 of the server 110) for a first subset of the other orders for the inhouse transporter to obtain a first status of the first subset of the other orders. The server 110 can dynamically access the internal database for a second subset of the other orders for the one or more partner transporters to obtain a second status of the first subset of the other orders. The server 110 can dynamically obtain a third status of a third subset of the other orders for the open marketplace transporter from the open marketplace system. Then, as shown in
At block 410, the server 110 outputs the first order to an internal transporter corresponding to the selected transporter indication in response to the selected transporter indication being selected from the one or more internal transporter indication. For example, to output the order in block 410, the server 110 may transmit the first order via the communication network 140 to a transporter selected from transporter A 120A to transporter N 120N. In some examples, to output the first order to the internal transporter, the server 110 outputs the first order to a driver of the internal transporter (e.g., for receipt and display on a graphical user interface of a driver's laptop, smartphone, or other computing device). In some examples, the first order can be output to the internal transporter, and the internal transporter determines a driver to ship the one or more loads and provide the driver information to the transportation company. In other examples, the first order can be output to the assigned driver of the internal transporter. In further examples, the internal transporter and/or the driver might not accept the first order to transport the one or more loads corresponding to the one or more load identifiers. Then, the user can reassign another transporter to the order. In other examples, outputting the first order to the internal transporter can include outputting the first order, which the internal transporter accepted, to the internal transporter.
In some examples, when the selected transporter indication is indicative of a first partner transporter of the one or more partner transporters, the server 110 can share the first order with the first partner transporter. For example, when a driver of a partner transporter (e.g., transporter N 120N) transports loads for the transportation company (e.g., transporter A 120A), the driver, via a driver computing device 124N1, 124NN, can update the status of the order in the TMS with a partner transporter account in the database 118 of the server 110. Then, the transportation company 120A can access the status of the order updated by the driver of the partner transporter in the database 118. In other examples, when a driver of a partner transporter (e.g., transporter N 120N) transports loads for the transportation company (e.g., transporter A 120A), the driver, via a driver computing device 124N1, 124NN, can directly update the status of the order in the TMS with the transportation company's account in the database 118 of the server 110. Then, the transportation company 120A can identify the status of the order updated by the driver of the partner transporter in the database 118.
In some examples,
At block 412, the server 110 outputs the first order to the open marketplace system in response to the selected transporter indication being selected from the open marketplace transporter indication. For example, to output the order in block 412, the server 110 may transmit the first order via the communication network 140 to the open marketplace system 130. In some examples, in response to the selected transporter indication being selected from the open marketplace transporter indication, the server 110 can obtain a status of the first order from the open marketplace system. In other examples, the server 110 can access the open marketplace system to obtain the status of the first order. In further examples, the status of the first order can include an order creation indication from the open marketplace system. For example, when the server 110 output the first order to the open marketplace system, the open marketplace system receives the first order as a request to generate an open marketplace order. When the open marketplace system generates the open marketplace order with an open marketplace transporter, the open marketplace system transmits an order creation indication indicating that the open marketplace order has been successfully generated. Then, the server 110 can receive the order creation indication and update the status of the order in the database 118. In some examples, when the status of the open marketplace order changes, the server 110 can receive an updated status of the open marketplace order from the open marketplace system. In further examples, the server 110 can request an updated status of the open marketplace order and update the status of the order based on the updated status of the open marketplace order from the open marketplace system.
Accordingly, after the first order is provided to the open marketplace system 130 and the first order is created on the open marketplace, transporters on the open marketplace may accept the first order. The acceptance can be communicated back to the server 110 via the communication network 140 and displayed to the user. Similarly, the open marketplace system 130 can communicate status updates on the accepted order through completion of the transport (e.g., indicating pickup, location during transit, completed delivery, etc.).
Accordingly, at least via this method of
At block 1902, a server (e.g., one or more server(s) 110, also referred to as the server 110) receives one or more load identifiers. In some examples, each load identifier is associated with a pickup location and a drop-off location. In some examples, block 1902 is substantially similar to block 402 of
At block 1904, the server 110 determines a transporter for the one or more load identifiers. In some examples, block 1904 is substantially similar to blocks 404 and 406 of
At block 1906, the server 110 generates a first order based on the one or more load identifiers and the transporter. In some examples, block 1906 is substantially similar to block 408 of
At block 1908, the server 110 generates a transportation task that is associated with the one or more load identifiers and that defines at least one trigger condition and a triggered action to be performed when the at least one trigger condition is satisfied. For example, the server 110 may generate the transportation task based on user input received from a client device (e.g., 122A, 122N) via a graphical user interface, such as illustrated and described with respect to
At block 1910, the server 110 executes the transportation task by performing the triggered action in response to satisfaction of the at least one trigger condition. Additional description of executing a transportation task is provided below.
In some examples, the transportation task is a load task. For example, the at least one trigger condition includes an elapsing of a first predetermined time period after receiving the one or more load identifiers, and the triggered action includes providing an order creation message. Then, to execute the load task, the server 110 can provide the order creation message in response to the elapsing of the first predetermined time period after receiving the one or more load identifiers. For example, when the server 110 has not received a user input or any suitable command to generate an order for the one or more load identifiers for a predetermined time period after the server 110 received the one or more load identifiers, the server 110 can generate and execute a load task to provide an order creation message to the user for the transportation company to create an order for the one or more load identifiers.
In further examples, the transportation task is another load task. The at least one trigger condition includes determining each load identifier of the one or more other load identifiers is associated with the pickup location, the pickup time, the drop-off location, the drop-off time, the requested service level, and/or the types of the loads of the one or more load identifiers, and the triggered action includes providing a load grouping message. Then, to execute the load task, the server 110 can generate the load grouping message in response to determining that the one or more other load identifiers are associated with the pickup location and the drop-off location. For example, the server 110 can identify the trigger condition indicating that the load identifiers have the same pickup location, the same drop-off location, the same or similar pickup time, the same or similar drop-off time, and/or a shared route between the load identifiers. Then, when the server 110 can determines that the trigger condition has been met, the server 110 can generate and execute a load task to provide a load grouping message to the user for the transportation company to group the one or more load identifiers.
In further examples, the transportation task is a transport task. For example, the at least one trigger condition includes providing one or more internal transporter indications and an open marketplace transporter indication for an open marketplace system, and the triggered action includes one or both of: generating a fare message for the one or more internal transporter indications and the open marketplace transporter indication, or generating a reputation message for the one or more internal transporter indications and the open marketplace transporter indication. To execute the transporter task, in response to providing the one or more internal transporter indications and the open marketplace transporter indication, the server 110 can perform one or both of: generating a fare message for the one or more internal transporter indications and the open marketplace transporter indication, or generating a reputation message for the one or more internal transporter indications and the open marketplace transporter indication. Thus, the transport task can assist the user decision to select a transporter by providing prices, ranks, and/or reviews for corresponding transporters. For example, when the server 110 provides the one or more internal transporter indications and/or the open marketplace indication, the server 110 determines that the triggering condition is satisfied. Then, the server can execute the transporter task by generating fare messages and/or reputation messages for the inhouse transporter, one or more partner transporters, and/or the external transporter of the open marketplace system.
In further examples, the transportation task is a preorder task. The server 110 can generate a preorder based on the one or more load identifiers. For example, to generate the first order, the server 110 assign the transporter to the preorder to generate the first order. In some examples, the at least one trigger condition includes an elapsing of a first predetermined time period after generating the preorder without assigning the transporter, and the triggered action includes providing an order creation escalation message. In further examples, to execute the preorder task, the server 110 provides the order creation escalation message in response to the elapsing of the first predetermined time period after generating the preorder without assigning the transporter. For example, when the server 110 has not received a user input or any suitable command to assign a transporter to a preorder for the one or more load identifiers for a predetermined time period after the server 110 generated the preorder, the server 110 can generate and execute a preorder task to provide an order escalation message to the user for the transportation company to create an order by assigning a transporter to the preorder.
In further examples, the transportation task is an order task. In some examples, the at least one trigger condition includes an elapsing of a predetermined time period after generating the first order without assigning a driver, and the triggered action includes providing a driver assignment escalation message. In further examples, to execute the order task, the server 110 includes providing the driver assignment escalation message in response to the elapsing of the predetermined time period. For example, when the server 110 has not received a user input or any suitable command to assign a driver to an order for a predetermined time period after the server 110 generated the order, the server 110 can generate and execute an order task to provide a driver assignment escalation message to the user for the transportation company to assign a driver to the order.
In further examples, the transportation task is another order task. In some examples, the at least one trigger condition includes an elapsing of a predetermined time period after an estimated time arrival for the first order, and the triggered action includes providing an order escalation message. In further examples, to execute the order task, the server 110 further provides the order escalation message in response to the elapsing of the predetermined time period. For example, when the server 110 has not received an indication from a driver, via a driver computing device, that the driver arrived at the pickup location or the drop-off location by the estimated arrival times on the pickup location or the drop-off location, respectively, the server 110 can generate and execute an order task to provide an order escalation message to arrive at the pickup location or the drop-off location soon.
In further examples, the transportation task is an order task. In some examples, the at least one trigger condition includes: generating a second order having at least one of: a same drop-off location, a shared route, or a same delivery date as the first order, and the triggered action includes providing an order grouping message. In further examples, to execute the transportation task, the server 110 provides the order grouping message in response to generating the second order. For example, the server 110 can identify the trigger condition indicating that the orders have the same pickup location, the same drop-off location, the same or similar pickup time, the same or similar drop-off time, and/or a shared route between the load identifiers. Then, when the server 110 can determines that the trigger condition has been met, the server 110 can generate and execute an order task to provide an order grouping message to the user for the transportation company to group the orders.
Accordingly, the server 110 implementing the TMS system, via the task generation and execution described with respect to the process 1900 of
At block 2102, a server (e.g., one or more server(s) 110, also referred to as the server 110) receives one or more load identifiers. In some examples, block 2102 is substantially similar to block 402.
At block 2104, the server 110 provides a group of the one or more load identifiers based on at least one of: a pickup location, a drop-off location, a delivery date, or a route of each of the one or more load identifiers. For example, the server 110 can provide a message to the user for the transportation company indicating that multiple load identifiers can be grouped for an order based on one or more grouping conditions. The grouping condition can include the same pickup location of the loads corresponding to the multiple load identifiers, the same drop-off location of the loads, the same or similar delivery date of the loads, and/or a shared route between routes of the loads. However, the grouping condition is not limited to the list recited above. For example, the grouping condition can further include levels of requested service for the loads, types of loads, or any other suitable conditions.
At block 2106, the server 110 provides one or more internal transporter indications and an open marketplace transporter indication for an open marketplace transporter in an open marketplace system. In some examples, block 2106 is substantially similar to block 404 of
At block 2108, the server 110 receives a user input to select the group and a selected transporter indication among the one or more internal transporter indications and the open marketplace transporter indication. In some examples, block 2108 is substantially similar to block 406 of
At block 2110, the server 110 generates a first order based on the group and the selected transporter indication. In some examples, block 2110 is substantially similar to block 408 of
At block 2112, the server 110 outputs the first order to an internal transporter corresponding to the selected transporter indication in response to the selected transporter indication being selected from the one or more internal transporter indications. In some examples, block 2112 is substantially similar to block 410 of
At block 2114, the server 110 outputs the first order to the open marketplace system in response to the selected transporter indication being selected from the open marketplace transporter indication. In some examples, block 2114 is substantially similar to block 412 of
At block 2202, the server 110 receives one or more load identifiers. In some examples, each load identifier can be associated with a pickup location and a drop-off location. In some examples, block 2202 is substantially similar to block 402 of
At block 2204, the server 110 generates a preorder based on the one or more load identifiers. In some examples, block 2204 is substantially to the preorder generation associated and described with respect to
At block 2206, the server 110 provides a graphical automation definition interface including multiple automation rule templates. For example, as shown in
At block 2208, the server 110 receives a user input for a first automation rule template of the multiple automation rule templates. Referring again to
In some examples, the first automation rule template can define at least one trigger condition to perform a triggered action. In further examples, the user input includes a configuration input to configure the at least one trigger condition of the first automation rule template. In further examples, the configuration input further adds at least one another trigger condition to trigger another trigger action. In some examples, the at least one trigger condition includes at least one of: a transporter providing a lowest proposed price, a predetermined transporter, a transporter with a fastest delivery speed, a transporter having a highest volume capacity, or a transporter with a highest rate. In some examples, the first automation rule template further defines a triggered action to be performed when the at least one trigger condition is satisfied. In further examples, the trigger action includes selecting the first transporter. In some examples, the server 110 can provide a user-friendly graphical user interface to configure a trigger condition and/or a triggered action of an automation rule or an automation rule template.
In some examples, blocks 2206 and 2208 can be performed at a different time from blocks 2202, 2204, 2210, and 2212 in that blocks 2206 and 2208 are to configure and operate automation rule templates for other processes in blocks 2202, 2204, 2210, and 2212. For example, blocks 2206 and 2208 can be performed before or in parallel with performance of blocks 2202 or 2204.
It should be appreciated that the at least one trigger condition are not limited to the one or more transporters. For example, the at least one trigger condition can be a load-related condition (e.g., whether a predetermined time period after receiving the one or more load identifiers elapses, whether each load identifier of the one or more other load identifiers is associated with the pickup location and the drop-off location of the one or more load identifiers, etc.), an order-related condition (e.g., whether an order departs on time, whether an order arrives on time, etc.), a driver-related condition (e.g., whether a predetermined time period after an order was created without a driver being assigned elapses, whether a driver arrives at a pickup location, etc.) or any other suitable condition.
In further examples, a trigger condition can be defined by selecting a predetermined condition 2408. For example, the server 110 can provide an option in the first GUI component 2402 to select one or more predetermined trigger condition (e.g., using a drop-box menu, an autosuggest function, check-boxes). In further examples, the server 110 can provide another option in the first GUI component 2402 such that the user can configure the trigger condition (e.g., by coding the trigger condition or by using a mapping tool to map a transportation system entity/group (e.g., transporters, orders, preorders, etc.) to another transportation system entity/group to configure the trigger condition).
In further examples, the automation rule template can further include a second GUI component 2404. In some examples, the second GUI component 2404 can further define at least one trigger condition. For example, if the first GUI component 2402 can define a first trigger condition (e.g., transporters having volumes higher than a predetermined volume), the second GUI component 2404 can define a second trigger condition (e.g., a transporter proposing the lowest price) among the result (e.g., transporters having volumes higher than a predetermined volume).
In some examples, the server 110 can allow the user to add another GUI component. For example, the GUI screen 2400 can provide an indication 2412 to add a GUI component. When the user selects the indication 2412 to add a GUI component, the server can provide an option to select a type of the GUI component. For example, the type can correspond to the filter 2406, the selection 2408, the coding 2410 to configure at least one trigger condition. Thus, the server 110 allows the user to add a GUI component to configure at least one trigger condition in various ways. In further examples, the new GUI component can be connected to any suitable component (e.g., the first GUI component 2402, the second GUI component 2404, etc.). For example, the new GUI component can be connected to the first GUI component 2402 for a different trigger condition from the trigger condition of the second GUI component 2404. In some examples, the first GUI component 2402 defines a trigger condition to select transporters having volumes higher than a threshold volume, and the second GUI component 2404 defines another trigger condition to select a transporter proposing the lowest price among the transporters produced from the first GUI component 2402. In some scenarios, the new GUI component can define a different trigger condition for one or more preorders having pickup locations and drop-off locations that the selected transporters from the first GUI component 2402 can cover. Thus, the server 110 can provide a user-friendly graphical user interface to configure a trigger condition of an automation rule template.
In some examples, a GUI component can define a triggered action. In some examples, a triggered action can include generating an order, assigning a transporter to a preorder, providing a notification, assigning a driver, or performing any other suitable triggered action. In some examples, a triggered action of a GUI component can be defined using the selection 2408 and/or the coding 2410. In some example, a GUI component can define a trigger condition and a triggered action together. In other examples, a GUI component can define a trigger condition and another GUI component can define a triggered condition. For example, if the first GUI component 2402 can define a first trigger condition (e.g., a transporter proposing the lowest price), the second GUI component 2404 can define a triggered action (e.g., generating an order by assigning the transporter to a preorder). In some scenarios, when the server 110 identifies a user input to use the automation rule template to select a transporter proposing the lowest price in the first GUI component 2402, the second GUI component 2404 defines a triggered action, which is to generate an order when a preorder is generated by automatically assigning the transporter to the preorder.
In further examples, a GUI component to define a triggered action can be connected to any suitable component (e.g., the first GUI component 2402, the second GUI component 2404, etc.). For example, the new GUI component can be connected to the first GUI component 2402 and perform another triggered action based on the result of the first GUI component 2402. In some examples, the first GUI component 2402 defines a trigger condition to select a transporter proposing the lowest price and the second GUI component 2404 defines a triggered action to generate an order based on the selected transporter. Then, the new GUI component can define another triggered action to send a notification about the selection to the transporter. Thus, the server 110 can provide a user-friendly graphical user interface to configure a trigger condition and/or a trigger action of an automation rule template.
In further examples, it should be appreciated that the automation rule template can be configured in a different way. For example, the automation rule template can be configured by using a root table as shown in
At block 2210, the server 110 identifies a first transporter of multiple transporters for the one or more load identifiers in response to the user input. In some examples, the first transporter satisfies the at least one trigger condition of the first automation rule template. It should be appreciated that it is not limited to the transporter to be identified in response to the user input.
In some examples shown in
At block 2212, the server 110 generates a first order based on the one or more load identifiers and the first transporter by performing the triggered action in response to satisfaction of the at least one trigger condition. Thus, the triggered action (e.g., generating the first order) can be automatically performed when the server identifies that the at least one trigger condition is satisfied (e.g., the first transporter satisfying the at least one trigger condition). In some examples, a triggered action based on the at least one trigger condition can include: generating an order, assigning a transporter to a preorder, providing a notification, assigning a driver, performing any other suitable triggered action. For example, the triggered action can be to send a notification. In some examples, he server 110 can transmit a notification to other transporters of the multiple transporters indicating that the first transporter satisfies the at least one trigger condition of the first automation rule template in response to the user input. In further examples, the server 110 can transmit a notification to other transporters of the plurality of transporters indicating that the first transporter is selected for the one or more load identifiers in response to the user input.
In some example, the server 110 can provide a GUI screen to shows history data to track load identifiers, preorders, transporters, and/or orders to verify whether the automation rule template is properly operated or the automation rule template is operated as the user 202 configured the automation rule template using the GUI in
In some examples, the server 110 can perform the GUI-based system integration using a system integration template. Referring to
Referring again to
In some examples, the first transportation function for the TMS can include at least one of: a load identifier-related function, a transporter-related function, an order-related function, a payment-related function, or any other suitable TMS-related function. In further examples, the load identifier-related function can include at least one of: generating one or more identifiers, posting the one or more identifiers, removing one or more identifiers, receiving information about one or more identifiers, or performing any other suitable load identifier-related function. In further examples, the transporter-related function can include at least one of: receiving external transporter information, receiving status information of an external transporter, or performing any other suitable transporter-related function. In further examples, the order-related function can include at least one of: generating an order, finding the order, canceling the order, generating a transportation task, finding the transportation task, canceling the transportation task, receiving information about an order, receiving information about a transportation task, or performing any other suitable order-related function. In even further examples, the payment-related function can include at least one of: posting a payment, receiving a status of the payment, posting a payable, or performing any other suitable payment-related function.
Referring again to
For example, the first transportation function corresponding to the first panel 3002 is to receive one or more load identifiers from an external ancillary system 150 (e.g., load identifier generating system), while the TMS performs the second transportation function (e.g., generates an order) of the second panel 3004 based on the one or more load identifiers received via the first transportation function.
At block 2806, the server 110 identifies a first communication data format of the first transportation function and a second communication data format of the second transportation function. In some examples, the server 110 can identify the first communication data format and the second communication data format by receiving a user input indicating the data formats or the communication network 140 from the external ancillary system 150 or any other suitable data source. In other examples, the server 110 can possess various data formats of transportation functions in the database 118 and identify the first communication data format and the second communication data format by accessing the database 118. For example, the first transportation function corresponding to the first panel 3002 is to receive one or more load identifiers from an external ancillary system 150 in five-digit format while the second transportation function (e.g., generates an order) of the second panel 3004 uses the one or more load identifiers in four-letter format as an input. The server 110 can identify the communication data format for the one or more load identifiers from the external ancillary system 150, which is a five-digit format while the communication data format for the one or more load identifiers in the TMS is a four-letter format.
At block 2808, the server 110 generates a transportation integration link 3005 on the graphical user interface between the first transportation panel and the second transportation panel to define a TMS integration application programming interface (API) by mapping the first communication data format and the second communication data format. In the examples above, the server 110 can define a TMS integration API by defining an API that is configured to convert the five-digit format load identifiers to the four-letter load identifiers and that is configured to perform the second transportation function based on the converted the four-letter load identifiers via the TMS integration API. In some examples, the server 110 can configure at least one of the first communication data format of the first transportation function for the TMS integration application programming interface (API) or the second communication data format of the second transportation function for the TMS integration API. For example, to configure the first communication data format or the second communication data format for the TMS integration API, the server 110 can add or delete any suitable data in the first or second communication data format in the data format configuration for the TMS integration API. Additionally or alternatively, the server can perform suitable transportation function to configure the data format data for the TMS integration API. Thus, the TMS integration API can accurately map the first communication data format and the second communication data format.
In further examples, the server 110 can allow the user 202 to add a new panel 3010 to be connected to a previous panel (e.g., the second panel 3008 and/or the first panel 3002) to perform a new transportation function associated with a previous transportation function (e.g., the second panel 3008 of the second panel 3008 and/or the first panel 3002 of the first transportation function of the first panel 3002). The user 202 can select and/or configure the new transportation function among a list of transportation functions 3004. Similar to block 2806, the server 110 can identify communication data formats of the transportation function to be connected to the new transportation function of the new panel 3010 and the new transportation function. In further examples, similar to block 2808, the server 110 can generates another transportation integration link on the graphical user interface between the previous transportation panel and the new transportation panel 3010 to define another TMS integration API by mapping the previous communication data format of the previous transportation function and the new communication data format of the new transportation function.
In some examples, after configuring the TMS integration using the GUI screen 3000, the server 110 can provide an indication 3012 to simulate or test the configured TMS integration with test data. For example, the server 110 can possess various data formats of external ancillary systems 150 and generate test data using the various data formats to provide the test data to the configured system integration. In some examples, the GUI screen 3000 can further include a history section 3014 to show the test or simulation result of the test data in the configured system integration, which perform the first transportation function of the first panel 3002 and the second transportation function of the second panel 3008.
At block 2810, the server 110 communicates, via the TMS integration API being executed by the electronic processor of the server 110, between the TMS and the external ancillary system 150. In some examples, to communicate between the TMS and the external ancillary system 150, the server 110 can receive data from the external ancillary system 150, identify the second transportation function of the external ancillary system 150 for the data (e.g., as having output the data), identify the TMS integration API corresponding to the second transportation function of the ancillary system, and provide the data to the TMS via the TMS integration API. For example, the TMS integration API may map the data from a first format of the external ancillary system 150 to a second format of the TMS. In further examples, the server 110 can identify data to be output to the second transportation function of the external ancillary system 150, identify the TMS integration API corresponding to the second transportation function of the external ancillary system 150, and provide the data to the external ancillary system 150 via the TMS integration API. For example, the TMS integration API may map the data from a first format of the TMS to a second format of the external ancillary system 150. Accordingly, when communicating via the TMS integration API, the TMS integration API may map or translate the data from a format of the transmitting component to a format of the receiving component.
In some examples, the server 110 can generate test input data to be input to the first transportation function for the TMS system or to the second transportation function for the ancillary system and provide the test input data on the graphical user interface to the first transportation panel. The server 110 can determine test output data from the second transportation function with the test input data in the first transportation function or from the first transportation function with the test input data in the second transportation function. The server 110 can provide the test output data on the graphical user interface.
Other examples and uses of the disclosed technology will be apparent to those having ordinary skill in the art upon consideration of the specification and practice of the invention disclosed herein. The specification and examples given should be considered exemplary only, and it is contemplated that the appended claims will cover any other such embodiments or modifications as fall within the true scope of the invention.
The Abstract accompanying this specification is provided to enable the United States Patent and Trademark Office and the public generally to determine quickly from a cursory inspection the nature and gist of the technical disclosure and in no way intended for defining, determining, or limiting the present invention or any of its embodiments.
This application claims priority to U.S. Provisional Application No. 63/501,578, filed on May 11, 2023, titled “SYSTEM AND METHOD FOR TRANSPORTATION MANAGEMENT,” which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
63501578 | May 2023 | US |