Logistics waybill management and control method and device, storage medium and server

Abstract

The invention discloses a logistics waybill management and control method and device, a storage medium and a server, and relates to the field of logistics data processing. The method comprises the following steps: in response to waybill creation, obtaining transportation demand information of waybills; a standard route serving as an execution reference is matched and bound from a preset standard route library, and the route defines a node sequence, a plan time window and an operation specification; and according to the route, an execution instruction is issued to each logistics operation system in a serialized manner. According to the invention, full-process automatic closed-loop control of the logistics waybill from planning, execution to abnormal dynamic adjustment is realized, and the full-process visualization level and the intelligent degree of abnormal response are improved.

Description

Technical Field

[0001] This application relates to the field of logistics data processing, and in particular to a method, device, storage medium and server for managing logistics waybills. Background Technology

[0002] Managing the entire process of a single shipment from dispatch to delivery typically relies on a segmented, modular management architecture. Order management systems, warehouse management systems, transportation management systems, and last-mile delivery systems, as independent functional units, are responsible for different stages of the logistics chain. These systems often synchronize basic information through limited, batch data interfaces, or rely more heavily on manual data entry and transmission between different platforms.

[0003] This technical architecture results in the complete flow status of a single shipment being recorded and stored fragmentarily across multiple heterogeneous systems. When it is necessary to trace the real-time location of goods or understand their current operational stage, operators or customer service personnel have to log into different management systems one by one to make scattered queries, and then manually summarize and verify the fragmented information. This process is not only time-consuming, but also makes it difficult to guarantee the accuracy and timeliness of the information, thus restricting the transparency and traceability of the entire logistics process.

[0004] Furthermore, due to the lack of a unified execution benchmark and real-time coordination mechanism throughout the entire process, when abnormal situations such as operational delays, capacity shortages, or route obstructions occur in one link, their impact is difficult for the system to automatically and quickly identify and transmit to upstream and downstream related links. Subsequent response measures heavily rely on manual judgment and intervention by dispatchers based on limited and delayed information. This response mode is inefficient and struggles to quickly assess the global impact and generate feasible overall adjustment plans in complex logistics networks, often leading to the expansion of the impact of local anomalies.

[0005] Overall, existing technical solutions have significant limitations in achieving end-to-end automated and intelligent closed-loop management of logistics waybills. The lack of coordination between different links and the passive and slow response to anomalies are key technical bottlenecks that restrict the efficiency and reliability of logistics operations. Summary of the Invention

[0006] This application provides a method, apparatus, storage medium, and server for managing logistics waybills, which can solve the problems in the prior art caused by the segmented management architecture, resulting in fragmented status information throughout the logistics process, delayed abnormal response, and a lack of automated global coordination mechanism. The technical solution is as follows: In a first aspect, embodiments of this application provide a method for managing logistics waybills, the method comprising: In response to the creation of a logistics waybill, the transportation demand information of the logistics waybill is obtained; wherein, the transportation demand information includes at least: origin code, destination code, cargo type code, and service timeliness requirements; Based on the transportation demand information, a standard route is matched from a pre-set standard route library as the execution basis for the logistics order, and the standard route is bound to the logistics order; wherein, the data structure of the standard route includes: multiple logistics nodes arranged in sequence, a node planning time window defined for each logistics node, and standard operation specifications associated with each node; Based on the node sequence and node planning time window of the standard route, execution instructions are serialized and issued to the corresponding logistics operation system.

[0007] Secondly, embodiments of this application provide a management and control device for logistics waybills, the device comprising: The acquisition module is used to acquire the transportation demand information of the logistics waybill in response to its creation; wherein the transportation demand information includes at least: origin code, destination code, cargo type code, and service timeliness requirements; The binding module is used to match a standard route from a pre-set standard route library as the execution basis for the logistics order based on the transportation demand information, and bind the standard route to the logistics order; wherein, the data structure of the standard route includes: multiple logistics nodes arranged in sequence, a node planning time window defined for each logistics node, and standard operation specifications associated with each node; The delivery module is used to serialize and deliver execution instructions to the corresponding logistics operation system according to the node sequence and node planning time window of the standard route.

[0008] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0009] Fourthly, embodiments of this application provide a server that may include a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0010] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: By binding a structured standard route to each waybill as the sole execution benchmark, and issuing serialized instructions to each operating system based on this benchmark, the data and process breakpoints between order, warehousing, and transportation links are broken, enabling automatic synchronization and visibility of waybill status across the entire logistics chain, as well as automatic triggering and collaboration of operations at each stage.

[0011] By collecting node data in real time and automatically comparing it with the planned time window, deviations can be detected instantly and accurately. Once the deviation exceeds the limit, an early warning can be automatically triggered, and subsequent paths can be quickly replanned based on real-time network data, generating backup plans and automatically updating subsequent instructions. This realizes a transformation from passive recording and manual intervention to proactive early warning and intelligent deviation correction, significantly shortening the anomaly response time.

[0012] This application's method forms a complete closed loop from benchmark setting, driven execution, monitoring feedback to dynamic adjustment. Based on real-time monitoring data and replanning results, it can continuously accumulate actual performance data for each path, providing a data foundation for future optimization and self-learning of the standard routing library. This enables path planning to continuously adapt to changes in network conditions, improving the resilience and efficiency of the overall logistics network. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a schematic diagram of the network architecture provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the logistics waybill management method provided in the embodiments of this application; Figure 3 This is another flowchart illustrating the logistics waybill management method provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the method for generating an alternative routing scheme provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a logistics waybill control device provided in this application; Figure 6 This is a schematic diagram of the computer storage medium provided in this application; Figure 7 This is a schematic diagram of the structure of a server provided in this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0016] It should be noted that the logistics waybill management method provided in this application is generally executed by the server, and correspondingly, the logistics waybill management device is generally set in the server.

[0017] Figure 1 An exemplary network architecture is shown that can be applied to the logistics waybill management method or logistics waybill management device of this application.

[0018] like Figure 1 As shown, the network architecture may include: terminal device 101 and server 102. Terminal device 101 and server 102 can communicate with each other via the network, which serves as the medium for providing communication links between the various units. The network may include various types of wired or wireless communication links, such as: wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables; and wireless communication links including Bluetooth communication links, Wi-Fi communication links, or microwave communication links.

[0019] It should be noted that the terminal device 101 and the server 102 can be either hardware or software. When the terminal device 101 and the server 102 are hardware, they can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the terminal device 101 and the server 102 are software, they can be implemented as multiple software programs or software modules (for example, to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0020] The terminal device of this application can be equipped with various communication client applications, such as video recording applications, video playback applications, voice interaction applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0021] A terminal device can be either hardware or software. When the terminal device is hardware, it can be various terminal devices with a display screen, including but not limited to smartphones, tablets, laptops, and desktop computers. When the terminal device is software, it can be installed on the terminal devices listed above. It can be implemented as multiple software programs or software modules (e.g., used to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0022] When the terminal device is hardware, it can also be equipped with a display device and a camera. The display device can be any device capable of displaying information, and the camera is used to capture video streams. For example, the display device can be a cathode ray tube display (CR), a light-emitting diode display (LED), an e-ink screen, a liquid crystal display (LCD), a plasma display panel (PDP), etc. Users can use the display device on the terminal device to view displayed text, images, videos, and other information.

[0023] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is for illustrative purposes only. Depending on implementation needs, there can be any number of terminal devices, networks, and servers.

[0024] The following will be combined with the appendix Figure 2 This application provides a detailed description of the logistics waybill management method provided in the embodiments of this application. The logistics waybill management device in the embodiments of this application can be... Figure 1 The server shown.

