A vehicle or goods delivery task graph automatic scheduling and inventory property linkage method and system

Abstract

This invention belongs to the field of information processing technology for vehicle or cargo delivery management, and discloses a method and system for automatically arranging vehicle or cargo delivery task diagrams and linking inventory ownership. The method reads contract items, business type, item identifier, warehouse location, delivery method, and ownership processing requirements when a sales contract takes effect, generating a directed graph of delivery tasks. Based on contract items, item identifiers, and warehouse locations, a unique occupancy key is generated, establishing an inventory occupancy record. The inventory occupancy status, delivery node execution status, and ownership status are written into the same delivery status fact table. Before the dispatch or outbound node is triggered, the inventory occupancy status and ownership status are verified. In case of node anomalies, inventory occupancy is released or restored, subsequent nodes are blocked, and the expected completion time is recalculated. This method can reduce the probability of delivery process misordering, duplicate inventory occupancy, and inconsistent ownership status.

Description

Technical Field

[0001] This invention belongs to the field of information processing technology for vehicle or cargo delivery management, specifically involving a method and system for automatic arrangement of vehicle or cargo delivery task diagrams and linkage with inventory ownership, applicable to business scenarios such as vehicle inspection, shipment, outbound delivery, vehicle pickup, ownership transfer, transfer confirmation, and inventory occupancy control after the sales contract takes effect. Background Technology

[0002] In vehicle sales, equipment sales, bulk cargo sales, and supply chain delivery scenarios, after a sales contract is signed, multiple delivery stages typically need to be processed sequentially or in parallel, including inventory locking, vehicle inspection application, shipment application, delivery, vehicle pickup confirmation, transfer of ownership, and registration / ownership confirmation. These stages are often handled by contract management systems, inventory management systems, warehouse management systems, transportation management systems, vehicle inspection systems, financial systems, and ownership management systems. These stages are not only sequentially dependent but also have status verification and anomaly rollback relationships. For example, if a vehicle fails inspection, shipment or delivery should generally not proceed; if payment, credit approval, or ownership status is not met, actual delivery should generally not occur; and if shipment is canceled or delayed, the expected completion time for subsequent stages such as vehicle pickup and ownership transfer needs to be adjusted accordingly.

[0003] Existing technologies include business flow orchestration schemes based on directed acyclic graphs (DAGs). Chinese patent CN117474312A discloses a visual business flow orchestration method. This method configures business flows and business flow node information based on a DAG, converts the node information into dynamic scripts, and stores them. After a third-party system calls the published business flow interface, the business flow engine controls the sequential or reverse execution of nodes based on their execution status, and performs resource submission and recycling operations after the process ends. This type of scheme can be used for node orchestration and execution control of general business processes.

[0004] However, in vehicle or cargo delivery scenarios, simply using general business flow orchestration is insufficient to fully address the consistency issues between contract items, specific goods, warehouse locations, inventory holdings, and ownership status. In actual operations, the same vehicle identification number, equipment serial number, cargo batch number, or warehouse unit code may be repeatedly referenced by multiple contracts or delivery tasks; inventory lock status, outbound status, and ownership status may be stored in different systems, making it impossible to complete consistency verification based on the same data source when executing dispatch or outbound nodes; when vehicle inspection fails, dispatch is canceled, outbound is rejected, or ownership transfer fails, subsequent nodes may still be manually or systematically continued, resulting in problems such as incorrect delivery order, duplicate inventory holdings, inconsistencies between ownership status and physical delivery status, and delayed reminders.

[0005] Therefore, there is a need to provide a solution for automatic task graph arrangement and inventory ownership linkage for vehicle or goods delivery business, so that delivery nodes after the sales contract takes effect can be automatically generated based on the contract fields, and the inventory occupancy status, delivery node execution status and ownership status can be linked and verified in a unified data structure to reduce the risks of manual process omissions, sequence errors, duplicate occupancy and inconsistent status. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for automatically arranging vehicle or cargo delivery task diagrams and linking them with inventory ownership, in order to solve the problems of complex delivery node dependencies after the sales contract takes effect, easy omissions or misordering of manually initiated processes, possible duplicate occupation of inventory, and possible inconsistencies between ownership status and outbound status.

[0007] To achieve the above-mentioned technical objectives, the present invention provides the following technical solution.

[0008] In a first aspect, the present invention provides a method for automatically arranging vehicle or cargo delivery task maps and linking them with inventory ownership, executed by a server, characterized by comprising:

[0009] S1. When the sales contract takes effect, read the contract delivery field, including contract items, item identifier, and warehouse location, and generate a delivery control vector;

[0010] S2. Based on the delivery control vector matching node template, generate a directed graph of delivery tasks including multiple delivery nodes, and write the preconditions, release conditions and rollback conditions.

[0011] S3. Determine the inventory occupancy range of the contract item based on the delivery control vector, generate a unique occupancy key using the item identifier, warehouse location, and inventory occupancy range, and establish an inventory occupancy record; when there are inventory occupancy records with the same resource occupancy key or overlapping occupancy range and which have not been released, refuse to establish a new inventory occupancy record, and write the contract item identifier, unique occupancy key, inventory occupancy record, delivery node execution status, and property rights status record into the same delivery status fact table;

[0012] S4. Trigger nodes that meet the preconditions according to the directed graph of the delivery task. Before triggering the target node involving physical flow, read the inventory occupancy status and ownership status of the unique occupancy key from the delivery status fact table. If the two do not meet the release conditions at the same time, block the target node.

[0013] S5. When a delivery node returns an abnormal result, update the delivery status fact table according to the rollback conditions, release or restore the inventory occupancy record, block subsequent nodes that depend on the abnormal delivery node, and recalculate the expected completion time of the subsequent node based on the updated inventory occupancy status, ownership status, and completed node time.

[0014] Specifically, in step S1, the contract delivery field also includes one or more of the following: business type field, buyer field, seller field, purchase order field, delivery method field, ownership processing requirement field, and delivery period field;

[0015] The item identification includes one or more of the following: vehicle identification number, equipment serial number, goods batch number, and storage unit code;

[0016] The ownership processing requirements include one or more of the following: vehicle registration and transfer requirements, goods ownership confirmation requirements, and property transfer application requirements.

[0017] The delivery control vector includes a contract item identifier field, an item identifier field, a warehouse location field, a delivery method field, an ownership processing requirement field, and a delivery deadline field.

[0018] Specifically, in step S2, the node template includes one or more of the following: vehicle delivery template, goods delivery template, and inventory transfer delivery template;

[0019] The vehicle delivery template includes multiple nodes such as inventory locking node, vehicle inspection node, transportation arrangement node, outbound node, vehicle pickup node and ownership processing node, and the ownership processing node includes property transfer node and / or transfer confirmation node.

[0020] The goods delivery template includes multiple nodes such as inventory locking node, transportation arrangement node, outbound node, receipt confirmation node, and ownership processing node.

[0021] The inventory transfer and delivery template includes multiple nodes such as the inventory lockout node, transfer application node, inventory release node, inventory import node, and inventory ownership update node.

[0022] The server selects the corresponding node template based on the delivery control vector and deletes or marks optional delivery nodes that do not match the current sales contract.

[0023] Specifically, in step S3, the inventory occupancy range includes one or more of the following: vehicle unit, equipment unit, storage unit, and quantity range within a batch of goods.

[0024] The inventory occupancy record includes a unique occupancy key, contract item identifier, item identifier, warehouse location, inventory occupancy range, occupancy quantity, occupancy status, occupancy source, occupancy validity period, and release identifier;

[0025] The occupancy status includes pending lock, locked, pending review, released, and expired;

[0026] When the validity period of an inventory occupancy record expires and the corresponding delivery task directed graph has not entered the target node involving physical flow, the server updates the occupancy status of the inventory occupancy record to pending review and suspends the triggering of the subsequent node corresponding to the inventory occupancy record.

[0027] Specifically, the delivery status fact table includes a unique occupancy key field, a contract item field, an item identifier field, a warehouse location field, an inventory occupancy range field, an inventory occupancy status field, a current delivery node field, a delivery node execution status field, an ownership status field, an anomaly identifier field, and an expected completion time field.

[0028] The property rights status includes unconfirmed, pending transfer, transferred, transfer failed, and frozen;

[0029] The server uses the unique occupancy key field as the association field for reading the inventory occupancy status field and the ownership status field, so that the target node and ownership processing node involved in physical flow can perform status verification based on the same delivery status fact table.

[0030] Specifically, the prerequisites include one or more of the following: inventory occupancy conditions, vehicle inspection results conditions, payment or credit conditions, transportation resource conditions, property rights status conditions, and vehicle registration and transfer information conditions;

[0031] The target nodes involved in the physical flow of goods include the shipping node and / or the outbound node;

[0032] When the target node is a shipping node, its release conditions include the inventory occupancy status being locked, the vehicle inspection node execution status being passed, and the transportation resource conditions being met.

[0033] When the target node is an outbound node, its release conditions include the inventory occupancy status being locked, payment or credit conditions being met, and the ownership status being pending transfer or already transferred.

[0034] The release conditions for the ownership processing node include the fulfillment of payment or credit conditions, and the completion status of the outbound node or delivery confirmation node.

[0035] Specifically, the rollback conditions include one or more of the following: vehicle inspection failure, transportation arrangement cancellation, shipment delay exceeding the preset time limit, vehicle pickup exceeding the time limit, outbound rejection, failure of transfer of ownership, and failure of transfer confirmation.

[0036] When the vehicle inspection node returns a failure result, the server updates the inventory usage record to be released and updates the subsequent nodes that depend on the vehicle inspection node to the blocked state.

[0037] When the transportation scheduling node or the shipping node returns a cancellation result, the server restores the inventory holding record to locked and updates the subsequent nodes that depend on that node to a pending re-orchestration state.

[0038] When the ownership transfer node returns a failure result, the server updates the ownership status record to transfer failure, keeps the execution status of the completed outbound node or the completed delivery confirmation node from being overwritten, and updates the subsequent nodes that depend on the ownership transfer node to the blocked state.

[0039] Specifically, in step S5, recalculating the expected completion time of the successor node includes:

[0040] Identify delivery nodes that return abnormal results as abnormal delivery nodes;

[0041] Based on the dependency edges from the abnormal delivery node to the successor node in the directed graph of the delivery task, determine the set of affected successor nodes;

[0042] Read the abnormal result time, completed node time, inventory status, ownership status, delivery method and delivery deadline of the abnormal delivery node;

[0043] Update the earliest triggerable time and expected completion time of each successor node in the order of their dependencies in the affected successor node set.

[0044] When the updated expected completion time exceeds the delivery deadline, a delivery delay notification is generated, and the corresponding delivery task directed graph is marked as requiring manual confirmation.

[0045] In a second aspect, the present invention also provides an automatic vehicle or cargo delivery task map arrangement and inventory ownership linkage system, used to implement the automatic vehicle or cargo delivery task map arrangement and inventory ownership linkage method described in the first aspect, the system comprising:

[0046] The contract parsing module is used to execute step S1;

[0047] The task graph orchestration module is used to execute step S2;

[0048] The inventory ownership linkage module is used to execute step S3;

[0049] The node execution module is used to execute step S4;

[0050] The exception rollback module is used to execute step S5.

[0051] Thirdly, the present invention also discloses a computer-readable storage medium having a computer program or instructions stored thereon, wherein when the computer program or instructions are executed by a processor, the method for automatic arrangement of vehicle or cargo delivery task maps and linkage of inventory ownership described in the first aspect is implemented.

[0052] This invention reads fields such as contract items, item identification, warehouse location, delivery method, and ownership processing requirements when a sales contract takes effect. It generates a delivery control vector and matches it with node templates to form a directed graph of delivery tasks. This allows nodes such as inventory locking, vehicle inspection, shipment, outbound delivery, vehicle pickup, ownership transfer, and ownership confirmation to automatically flow according to preconditions, release conditions, and rollback conditions. By determining the inventory occupancy range of contract items based on the delivery control vector, a unique occupancy key is generated using the item identification, warehouse location, and inventory occupancy range. The inventory occupancy status, delivery node execution status, and ownership status are recorded in the same delivery status fact table. The server can perform unified verification before the shipment or outbound node is triggered, thereby reducing the possibility of the same vehicle or goods being repeatedly occupied or incorrect outbound or shipment due to unmet ownership status. When any delivery node returns an abnormal result, the server releases or restores the inventory occupancy record according to the rollback conditions, blocks subsequent nodes dependent on the abnormal node, and recalculates the expected completion time of subsequent nodes, which helps maintain consistency between the delivery process, inventory occupancy, and ownership status. Attached Figure Description

[0053] Figure 1 This is a flowchart illustrating the automatic arrangement of vehicle or cargo delivery task diagrams and the linkage of inventory ownership according to the present invention.

[0054] Figure 2 This is a schematic diagram illustrating the data association between the directed graph of the delivery task, the unique occupancy key, the inventory occupancy record, the property rights status record, and the delivery status fact table in this invention. Detailed Implementation

[0055] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the following embodiments are only used to illustrate the implementation of the present invention and are not intended to limit the scope of protection of the present invention. Where there is no conflict, the technical features in the following embodiments can be combined with each other.

[0056] I. General Description

[0057] This invention provides a method for automatically arranging vehicle or cargo delivery task maps and linking them with inventory ownership. This method can be deployed on the server side of a vehicle sales management system, cargo sales management system, supply chain collaboration platform, warehouse management system, or enterprise resource planning system. The server can be a single business server or a server cluster consisting of application servers, database servers, message queue servers, and interface servers. The server communicates with a sales contract system, inventory management system, warehouse operation system, transportation management system, financial collection system, vehicle inspection system, vehicle registration and transfer system, or ownership transfer approval system. This allows for the automatic generation of delivery tasks after a sales contract takes effect, control of node flow, restriction of duplicate inventory holdings, and maintenance of consistency between ownership and delivery status.

[0058] In this embodiment, "vehicle" or "goods" refers to a delivery object with a traceable item identifier. For vehicles, the item identifier can be a vehicle identification number, engine number, vehicle inventory number, or vehicle certificate of conformity number; for general goods, the item identifier can be an equipment serial number, goods batch number, storage unit code, or pallet code. Warehouse location can include warehouse number, storage area number, storage location number, dealership number, or transit station number. Ownership processing requirements can include vehicle registration and transfer of ownership requirements, goods ownership confirmation requirements, and property transfer application requirements, etc.

[0059] II. Method Implementation

[0060] like Figure 1 As shown, the method of this embodiment includes the following steps.

[0061] S1. Generate a delivery control vector when the sales contract takes effect.

[0062] When a sales contract takes effect, the server reads the contract delivery fields, including contract items, item identifiers, and warehouse location, and generates a delivery control vector. The contract delivery fields may also include one or more of the following: business type, buyer, seller, purchase order, delivery method, ownership processing requirements, and delivery deadline.

[0063] Specifically, sales contracts can be generated by the contract management system and pushed to the server, or the server can retrieve them periodically via an interface. Upon receiving a sales contract activation event, the server first determines whether the contract status is signed, activated, or approved. If the contract status does not meet the activation conditions, a delivery control vector is not generated. If the contract status meets the activation conditions, the contract items in the contract are parsed. A sales contract may include one contract item or multiple contract items; each contract item may correspond to a vehicle, a batch of goods, a storage unit, or multiple similar items.