[0025] Please see Figure 2 This is a flowchart illustrating a method for managing logistics waybills, as provided in this application embodiment. Figure 2 As shown, the method described in this application embodiment may include the following steps: S1. In response to the creation of a logistics waybill, obtain the transportation demand information of the logistics waybill; wherein, the transportation demand information includes at least: origin code, destination code, cargo type code and service timeliness requirements.

[0026] The server responds to requests from external systems to create logistics waybills by deploying a well-defined network service interface. This interface serves as a standardized communication entry point between the server and upstream business systems, typically based on a common network protocol. When an upstream order management system, e-commerce platform, or customer portal needs to initiate a new logistics transportation task, it constructs a structured request data packet according to the interface's specifications and sends it to the server's designated access point via network calls.

[0027] Upon receiving a request, the server first performs necessary network protocol layer processing, followed by the application layer's business logic processing flow. The core processing flow is parsing and verification. The server disassembles and analyzes the request data packet according to predefined format rules, extracting the fields that carry business semantics. This process includes checks on data integrity, format compliance, and logical validity, such as verifying the existence of required fields and whether the encoded values ​​are within a preset range of valid enumerations.

[0028] After verification, the server extracts the core parameter set constituting the transportation demand information from the request data packet. These parameters are the raw inputs for all subsequent intelligent scheduling and route decisions, and their critical requirement is that they must be unambiguously digitally defined. Specifically, the origin and destination codes must be able to map to unique geographical locations or operational nodes within the internal logistics network model; the cargo type code must accurately correspond to a predefined classification system that distinguishes cargo physical attributes, storage requirements, or processing specifications; and the service timeliness requirement must be transformed into a clear time metric or level identifier that can be calculated by the system. After completing the above processing, this extracted and standardized transportation demand information will be placed in the server's memory workspace or encapsulated as internal data objects for direct use in the next step of the process.

[0029] For example, after a furniture e-commerce platform completes a transaction, its backend system needs to create a logistics tracking number for a sofa awaiting delivery. The platform system, acting as a client, calls the "Create Tracking" application programming interface (API) provided by the logistics server. During the call, the platform system generates a request according to the API's specifications. This request includes the sofa's shipping warehouse number "WH_A_01" as the origin code, the delivery address's corresponding end-point number "SITE_B_42" as the destination code, selects the code "LHF" corresponding to the "Large Furniture" category based on the sofa's characteristics, and specifies the delivery time code "STD_72H" for the "Standard Delivery" service.

[0030] After receiving this request, the network interface layer of the logistics server passes it to the business logic unit. The business logic unit parses the request content, confirms that all required fields have been provided, and verifies that each coded value exists in the corresponding dictionary table maintained by the server. After successful verification, the server extracts four key data points: "WH_A_01", "SITE_B_42", "LHF", and "STD_72H", which together constitute the core requirement information for this transportation task. Subsequently, this information is encapsulated into an internal transmission object, marking the successful completion of step S1 and preparing the data for the next step of route matching.

[0031] S2. Based on the transportation demand information, a standard route is matched from the pre-set standard route library as the execution basis for the logistics order, and the standard route is bound to the logistics order. The data structure of the standard route includes: multiple logistics nodes arranged in sequence, a node planning time window defined for each logistics node, and standard operating procedures associated with each node.

[0032] After obtaining the transportation demand information, the server immediately initiates the standard route matching and binding process. The core of this process is to select an optimal preset route for the current waybill from the persistently stored route resource library based on predetermined logic.

[0033] To achieve efficient matching, the server relies on a pre-built and populated standard routing library. Physically, this library typically manifests as one or more tables in a relational database, or as a dedicated search engine index. Each standard routing record is a structured data entity that fully describes a feasible logistics path from origin to destination. Each record not only contains a unique identifier but, more importantly, stores an ordered list of nodes that make up the path. A planned time window is explicitly defined for each node, and it is associated with a standard operating procedure document or set of instructions that the node should execute. These time windows typically include planned arrival and departure times, and the operating procedures may include loading and unloading requirements, sorting rules, and security checks.

[0034] The matching operation is performed by a dedicated service module on the server. This module receives the transportation demand information from the previous step and uses the origin code, destination code, cargo type code, and service timeliness requirements as a set of composite query conditions. Based on these conditions, the server initiates a query request to the standard routing library. The essence of the query is to find routes among all routing records that have a perfect match between the origin and destination codes, and whose preset cargo type compatibility and promised timeliness cover or equal the current demand. To improve query performance, the standard routing library creates database indexes on key fields such as origin and destination.

[0035] When the query returns results, three scenarios are possible. First, a single standard route that perfectly matches all constraints is found. Second, multiple candidate routes that meet the criteria are found. In this case, the server automatically filters based on preset secondary optimization rules, such as selecting the route with the shortest overall execution time, the fewest transfers, or the highest historical execution stability. Third, no routes that meet the criteria are found. This may trigger an exception handling process or a real-time route calculation process, but this is not the core scope of this step. After successfully selecting a standard route, the server performs a binding operation. The technical essence of binding is establishing a relationship between the current logistics waybill record and the selected standard route record in the business database. A typical implementation is to store the unique number of the standard route as a foreign key field in the waybill record. Another approach is to add a new record in a separate binding relationship table, recording both the waybill number and the route number. After this operation is completed, the standard route officially becomes the benchmark guiding all subsequent stages of this waybill.

[0036] For example, in the previous step, the server obtained the following transportation demand information: the origin code is "City North District Collection Center", the destination code is "City South District Distribution Station", the cargo type code is "Temperature-controlled medicines", and the service time requirement is "to arrive before 18:00 the next day".

[0037] The server's internal path matching service uses these four conditions for querying. Assuming the standard route database contains a record with the ID "SR_Med_North_South_NextDay", its origin field is "City North District Collection Center", its destination field is "City South District Distribution Station", its applicable goods type field includes "Temperature-Controlled Medicines", and its promised delivery time is "Next Day Delivery", then this route will be matched in the query.

[0038] Further examination of the data structure of this route reveals that its node sequence may be defined as follows: The first node, "North District Collection Center Cold Storage," has a planned time window of "08:00 to 09:00" and the operating procedure is "checking temperature control labels and packing"; the second node, "Intercity Cold Chain Trunk Line," has a planned time window of "09:30 to 11:30" and the operating procedure is "vehicle temperature monitoring"; the third node, "South District Distribution Cold Storage," has a planned time window of "12:00 to 13:00" and the operating procedure is "rapid sorting and transshipment"; and the fourth node, "South District Distribution Station," has a planned time window of "14:00 to 16:00" and the operating procedure is "door-to-door delivery and signing for receipts."

[0039] After the server selects this route, it will associate the internal tracking number of the waybill with the route number "SR_Med_North_South_NextDay" and write it into the database. At this point, the transportation route and standards for each stage of the shipment of medicines are officially determined.

[0040] S3. Based on the node sequence and node planning time window of the standard route, issue execution instructions to the corresponding logistics operation system in a serialized manner.

[0041] Once the server has bound the waybill to the standard route, it initiates an automated process that transforms the static route plan into dynamic work instructions. The goal of this process is to drive the various entities in the logistics network to collaborate in an orderly manner, based on established execution benchmarks.

[0042] The server first parses the bound standard routing data structure. It reads the node sequence and iterates through each logistics node in the sequence. For each node, the server combines the node's type attributes with a pre-built instruction template library to generate one or more specific, executable operation instructions. Each instruction contains at least several key elements: first, a clearly defined action, such as picking up, warehousing, sorting, or shipping; second, the target logistics operation system executing the instruction, such as a transportation management subsystem, a specific warehouse management system, or a carrier's interface platform; and third, a precise trigger time point or time range, derived from the node's planned time window, typically referring to the planned departure or arrival time.

[0043] Next, the server sorts all the instructions generated for this shipment in chronological order of their trigger times, forming an instruction queue arranged along a timeline. This queue represents the workflow of the entire transportation task over time.

[0044] Subsequently, an independently operating instruction scheduler begins operation. This scheduler continuously monitors the system clock and compares it with the trigger times in the instruction queue. When the system time reaches or is about to reach the preset trigger time of an instruction in the queue, the scheduler retrieves the instruction from the queue. The scheduler then sends the instruction content to the target system specified in the instruction through pre-established communication links between the server and various logistics operation systems, such as application programming interface calls or message brokers.

[0045] After an instruction is issued, the server expects to receive execution status feedback from the target operating system. This feedback may be asynchronous and serves to confirm that the instruction has been received and execution has begun. The server records the issuance status, time, and subsequent feedback for each instruction, thus forming the basis for digital tracking of the waybill execution process.

[0046] For example, the node sequence of a standard route is "Warehouse No. 1", "East China Land Transport Trunk Line", "Distribution Center No. 2", and "South City Distribution Station".

[0047] After the server parses the data, it generates an instruction for the "Warehouse No. 1" node. The instruction might be "Prepare for picking and packing," triggered at 8:00 AM, and received by the warehouse management system of Warehouse No. 1. Next, it generates an instruction for the "East China Land Transport Trunk Line" node, stating "Dispatch vehicles to arrive at Warehouse No. 1 for loading at 9:00 AM," triggered at 8:30 AM, and received by the trunk line transportation dispatch system. Finally, it generates an instruction for the "Distribution Center No. 2" node, stating "Goods are expected to arrive at 2:00 PM; please prepare for unloading," triggered at 12:00 PM, and received by the management system of Distribution Center No. 2.

[0048] The server arranges these instructions in the order of 8:00, 8:30, and 12:00. At 8:00 AM, the instruction scheduler sends picking instructions to the Warehouse 1 management system; at 8:30 AM, it sends dispatch instructions to the transportation scheduling system. After receiving the instructions, each system executes the corresponding operation and returns confirmation information to the server as "instruction received" or "operation started," thereby driving the physical flow of goods according to the predetermined plan.

[0049] Please see Figure 3 This is a flowchart illustrating a method for managing logistics waybills, as provided in this application embodiment. Figure 3 The flowchart in Figure 2 In addition to the above, the following steps are also included: S4. During the execution of the logistics waybill, collect the actual status data of the goods at each node of the standard route in real time. The actual status data includes at least the actual time window of the node.

[0050] Upon receiving the instruction, the server initiates a real-time sensing and data collection phase of the logistics waybill's physical movement. The core of this phase is establishing a continuous, automated data feedback channel from the physical world to the digital system to capture the real-time progress of the goods at every stage.

[0051] To achieve this goal, the server relies on deep integration with the operational systems of each logistics node. At each logistics node, such as a warehouse, distribution center, or transport vehicle, its corresponding operations management system is pre-configured or modified to automatically send status event messages to the server when critical business actions occur. These critical actions typically include goods arriving at the node, completing specific operations within the node, and goods leaving the node. Furthermore, IoT sensing devices deployed at the node sites, such as barcode scanners, access control sensors, or vehicle GPS terminals, can also be configured to send raw identification and location signals to the server directly or via an edge gateway.

[0052] Status event messages are organized according to a pre-agreed data format and communication protocol. Each message is essentially a structured data packet, which must contain several key data elements: first, an identifier that uniquely identifies a specific logistics waybill; second, the logistics node code where the event occurred; third, a clear event type enumeration value to distinguish different operational stages such as arrival, departure, sorting start, and loading completion; and fourth, a precise timestamp of the event, usually automatically recorded and filled in by the system or device that generated the event at the moment the event is triggered. These data elements together constitute the basic information reflecting the actual time window of the node.

[0053] The server-side features a dedicated event receiving and processing service. This service continuously receives asynchronous event message streams from nodes across the entire network by listening on open network ports or subscribing to message queues. For each arriving message, the receiving service first performs basic format verification and security authentication, then converts it into an internally unified data model and immediately transmits it to subsequent storage and analysis modules. Through this continuous aggregation, the server can synchronously reconstruct the movement trajectory and timeline of goods in the physical network within the digital space, providing factual evidence for subsequent monitoring and decision-making.

[0054] For example, a shipment is being transported from warehouse number one to distribution center number two according to the routing plan. When the vehicle carrying the shipment arrives at the gate of distribution center number two, the access control system automatically reads the RFID tag on the vehicle or the shipment and generates a status event message. This message includes the shipment number, the node code "distribution center number two", the event type "arrival", and the timestamp of the scan time, and is immediately sent to the server.

[0055] After unloading, the goods are transported to the sorting area. Operators use handheld terminals to scan the barcodes of the goods to confirm the start of the sorting operation. The handheld terminal system then generates a "Sorting Operation Started" event message, attaching a new timestamp, and sends it to the server. Once sorting is complete, the goods are placed on the loading platform for the next station. After confirming loading, the warehouse management system automatically triggers a "Departure" event message, recording the time of loading completion and reporting it.

[0056] Throughout the process, the server's event receiving service continuously collects these messages sent from the "Second Distribution Center" node. Based on the timestamps in the "Arrival" and "Departure" messages, the server accurately determines the actual arrival and departure times of the goods at that distribution center node, i.e., the node's actual time window. Simultaneously, the intermediate operation messages also enhance the transparency of how the goods are processed within that node.

[0057] S5. Compare the actual time window of the current node with the node's planned time window in the standard route to calculate the time deviation.

[0058] Once the server captures the actual status event of goods at a certain logistics node, it immediately triggers a real-time data comparison and calculation process. The purpose of this process is to quantify the difference between actual operational performance and preset execution benchmarks; its technical essence is a timestamp-based numerical calculation and comparison operation.

[0059] This process is executed by a dedicated real-time processing module on the server. When this module receives a status event message containing a waybill identifier, node code, and actual timestamp, it first quickly retrieves and loads the standard routing data structure bound to that waybill from memory or cache based on the waybill identifier. Next, the module uses the node code from the event message as the key to search through the node sequence of the standard route to locate the corresponding predefined node and obtain the node's pre-set planned time window. This planned time window typically includes two key time reference points: the planned arrival time and the planned departure time.

[0060] Subsequently, the comparison module selects the corresponding planned time base for comparison calculation based on the event type reported in the event message. If the event type is "goods arrival," the actual arrival timestamp in the message is compared with the planned arrival time of that node in the standard route. If the event type is "goods departure," the actual departure timestamp is compared with the planned departure time. The comparison operation is completed by calculating the difference between the two timestamps, and this difference is defined as the time deviation.

[0061] The calculated time deviation is a numerical value with a clear sign. Typically, if the actual timestamp is later than the planned time, the deviation is positive, indicating a delay; if the actual timestamp is earlier than the planned time, the deviation is negative, indicating the operation was completed ahead of schedule. This deviation value, along with information such as the waybill identifier and node code, is encapsulated into a comparison result data object. This result object is immediately output and transmitted to the downstream monitoring and decision analysis module of the server, providing direct quantitative evidence for whether to trigger early warnings or intervention measures.

[0062] For example, the server receives an event message showing that the goods with waybill number WB123456 have arrived at the node coded "Transit Hub Alpha", and the actual arrival timestamp is recorded as 2:05 PM.