[0064] The server standardizes contract fields. For example, terms like "self-pickup," "customer picks up vehicle at store," and "store delivery" in the contract text are uniformly mapped to "self-pickup" in the delivery method field; "transfer," "logistics delivery," and "warehouse dispatch" are uniformly mapped to "shipment" in the delivery method field; and "requires transfer of ownership," "requires vehicle registration," and "requires transfer registration" are uniformly mapped to "vehicle registration and transfer of ownership requirement" in the ownership processing requirement field. For the purchase order field, the server can read it based on the purchase order number, purchase batch, or upstream order number associated with the sales contract; for the warehouse location field, the server can query the current storage warehouse location from the inventory management system based on the item identifier.

[0065] In one implementation, the delivery control vector includes a contract item identifier, a business type field, a buyer field, a seller field, a purchase order field, an item identifier field, a warehouse location field, a delivery method field, a rights processing requirement field, and a delivery deadline field. This delivery control vector is used for subsequent matching of node templates and generation of a directed graph of delivery tasks. For a single sales contract comprising multiple contract items, the server generates a delivery control vector for each contract item separately, ensuring that each contract item corresponds to at least one independent directed graph of delivery tasks, thus preventing overlapping delivery states between different items.

[0066] For example, a sales contract includes three vehicles, contract items A1, A2, and A3, corresponding to vehicle identification numbers VIN001, VIN002, and VIN003, respectively. All three are located in warehouse area WH01-A, the delivery method is carrier shipment, and the ownership transfer requirement is vehicle registration and transfer. The server generates three delivery control vectors, ensuring each vehicle has independent records of subsequent inventory occupancy and ownership status.

[0067] S2. Generate a directed graph of delivery tasks based on the delivery control vector.

[0068] The server matches the node template with the delivery control vector, generates a directed graph of delivery tasks including multiple delivery nodes, and writes the preconditions, release conditions, and rollback conditions.

[0069] In this embodiment, the server pre-stores a candidate node library and a node template library. The candidate node library stores orchestratable delivery nodes, which may include one or more of the following: inventory locking nodes, vehicle inspection nodes, transportation arrangement nodes, dispatch nodes, outbound nodes, vehicle pickup nodes, receipt confirmation nodes, ownership processing nodes, transfer application nodes, transfer-in nodes, and inventory ownership update nodes. The node template library stores node selection rules and dependency edge rules under different business types, delivery methods, and ownership processing requirements. Based on the business type, delivery method, and ownership processing requirements in the delivery control vector, the server selects multiple delivery nodes from the candidate node library and generates a directed graph of delivery tasks according to the dependency edge rules in the node template library.

[0070] In one implementation, the vehicle delivery template may include multiple nodes selected from inventory locking, vehicle inspection, transportation arrangement, outbound, vehicle pickup, and ownership processing; the goods delivery template may include multiple nodes selected from inventory locking, transportation arrangement, outbound, receipt confirmation, and ownership processing; and the inventory transfer delivery template may include multiple nodes selected from inventory transfer-out locking, transfer application, outbound outbound, transfer-in inbound, and inventory ownership update. After matching the node templates, the server can delete inapplicable optional delivery nodes or mark inapplicable optional delivery nodes as inapplicable based on the specific delivery method of the current sales contract.

[0071] In this embodiment, the target node involving physical flow refers to the delivery node that causes physical flow results such as vehicle or cargo transportation, departure from the warehouse, retrieval, receipt, or delivery confirmation. The target node may include a dispatch node and / or an outbound node. A transportation arrangement node indicates pre-transportation processing such as dispatch application, transportation resource confirmation, waybill generation, or dispatch plan confirmation, and does not necessarily indicate that the vehicle or cargo has actually left the warehouse. Ownership processing nodes indicate the handling of vehicle or cargo ownership status and may include ownership transfer nodes and / or transfer confirmation nodes.

[0072] When generating the directed graph of delivery tasks, the server establishes dependency edges between delivery nodes. Dependency edges represent the execution order between nodes. Each delivery node can include a node identifier, node name, node type, preconditions, release conditions, rollback conditions, node execution status, and expected completion time. Preconditions determine whether a delivery node can be triggered; release conditions determine whether the corresponding business action is allowed before the delivery node is executed; rollback conditions determine whether to release, restore, block subsequent nodes, or update the ownership status when a delivery node returns an abnormal result.

[0073] For example, when the business type is vehicle sales, the delivery method is carrier shipment, and the ownership transfer requirement is vehicle registration and transfer, the server can select a vehicle delivery template that includes nodes such as inventory lock, vehicle inspection, transportation arrangement, outbound, vehicle pickup, ownership transfer, and transfer confirmation. If the delivery method is customer self-pickup, the server can delete the transportation arrangement node or set it to an inapplicable state; if the current sales contract does not require registration and transfer, the server can delete the transfer confirmation node or set it to an inapplicable state.

[0074] In a practical system, the directed graph of delivery tasks can be stored in a database table or a graph database. If a relational database is used, nodes and dependencies can be stored in a task node table and a task dependency table, respectively. The task node table includes fields such as task graph identifier, node identifier, node name, node status, precondition code, release condition code, rollback condition code, and expected completion time; the task dependency table includes fields such as task graph identifier, predecessor node identifier, successor node identifier, and dependency type. If a graph database is used, delivery nodes can be treated as graph nodes, and dependencies as graph edges, with condition rules stored in the attributes of both the graph nodes and edges.

[0075] S3. Generate a unique occupancy key and establish a delivery status fact table.

[0076] The server determines the inventory occupancy range of the contract item based on the delivery control vector, generates a unique occupancy key using the item identifier, warehouse location, and inventory occupancy range, and establishes an inventory occupancy record. When there are identical unique occupancy keys, or when there are unreleased inventory occupancy records with the same item identifier, warehouse location, and overlapping inventory occupancy ranges, the server refuses to establish a new inventory occupancy record and writes the contract item identifier, unique occupancy key, inventory occupancy record, delivery node execution status, and property rights status record into the same delivery status fact table.

[0077] This step is used to maintain data consistency between inventory holdings, delivery milestones, and ownership status. For example... Figure 2 As shown, the unique occupancy key is used to identify the specific inventory resource occupied by the sales contract, and the contract item identifier is used to mark the sales contract item to which the inventory occupancy record belongs. Both are written into the delivery status fact table. The contract item identifier is not a necessary field for determining whether the same inventory resource is occupied repeatedly; when the server determines resource occupancy conflicts, it uses the item identifier, warehouse location, and inventory occupancy range as the basis.

[0078] In one implementation, the server determines the inventory occupancy range for a contract item based on a delivery control vector. The inventory occupancy range can be a vehicle unit, equipment unit, storage unit, or a quantity range within a batch of goods. For example, for a single vehicle, the inventory occupancy range can be the vehicle unit corresponding to that vehicle identification number; for a single piece of equipment, the inventory occupancy range can be the equipment unit corresponding to that equipment serial number; for goods delivered in batches, the inventory occupancy range can be a quantity range within that batch; for goods managed in units of pallets, boxes, or storage locations, the inventory occupancy range can be the corresponding storage unit.

[0079] The server generates a unique occupancy key based on the item identifier, warehouse location, and inventory occupancy range. This unique occupancy key can be obtained by hashing the concatenation of the item identifier, warehouse location, and inventory occupancy range, or it can be a composite key composed of these three elements. To facilitate auditing and manual verification, the server can simultaneously store both the original unique occupancy key and its digest value.

[0080] In one implementation, the unique occupancy key is generated as follows: the item identifier, warehouse location, and inventory occupancy range are combined in a fixed order to form a key source string, with the format "item identifier-warehouse location-inventory occupancy range". The server performs character normalization on the key source string, removing spaces, full-width / half-width differences, and capitalization differences; then, a unique occupancy key is generated. If different contract items request the same item identifier, the same warehouse location, and the same inventory occupancy range, the server generates the same unique occupancy key. If different contract items request the same item identifier, the same warehouse location, and partially overlapping inventory occupancy ranges, the server identifies this as a resource occupancy conflict based on the overlapping inventory occupancy ranges.