[0063] The server's real-time processing module immediately took action. Based on the waybill number WB123456, it quickly located its corresponding standard route. In the node sequence of this route, it found the node definition coded as "Transit Hub Alpha" and read the planned time window for that node, where the planned arrival time was set to 2:00 PM.

[0064] Next, the module performs a comparison calculation. The actual arrival time of 2:05 PM is compared with the planned arrival time of 2:00 PM. The difference is calculated to be a time deviation of plus five minutes. This result clearly indicates that the goods' actual arrival time at this node was delayed by five minutes compared to the original plan.

[0065] Subsequently, a comparison result containing information such as "Waybill WB123456, node transit hub Alpha, deviation +5 minutes" was generated and immediately sent to the follow-up service responsible for monitoring and anomaly handling, informing them that an unplanned delay had occurred.

[0066] S6. If the time deviation exceeds the preset time threshold for that node, an abnormal warning message is generated, and based on the acquired current transportation network status data, the logistics waybill is re-routed from the next node, generating a backup route plan.

[0067] After calculating the time deviation, the server immediately enters a logical judgment and intelligent decision-making phase. This phase first assesses the severity of the deviation according to predefined rules. If it is determined to be abnormal, it simultaneously executes two key tasks: early warning and path regeneration.

[0068] Specifically, a threshold mapping table is stored in the server's memory or configuration center. This table presets the maximum acceptable time deviation value, i.e., the duration threshold, for different types of logistics nodes. The server compares the calculated time deviation value with the duration threshold corresponding to that node. If the absolute value of the time deviation exceeds the duration threshold, the node is determined to have malfunctioned.

[0069] Upon detecting an anomaly, the server first generates and distributes an alert. The alert is a structured data object that integrates at least the waybill identifier that triggered the anomaly, the node code where the anomaly occurred, the calculated time deviation, and the timestamp of the anomaly. The server pushes this alert to the monitoring center's visual dashboard in real time via its internal message bus or dedicated notification interface. It can also send it to relevant dispatchers or administrators via SMS or instant messaging tools according to configured rules, thus proactively exposing anomalies.

[0070] While generating the alert, the server simultaneously initiates a dynamic route replanning process. The goal of this process is to find a feasible new path for the waybill, continuing from the current node to its destination, in the event that the existing plan has been disrupted. The process first determines the starting point of the replanning, which is the direct successor node to the current abnormal node. Then, based on the current system time and the waybill's final promised delivery time, it recalculates the remaining available transportation time budget.

[0071] Subsequently, the server initiates a real-time data aggregation subprocess to retrieve current capacity network status data from multiple internal and external data sources. This includes querying the transportation management system to obtain subsequent trunk line services that have not yet departed and their remaining capacity, calling the map service interface to obtain real-time travel times for key road segments, and reading the current operational load status of major distribution centers. This dynamic data, together with the static network topology, constitutes a real-time updated network view.

[0072] The replanning engine uses a path search algorithm to calculate routes based on the new origin, destination, remaining time budget, cargo constraints, and the aforementioned real-time network view. Under the current constraints, the algorithm finds all feasible paths from the new origin to the original destination, and may rank these paths based on factors such as cost, reliability, or total time. Ultimately, it outputs one or more recommended paths, packaged into a complete alternative routing plan. This plan includes a new node sequence, estimated time windows for each node, and a description of the key changes compared to the original plan.

[0073] For example, a waybill at "Distribution Center A" node has a planned departure time of 1 PM, but the actual departure time deviation is calculated to be a delay of 40 minutes. The preset time threshold for this type of node is 30 minutes. After comparison, the server finds that the 40-minute deviation exceeds the 30-minute threshold and therefore determines it to be abnormal.

[0074] The server immediately generates an alert message stating that "Waybill WB789012 is delayed for forty minutes from leaving the distribution center at node A," and publishes this message to the monitoring screen and sends it to the line dispatcher's mobile phone.

[0075] Meanwhile, the replanning process was initiated. The next node, "Trail Route X," was determined as the new planning starting point. Calculations revealed that the originally scheduled connecting "Trail Route X" was unavailable due to the current delay. The process then queried real-time data and found that another "Trail Route Y," departing slightly later, still had available space, and its route from "Distribution Center A" to the next hub, "Distribution Center B," was currently unobstructed. The replanning engine calculated that using "Trail Route Y" would still meet the final delivery time requirement of the waybill. Therefore, a backup route plan was generated, the core of which was replacing "Trail Route X" with "Trail Route Y" in the original route, and recalculating the estimated arrival and departure times of all subsequent nodes starting from "Distribution Center B."

[0076] S7. Based on the backup routing plan, update the subsequent execution instructions of the logistics waybill and send them to the corresponding logistics operation system.

[0077] After generating the backup routing plan, the server immediately executes a dynamic workflow update and instruction switching process. The purpose of this process is to seamlessly and promptly transform the newly formulated emergency route plan into executable work commands, thereby guiding the physical flow of logistics orders from the original route to the new route.

[0078] The server first formally adopts the backup routing scheme as the current valid route for this waybill. At the data level, the server updates the routing association information for this waybill in memory and the database, using the new node sequence and its corresponding time window from the backup routing scheme to overwrite or replace all subsequent planned content starting from the next node in the original standard route. This means that the execution baseline of the waybill has been dynamically adjusted in the system.

[0079] Next, the server needs to process instructions that were previously generated based on the original route but have not yet been executed. The server sends a cancellation or invalidation notification to the instruction scheduler, targeting all pending instructions in the instruction queue that belong to that waybill and whose trigger time is later than the current time. Upon receiving the notification, the instruction scheduler removes these instructions from the pending execution queue and may optionally send a cancellation notification to the relevant job system to avoid triggering invalid operations.

[0080] Subsequently, the server initiates a new instruction generation process, consistent with the initial instruction orchestration logic, but with the updated backup routing scheme as input. The server parses the new node sequence from the backup routing scheme and generates corresponding operation instructions for each node, starting from the next node to be executed. These new instructions are triggered based on the estimated time window in the new scheme and their corresponding target job systems are clearly defined. All newly generated instructions are sorted and added to the instruction scheduler's execution queue.

[0081] Finally, the instruction scheduler continues operating based on the new queue. When the system time reaches the trigger time for a new instruction, the scheduler sends these instructions to the corresponding logistics operation system, such as the new transportation carrier system or the modified warehouse management system. Through this series of operations, all subsequent operations on the waybill will strictly follow the new backup routing scheme, thereby achieving dynamic remediation for abnormal situations and continuous process control.

[0082] For example, for a waybill that was previously delayed, the server generates a backup route to switch its subsequent trunk line transport from "Schedule X" to "Schedule Y".

[0083] The server first updates the data for the waybill, locking its subsequent path to a new route that includes "Schedule Y". Next, it notifies the dispatcher to cancel all pending instructions related to "Schedule X", such as "Load at the loading area of ​​Schedule X at 2 PM".

[0084] Then, the server generates a completely new sequence of instructions based on the new scheme. This includes generating a new instruction that reads "Load cargo at the designated platform for shift Y at 3:30 PM," with the trigger time set to 3:00 PM, and the receiving system updated to the transportation agent system responsible for "shift Y." Simultaneously, all subsequent forecast instructions from all nodes (such as the new distribution center) will also be recalculated and generated.

[0085] The dispatcher adds new instructions to the queue. At 3:00 PM sharp, the dispatcher sends the loading instructions to the new transportation agency system. Upon receiving the instructions, the transportation agency system arranges vehicles and personnel to execute them, thus successfully redirecting the actual transportation flow of the goods from the missed "shift X" to the available "shift Y," ensuring the continuity of the transportation task.