[0081] Inventory holding records include a unique holding key, contract item identifier, item identifier, warehouse location, inventory holding range, holding quantity, holding status, holding source, holding validity period, and release identifier. Holding status can include pending lock, locked, pending review, released, and expired. Holding source can be a sales contract, inventory transfer, manual locking, or after-sales exchange. Holding validity period can be determined based on the delivery deadline stipulated in the sales contract, shipping plan, or the company's inventory locking rules.

[0082] Before creating an inventory occupancy record, the server checks if there are any unreleased inventory occupancy records with the same unique occupancy key, or if there are any unreleased inventory occupancy records with the same item identifier, warehouse location, and overlapping inventory occupancy range. An unreleased inventory occupancy record refers to an occupancy status of pending lock, locked, or pending review, with a release identifier that is empty or not released. If any of the above unreleased inventory occupancy records exist, the server refuses to create a new inventory occupancy record for the current contract item and returns a duplicate occupancy warning to the contract processing end, inventory management end, or delivery management end; if no such unreleased inventory occupancy record exists, the server creates the inventory occupancy record and sets the occupancy status to locked.

[0083] The Delivery Status Fact Table is used to uniformly store contract item identifiers, unique occupancy keys, inventory occupancy records, delivery node execution status, and property ownership status records. This table may include fields for unique occupancy key, contract item, item identifier, warehouse location, inventory occupancy range, inventory occupancy status, current delivery node, delivery node execution status, property ownership status, anomaly flag, and expected completion time. Property ownership status includes unconfirmed, pending transfer, transferred, transfer failed, and frozen. The anomaly flag field indicates whether there are any anomalies such as vehicle inspection failure, transportation arrangement cancellation, shipment delay, outbound rejection, property ownership transfer failure, or transfer confirmation failure.

[0084] By writing inventory occupancy records, delivery node execution status, and property rights status records into the same delivery status fact table, the server can read the inventory occupancy status and property rights status from the same data source based on the same unique occupancy key when executing target nodes and ownership processing nodes involving physical flow. This reduces the inconsistency caused by different systems maintaining status separately. For distributed deployment scenarios, the delivery status fact table can be stored in the main database and updated via transactions; alternatively, it can use a record update method with version numbers to avoid state overwriting caused by simultaneous updates from multiple devices.

[0085] In one implementation, when the server updates the delivery status fact table, it first reads the current record version number, performs an update on the inventory occupancy status or ownership status, and then increments the record version number. If the record version number has already changed when the update is submitted, it indicates that concurrent updates exist, and the server rejects this update and rereads the latest record. This method reduces the probability of overwriting when multiple interfaces such as transportation scheduling, shipment, outbound, and ownership transfer simultaneously write back status.

[0086] S4. Triggering and blocking delivery nodes based on the delivery status fact table.

[0087] The server triggers delivery nodes that meet the preconditions according to the directed graph of delivery tasks. Before triggering the target node involving physical flow, it reads the inventory occupancy status and ownership status corresponding to the unique occupancy key from the delivery status fact table. If the two do not meet the release conditions at the same time, the target node is blocked.

[0088] Specifically, the server scans executable nodes according to the dependency order of the directed graph of delivery tasks. If all preceding nodes of a delivery node are in a completed, passed, or inapplicable state, and the preconditions for that delivery node are met, then that delivery node enters a triggerable state. For general verification nodes, such as inventory lock nodes, vehicle inspection nodes, and vehicle pickup nodes, the corresponding business interface can be triggered directly or a pending task can be generated after the preconditions are met. For shipping nodes and outbound nodes, since they directly affect the physical flow of vehicles or goods, the server further performs release condition verification before triggering.

[0089] Taking the shipping node as an example, the server reads the inventory occupancy status and ownership status corresponding to the unique occupancy key from the delivery status fact table. If the inventory occupancy status is locked, the vehicle inspection node execution status is passed, the transportation resource conditions are met, and the ownership status is not frozen, then the shipping node meets the release conditions. If the inventory occupancy status is released, pending review, or expired, or the ownership status is frozen, the server blocks the shipping node, updates the shipping node execution status to blocked, and generates a blocking reason. The blocking reason can include inventory not locked, inventory occupancy released, inventory occupancy pending review, ownership status frozen, or vehicle inspection result failed.

[0090] Taking the outbound node as an example, the server reads the inventory occupancy status and ownership status. If the inventory occupancy status is locked and the ownership status is pending transfer or transferred, the outbound node meets the release conditions. If the inventory occupancy status is not locked, or the ownership status is unconfirmed, transfer failed, or frozen, the server blocks the outbound node. For situations in actual business operations where "outbound first, ownership transfer later" is allowed, the outbound node release condition can be configured to have the inventory occupancy status locked and the ownership status pending transfer; for situations where "ownership transfer must precede outbound", the outbound node release condition can be configured to have the inventory occupancy status locked and the ownership status transferred. This configuration can be determined by the node template or the business type field.

[0091] During node execution, the server generates a node execution record for each delivery node. The node execution record may include the node identifier, trigger time, trigger source, precondition verification results, release condition verification results, execution result, rollback operation, changes in inventory holding records, changes in property ownership status records, and operator identifier. The trigger source can be automatically triggered by the system, manually triggered, triggered by interface write-back, or triggered by a scheduled task. By saving the node execution record, the triggering, blocking, and rollback processes of delivery nodes can be reconstructed during subsequent audits.

[0092] S5, abnormal rollback, subsequent node blocking, and recalculation of expected completion time.

[0093] When a delivery node returns an abnormal result, the server updates the delivery status fact table according to the rollback conditions, releases or restores the relevant inventory holding records, blocks subsequent delivery nodes that depend on the abnormal delivery node, and recalculates the expected completion time of subsequent delivery nodes based on the updated inventory holding status, ownership status, and the time of completed delivery nodes.

[0094] In this implementation, abnormal results can be returned by external system interfaces or submitted by a manual reviewer. For example, the vehicle inspection system may return a failure to pass inspection, the transportation system may return a cancellation or delay in shipment, the warehouse system may return a rejection of outbound shipment, the property transfer approval system may return a failure to transfer property rights, and the vehicle registration and transfer system may return a failure to confirm transfer. After receiving an abnormal result, the server first identifies the delivery node that returned the abnormal result as the abnormal delivery node, and then reads the rollback conditions corresponding to that delivery node.

[0095] Rollback conditions include one or more of the following: vehicle inspection failure, shipment cancellation, shipment delay exceeding the preset time limit, vehicle pickup exceeding the time limit, rejection of vehicle leaving the warehouse, failure of transfer of ownership, and failure of transfer confirmation. Different abnormal results correspond to different rollback actions.

[0096] When the vehicle inspection node returns a failure result, it indicates that the delivery object does not currently meet the delivery requirements. The server updates the inventory holding record to "released" and also updates the inventory holding status in the delivery status fact table to "released." Simultaneously, the shipping node, vehicle pickup node, outbound node, ownership transfer node, and transfer confirmation node are updated to a blocked state. This process prevents shipping, outbound, or ownership transfer from proceeding after a failed inspection. If a different vehicle or cargo is subsequently selected, the server needs to regenerate a unique holding key or establish a new directed graph for the delivery task based on the new item identifier and warehouse location.

[0097] When the shipping node returns a cancellation result, it indicates that the shipping operation was not completed, but the vehicle or goods may still be in the original warehouse or can be rescheduled. The server restores the inventory holding record to locked and updates the pickup node and its subsequent delivery nodes to a pending rescheduling state. The inventory holding record is not released directly at this time to avoid the contract remaining valid while the vehicle or goods are held by other contracts. If the shipping cancellation is accompanied by contract termination or a change of delivery party, the server can update the inventory holding record to released based on manual confirmation.

[0098] When the return delay of the shipping node exceeds the preset time limit, the server does not need to immediately release the inventory holding record. Instead, it recalculates the expected completion time of the pickup node, outbound node, ownership transfer node, and transfer confirmation node based on transportation timeliness, warehouse operation time, and standard processing time of subsequent nodes. If the recalculated expected completion time exceeds the delivery deadline stipulated in the sales contract, the server generates a delivery delay notification and marks the directed graph of the delivery task as requiring manual confirmation.

[0099] When the property transfer node returns a failure result, the server updates the property status record to "transfer failed," keeps the execution status of the outbound node from being overwritten, and updates the transfer confirmation node to a blocked state. Keeping the execution status of the outbound node from being overwritten is to prevent completed physical transfer records from being incorrectly rolled back. At this time, the server can generate a property anomaly review task, allowing business personnel to determine whether to supplement ownership information, re-initiate the property transfer application, or take other actions.

[0100] When recalculating the expected completion time of subsequent delivery nodes, the server determines the set of affected subsequent delivery nodes based on the dependency edges from the aberrant delivery node to the subsequent delivery node in the directed graph of the delivery task. Then, it reads the aberrant result time, completed delivery node time, inventory status, ownership status, delivery method, and delivery deadline of the aberrant delivery node. The server then updates the earliest triggerable time and expected completion time of each subsequent delivery node in the order of dependencies within the set of affected subsequent delivery nodes.

[0101] In one implementation, each delivery node has a preset standard processing time and an executable time period. For example, the standard processing time for the vehicle inspection node is 4 hours, the standard processing time for the shipment node is 1 business day, the standard processing time for the vehicle pickup node is 0.5 business days, the standard processing time for the transfer of ownership node is 2 business days, and the standard processing time for the transfer confirmation node is 3 business days. If the shipment node returns a delay after 18:00 on the same day, and the warehouse operation period is from 9:00 to 18:00 daily, the server will postpone the earliest trigger time of the subsequent node to the next operation period. In this way, the expected completion time matches the actual operation time.

[0102] III. System Implementation

[0103] This invention also provides an automatic vehicle or cargo delivery task diagram arrangement and inventory ownership linkage system for implementing the above method. The system includes a contract parsing module, a task diagram arrangement module, an inventory ownership linkage module, a node execution module, and an exception rollback module.

[0104] The contract parsing module executes step S1, reading contract items, business type, buyer, seller, purchase order, item identifier, warehouse location, delivery method, and ownership processing requirements from the sales contract, and generating a delivery control vector. The contract parsing module may include a field mapping unit, a contract item splitting unit, and a field completion suggestion unit. The field mapping unit maps form fields or text fields in the contract to uniform field items; the contract item splitting unit splits a sales contract into multiple contract items; and the field completion suggestion unit generates completion suggestions when item identifiers, warehouse locations, or ownership processing requirements are missing.

[0105] The task graph orchestration module executes step S2, selecting node templates based on the delivery control vector, generating a directed graph of delivery tasks, and writing preconditions, release conditions, and rollback conditions. The task graph orchestration module can connect to a node template library. The node template library stores the set of nodes and dependent edges corresponding to different business types, delivery methods, and ownership processing requirements.

[0106] The inventory ownership linkage module executes step S3, generates a unique occupancy key, establishes an inventory occupancy record, and writes the inventory occupancy record, delivery node execution status, and ownership status record into the same delivery status fact table. The inventory ownership linkage module can call the inventory management system interface to query the warehouse location and existing inventory occupancy record corresponding to the item identifier, and can also call the ownership management system interface to read the ownership status.

[0107] The node execution module executes step S4, triggering delivery nodes that meet the preconditions according to the directed graph of delivery tasks. Before triggering the shipping or outbound node, it reads the delivery status fact table to verify the inventory occupancy status and ownership status. The node execution module can send tasks to the vehicle inspection system, transportation management system, warehouse management system, and ownership transfer system via message queues, and can also generate pending tasks for business personnel to handle.

[0108] The exception rollback module is used to execute step S5. When a delivery node returns an exception result, it updates the delivery status fact table, releases or restores related inventory holding records, blocks subsequent delivery nodes that depend on the exception delivery node, and recalculates the expected completion time of the subsequent delivery node. The exception rollback module may include an exception node identification unit, a rollback operation execution unit, a subsequent node identification unit, and an expected completion time calculation unit.

[0109] The aforementioned system modules can be deployed on a server as software programs or as microservices. The modules can interact with each other via databases, message queues, or remote procedure call interfaces. Any implementation of steps S1 to S5 described above constitutes a feasible implementation of the system of this invention.

[0110] IV. Examples

[0111] The implementation process of this invention will be described below using vehicle sales and delivery scenarios, abnormal rollback scenarios, and duplicate inventory holding scenarios. It should be noted that the order of delivery nodes in the directed graph of the delivery task is determined by the dependency edges in the node template. The node order given in the following embodiments is only a configuration method for one vehicle delivery scenario; in other vehicle or goods delivery scenarios, the order of the outbound node, dispatch node, and vehicle pickup node can be adjusted according to the delivery method, warehouse operation rules, and ownership processing requirements.

[0112] In this implementation, the dispatch node can refer to dispatch application, transportation resource confirmation, waybill generation, or dispatch plan confirmation, and does not necessarily indicate that the vehicle or goods have actually left the warehouse; the actual departure action is recorded by the outbound node. For goods sales scenarios, the dispatch node can also be set after the outbound node to record the transportation status of goods after they leave the warehouse; for vehicle sales scenarios, the dispatch node can be set before the outbound node to confirm transportation resources and generate a waybill.

[0113] 4.1 Example 1: Delivery task diagram arrangement and inventory ownership linkage of vehicle sales contracts

[0114] In the business system of a vehicle dealership, sales contract C2026-001 has taken effect. This contract includes a contract item L001, the business type is vehicle sales, the buyer is customer A, the seller is dealer B, the purchase order is P2026-052, the item identification is vehicle identification number VIN-A001, the warehouse location is WH-HZ-01-A03, the delivery method is carrier shipment, the ownership processing requirement is vehicle registration and transfer, and the delivery deadline is April 30, 2026.

[0115] After receiving the sales contract effectiveness event, the server reads the above fields and generates a delivery control vector. This delivery control vector includes the contract item identifier L001, the business type field "vehicle sales," the buyer field "customer A," the seller field "distributor B," the purchase order field "P2026-052," the item identifier field "VIN-A001," the warehouse location field "WH-HZ-01-A03," the delivery method field "transportation," the ownership processing requirement field "vehicle registration and transfer," and the delivery deadline field "April 30, 2026."

[0116] The server selects a vehicle delivery template based on the delivery control vector and generates a directed graph of the delivery task. This directed graph includes an inventory lock node N1, a vehicle inspection node N2, a shipment node N3, a delivery node N4, a pickup node N5, a transfer of ownership node N6, and a transfer confirmation node N7. Dependency edges include N1 pointing to N2, N2 pointing to N3, N3 pointing to N4, N4 pointing to N5, N5 pointing to N6, and N6 pointing to N7.

[0117] Among them, the inventory lock node N1 is used to establish or confirm vehicle inventory occupancy; the vehicle inspection node N2 is used to conduct pre-delivery inspection of the vehicle's appearance, configuration, documents, and accompanying materials; the dispatch node N3 is used to generate a dispatch application, confirm transportation resources, or generate a waybill, but does not indicate that the vehicle has actually left the warehouse; the outbound node N4 is used to confirm that the vehicle has actually left the warehouse in the warehouse operation system; the vehicle pickup node N5 is used to record customer pickup confirmation or delivery confirmation after the vehicle arrives at the store or delivery location; the ownership transfer node N6 is used to process changes in the ownership status of the vehicle or goods; and the transfer confirmation node N7 is used to record the processing results of vehicle registration, transfer of ownership, or transfer registration.