[0086] In one possible embodiment, S1, in response to the creation of a logistics waybill, obtaining the transportation demand information of the logistics waybill, including: S11. Receive a request sent through the preset logistics waybill creation interface. The request body encapsulates transportation demand information. S12. Deserialize the request body to extract the structured data object; S13. Read the values ​​of the origin code, destination code, cargo type code and service timeliness requirement fields from the structured data object.

[0087] In step S11, the server deploys and runs a network service application, providing a clear and stable interface for creating logistics waybills. This interface is represented by a specific Uniform Resource Locator (URL) at the network layer. When an upstream customer business system needs to initiate a logistics transportation entrustment, it, as a client, constructs a request according to predefined communication protocol specifications, such as Hypertext Transfer Protocol (HTTP). This request is directed to the network address and port that the server is listening on. The payload of the request, i.e., the request body, encapsulates all the required information for this transportation task according to a pre-agreed data organization format. The server-side network service framework or a custom request listener runs continuously, responsible for capturing requests arriving at this interface address. Once a valid network request is received, the server performs preliminary protocol parsing to confirm that its method type and header information are compliant. Subsequently, the complete request data, especially the request body containing business data, is handed over to the subsequent business logic processing module for in-depth processing.

[0088] In step S12, after obtaining the raw request body data containing transportation demand information, the server needs to convert it from a transmission format into a data structure that is easy for the program to manipulate and compute. This process is called deserialization. The request body is usually encapsulated in a common, structured text or binary format, such as a lightweight data exchange format or an extensible markup language. The server calls the corresponding parsing library or the built-in functions of the framework to perform syntactic analysis on the raw content of the request body. The parser recognizes the structural markers in the format, such as object start and end, key name and key value separators, etc., and reconstructs the linear, serialized byte stream or string into a hierarchical structured data object in memory based on these markers. This object is usually represented in the program logic as a mapping or an instance of a specific class, and its attribute names correspond to the key names in the request body. After deserialization, the transportation demand information is transformed from a network message format into a memory object that can be directly accessed and manipulated by the programming language.

[0089] In step S13, after successfully deserializing the request body into a structured data object, the server needs to precisely extract several core parameters necessary for subsequent route matching. The server accomplishes this by accessing specific attributes of the data object. The access method depends on the programming language and object type; a common practice is to retrieve the corresponding value using the attribute name as the key. The server will sequentially attempt to read the attributes representing the origin code, the destination code, the cargo type code, and the service timeliness requirement. To ensure the robustness of the process, the server typically performs simple checks before or after reading each attribute value, such as confirming that the attribute exists and its value is not empty. Finally, these four successfully read field values ​​are separated from the composite data object as independent, explicit data items, ready to trigger subsequent standard route query and matching processes.

[0090] In one possible embodiment, S2, based on transportation demand information, matching a standard route from a pre-set standard route library as the execution basis for the logistics waybill includes: S21. Using the origin code, destination code, cargo type code, and service timeliness requirements as joint query conditions, perform a query in the index of the standard route library to obtain one or more candidate standard routes; S22. If multiple candidate standard routes are obtained, one of them shall be selected as the execution benchmark according to the preset selection strategy. The preset selection strategy is to select the standard route with the highest priority score, the lowest benchmark cost, or the fewest number of nodes.

[0091] In step S21, after obtaining the specific field values ​​of the transportation demand information, the server initiates a query process against the pre-set standard routing database. The core of this process is to use a precise set of conditions to quickly locate the option that meets the conditions from a massive number of routing schemes.

[0092] Standard routing databases are typically built on relational databases or dedicated search engines, and incorporate composite indexes for frequently queried fields to optimize performance. The server combines four parameters—origin code, destination code, cargo type code, and service timeliness requirement—to form a complete query condition tuple. The routing query service on the server constructs a query statement targeting the standard routing database. The core logic of this statement requires that four conditions be met simultaneously: the origin code registered in the routing record must be exactly the same as the origin code in the query parameters; the destination code registered in the routing record must be exactly the same as the destination code in the query parameters; the set of applicable cargo types in the routing record must include the cargo type codes in the query parameters; and the timeliness level promised by the routing record must be greater than or equal to the service timeliness requirement in the query parameters.

[0093] The query is sent to the standard routing library for execution. Thanks to pre-built indexes, the database engine can efficiently retrieve the data and return a result set. This result set may be empty, indicating that no exact match was found; or it may contain one or more data records, each representing a candidate standard route that satisfies all constraints.

[0094] In step S22, when multiple candidate standard routes exist in the query result set, the server needs to automatically select one as the final execution benchmark. This decision relies on a set of pre-defined, configurable selection strategies.

[0095] The server maintains a policy configuration internally. This policy specifies the core metrics and sorting direction used when selecting the best route among multiple qualified routes. Common policies include, but are not limited to, the following: First, the highest priority score policy, which selects the route with the highest numerical value in the routing record called "priority score," which may take into account factors such as historical on-time performance and customer preferences; second, the lowest baseline cost policy, which selects the route with the lowest value in the "baseline cost" field of the routing record; and third, the fewest nodes policy, which selects the route with the fewest nodes in the routing node sequence in order to reduce transit links.

[0096] After obtaining multiple candidate routes, the server reads the corresponding metric field value from each candidate route based on the currently effective policy. Then, the server sorts all candidate routes according to this metric, ranking them in descending or ascending order if the policy is the highest or lowest. Finally, the candidate route ranked first in the sorting results is officially selected as the execution benchmark for the current logistics order.

[0097] In one possible embodiment, the method for managing logistics waybills further includes, S8. If no standard route is found in the standard route library based on the transportation demand information, the real-time route calculation engine is triggered to generate a new standard route based on the transportation demand information and the current capacity network status, and use it as the execution benchmark.

[0098] Step S8 describes a supplementary and extended mechanism to the core process of step S2, used to handle special scenarios where no ready-made solutions are available in the standard routing library.

[0099] If, in step S21, the server's query to the standard route database returns an empty result set, meaning no matching standard route was found, the system determines that a "route missing" event has occurred. In this case, the server will not simply return an error, but will trigger a more advanced real-time route calculation process as a backup plan.

[0100] The server wakes up or invokes a separate real-time routing calculation engine. This engine receives current transportation demand information as input. Simultaneously, the engine actively acquires and aggregates capacity network status data reflecting the real-time situation by calling multiple internal and external data interfaces, such as available transport schedules, real-time capacity of road segments, and current processing load at transshipment hubs. Based on this real-time dynamic information and the static network topology, the engine performs real-time calculations using complex path search and optimization algorithms. This calculation process attempts to find one or more feasible transportation routes under the hard constraints of meeting cargo characteristics and service timeliness requirements, and typically optimizes them based on objectives such as cost or timeliness.

[0101] After calculation, the engine outputs an optimal route. The server formats and encapsulates this dynamically generated route according to the standard routing data structure, and then directly assigns it to the current logistics waybill as the execution basis for this shipment. In addition, the system can selectively store this newly generated route back into the standard routing library after necessary review or annotation, thereby enriching the knowledge base and enabling the system to self-improve and learn.

[0102] In one possible embodiment, S3, based on the node sequence and node planning time window of the standard route, serializes and issues execution instructions to the corresponding logistics operation system, including: S31. Based on the preset node type-instruction template mapping relationship, generate at least one execution instruction for each node in the node sequence, and assign a trigger time based on the planned time window of that node to each instruction; S32. Sort all generated execution instructions according to their trigger times to form an instruction sequence; S33. Monitor system time: When the trigger time of the instruction arrives, send the instruction to the corresponding logistics operation system.