[0118] For shipment node N3, prerequisites include that the vehicle inspection node N2 has passed, release conditions include that the inventory status is locked and transportation resource conditions are met, and rollback conditions include shipment cancellation or shipment delay exceeding the preset time limit. For outbound node N4, prerequisites include that shipment node N3 has been completed or the waybill has been generated, release conditions include that the inventory status is locked, payment or credit conditions are met, and the ownership status is pending transfer or transferred, and rollback conditions include outbound rejection. For business types that require ownership transfer before outbound shipment, the server can configure the release conditions for outbound node N4 to have the inventory status locked and the ownership status transferred.

[0119] The server determines the inventory occupancy range of contract item L001 as the vehicle unit corresponding to vehicle identification code VIN-A001 based on the delivery control vector, and generates a unique occupancy key K001 using item identifier VIN-A001, warehouse location WH-HZ-01-A03, and the aforementioned inventory occupancy range. After querying the inventory occupancy records, the server finds no unreleased inventory occupancy records for the same item identifier and warehouse location. Therefore, it creates an inventory occupancy record, sets the occupancy status to locked, the occupancy quantity to 1, the occupancy source to the sales contract, and the occupancy validity period to April 30, 2026. Simultaneously, the server writes the unique occupancy key K001, contract item L001, item identifier VIN-A001, warehouse location WH-HZ-01-A03, inventory occupancy status locked, current delivery node N1, ownership status pending transfer, anomaly flag empty, and expected completion time into the delivery status fact table.

[0120] After inventory locking node N1 is completed, the server triggers vehicle inspection node N2. The vehicle inspection system returns that the inspection has passed, and the server updates the execution status of the vehicle inspection node to "passed." Subsequently, the server prepares to trigger shipping node N3. Before triggering, the server reads the inventory occupancy status and ownership status corresponding to the unique occupancy key K001 from the delivery status fact table. The read result shows that the inventory occupancy status is locked, and the ownership status is pending transfer. The server determines that the release conditions for shipping node N3 are met, and therefore sends a shipping application to the transportation management system and generates a waybill.

[0121] After shipment node N3 is completed, the server prepares to trigger outbound node N4. Before triggering outbound node N4, the server reads the delivery status fact table again to confirm that the inventory occupancy status is locked, the ownership status is pending transfer, and the payment or credit conditions are met. Then, it sends an outbound request to the warehouse management system. Once the warehouse management system returns that the outbound process is complete, the server updates the execution status of outbound node N4 to "completed."

[0122] After the vehicle arrives at the store or delivery location, the server triggers the vehicle pickup node N5. After the customer confirms the pickup, the server triggers the ownership transfer node N6. The financial system confirms that the payment or credit conditions are met, the ownership transfer system returns that the ownership transfer is complete, and the server updates the ownership status to "transferred." Finally, the server triggers the transfer confirmation node N7. After the registration and transfer documents are met, the transfer confirmation node is completed, and the directed graph of the delivery task ends.

[0123] In this embodiment, both the shipping node and the outbound node read the inventory occupancy status and ownership status based on the same delivery status fact table, and the outbound node also performs release verification in conjunction with payment or credit conditions. Through this process, the server can uniformly verify inventory occupancy, payment or credit conditions, and ownership status before the vehicle is physically moved.

[0124] 4.2 Example 2: Inventory release and subsequent node blocking when vehicle inspection fails

[0125] Sales contract C2026-002 includes contract item L002, vehicle identification number VIN-A002, warehouse location WH-HZ-01-A04, delivery method is carrier shipment, and ownership processing requirement is vehicle registration and transfer. The server generates a delivery control vector, a directed graph of delivery tasks, and a unique occupancy key K002 according to Example 1, and establishes an inventory occupancy record with the occupancy status set to locked.

[0126] After the inventory locking node is completed, the server triggers the vehicle inspection node. The vehicle inspection system returns an inspection failure, with the reason recorded as exterior damage. The server determines the vehicle inspection node as an abnormal delivery node and reads the corresponding rollback conditions. Based on the rollback conditions, the server updates the inventory holding record to "released," updates the inventory holding status in the delivery status fact table to "released," and updates the shipping node, outbound node, vehicle pickup node, ownership transfer node, and transfer confirmation node to "blocked." Simultaneously, the server generates an exception handling task, prompting business personnel to choose between replacing the vehicle, repairing and re-inspecting, or canceling the contract.

[0127] If the sales personnel choose to change vehicles, a unique occupancy key K009 is generated based on the new item identifier VIN-A009, the new warehouse location WH-HZ-01-B01, and the new inventory occupancy range, and a new inventory occupancy record is re-established. The inventory occupancy record corresponding to the original unique occupancy key K002 remains in a released state to prevent VIN-A002 from continuing to be occupied by the current sales contract.

[0128] In this embodiment, after the vehicle inspection node returns an error, the server does not proceed with the shipping, warehousing, vehicle pickup, ownership transfer, and title confirmation nodes. Instead, it blocks subsequent nodes based on the dependency edges in the directed graph of the delivery task and releases the corresponding inventory occupancy record. This process prevents vehicles that fail inspection from continuing into the physical delivery process.

[0129] 4.3 Example 3: Recalculation of expected completion time of subsequent nodes when shipment is delayed

[0130] The delivery deadline for sales contract C2026-003 is April 28, 2026. The item identification is VIN-A003, and the warehouse location is WH-HZ-01-A05. After the server generated the directed graph of the delivery task, the inventory lock node and the vehicle inspection node have been completed. The original expected completion time for the shipment node was 18:00 on April 24, 2026; the original expected completion time for the outbound node was 12:00 on April 25, 2026; the original expected completion time for the vehicle pickup node was 18:00 on April 25, 2026; the original expected completion time for the transfer of ownership node was 18:00 on April 27, 2026; and the original expected completion time for the transfer confirmation node was 18:00 on April 28, 2026.

[0131] The shipping node returned a shipping delay at 17:30 on April 24, 2026, with an estimated delay of 1 day. The server determined the shipping node to be an abnormal delivery node and, based on the directed graph of delivery tasks, identified the set of affected subsequent delivery nodes, including the outbound node, vehicle pickup node, ownership transfer node, and transfer confirmation node. The server read the time of the abnormal result, the time of completed delivery nodes, inventory occupancy status, ownership status, delivery method, and delivery deadline. The inventory occupancy status is locked, the ownership status is pending transfer, and the delivery method is carrier dispatch.

[0132] The server recalculates the earliest triggerable time and expected completion time of subsequent delivery nodes according to the dependency order. After recalculation, the expected completion time of the outbound node is updated to 12:00 on April 26, 2026, the expected completion time of the vehicle pickup node is updated to 18:00 on April 26, 2026, the expected completion time of the property transfer node is updated to 18:00 on April 29, 2026, and the expected completion time of the transfer confirmation node is updated to 18:00 on April 30, 2026.

[0133] Because the expected completion time of the transfer confirmation node exceeded the delivery deadline of April 28, 2026, the server generated a delivery delay notice and marked the corresponding delivery task's directed graph as requiring manual confirmation. Business personnel can use this notice to confirm a new delivery time with the customer, or adjust transportation resources, change the delivery location, or replace the available vehicle.

[0134] In this embodiment, the shipment delay does not directly release the inventory holding record. Instead, it keeps the inventory holding status locked and recalculates the expected completion time for the affected subsequent delivery nodes. This process can prevent subsequent nodes from proceeding incorrectly according to the original plan when the contract is still valid and the vehicle still needs to be delivered.

[0135] 4.4 Example 4: Rejection Processing for Duplicate Inventory Holdings

[0136] Sales contract C2026-004 has already established an inventory occupancy record for vehicle VIN-A004 at warehouse location WH-HZ-01-A06, with the occupancy status set to locked. Subsequently, another sales contract C2026-005 also references vehicle VIN-A004 and warehouse location WH-HZ-01-A06. When processing contract C2026-005, the server prepares to establish an inventory occupancy record based on contract terms, item identifier, and warehouse location.

[0137] Before creating a new inventory holding record, the server queries for unreleased inventory holding records using item identifier VIN-A004 and warehouse location WH-HZ-01-A06. It finds that the inventory holding record corresponding to contract C2026-004 is still locked. The server refuses to create a new valid inventory holding record for contract C2026-005 and returns a duplicate holding warning. The directed graph of the delivery task corresponding to contract C2026-005 does not enter the shipping or outbound nodes.

[0138] If contract C2026-004 is subsequently terminated, or the corresponding inventory occupancy record is updated to be released due to reasons such as vehicle inspection failure or contract cancellation, the server can reprocess contract C2026-005 and, after confirming that there are no unreleased inventory occupancy records, create a new inventory occupancy record for contract C2026-005.

[0139] In this embodiment, the server determines a unique occupancy key using the item identifier VIN-A004, the warehouse location WH-HZ-01-A06, and the corresponding vehicle unit, and queries whether there are any unreleased inventory occupancy records with the same unique occupancy key or overlapping inventory occupancy ranges. This can prevent the same vehicle from being repeatedly occupied due to multiple contracts being processed in parallel.

[0140] V. Comparative Examples and Tests

[0141] To illustrate the effectiveness of the method described in this invention in reducing duplicate inventory holdings, erroneous outbound shipments, and incorrect progress following anomalies, test samples were constructed using historical delivery process data from an enterprise testing environment. The test samples included 120 sales contracts in total: 80 vehicle sales contracts and 40 goods sales contracts. These included 72 normal delivery samples, 12 samples of failed vehicle inspections, 16 samples of cancelled or delayed shipments, 8 samples of rejected outbound shipments, 8 samples of failed transfer of ownership, and 4 samples of duplicate use of the same item identifier. In the test environment, the interfaces for inventory, vehicle inspection, transportation, warehouse, and ownership status all returned data using simulated interfaces with fields consistent with those in the actual system.

[0142] 5.1 Comparative Example 1

[0143] Delivery nodes are initiated manually. After the contract takes effect, business personnel initiate tasks in the vehicle inspection application, shipment application, vehicle pickup application, warehouse management and transfer of ownership application modules respectively. Each module maintains its own status. A directed graph of delivery tasks is not used, nor are unique occupancy keys and delivery status fact tables.

[0144] 5.2 Comparative Example 2

[0145] A standard workflow template is used. After the contract takes effect, the system generates fixed workflow nodes based on the business type, but inventory occupancy records, node execution status, and ownership status are stored separately in the inventory system, workflow system, and ownership system, respectively. The shipping and outbound nodes only verify whether the preceding workflow nodes have been completed; they do not simultaneously read the inventory occupancy status and ownership status from the same delivery status fact table.

[0146] 5.3, Example Set

[0147] The method described in this invention is employed as follows: After the contract takes effect, the server generates a delivery control vector and a directed graph of delivery tasks. Based on the delivery control vector, the inventory occupancy range of the contract items is determined. A unique occupancy key is generated using the item identifier, warehouse location, and inventory occupancy range. An inventory occupancy record is established, and the inventory occupancy record, delivery node execution status, and property rights status record are written into the same delivery status fact table. Before the dispatch node and outbound node are triggered, the same delivery status fact table is read to verify the inventory occupancy status and property rights status. If an anomaly occurs, subsequent delivery nodes are blocked according to the rollback conditions, and the expected completion time is recalculated.

[0148] The test statistics include: number of times inventory was repeatedly held, number of times goods were issued or shipped when the ownership status was not met, number of times subsequent nodes continued to progress after an abnormal node, and number of times delivery delay notifications were missed. The statistical results are shown in Table 1.

[0149] Table 1. Comparison of Delivery Anomaly Control Effects under Different Delivery Processing Methods

[0150] Comparative Example 1 4 6 14 9 Comparative Example 2 2 3 7 5 Example group 0 0 0 1

[0151] In the above tests, Comparative Example 1, due to each module being initiated manually, resulted in 4 instances of duplicate inventory holding when the same item identifier was repeatedly referenced; and 6 instances of outbound or shipment occurred when the ownership status was unconfirmed or transfer failed. Comparative Example 2, although using a standard process template to reduce some sequential errors, still resulted in 2 instances of duplicate inventory holding and 3 instances of outbound or shipment when the ownership status was not met, because the inventory holding record, node execution status, and ownership status were not maintained in the same delivery status fact table. The Example 1 group rejected duplicate holding in the unreleased state through unique holding keys and inventory holding range overlap checks, and avoided duplicate inventory holding and outbound or shipment when the ownership status was not met through dual-state checks of the shipment node and outbound node. One instance of a delivery delay notification being missing in the Example 1 group originated from a sample where the delivery deadline field in the test data was empty; after completing the delivery deadline field, the server could generate a status requiring manual confirmation.

[0152] The above results are statistical results obtained under preset test samples and interface return rules, and do not indicate that manual configuration errors or external system data errors will not occur in all business scenarios. The above comparative examples are used to illustrate that the technical solution of the present invention can achieve consistent control over inventory occupancy, delivery nodes, and property rights status in the test environment. Test data can be adjusted according to the number of contracts, number of warehouses, delivery methods, and ownership handling rules of different enterprises, without affecting those skilled in the art to implement the present invention based on the above steps.

[0153] VI. Other Implementation Instructions

[0154] This invention does not rely on specific hardware devices, nor is it limited to specific database types or programming languages. The server can be implemented using languages ​​such as Java, Go, Python, and C#; the database can be MySQL, PostgreSQL, Oracle, SQL Server, or a graph database; and the external system interface can be implemented using HTTP interfaces, message queues, database views, or enterprise service bus methods.

[0155] In implementation, those skilled in the art can configure it according to the following data table:

[0156] The contract item list is used to store contract items, business types, buyers, sellers, purchase orders, item identification, warehouse locations, delivery methods, ownership processing requirements, and delivery deadlines;

[0157] The node template table is used to store node templates, delivery nodes, prerequisites, release conditions, and rollback conditions.

[0158] The task node table is used to store the delivery nodes and their execution status in the directed graph of delivery tasks;

[0159] The task dependency table is used to store the dependency edges between delivery nodes;

[0160] The inventory occupancy record table is used to store the unique occupancy key, contract item identifier, item identifier, warehouse location, occupied quantity, occupancy status, occupancy source, occupancy validity period, and release identifier;

[0161] The delivery status fact table is used to store the unique occupancy key field, contract item field, item identifier field, warehouse location field, inventory occupancy status field, current delivery node field, delivery node execution status field, ownership status field, exception identifier field, and expected completion time field.

[0162] The node execution log table is used to store the node triggering, verification, execution, blocking, and rollback processes.

[0163] After configuring according to the above data table and steps, the server can automatically generate a directed graph of delivery tasks when the sales contract takes effect, establish inventory occupancy records, and perform verification of inventory occupancy status and ownership status before the dispatch and outbound nodes are triggered. When any delivery node returns an abnormal result, the server updates the delivery status fact table according to the rollback conditions, releases or restores the inventory occupancy record, blocks the affected subsequent delivery nodes, and recalculates the expected completion time of the subsequent delivery nodes. Those skilled in the art can implement the technical solution of the present invention based on the above description.

[0164] This invention also provides a computer-readable storage medium storing a computer program or instructions. When executed by a processor, the computer program or instructions implement the steps of the above-described method for automatically arranging vehicle or cargo delivery task maps and linking inventory ownership. The computer-readable storage medium can be a read-only memory, random access memory, disk, optical disk, solid-state drive, flash memory, or other non-transitory storage medium. The computer program or instructions can be deployed on a server or server cluster, enabling the server to perform contract parsing, task map arrangement, inventory ownership linkage, node execution, and exception rollback processing.