[0103] In step S31, after determining the execution basis of the waybill, i.e., the standard route, the server begins the automated orchestration of work instructions. The server maintains a predefined mapping configuration that associates various logistics node types with corresponding instruction templates. Node types include, for example, collection points, distribution centers, trunk transportation, and delivery stations. Each instruction template defines in detail the standard operating actions for that type of node, the target operating system required to execute the action, and the basic structure of the instruction content.

[0104] The server parses the node sequence in the standard route and processes each node sequentially. For each node in the sequence, the server first identifies its node type, and then finds one or more corresponding instruction templates based on the aforementioned mapping relationship. Next, the server fills the instruction template with the specific information of the current waybill, such as the waybill number, cargo details, and the node's specific attributes, such as the actual location code, thereby generating a specific, executable instruction instance. Subsequently, the server calculates a precise trigger time for each generated instruction based on the node's planned time window. For example, for a "distribution center arrival" node, whose planned time window includes the planned arrival time, the server may generate an "arrival forecast" instruction based on a preset lead time rule and set the trigger time to a fixed duration before the planned arrival time.

[0105] In step S32, after generating corresponding execution instructions for all nodes in the route, the server receives a set of instruction instances, each with its own independent trigger time. To ensure that the entire transportation process proceeds in an orderly manner strictly according to the time plan, the server needs to organize this set of instructions in a time sequence.

[0106] The server initiates a sorting process. It reads the trigger timestamp from each instruction instance and then sorts all instructions in ascending order based on the timestamps, with instructions triggered earlier appearing first and those triggered later appearing last. After this process, the previously loosely grouped instructions are organized into a linear, time-axis-arranged sequence. This sequence clearly shows the order and timing of the triggering of each operation instruction throughout the entire process from order initiation to completion, forming a digital workflow timeline.

[0107] In step S33, after the instruction sequence is generated, an independent scheduling mechanism is needed to ensure its timely execution. A resident instruction scheduling service runs on the server. The core function of this service is to monitor the system time and drive the sending of instructions. The instruction scheduling service continuously reads the system's real-time clock and compares the current time with the trigger time of the most recent instruction in the instruction sequence. When the system time reaches or exceeds the preset trigger time of an instruction, the scheduling service marks that instruction as "pending sending" from the sequence. Subsequently, the scheduling service calls the corresponding predefined application programming interface (API) based on the target operating system specified in the instruction. This API is a communication contract specifically agreed upon between the server and the target operating system for executing such instructions. The scheduling service encapsulates the specific content of the instruction according to the format required by the API and sends it to the target operating system via network call. In some implementations, after sending the instruction, the scheduling service also listens for feedback from the target system to confirm whether the instruction has been successfully received and processed, thereby updating the execution status of the instruction.

[0108] In one possible embodiment, S5, comparing the actual time window of the current node with the planned time window of the corresponding node to calculate the time deviation, includes: S51. Receive node event message streams containing waybill number, node code, event type, and actual timestamp in real time; S52. Obtain the corresponding execution baseline by querying the waybill number, and match the corresponding node plan time window from the execution baseline by the node code; S53. Based on the event type, calculate the difference between the actual timestamp and the latest planned time in the node's planned time window to obtain the time deviation.

[0109] In step S51, the server establishes a continuous event listening and receiving mechanism to acquire discrete status signals reflecting the progress of cargo transportation in real time. At each operational node of the logistics network, such as warehouses, transfer stations, or transportation vehicles, the deployed business systems or IoT devices immediately generate a structured status report, i.e., a node event message, upon completion of a critical action. These messages are continuously sent to the server via asynchronous transmission methods, such as through message middleware or direct network interface calls. Each message, as an independent data unit, has a standardized definition of content, which must include a unique waybill number that can trace the specific transportation task, a node logical code identifying the location of the event, an event type enumeration value describing what action occurred, and a timestamp recording the exact time the action occurred. The server has a dedicated event ingestion service that continuously listens to the designated communication channel, continuously receiving these event messages and converting them into an internally unified format, forming an ordered or parallel node event message stream, providing a data source for subsequent real-time processing.

[0110] In step S52, after receiving a node event message, the server needs to immediately associate and compare it with the pre-defined transportation plan. This process begins with data association and retrieval. The server first extracts the waybill number from the event message and uses it as the primary key to quickly query the waybill management database or cache to retrieve the execution baseline followed by the waybill at the current moment, which fully records the sequence of all planned nodes and their time windows. Next, the server extracts the node code from the same event message and uses this code as the index key to search and match within the node sequence of the recently retrieved execution baseline. Through matching, the server can locate the planned node corresponding to the event and fully read the pre-set planned time window data for that node, which includes key baseline values ​​such as the latest planned time. The entire query and matching process requires high efficiency and low latency to ensure real-time monitoring.

[0111] In step S53, after successfully associating with the execution benchmark, the server executes the core time deviation calculation logic. The calculation varies depending on the specific type of event to ensure the benchmark for comparison is correct. The server reads the event type field from the event message. If the event type indicates an "arrival" event, such as goods arriving or a vehicle entering the site, the server takes the actual timestamp from the event message and subtracts it from the "planned latest arrival time" in the node's planned time window obtained in step S52. If the event type indicates a "departure" event, such as goods leaving the site or a vehicle departing, the server subtracts the actual timestamp from the "planned latest departure time." The difference obtained is the time deviation value. This deviation value is a signed numerical value; typically, a positive number indicates that the actual occurrence time is later than the planned latest time (i.e., a delay), while zero or a negative number indicates on time or earlier than the planned latest time. This deviation value, along with context information, is encapsulated into a calculation result and output to the downstream early warning judgment module.

[0112] In one possible embodiment, see Figure 4 The diagram shows the process of generating an alternative routing scheme.

[0113] S6. Based on the acquired current transportation network status data, re-plan the route for the logistics waybill starting from the next node, including: S61. Determine the planning starting point as the subsequent node of the current abnormal node and the final destination of the waybill as the ending point, and calculate the remaining transportation time budget based on the current time.

[0114] S62. Obtain real-time status data that constitutes the dynamic transportation network.

[0115] S63. In a dynamic transportation network, a graph search algorithm constrained by the remaining transportation time budget is executed to obtain one or more feasible paths from the origin to the destination. The graph search algorithm follows the principle of minimum perturbation and prioritizes searching for feasible paths with the highest overlap with the original standard routing node sequence.

[0116] S64. Based on the preset optimization objectives, perform a comprehensive evaluation and ranking of feasible paths, and generate a backup routing scheme that includes a primary recommended path.

[0117] In step S61, when the server determines that the current node is abnormal and initiates replanning, it first needs to clearly define the calculation scope and time constraints of the new path. Starting from the node that is currently abnormal, the server locates the direct successor node of the abnormal node in its bound standard routing node sequence and establishes this successor node as the starting point for replanning the path. The destination of the transportation remains unchanged, i.e., the destination originally specified in the waybill. Subsequently, the server calculates the remaining transportation time budget. The server takes the final promised delivery time of the waybill, subtracts the current system time, and obtains a preliminary total remaining time. Then, the server subtracts a pre-set standard buffer time necessary for end-of-line operations at the destination (such as last-mile delivery and customer signature) from this total remaining time. The final duration is the net remaining time budget that can be used to plan trunk and transit transportation from the new starting point to the destination. This budget is a core constraint that subsequent path search must satisfy.

[0118] For example, a waybill's final promised delivery time is 6 PM the following day. The current system time is 3 PM today, and the "Distribution Center A" node where the current shipment is located has experienced an anomaly. The server determines that the next planned node of "Distribution Center A," "Trunk Bus X," is the new planning starting point, with the destination remaining the original destination, "City B." The total remaining time is calculated to be 27 hours (from 3 PM today to 6 PM the following day). Subtracting the standard buffer time of 3 hours for last-mile delivery, the net remaining time budget for route planning from "Trunk Bus X" to "City B" before entry into the city is 24 hours.

[0119] In step S62, to perform effective real-time planning, the server must construct a dynamic transportation network view reflecting the current situation. The server aggregates real-time status information by calling various data interfaces. On one hand, the server calls the application programming interface (API) of the internal transportation management system to query available transportation resources, such as subsequent buses that have not yet departed, specific flight times, remaining cargo capacity, and current location. On the other hand, the server calls external traffic data service interfaces to obtain real-time traffic information, estimated travel times, and potential traffic control or weather impacts for major transportation routes. This real-time data from different sources, combined with the static topology of the logistics network, defines a dynamically changing weighted network graph. In this graph, nodes represent logistics facilities, and the weights of the edges (such as travel time and transportation costs) are continuously updated based on real-time data.

[0120] Continuing the previous example, when planning, the server first calls the internal schedule query interface to obtain all available trunk line services departing from the vicinity of "Distribution Center A" and heading towards "City B," along with their departure times, estimated journey times, and remaining cargo space. Simultaneously, it calls the external map service interface to obtain the current highway congestion status and estimated travel times for these service routes. Furthermore, it may also query the real-time traffic restrictions on major freight routes entering "City B." All this real-time information is integrated to accurately assess the current actual capacity of each potential route.

[0121] In step S63, the server uses the dynamic network graph constructed in step S62 and the constraints determined in step S61 to initiate the path search algorithm. This algorithm treats the network graph as a graph structure composed of nodes and edges, with the new starting point as the source and the final destination as the sink. During execution, the algorithm uses the "net remaining time budget" as a hard constraint, expanding only paths whose cumulative estimated time does not exceed this budget. Specifically, the algorithm follows the "minimum perturbation" principle for optimization. This means that when evaluating paths, the algorithm prioritizes options with high overlap with the original standard route node sequence. For example, the algorithm tends to select paths that utilize as many planned subsequent nodes as possible, or only replace local road segments that are unusable due to anomalies, rather than performing a global, disruptive replanning, to reduce the impact on already allocated resources and subsequent processes.

[0122] For example, in a dynamic network, starting from a new origin "mainline bus X" (which has been missed) and heading towards the destination "city B," the algorithm begins its search. It finds a slightly later departure "mainline bus Y" also heading towards "city B," and its transfer node upon arrival is the same as the original route plan. Although another completely different path exists, detouring through other hubs, the algorithm prioritizes "mainline bus Y" as a feasible path for preservation and evaluation because its path has a higher degree of overlap with the subsequent node sequence of the original route, adhering to the principle of minimum perturbation.

[0123] In step S64, after finding one or more feasible paths that meet the time budget, the server needs to select the optimal solution. Based on preset optimization objectives, the server performs a multi-dimensional comprehensive evaluation of each feasible path. Evaluation metrics typically include the path's total estimated time (which must be shorter than the remaining time budget), total transportation cost, path reliability score (based on historical punctuality or real-time traffic stability), and potential additional operational costs due to path changes. The server assigns weights to each metric and calculates a comprehensive score for each path. Subsequently, all feasible paths are ranked according to their comprehensive scores. Finally, the server selects the top-ranked path as the primary recommended path and encapsulates its detailed information, along with a new node sequence and node time windows estimated based on real-time data, into a complete and directly replaceable backup routing solution.

[0124] Suppose the search yields two feasible paths: Path 1 uses "mainline train Y," with a total travel time of 22 hours, lower cost, and high overlap with the original route; Path 2 uses a "high-speed rail plus shuttle" solution, with a total travel time of 20 hours, but higher cost and the need to activate a completely new transfer node. If the system's preset optimization objective is "cost priority," then Path 1 has a higher overall score and is determined as the primary recommended path. Based on this, the server generates a backup routing plan, specifying the new execution sequence as: shuttle from the current distribution center to the loading point of "mainline train Y," with subsequent execution proceeding according to the original planned nodes.

[0125] In one possible embodiment, the comprehensive evaluation in step S64 includes: S641. Calculate the estimated total time, total cost, reliability score, and additional cost of route change for each feasible path; S642. The probability of secondary delay risk for each feasible path in the future time period is used as an evaluation indicator for ranking. The probability of risk is output by a prediction model trained with historical data.

[0126] In step S641, the server performs a multi-dimensional quantitative evaluation of each feasible path to support the final optimization decision. The evaluation first calculates the estimated total time for the path. Based on the real-time weights of edges in the dynamic transportation network, the server accumulates the estimated time for all segments (including transportation and transfer operations) from the planned origin to the final destination to obtain the total time for the path under the current network conditions. Next, the total cost is calculated. The server summarizes all costs involved in the path, including transportation costs, transfer processing fees, and other possible surcharges. This cost data comes from internal fare tables or real-time quotation interfaces from external suppliers. Then, the path's reliability score is evaluated. Based on historical execution data, the server calculates the planned achievement rate or on-time rate of the path or its key segments and nodes over a past period, converting this statistical value into a reliability score. In addition, the server needs to estimate the additional costs associated with path changes. This cost quantifies the additional expenses that may arise from switching to a new path, such as cancellation fees for already scheduled resources, expedited fees for newly launched resources, or additional management and coordination costs. By calculating the above four indicators, the server constructs a preliminary quantitative profile for each path.

[0127] For example, for a feasible alternative route "Hub A -> Trunk Line B -> Hub C", the server first queries real-time data: the current travel time from A to B, the travel time of the trunk line service, and the standard operating time at Hub C, summing these to obtain a total travel time of 18 hours. Next, it queries the freight cost of the trunk line service and the standard operating fees of both hubs, summing these to obtain the total cost. Then, it retrieves data from the historical database showing that the on-time rate of the trunk line service over the past month was 95%, and the delay rate at Hub C was less than 5%, resulting in a reliability score of 90 points (out of 100) for this route. Finally, it assesses the penalty incurred due to cancelling the originally scheduled cargo space at the other hub by switching to this route, recording this as an additional cost for the change.

[0128] In step S642, to enhance the foresight and risk avoidance capabilities of decision-making, the server introduces a predictive metric based on machine learning—the probability of future secondary delays—in addition to traditional evaluation metrics. The server internally deploys a trained predictive model, trained on a large amount of historical transportation data (such as historical delay records, weather-related data, and holiday traffic data). When evaluating several feasible paths, the server inputs the feature data of each path into the model. This feature data includes the path's constituent nodes, the planned future time period, currently acquired weather warnings, and associated transport providers. After analyzing these features, the predictive model outputs a probability value between 0 and 1, representing the likelihood of new, unplanned delays occurring during the path's future execution. Subsequently, the server uses this risk probability as an important negative evaluation metric, participating in the comprehensive evaluation and ranking along with other metrics. Paths with higher risk probabilities are penalized more severely in the ranking, thus guiding the system to prioritize robust paths that are not only currently feasible but also have lower future risks.

[0129] Continuing the example, when evaluating the "A Hub -> B Trunk Line -> C Hub" route, the server extracts the following features: the route includes "B Trunk Line," it is planned to pass through "a certain mountainous section" tomorrow afternoon, and the weather forecast indicates a rain warning for that section during that time period. The server inputs these features into a pre-trained delay risk prediction model. After analyzing historical data, the model finds that under similar conditions, "B Trunk Line" has a higher probability of delays due to weather in that section, therefore outputting a secondary delay risk probability of 0.7 (i.e., 70%). In the final ranking, although other indicators are acceptable, this route will be ranked lower due to this high-risk indicator, prompting the system to potentially choose an alternative route with a lower risk probability.