Claims

1. A method for automatically arranging vehicle or cargo delivery task diagrams and linking them with inventory ownership, executed by a server, characterized in that: include: S1. When the sales contract takes effect, read the contract delivery field, which includes contract items, item identifiers, and warehouse location, and generate a delivery control vector; S2. Based on the delivery control vector matching node template, generate a directed graph of delivery tasks including multiple delivery nodes, and write the preconditions, release conditions and rollback conditions. S3. Determine the inventory occupancy range of the contract item based on the delivery control vector, generate a unique occupancy key using the item identifier, warehouse location, and inventory occupancy range, and establish an inventory occupancy record. When there are inventory occupancy records with the same resource occupancy key or overlapping occupancy range that have not been released, the creation of a new inventory occupancy record is refused, and the contract item identifier, unique occupancy key, inventory occupancy record, delivery node execution status, and property rights status record are written into the same delivery status fact table. S4. Trigger nodes that meet the preconditions according to the directed graph of the delivery task. Before triggering the target node involving physical flow, read the inventory occupancy status and ownership status of the unique occupancy key from the delivery status fact table. If the two do not meet the release conditions at the same time, block the target node. S5. When a delivery node returns an abnormal result, update the delivery status fact table according to the rollback conditions, release or restore the inventory occupancy record, block subsequent nodes that depend on the abnormal delivery node, and recalculate the expected completion time of the subsequent node based on the updated inventory occupancy status, ownership status, and completed node time.

2. The method for automatic arrangement of vehicle or cargo delivery task diagrams and linkage with inventory ownership as described in claim 1, characterized in that, In step S1, the contract delivery field also includes one or more of the following: business type field, buyer field, seller field, purchase order field, delivery method field, ownership processing requirement field, and delivery period field; The item identification includes one or more of the following: vehicle identification number, equipment serial number, goods batch number, and storage unit code; The ownership processing requirements include one or more of the following: vehicle registration and transfer requirements, goods ownership confirmation requirements, and property transfer application requirements. The delivery control vector includes a contract item identifier field, an item identifier field, a warehouse location field, a delivery method field, an ownership processing requirement field, and a delivery deadline field.

3. The method for automatic arrangement of vehicle or cargo delivery task diagrams and linkage with inventory ownership as described in claim 1, characterized in that, In step S2, the node template includes one or more of the following: vehicle delivery template, goods delivery template, and inventory transfer delivery template. The vehicle delivery template includes multiple nodes such as inventory locking node, vehicle inspection node, transportation arrangement node, outbound node, vehicle pickup node, and ownership processing node. The ownership processing node includes property transfer node and / or transfer confirmation node. The goods delivery template includes multiple nodes such as inventory locking node, transportation arrangement node, outbound node, receipt confirmation node, and ownership processing node. The inventory transfer and delivery template includes multiple nodes such as the inventory lockout node, transfer application node, inventory release node, inventory import node, and inventory ownership update node. The server selects the corresponding node template based on the delivery control vector and deletes or marks optional delivery nodes that do not match the current sales contract.

4. The method for automatic arrangement of vehicle or cargo delivery task diagrams and linkage with inventory ownership as described in claim 1, characterized in that, In step S3, the inventory occupancy range includes one or more of the following: vehicle unit, equipment unit, storage unit, and quantity range within a batch of goods. The inventory occupancy record includes a unique occupancy key, contract item identifier, item identifier, warehouse location, inventory occupancy range, occupancy quantity, occupancy status, occupancy source, occupancy validity period, and release identifier; The occupancy status includes pending lock, locked, pending review, released, and expired; When the validity period of an inventory occupancy record expires and the corresponding delivery task directed graph has not entered the target node involving physical flow, the server updates the occupancy status of the inventory occupancy record to pending review and suspends the triggering of the subsequent node corresponding to the inventory occupancy record.

5. The method for automatic arrangement of vehicle or cargo delivery task diagrams and linkage with inventory ownership as described in claim 1, characterized in that, The delivery status fact table includes a unique occupancy key field, a contract item field, an item identifier field, a warehouse location field, an inventory occupancy range field, an inventory occupancy status field, a current delivery node field, a delivery node execution status field, an ownership status field, an anomaly identifier field, and an expected completion time field. The property rights status includes unconfirmed, pending transfer, transferred, transfer failed, and frozen; The server uses the unique occupancy key field as the association field for reading the inventory occupancy status field and the ownership status field, so that the target node and ownership processing node involved in physical flow can perform status verification based on the same delivery status fact table.

6. The method for automatic arrangement of vehicle or cargo delivery task diagrams and linkage with inventory ownership as described in claim 1, characterized in that, The prerequisites include one or more of the following: inventory occupancy conditions, vehicle inspection results conditions, payment or credit conditions, transportation resource conditions, property ownership status conditions, and vehicle registration and transfer information conditions. The target nodes involved in the physical flow of goods include the shipping node and / or the outbound node; When the target node is a shipping node, its release conditions include the inventory occupancy status being locked, the vehicle inspection node execution status being passed, and the transportation resource conditions being met. When the target node is an outbound node, its release conditions include the inventory occupancy status being locked, payment or credit conditions being met, and the ownership status being pending transfer or already transferred. The release conditions for the ownership processing node include the fulfillment of payment or credit conditions, and the completion status of the outbound node or delivery confirmation node.

7. The method for automatic arrangement of vehicle or cargo delivery task diagrams and linkage with inventory ownership as described in claim 1, characterized in that, The rollback conditions include one or more of the following: vehicle inspection failure, transportation arrangement cancellation, shipment delay exceeding the preset time limit, vehicle pickup exceeding the time limit, outbound rejection, failure of property transfer, and failure of transfer confirmation. When the vehicle inspection node returns a failure result, the server updates the inventory usage record to be released and updates the subsequent nodes that depend on the vehicle inspection node to the blocked state. When the transportation scheduling node or the shipping node returns a cancellation result, the server restores the inventory holding record to locked and updates the subsequent nodes that depend on that node to a pending re-orchestration state. When the ownership transfer node returns a failure result, the server updates the ownership status record to transfer failure, keeps the execution status of the completed outbound node or the completed delivery confirmation node from being overwritten, and updates the subsequent nodes that depend on the ownership transfer node to the blocked state.

8. The method for automatic arrangement of vehicle or cargo delivery task diagrams and linkage with inventory ownership as described in claim 1, characterized in that, In step S5, recalculating the expected completion time of the successor node includes: Identify delivery nodes that return abnormal results as abnormal delivery nodes; Based on the dependency edges from the abnormal delivery node to the successor node in the directed graph of the delivery task, determine the set of affected successor nodes; Read the abnormal result time, completed node time, inventory status, ownership status, delivery method, and delivery deadline of the abnormal delivery node; Update the earliest trigger time and expected completion time of each successor node in the order of their dependencies in the affected successor node set. When the updated expected completion time exceeds the delivery deadline, a delivery delay notification is generated, and the corresponding delivery task directed graph is marked as requiring manual confirmation.

9. A system for automatically arranging vehicle or cargo delivery task diagrams and linking them with inventory ownership, characterized in that, The system is used to implement the automatic arrangement of vehicle or cargo delivery task maps and the linkage of inventory ownership as described in any one of claims 1 to 8, the system comprising: The contract parsing module is used to execute step S1; The task graph orchestration module is used to execute step S2; The inventory ownership linkage module is used to execute step S3; The node execution module is used to execute step S4; The exception rollback module is used to execute step S5.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by the processor, they implement the automatic arrangement of vehicle or cargo delivery task maps and the linkage of inventory ownership as described in any one of claims 1 to 8.

Images