[0130] The following are embodiments of the apparatus of this application, which can be used to execute the embodiments of the method of this application.

[0131] Please see Figure 5 This illustration shows a schematic diagram of a logistics waybill management device provided in an exemplary embodiment of this application, hereinafter referred to as device 5. Device 5 can be implemented as all or part of a server through software, hardware, or a combination of both. Device 5 includes: The acquisition module 501 is used to acquire the transportation demand information of the logistics waybill in response to its creation; wherein the transportation demand information includes at least: origin code, destination code, cargo type code and service timeliness requirements; The binding module 502 is used to match a standard route from a pre-set standard route library as the execution basis for the logistics order based on the transportation demand information, and bind the standard route to the logistics order; wherein, the data structure of the standard route includes: multiple logistics nodes arranged in sequence, a node planning time window defined for each logistics node, and standard operation specifications associated with each node; The issuing module 503 is used to serialize and issue execution instructions to the corresponding logistics operation system according to the node sequence and node planning time window of the standard route.

[0132] For further details regarding the implementation of the above technical solution by each module in the above logistics waybill management device, please refer to the description in the logistics waybill management method provided in the above-mentioned embodiments of the invention, which will not be repeated here.

[0133] See Figure 6 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., ... Figure 6 The computer program shown above), the instructions are adapted to be loaded and executed by a processor as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0134] This application also provides a computer program product that stores at least one instruction, which is loaded and executed by the processor to implement the logistics waybill management method described in the above embodiments.

[0135] Please see Figure 7 This provides a schematic diagram of a server structure for an embodiment of this application. For example... Figure 7 As shown, the server 700 may include: at least one processor 701, at least one network interface 704, a user interface 703, a memory 705, and at least one communication bus 702.

[0136] The communication bus 702 is used to enable communication between these components.

[0137] The user interface 703 may include input units such as a mouse and keyboard.

[0138] The network interface 704 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0139] The processor 701 may include one or more processing cores. The processor 701 connects to various parts of the server 700 via various interfaces and lines, and performs various functions and processes data of the server 700 by running or executing instructions, programs, code sets, or instruction sets stored in the memory 705, and by calling data stored in the memory 705. Optionally, the processor 701 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 701 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 701 and may be implemented as a separate chip.

[0140] The memory 705 may include random access memory (RAM) or read-only memory. Optionally, the memory 705 may include a non-transitory computer-readable storage medium. The memory 705 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 705 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 705 may also be at least one storage device located remotely from the aforementioned processor 701. Figure 7 As shown, the memory 705, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0141] exist Figure 7In the server 700 shown, the user interface 703 is mainly used to provide an input interface for the user and obtain the user input data; while the processor 701 can be used to call the application program stored in the memory 705 and specifically execute, such as Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0142] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0143] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for managing logistics waybills, characterized in that, The method includes: In response to the creation of a logistics waybill, the transportation demand information of the logistics waybill is obtained; wherein, the transportation demand information includes at least: origin code, destination code, cargo type code, and service timeliness requirements; Based on the transportation demand information, a standard route is matched from a pre-set standard route library as the execution basis for the logistics order, and the standard route is bound to the logistics order; wherein, the data structure of the standard route includes: multiple logistics nodes arranged in sequence, a node planning time window defined for each logistics node, and standard operation specifications associated with each node; Based on the node sequence and node planning time window of the standard route, execution instructions are serialized and issued to the corresponding logistics operation system.

2. The method according to claim 1, characterized in that, Also includes: During the execution of the logistics waybill, the actual status data of the goods at each node of the standard route is collected in real time, and the actual status data includes at least the actual time window of the node; The actual time window of the current node is compared with the node's planned time window in the standard route to calculate the time deviation. If the time deviation exceeds the preset time threshold for that node, an abnormal warning message is generated, and based on the acquired current transportation network status data, the route for the logistics order is replanned from the next node, generating an alternative route scheme. Based on the backup routing scheme, update the subsequent execution instructions of the logistics waybill and send them to the corresponding logistics operation system.

3. The method according to claim 1, characterized in that, The step of matching a standard route from a pre-set standard route library as the execution basis for the logistics order based on the transportation demand information includes: Using the origin code, destination code, cargo type code, and service timeliness requirements as joint query conditions, a query is performed in the index of the standard route library to obtain one or more candidate standard routes; If multiple candidate standard routes are obtained, one of them is selected as the execution benchmark according to a preset selection strategy; wherein, the preset selection strategy is: to select the standard route with the highest priority score, or the lowest benchmark cost, or the fewest number of nodes.

4. The method according to claim 1, characterized in that, The step of serializing and issuing execution instructions to the corresponding logistics operation system based on the node sequence and node planned time window of the standard route includes: Based on the preset node type-instruction template mapping relationship, at least one execution instruction is generated for each node in the node sequence, and each instruction is assigned a trigger time based on the planned time window of that node; All generated execution instructions are sorted according to the trigger time to form an instruction sequence; The system monitors the time and, when the trigger time for an instruction arrives, sends the instruction to the corresponding logistics operation system.

5. The method according to claim 2, characterized in that, The step of comparing the actual time window of the current node with the planned time window of the corresponding node to calculate the time deviation includes: Receive node event message streams in real time, including waybill number, node code, event type, and actual timestamp; The corresponding execution baseline is obtained by querying the waybill number, and the corresponding node plan time window is matched from the execution baseline by the node code; Based on the event type, the difference between the actual timestamp and the latest planned time in the node's planned time window is calculated to obtain the time deviation.

6. The method according to claim 2, characterized in that, The process of rerouting the logistics waybill from the next node based on the acquired current transportation network status data includes: Determine the starting point of the planning process based on the subsequent nodes of the current abnormal node and the final destination of the waybill as the endpoint, and calculate the remaining transportation time budget based on the current time. Obtain real-time status data that constitutes the dynamic transportation network; In the dynamic transportation network, a graph search algorithm constrained by the remaining transportation time budget is executed to obtain one or more feasible paths from the origin to the destination; wherein, the graph search algorithm follows the principle of minimum perturbation, prioritizing the search of feasible paths with the highest overlap with the original standard routing node sequence; Based on preset optimization objectives, the feasible paths are comprehensively evaluated and ranked to generate a backup routing scheme that includes a primary recommended path.

7. The method according to claim 6, characterized in that, The comprehensive evaluation includes: Calculate the estimated total time, total cost, reliability score, and additional cost of route change for each feasible path; The probability of secondary delay risk for each feasible path in the future time period is used as an evaluation indicator for ranking. The probability of secondary delay risk is output by a prediction model trained with historical data.

8. A control device for logistics waybills, characterized in that, include: The acquisition module is used to acquire the transportation demand information of the logistics waybill in response to its creation; wherein the transportation demand information includes at least: origin code, destination code, cargo type code, and service timeliness requirements; The binding module is used to match a standard route from a pre-set standard route library as the execution basis for the logistics order based on the transportation demand information, and bind the standard route to the logistics order; wherein, the data structure of the standard route includes: multiple logistics nodes arranged in sequence, a node planning time window defined for each logistics node, and standard operation specifications associated with each node; The delivery module is used to serialize and deliver execution instructions to the corresponding logistics operation system according to the node sequence and node planning time window of the standard route.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the steps of the method as described in any one of claims 1 to 7.

10. A server, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the method as described in any one of claims 1 to 7.

Images