Dynamic process processing method and system based on multi-module collaboration in smart logistics scenarios

Abstract

The present application provides a process dynamic processing method and system based on multi-module collaboration in a smart logistics scenario, which relates to the field of smart logistics technology. The method includes: obtaining order data from an order management module; in a billing engine module, generating a skeleton settlement order node based on the order data, and writing the skeleton settlement order node into a graph database; in an item processing module, generating at least one item node based on a preset item rule tree and based on the skeleton settlement order node, and writing the item node into the graph database; in the graph database, creating a forward edge between the skeleton settlement order node and the item node, and simultaneously creating a reverse edge from the item node to the skeleton settlement order node; forming a causal traceability path covering orders, items and vouchers in the graph database; significantly improving the system's data collaboration, anomaly detection efficiency, and the transparency and audit accuracy of business data processing.

Description

Technical Field

[0001] The present application relates to the field of smart logistics technology, and more specifically, to a process dynamic processing method and system based on multi-module collaboration in smart logistics scenarios. Background Art

[0002] With the rapid development of the smart logistics industry, logistics companies are increasingly relying on information systems. Currently, most logistics companies use comprehensive information systems that integrate multiple functional modules, such as order management, expense billing, and financial accounting, to improve business processing efficiency. However, in practical applications, these information systems still have several prominent issues.

[0003] Specifically, existing logistics information systems still lack the ability to achieve data collaboration and consistency management across functional modules. Data is often stored in silos, lacking effective data linkage and unified views across modules. This makes it difficult to quickly trace and effectively audit data anomalies or changes. Furthermore, because logistics operations involve a large number of orders processed in parallel, existing systems lack effective anomaly detection mechanisms when handling complex business linkages and batch data, making it difficult to promptly identify and locate anomalies, further increasing the difficulty and cost of financial accounting and business management.

[0004] Therefore, how to effectively improve the data collaboration, consistency management capabilities, and anomaly detection and positioning efficiency of logistics information systems has become a key technical issue that needs to be urgently solved in current logistics information systems. Summary of the Invention

[0005] In response to the shortcomings of the existing technology, this application provides a process dynamic processing method and system based on multi-module collaboration in smart logistics scenarios.

[0006] First, this application provides a dynamic process processing method based on multi-module collaboration in smart logistics scenarios, including:

[0007] Get order data from the order management module;

[0008] In the billing engine module, a skeleton settlement order node is generated based on the order data, and the skeleton settlement order node is written into the graph database;

[0009] In the item processing module, at least one item node is generated based on the preset item rule tree and the skeleton settlement order node, and the item node is written into the graph database;

[0010] In the graph database, a forward edge is created between the skeleton settlement order node and the item node, and a reverse edge is simultaneously created from the item node to the skeleton settlement order node;

[0011] Generate a voucher node based on the item node, and create an edge from the item node to the voucher node, so as to form a causal traceability path covering the order, item, and voucher in the graph database;

[0012] Batch data consistency analysis is performed on the skeleton settlement order nodes and their corresponding voucher nodes that belong to the common business context to identify voucher nodes indicating data anomalies. The batch data consistency analysis utilizes business timing information that reflects the causal order between the skeleton settlement order nodes in the group to dynamically evaluate the amount distribution of each voucher node in the group.

[0013] As an optional implementation, it also includes:

[0014] In response to receiving an adjustment instruction, the target voucher node in the graph database is located according to the voucher node identifier carried by the adjustment instruction, and the preset adjustment operation is performed on the target voucher node without modifying the original record of the target voucher node, generating an adjustment record including an offset type edge and a difference node, and writing the adjustment record into the graph database.

[0015] As an optional implementation, generating at least one sub-item node based on the skeleton settlement order node according to a preset sub-item rule tree and writing the sub-item node into the graph database includes:

[0016] Based on the business type information of the skeleton settlement order node, searching for a rule path corresponding to the business type information in the itemized rule tree;

[0017] In response to successfully finding the rule path, extracting billing items and billing parameters from the rule path level by level, and performing billing calculation on the skeleton settlement form node based on the billing items and billing parameters to generate sub-item nodes;

[0018] Generate a unique sub-item identifier for the sub-item node, and after setting the billing item, billing parameter, and the sub-item identifier as node attributes of the sub-item node, write the sub-item node and its node attributes into the graph database;

[0019] In response to not finding a rule path corresponding to the business type information in the itemized rule tree, marking the skeleton settlement order node as a pending state, and writing the skeleton settlement order node in the pending state into the graph database.

[0020] The step of creating a forward edge between the skeleton settlement order node and the item node, and simultaneously creating a reverse edge from the item node to the skeleton settlement order node includes:

[0021] When creating the reverse edge, the unique item identifier of the item node is written into the graph database as an attribute of the reverse edge, so that the skeleton settlement order node can be directly located to the corresponding item node based on the unique item identifier.

[0022] As an optional implementation, generating a voucher node based on the item node and creating an edge from the item node to the voucher node includes:

[0023] Determine the financial subject corresponding to the sub-item node based on the preset mapping relationship between the billing item attributes and the financial subject;

[0024] Group multiple sub-item nodes belonging to the same skeleton settlement document node according to the determined financial subjects, and generate corresponding voucher nodes for each group;

[0025] For each group, calculate the sum of the amounts of all item nodes in the group, and set the sum as the amount attribute of the corresponding voucher node;

[0026] Create edges pointing to corresponding voucher nodes for all sub-item nodes in each group, and record the unique sub-item identifier of the sub-item node in the attributes of the edge as the basis for tracing the source of the amount attribute of the voucher node.

[0027] As an optional implementation, grouping multiple sub-item nodes belonging to the same skeleton settlement order node according to the determined financial account and generating a corresponding voucher node for each group includes:

[0028] Obtaining a preset financial account template corresponding to the business type of the skeleton settlement document node, wherein the financial account template includes a full set of financial accounts to be generated under the business type;

[0029] Based on the financial account template, determine whether each financial account in the financial account template has a corresponding sub-item node:

[0030] If there is at least one sub-item node corresponding to the financial account, group the at least one sub-item node into a group, generate a voucher node corresponding to the financial account, and calculate the sum of the amounts of all sub-item nodes in the group as the amount attribute of the generated voucher node;

[0031] If there is no item node corresponding to the financial account, a blank voucher node with an amount attribute of zero is generated;

[0032] The voucher nodes generated corresponding to all financial subjects in the financial subject template are written into the graph database to form a voucher node set consistent with the structure of the financial subject template.

[0033] As an optional implementation, the method further includes:

[0034] Before writing the skeleton settlement order node, item node, voucher node, and the edges between them into the graph database, a logical clock timestamp is assigned to each data entity to be written. The logical clock timestamp is used to reflect the business causal order between data entities and is generated independently of the physical clock.

[0035] The distributing logical clock timestamp includes:

[0036] Based on the causal dependency between the data entity to be written and the data entities that already exist in the graph database and have a direct dependency relationship with the data entity to be written, the logical clock timestamp of the data entity that has a direct dependency relationship with the data entity to be written is obtained;

[0037] Add one to the maximum of the local logical clock value of the current module and the logical clock timestamp of the data entity that has a direct dependency on the data entity to be written, and use the result as the logical clock timestamp of the data entity to be written;

[0038] The logical clock timestamp is set as the timestamp attribute of the data entity to be written, and the local logical clock value of the current module is updated to the logical clock timestamp.

[0039] As an optional implementation, the batch data consistency analysis is a heuristic rule-based detection, including:

[0040] Constructing an order coupling matrix for quantifying the degree of coupling between the skeleton settlement order nodes;

[0041] identifying a coupling cluster based on the order coupling matrix, wherein the coupling cluster is a group of skeleton settlement order nodes having a coupling degree greater than a preset coupling threshold;

[0042] For the coupling cluster, when there is a missing amount or an amount difference greater than a first preset threshold value in each voucher node corresponding to the same financial account within the coupling cluster, a multi-order parallel anomaly is detected.

[0043] As an optional implementation, the detecting of multiple orders in parallel anomaly includes:

[0044] Construct a business snapshot data matrix, wherein its rows are composed of the skeleton settlement document nodes in the coupling cluster, its columns are composed of the financial accounts in the financial account template, and its element values ​​are the voucher amounts under the financial accounts of the skeleton settlement document nodes;

[0045] Decomposing the business snapshot data matrix using a preset mathematical model to generate a basic business pattern matrix and a sparse anomaly matrix;

[0046] The multi-order parallel exception is identified based on the non-zero elements in the sparse exception matrix.

[0047] As an optional implementation manner, the decomposing the business snapshot data matrix by using a preset mathematical model to generate a basic business pattern matrix and a sparse anomaly matrix includes:

[0048] Obtaining the logical clock timestamp corresponding to each skeleton settlement order node in the business snapshot data matrix;

[0049] Calculating the causal proximity between the skeleton settlement order nodes in the coupling cluster based on the logical clock timestamp, and introducing a timing weight corresponding to the causal proximity to the decomposition process of the mathematical model, wherein the timing weight is a monotonically decreasing function of the difference between the logical clock timestamps of the skeleton settlement order nodes;

[0050] The weighted matrix decomposition is completed to generate the basic business model matrix and the sparse exception matrix.

[0051] Secondly, this application provides a process dynamic processing system based on multi-module collaboration in smart logistics scenarios, including:

[0052] The order management module is used to obtain and output order data to the billing engine module. The order data is used to generate a skeleton settlement order node;

[0053] A billing engine module generates a skeleton settlement order node based on the order data and writes the skeleton settlement order node into a graph database;

[0054] An item processing module generates at least one item node based on a preset item rule tree and the skeleton settlement order node, classifies and aggregates the item nodes according to the financial account template to generate voucher nodes, constructs an order coupling matrix based on the order data, detects multi-order parallel anomalies, and generates a difference node for linkage adjustment based on the multi-order parallel anomalies;

[0055] The graph database is used to store skeleton settlement order nodes, item nodes, voucher nodes, difference nodes, order coupling matrix, and the forward and reverse edges between nodes, and maintain the logical clock timestamps of each node and edge to form a causal traceability path covering orders, items and vouchers.

[0056] Compared with the existing technology, the dynamic processing method of multi-module collaborative process in smart logistics scenarios proposed in the embodiment of the present application significantly improves the system's data collaboration and consistency management capabilities by establishing clear data entities (skeleton settlement order nodes, sub-item nodes, voucher nodes) and clear causal traceability paths between order management, billing engine and sub-item processing modules. Specifically, by introducing a graph database and constructing a bidirectional edge structure between the skeleton settlement order node and the sub-item node, fast data association query and efficient causal traceability are achieved, which significantly improves the location and audit efficiency of abnormal data. In addition, through the batch data consistency analysis method, especially the introduction of a dynamic evaluation mechanism based on heuristic rules and time-series weighted matrix decomposition, the system can more accurately identify abnormal amounts and abnormal nodes in batch orders, thereby effectively reducing financial risks and significantly reducing audit costs. Therefore, the technical solution provided by the present application effectively solves the technical problems of insufficient data collaboration and low anomaly detection efficiency in existing smart logistics information systems, significantly improves the reliability and transparency of logistics business data processing, and has good practical value. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 Flowchart of the dynamic process processing method based on multi-module collaboration in smart logistics scenarios provided by this application;

[0058] Figure 2 A flowchart of a method for writing item nodes into a graph database provided in this application;

[0059] Figure 3 A flowchart of a method for generating a voucher node based on a sub-item node and creating an edge from the sub-item node to the voucher node provided in this application;

[0060] Figure 4 Schematic diagram of the process dynamic processing system based on multi-module collaboration in smart logistics scenarios provided for this application.

[0061] Figure numerals: 10, order management module; 20, billing engine module; 30, item processing module; 40, graph database. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solutions and advantages of this application more clear, the specific implementation methods of this application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0063] The present application provides a method for dynamically processing processes based on multi-module collaboration in smart logistics scenarios. This method can be applied to a complex smart logistics platform that integrates multiple business modules, such as order management, billing, and financial accounting. In a preferred embodiment, the method is implemented by a backend service system deployed on a server cluster. This system includes, but is not limited to, an order management module 10, a billing engine module 20, and an itemization processing module 30, interacting with a graph database 40 instance.

[0064] See also Figure 1 FIG. 1 is a flowchart of a method for dynamic process processing based on multi-module collaboration in a smart logistics scenario according to an embodiment of the present application. The method includes steps S101 to S106, wherein:

[0065] S101: Obtain order data from the order management module;

[0066] S102: In the billing engine module, a skeleton settlement order node is generated based on the order data, and the skeleton settlement order node is written into a graph database;

[0067] S103: In the item processing module, at least one item node is generated based on the preset item rule tree and the skeleton settlement order node, and the item node is written into the graph database;

[0068] S104: In the graph database, a forward edge is created between the skeleton settlement order node and the item node, and a reverse edge is simultaneously created from the item node to the skeleton settlement order node;

[0069] S105: Generate a voucher node based on the item node, and create an edge from the item node to the voucher node, so as to form a causal traceability path covering the order, item, and voucher in the graph database;

[0070] S106: Perform batch data consistency analysis on the skeleton settlement order nodes and their corresponding voucher nodes that belong to the common business context to identify voucher nodes indicating data anomalies, wherein the batch data consistency analysis utilizes business timing information that reflects the causal order between the skeleton settlement order nodes in the group to dynamically evaluate the amount distribution of each voucher node in the group.

[0071] As an optional implementation, in response to receiving an adjustment instruction, the target voucher node in the graph database is located according to the voucher node identifier carried by the adjustment instruction, and the preset adjustment operation is performed on the target voucher node without modifying the original record of the target voucher node, generating an adjustment record including an offset type edge and a difference node, and writing the adjustment record into the graph database.

[0072] During implementation, upon receiving a new logistics order, the order management module automatically publishes the order-related data to a pre-set message queue system. This order data typically includes details such as order ID, customer ID, carrier ID, business type, cargo type, weight, volume, shipping route, billing period, and estimated costs.

[0073] Among them, the business types may exemplarily include cold chain transportation, less-than-truckload freight or full truckload transportation.

[0074] After the billing engine module receives the order data from the message queue in real time or quasi-real time, it immediately generates a skeleton settlement order node and writes the node into the graph database.

[0075] Specifically, in complex logistics operations, the calculation of billing items may involve complex external data calls or third-party services, such as rate inquiries or retrieval of special billing rules, which can be time-consuming or risk failure. By first generating a stable and lightweight skeleton node, the system can immediately confirm the start of the entire settlement process and obtain a unique identifier. Even if anomalies occur in the subsequent itemized billing processing, they only affect the itemized tasks themselves, without affecting the existence and stability of the entire settlement order node, significantly improving the system's fault tolerance and business processing efficiency.

[0076] Specifically, a skeleton bill node in a graph database can be represented by a data node labeled SkeletonBill. Its attributes include at least key information such as the skeleton bill ID, source order ID, customer ID, carrier ID, business account period, cargo category, settlement status, and node creation time. Settlement status can include various specific statuses, such as pending, in progress, or completed.

[0077] After the skeleton settlement order node is written into the graph database, the itemized processing module monitors and obtains the node information in real time. Based on the business type carried by the node, it determines the specific billing items and billing parameters for this order in the preset itemized rule tree.

[0078] For example, for the cold chain logistics business type, the itemized rule tree usually defines specific billing items such as basic freight, fuel surcharge and cold chain surcharge.

[0079] The item processing module generates corresponding item nodes based on the determined billing items and billing parameters. Each item node can be specifically represented in the graph database as a data node labeled BillItem. Its attributes include a unique item identifier, billing item name, corresponding fee amount, billing parameters, and the specific calculation logic for the fee amount.

[0080] For example, the name of the billing item can be specifically expressed as basic freight or cold chain surcharge, and the fee amount is, for example, 1,200 yuan. The calculation logic of the fee amount may be determined based on the weight of the transported goods or the actual mileage.

[0081] Next, this application further establishes a clear bidirectional edge structure between the skeleton settlement order node and each sub-item node in the graph database.

[0082] Specifically, the system creates a forward edge from the skeleton settlement document node to each item node, with the edge type "Has Item" (HAS_ITEM), enabling efficient querying from the skeleton node to all associated item nodes. Simultaneously, the system also creates a reverse edge from each item node back to the skeleton settlement document node, with the edge type "Part of" (PART_OF), enabling rapid tracing back from any item node to its corresponding skeleton settlement document node. This forward and reverse bidirectional edge structure effectively reduces graph database query complexity and significantly improves data traceability and audit efficiency.

[0083] After completing the creation of the sub-item node and the establishment of the bidirectional edge, the sub-item processing module further creates the corresponding financial voucher node based on the data of the sub-item node.

[0084] During the specific implementation process, the system classifies and aggregates multiple sub-item nodes with the same financial attributes based on the preset accounting subject mapping rules, summarizes the amounts, and then generates the corresponding financial voucher nodes.

[0085] For example, for all itemized nodes belonging to the "Accounts Receivable - Freight" account, the system aggregates the amounts and creates a voucher node representing the total amount for that account. This aggregation operation makes the connection between business data and financial data more natural and smooth, enhancing the clarity and maintainability of the entire financial accounting process.

[0086] It should be noted that this application uses an immutable account adjustment mechanism to adjust financial data, rather than the traditional method of directly modifying data records, thereby completely preserving the historical records of financial data changes and achieving transparent audit tracking.

[0087] When the system receives an adjustment instruction, for example, if the amount of the "Basic Freight" voucher originally set at 1,200 yuan needs to be adjusted to 1,150 yuan, the specific operation is as follows:

[0088] The system first locates the voucher node with an original amount of 1,200 yuan in the graph database and marks it as the V1 node.

[0089] Next, the system creates a new voucher node V2 with an amount attribute of negative 1,200 yuan, and establishes a reversal edge of type "REVERSES" from V2 to the V1 node to logically reverse the amount of the V1 node.

[0090] Subsequently, the system creates a new voucher node V3 with the correct amount attribute of 1,150 yuan as the valid voucher after this account adjustment.

[0091] At the same time, the system associates both V2 and V3 nodes with the corresponding skeleton settlement document nodes or sub-item nodes, and assigns the same adjustment batch number for marking.

[0092] Through this mechanism, when the system needs to calculate or query the final effective amount, it can identify the V1 node as reversed based on the edge type REVERSES and exclude it from the effective amount. The actual amount is determined as the sum of -1200 (V2 node) and 1150 (V3 node), resulting in a -50 adjustment or the 1150 in V3 as the final effective voucher amount. The entire history of the reconciliation process is clearly and completely recorded in the graph database as nodes and edges, providing a complete causal traceability path for financial audits and issue tracking.

[0093] As an optional implementation, see Figure 2 , which is a flowchart of a method for writing item nodes into a graph database provided by this application, including steps S201 to S204, wherein:

[0094] S201: Based on the business type information of the skeleton settlement order node, searching for a rule path corresponding to the business type information in the itemized rule tree;

[0095] S202: In response to successfully finding the rule path, extracting billing items and billing parameters from the rule path level by level, and performing billing calculation on the skeleton settlement form node based on the billing items and billing parameters to generate sub-item nodes;

[0096] S203: Generate a unique sub-item identifier for the sub-item node, and after setting the billing item, billing parameter, and the sub-item identifier as node attributes of the sub-item node, write the sub-item node and its node attributes into the graph database;

[0097] S204: In response to not finding a rule path corresponding to the business type information in the itemized rule tree, marking the skeleton settlement order node as a pending state, and writing the skeleton settlement order node in the pending state into the graph database.

[0098] In smart logistics business, order types and scenarios vary greatly, and various types of orders often correspond to different and diverse billing items and parameters. The traditional hard-coding method of billing processing requires the system to frequently modify the code and redeploy it when business rules change or new business types are launched, which seriously reduces the maintainability and scalability of the system. To solve the above problems, this application provides a dynamic item generation method based on a preset item rule tree.

[0099] During the implementation, a rule tree is first configured and maintained through a pre-set management interface. The core data structure of this rule tree is a tree-like decision-making structure. This tree structure consists of a series of nodes and branch paths, with each node corresponding to a judgment condition, such as order business type, cargo weight, cargo volume, or transportation mileage, among other billing-related conditions. Multiple possible branches are defined under each node, each representing a rule path that meets specific conditions. The leaf nodes of the tree explicitly store the billing items, billing parameters, and calculation logic ultimately applicable to a specific scenario.

[0100] When the sub-item processing module detects the successful creation of a new skeleton settlement order node from the graph database, it immediately extracts order-related information from the node's data attributes, particularly the business type, to initiate a rule path search. The sub-item processing module first reads the root node of the rule tree and determines the decision condition corresponding to the root node, such as the business type. The module compares the business type value of the skeleton settlement order node with each branch condition in the root node to find a fully matching branch path. For example, if the business type of the skeleton settlement order node is "cold chain transportation," the module selects the path with the business type equal to "cold chain transportation" to proceed to the next-level decision node.

[0101] During the subsequent, step-by-step rule search, the item processing module sequentially extracts other order attributes, such as cargo weight, volume, or mileage, and compares each with the branch conditions of the current decision node. It then selects branches that meet the conditions and continues traversing downward until it reaches a leaf node in the rule tree. Upon reaching a leaf node, the module automatically extracts the configured billing item names, billing parameters, and corresponding billing logic or calculation formulas from each node in the rule path.

[0102] For example, for a 600kg cold chain transport order, the module extracts three billing items from the rule tree path: "Basic Freight," "Cold Chain Surcharge," and "Overweight Surcharge." It also extracts the associated billing parameters for each item, such as a basic freight price of 2 yuan per kilometer, a cold chain surcharge of 1 yuan per kilometer, and an overweight surcharge of 0.5 yuan per kilogram, along with the corresponding calculation formulas. The itemized processing module uses these extracted parameters and formulas, combined with specific order data such as cargo weight and mileage extracted from the skeleton settlement order node, to perform precise fee calculations to obtain the final amount for each billing item.

[0103] After completing the calculation of the specific amount, the sub-item processing module will generate a specific sub-item node for each billing item with a certain amount. At this time, the system uses a distributed unique ID generation strategy such as the standard UUID algorithm or the Snowflake algorithm to assign a globally unique identification ID to each newly generated sub-item node. The data structure of the sub-item node will include this unique ID, the name of the billing item, the specific amount calculated, the billing parameters used, and the corresponding calculation formula. The sub-item processing module will then persist the sub-item node containing complete attribute data into the graph database, completing the generation and storage process of this sub-item node. The use of a globally unique ID strategy ensures that subsequent references to the node and data tracing are clearly directed and efficient.

[0104] Furthermore, an exception handling mechanism has been implemented for rule lookup failures to ensure the stability and fault tolerance of the system's processing flow. If the business type information or other order attributes extracted from the skeleton settlement order node cannot be fully matched within the itemized rule tree—in other words, if there is no corresponding rule in the rule tree—the system automatically executes the pre-set exception handling process, rather than directly throwing an error and interrupting the processing flow.

[0105] During implementation, the itemized processing module proactively updates the status attribute of the corresponding skeleton settlement document node from "Processing" to a clearly defined exception status, such as "Pending - Missing Rules." The node with the changed status is immediately persisted in the graph database to clearly indicate that billing processing for this node has not yet been completed. The system also automatically sends predefined alerts to relevant business personnel, alerting them to the missing rules.

[0106] This way, after receiving an alert, by adding billing rules corresponding to the newly added business type through the system's rule management interface, the pending skeleton settlement order node can be reprocessed manually or through a scheduled system task. This exception handling design ensures that even if there is a delay in configuring business rules, the order processing process will not be interrupted and system data will not be lost.

[0107] As an optional implementation, the step of creating a forward edge between the skeleton settlement order node and the item node, and simultaneously creating a reverse edge from the item node to the skeleton settlement order node includes:

[0108] When creating the reverse edge, the unique item identifier of the item node is written into the graph database as an attribute of the reverse edge, so that the skeleton settlement order node can be directly located to the corresponding item node based on the unique item identifier.

[0109] In actual smart logistics scenarios, a skeleton settlement order node often has a one-to-many relationship with numerous itemized nodes. For example, a typical logistics order may involve dozens or even hundreds of specific expense items, such as base freight, fuel surcharges, cold chain surcharges, and storage fees. These items are stored as independent nodes in the graph database and are associated with their corresponding skeleton settlement order nodes.

[0110] In the above solution, bidirectional edges are established between the skeleton settlement order node and each item node: a forward edge from the skeleton settlement order node to the item node, and a reverse edge from the item node back to the skeleton settlement order node. This data structure meets the requirements for general query scenarios, but in certain specific scenarios, such as when an external system initiates a precise query request that requires rapid location and update of the data for a specific item node based on the skeleton settlement order node ID and a specific item ID, this conventional data structure presents a significant performance bottleneck.

[0111] Specifically, in order to complete the precise query operation, it is necessary to first locate the target skeleton settlement order node based on the skeleton settlement order node identifier, and then the system must traverse the dozens or even hundreds of sub-item nodes connected to all forward edges starting from the skeleton settlement order node, and check the unique identification attributes of each sub-item node one by one until the target sub-item node is found. This node-by-node scanning method will significantly reduce query performance as the number of sub-item nodes increases. When the number of sub-item nodes reaches hundreds or thousands, the system's I / O overhead, memory usage, and response delay will increase sharply, significantly reducing the overall query efficiency and forming a technically obvious performance bottleneck. This application clearly defines this problem as "the problem of inefficient precise search of neighbor nodes of high-degree nodes in one-to-many relationships" in graph databases.

[0112] To effectively solve the above technical problems, this embodiment proposes an optimized data structure and specific implementation method. Specifically, when the item processing module creates an item node for the skeleton settlement order node and establishes a bidirectional association relationship in the graph database, in addition to creating a forward edge in the conventional manner (from the skeleton settlement order node to the item node, the edge type is HAS_ITEM), this embodiment specifically optimizes the creation method of the reverse edge. That is, when synchronously creating a reverse edge from the item node to the skeleton settlement order node, the unique item identifier of the item node is used as an explicit attribute of the reverse edge and is explicitly written into the graph database.

[0113] In practice, the sub-item processing module creates a unique identifier for the sub-item node in the same transaction as the sub-item node. This unique identifier can be generated using a standard UUID algorithm or a snowflake algorithm to create a globally unique ID. The module then explicitly sets the edge type to PART_OF when creating a reverse edge and defines a clear set of attributes for the edge, for example:

[0114] Edge type: PART_OF;

[0115] Edge attribute set: item_id = "unique identifier of the item node", for example, "3f7d4e6a-1b2c-4d9e-8b6c-ea2f3c1d4a8e", create_time = "2024-03-12T10:15:00Z" and other specific attribute data.

[0116] Among them, item_id is the item identifier, and its value is the unique identifier of the item node. create_time is the creation time, which records the creation time of the edge.

[0117] Through this implementation method, the data structure formed in the graph database becomes: each sub-item node points to the skeleton settlement order node through a reverse edge that clearly carries its own unique identifier, thereby forming a clearer and more efficient index relationship between the skeleton settlement order node and the sub-item node.

[0118] In specific applications, when an external system or business scenario requires direct location of the target item node based on the skeleton settlement document node ID and specific item ID, the system only needs to execute the following efficient query process:

[0119] First, the target skeleton settlement order node is quickly located based on the skeleton settlement order node identifier. Subsequently, instead of traversing all associated item nodes, the system immediately queries all reverse edges pointing to the skeleton node and directly filters on the attributes of these edges.

[0120] This allows the system to instantly locate the target sub-item node with a single edge attribute index lookup, eliminating the traditional node-by-node scan. This query process achieves true "direct" positioning, meaning it's no longer limited by the growing number of sub-item nodes, significantly reducing database I / O operations, memory usage, and response latency.

[0121] As an optional implementation, see Figure 3 , which is a flowchart of a method provided by the present application for generating a voucher node based on a sub-item node and creating an edge from the sub-item node to the voucher node, including steps S301 to S304, wherein:

[0122] S301: Determine the financial subject corresponding to the sub-item node based on a preset mapping relationship between billing item attributes and financial subjects;

[0123] S302: Grouping multiple sub-item nodes belonging to the same skeleton settlement document node according to the determined financial subjects, and generating a corresponding voucher node for each group;

[0124] S303: For each group, calculate the sum of the amounts of all item nodes in the group, and set the sum as the amount attribute of the corresponding voucher node;

[0125] S304: Create edges pointing to corresponding voucher nodes for all sub-item nodes in each group, and record the unique sub-item identifier of the sub-item node in the attributes of the edge as a basis for tracing the source of the amount attribute of the voucher node.

[0126] In order to clearly and automatically convert the billing details of logistics business into financial accounting voucher data, this application provides a specific implementation method, which effectively solves the granularity difference problem between business data and financial accounting through a sophisticated data conversion and aggregation process.

[0127] In practice, after creating multiple sub-item nodes under the skeleton settlement document node, the sub-item processing module will automatically convert the data to financial voucher nodes. This process includes clear financial account mapping, sub-item node grouping and aggregation, amount aggregation, and data association tracing.

[0128] First, the system maintains a flexibly configurable mapping relationship between billing items and financial accounts. This mapping relationship is usually stored in a dedicated configuration database or configuration file of the system, for example, in the form of a database table.

[0129] For example, each configuration record explicitly includes two key fields: the business billing item name and the corresponding financial account code and name. For example, "Basic Freight" maps to the financial account code "112201-Accounts Receivable-Freight Revenue," "Fuel Surcharge" maps to "112201-Accounts Receivable-Freight Revenue," and "Storage Fee" maps to "112202-Accounts Receivable-Storage Revenue." This configuration can be flexibly maintained and updated by finance or operations personnel through the system's management interface, ensuring the system can adapt to changes in business and financial regulations in real time.

[0130] Secondly, when the item processing module needs to convert the business item node into a financial voucher node, the specific implementation process is as follows:

[0131] The itemization processing module first extracts detailed attribute data for all itemization nodes belonging to the same skeleton settlement document node, including each itemization node's unique identifier, billing item name, amount, and other detailed information. The module then creates a temporary hash map structure in memory to automatically group and aggregate the items by financial account.

[0132] The module traverses each business sub-item node in turn, and performs the following specific processing for each sub-item node: first, it reads the billing item name of the sub-item node from the node attributes, and then uses the mapping relationship configured above to quickly query the financial account code and name corresponding to the billing item. After determining the financial account, the module uses the financial account code as the key value to search in the in-memory hash map: if the group corresponding to the account code has not yet been established, the module immediately creates an empty list in the hash map with this financial account code as the value, and stores the current sub-item node in the newly created list; if the group corresponding to the account code already exists, the current sub-item node is directly appended to the list. Through this traversal process, the system quickly forms a mapping relationship in memory that clearly groups multiple sub-item nodes based on financial accounts.

[0133] After grouping all item nodes, the item processing module further performs an amount aggregation calculation for each group. Specifically, for each financial account group, the module traverses all item nodes within the group, extracts the amount attribute of each node in turn, and accurately accumulates the amounts to obtain the total amount of the financial account group.

[0134] Subsequently, a financial document node is created using a clear data structure to reflect the calculated total amount and the corresponding financial accounting information.

[0135] Specifically, the attribute data for each financial voucher node includes a unique voucher identifier (e.g., generated using a UUID or snowflake algorithm), as well as essential financial accounting information such as the financial account code, account name, total amount, and corresponding accounting period. The module writes the generated financial voucher nodes into the graph database in a standardized manner, completing the formal storage of the financial voucher data.

[0136] To further ensure precise traceability between business data and financial data, after creating the financial voucher node, the module also creates a clear association between each item node involved in the amount calculation and the voucher node. This means creating a specific edge data structure from each item node to the financial voucher node. Each such edge explicitly stores the relationship type to the voucher node in the graph database, for example, "CONTRIBUTES_TO." The edge attributes also clearly record the item node's unique identifier and the time the edge was created. This data structure ensures that the source data for the amounts on the financial voucher nodes is clear, explicit, and traceable.

[0137] When financial accountants or auditors in the system have questions about the source of a certain financial voucher amount and need to audit the specific amount composition, the specific tracing query process is as follows: First, quickly locate the voucher node in the graph database using the voucher node's unique identifier. Then, immediately query and obtain all edges of type "CONTRIBUTES_TO" pointing to the voucher node, and quickly extract the specific sub-item node unique identifier from the attribute data of each edge. The system audit module then directly obtains each specific sub-item node attribute data in batches based on these unique identifiers, including detailed data such as the billing item name, specific amount value, calculation logic, and the order to which it belongs. This precise reverse data tracing process ensures that the data source of the financial voucher node is completely transparent, clearly traceable, and greatly improves financial audit efficiency and accounting transparency.

[0138] In this way, refined conversion and automatic aggregation of business data into financial data are achieved, solving the problems of data redundancy and accounting difficulties caused by the granularity differences between business and financial accounting, and ensuring the efficiency, accuracy and transparency of financial data.

[0139] As an optional implementation, grouping multiple sub-item nodes belonging to the same skeleton settlement order node according to the determined financial account and generating a corresponding voucher node for each group includes:

[0140] Obtaining a preset financial account template corresponding to the business type of the skeleton settlement document node, wherein the financial account template specifies the full set of financial accounts to be generated for the business type;

[0141] Based on the financial account template, determine whether each financial account in the financial account template has a corresponding sub-item node:

[0142] If there is at least one sub-item node corresponding to the financial account, group the at least one sub-item node into a group, generate a voucher node corresponding to the financial account, and calculate the sum of the amounts of all sub-item nodes in the group as the amount attribute of the generated voucher node;

[0143] If there is no item node corresponding to the financial account, a blank voucher node with an amount attribute of zero is generated;

[0144] The voucher nodes generated corresponding to all financial subjects in the financial subject template are written into the graph database to form a voucher node set consistent with the structure of the financial subject template.

[0145] This application further proposes a voucher node generation method based on a financial account template to address the challenges of financial data processing and analysis caused by inconsistent data structures in actual business processes. In actual smart logistics systems, due to the diversity and complexity of business scenarios, different orders may have significant differences in expense details, resulting in inconsistent structures in the final set of financial vouchers generated for different orders.

[0146] For example, within a batch of orders for the same "cold chain transportation" business type, some orders include basic freight and fuel surcharges, but no storage or handling service fees; while other orders may include both storage and other miscellaneous fees. This inconsistency in the structure of the voucher collection significantly complicates data integration and processing for downstream data warehouses, ERP systems, or financial analysis systems, easily leading to omissions or processing errors during data analysis and auditing, creating significant technical issues.

[0147] To solve the above technical problems, this application defines and configures corresponding financial account templates in advance based on business types, thereby ensuring that the financial voucher node sets ultimately output by all orders of the same business type are completely consistent in structure.

[0148] During specific implementation, a set of financial account templates are pre-defined and maintained in the system. The financial account template is defined separately for specific business types. For example, for the "cold chain transportation" business type, the system configures a "cold chain transportation financial account template." This template clearly stipulates all the financial accounts that the cold chain transportation business should theoretically include, such as "112201-Accounts Receivable-Freight Income," "112202-Accounts Receivable-Warehousing Income," and "112203-Accounts Receivable-Operational Service Income." It should be emphasized that this template data is stored in a system-specific configuration database or configuration file, and can be flexibly maintained and updated through the system's management interface.

[0149] When the itemization processing module completes the creation of multiple itemization nodes under the same skeleton settlement document node and prepares to generate voucher nodes, it first extracts specific transaction type information from the transaction type attribute of the skeleton settlement document node. Based on this extracted transaction type information, it then automatically retrieves and finds a matching financial account template from the aforementioned financial account template configuration database, obtaining the corresponding complete set of financial account data.

[0150] The sub-item processing module uses the full set of financial items specified in the financial item template as the basis for traversal processing, and sequentially determines the correspondence between each financial item in the template and the currently existing sub-item node. Specifically, the module performs the following specific processing flow for each financial item:

[0151] For the currently traversed financial account, the sub-item processing module first quickly searches for all sub-item nodes mapped to the financial account from the sub-item node list stored in memory. For example, when the module traverses "112201 - Accounts Receivable - Freight Income," it searches all sub-item nodes for billing item attributes such as "Basic Freight" or "Fuel Surcharge" that are mapped to the financial account.

[0152] If the query result is not empty, meaning that at least one item node mapped to the financial account exists in the system, the module groups these nodes together and accurately adds up the amount attributes of all item nodes within the group to obtain the total amount for the financial account group. The module then creates a voucher node corresponding to the financial account, setting its unique voucher identifier, financial account code and name, total amount, and corresponding account period attributes.

[0153] If the query result is empty (meaning no item node currently mapped to the financial account exists in the system), the module does not skip the financial account. Instead, it explicitly creates a blank voucher node for the financial account with the amount attribute value explicitly set to zero. The data structure of this blank voucher node is exactly the same as a normal voucher node, with the only difference being that the amount is explicitly recorded as zero. This zero-valued voucher creation method effectively avoids ambiguous "missing data" states in the data structure, ensuring that the generated voucher set remains structurally stable and consistent.

[0154] After the module has traversed all financial accounts in the financial account template, it combines all normal voucher nodes and blank voucher nodes with zero amounts into a complete data set and persists them in batches to the graph database in a transactionally consistent manner. This ensures that the output data structure strictly matches the corresponding financial account template each time the system generates voucher data.

[0155] The above-mentioned template-driven method of generating voucher node sets offers significant technical advantages. On the one hand, when integrating this financial voucher data, downstream data warehouse systems or ERP systems can pre-design fixed data interfaces and data processing flows, eliminating the need to dynamically determine whether each financial account exists. This significantly reduces the complexity and error probability of inter-system integration.

[0156] On the other hand, during the analysis of financial data, since each order of the same business type outputs a set of voucher nodes with a uniform structure, financial analysts can obtain a unified and regular data format when conducting data statistics, horizontal comparisons or trend analysis, and no longer encounter statistical or analytical deviations caused by missing data fields.

[0157] As an optional implementation, it also includes:

[0158] Before writing the skeleton settlement order node, sub-item node, voucher node and the edges between them into the graph database, a logical clock timestamp is assigned to each data entity to be written. The logical clock timestamp is used to reflect the business causal order between data entities and is generated independently of the physical clock.

[0159] In actual smart logistics business processing, the various functional modules of this application are often deployed in a distributed server cluster environment, running on different physical nodes. In a distributed system environment, the physical clocks of different servers are usually not strictly synchronized, and there are varying degrees of clock deviation. This clock deviation may fluctuate within the range of several milliseconds or even higher.

[0160] In traditional technical solutions that rely on physical clocks, when each module writes data based on a physical timestamp, the causal order of data may be reversed due to "clock deviation".

[0161] For example, the billing engine module may be deployed on server A, while the item processing module is deployed on server B. If the physical clock of server B is about 5 milliseconds faster than that of server A, then when the billing engine module generates and writes the skeleton settlement order node at the physical timestamp of server A marked as time T, and immediately sends the message to the item processing module, after receiving the message, although the item processing module physically processes it after time T, due to clock deviation, the processing timestamp recorded by it may be marked as T-5 milliseconds. In this way, the physical timestamp of the item node, which is the "result" in the causal relationship, is earlier than that of the skeleton settlement order node, which is the "cause", resulting in serious and unacceptable causal relationship confusion in the data in the database. This confusion poses huge risks to the audit, problem tracking and data analysis of financial data, and seriously damages the consistency, integrity and credibility of system data.

[0162] To address the above issues, this embodiment introduces a logical clock timestamp mechanism to completely eliminate the data causal relationship confusion caused by clock deviation in a distributed environment, thereby ensuring the consistency and reliability of system data.

[0163] In practice, each module involved in process processing maintains an independent logical clock counter within itself to generate logical clock timestamps. This logical clock counter is stored in memory as an integer and is managed only within the module, not directly dependent on any physical clock.

[0164] Whenever a module creates a new data entity and prepares to write it to the graph database, it explicitly assigns a logical clock timestamp. Data entities include, but are not limited to, skeleton settlement order nodes, item nodes, voucher nodes, and the various edges between nodes. This logical clock timestamp is a monotonically increasing integer value, generated according to the following rules:

[0165] First, when the module receives an external event or message, such as an order message in the message queue, a skeleton settlement order creation event, or an item creation event, it reads the logical clock timestamp carried in the received event or message. If the external event or message does not carry a logical clock timestamp, the external logical clock value is considered to be 0. The module then updates its local logical clock counter to the larger of the current local count value and the externally received logical clock value plus one, which becomes the module's current latest logical clock value.

[0166] Specifically, taking the billing engine module as an example, when the billing engine module receives order data from the order management module, if the order message carries a logical clock value of 100, the billing engine module first performs a local logical clock update operation, updating its own logical clock counter to "max(current local clock, 100) + 1". If the current local clock value is 99, the updated local logical clock becomes 101. Thereafter, when the billing engine module generates a skeleton settlement order node based on the order data, it writes the logical clock value 101 as an explicit attribute into the skeleton settlement order node's data structure.

[0167] Subsequently, when the itemization processing module receives an event from the billing engine module indicating the successful creation of a skeleton settlement order node, it reads the logical clock value 101 carried by the skeleton node from the event and updates its own local logical clock to "max(current local clock, 101) + 1." Assuming the current local clock of the itemization processing module is 100, the updated clock becomes 102. Thereafter, when the itemization processing module creates an itemization node, it writes the logical clock value 102 as an explicit attribute into the itemization node data structure.

[0168] The storage method of the above-mentioned logical clock timestamp value is clearly and specifically reflected as a dedicated field or attribute of each data entity. For example, in the graph database, a dedicated integer attribute field named "logical_timestamp" is set for each node or edge to explicitly record the logical clock value to avoid confusion with the original physical clock or creation time field.

[0169] By introducing the aforementioned logical clock mechanism, the problem of data causal order reversal caused by reliance on physical clocks is avoided, fundamentally ensuring the correctness of the data's causal relationship. Taking the clock deviation scenario between the billing engine module and the itemized processing module as an example, even if server B's physical clock is up to 5 milliseconds faster than server A, in this embodiment, the logical clock timestamp of the skeleton settlement order node is always 101, while the logical clock timestamp of the itemized node is always 102, clearly reflecting the fact that 101 < 102. This strictly ensures the correct causal order of the data at a logical level, and is no longer affected by the deviation of the physical clock.

[0170] It should be emphasized that the monotonically increasing nature of the logical clock ensures the global uniqueness and consistency of the entire system event sequence. Whether in auditing, tracking, or analysis scenarios, system data only needs to be sorted according to the logical clock timestamp sequence to ensure a global timeline that accurately reflects the actual business processing sequence, avoiding the risk of data confusion caused by physical clock problems, which is common in distributed systems.

[0171] As an optional implementation, the process of allocating a logical clock timestamp includes:

[0172] Before writing the skeleton settlement order node, item node, voucher node, and the edges between them into the graph database, a logical clock timestamp is assigned to each data entity to be written. The logical clock timestamp is used to reflect the business causal order between data entities and is generated independently of the physical clock.

[0173] The distributing logical clock timestamp includes:

[0174] Based on the causal dependency between the data entity to be written and the data entities that already exist in the graph database and have a direct dependency relationship with the data entity to be written, the logical clock timestamp of the data entity that has a direct dependency relationship with the data entity to be written is obtained;

[0175] Add one to the maximum of the local logical clock value of the current module and the logical clock timestamp of the data entity that has a direct dependency on the data entity to be written, and use the result as the logical clock timestamp of the data entity to be written;

[0176] The logical clock timestamp is set as the timestamp attribute of the data entity to be written, and the local logical clock value of the current module is updated to the logical clock timestamp.

[0177] During the specific implementation process, in order to ensure that the causal relationship between data entities created in a multi-module, distributed environment can always maintain correctness and global consistency, this embodiment clearly defines a precise generation and distribution mechanism for logical clock timestamps to completely avoid the problem of data causal order confusion caused by physical clock deviation of distributed servers.

[0178] In this embodiment, a logical clock counter is maintained within each module. This counter is used to continuously record the highest logical timestamp value of data entities generated in the module's history. When a module prepares to create a new data entity and write it to the graph database, the specific process of generating the logical clock timestamp is as follows:

[0179] First, the module explicitly analyzes and identifies other data entities already written to the graph database that the data entity to be written directly depends on, in order to establish strict causal relationships. For example, when the sub-item processing module prepares to create a new sub-item node, it first explicitly analyzes the sub-item node's direct business process dependency, namely the corresponding skeleton settlement order node. The sub-item processing module then retrieves the logical clock timestamp of the skeleton settlement order node from the graph database. For example, the logical clock timestamp of the skeleton settlement order node is clearly 101.

[0180] The sub-item processing module then reads the current local logical clock value from its own local logical clock counter. For example, the current local clock value is 95. At this point, the module explicitly performs a critical max() operation. Specifically, the module takes the larger of the two logical clock values, resulting in a maximum value of 101.

[0181] It's important to note that the introduction of the max() function logically plays a crucial role in "logical clock synchronization." Essentially, the module uses the max() function to specify the timestamp of the latest causal event represented by the upstream business process, namely the skeleton settlement order node. This allows the module's local logical clock to be accurately calibrated and synchronized to the correct point in the business process. This synchronization process ensures that the logical timestamp of a newly generated locally event will never be earlier than any existing causal event, fundamentally eliminating the potential risk of causal timestamp reversal.

[0182] After obtaining the result value 101 after the max() operation, the module then explicitly performs a +1 operation on the logical clock value, thereby generating a logical clock timestamp 102 of the new data entity.

[0183] It should be emphasized that the +1 operation ensures that the timestamp of the newly generated event is not only no earlier than any existing event, but is also strictly greater than the timestamps of all directly dependent upstream events, thus forming a clear and strict causal order relationship and eliminating any potential possibility of timestamp equality or stagnation.

[0184] Next, after explicitly generating the logical clock timestamp 102 for the new data entity, the item processing module writes this value into the newly generated item node as an explicit attribute, for example, as the logical_timestamp field in the item node data structure. This embodiment also emphasizes a key operation: the module must explicitly update its local logical clock counter to the latest, larger logical clock timestamp value (i.e., 102) that was just generated and used.

[0185] It is important to point out that this explicit step of updating the local logical clock counter is a necessary measure to ensure the causal order consistency within the module.

[0186] To illustrate the necessity of this update operation more clearly, here is a counterexample:

[0187] After generating and assigning the logical clock value 102, the module did not update its local logical clock counter. The local counter value remained at the previous value of 95. When the module then proceeded to process another internal task, perhaps one that had no direct causal relationship with an external event, the logical timestamp of the next data entity generated would be 96, according to the rule of the unupdated local counter value 95+1. This would be significantly less than the previously generated and used logical timestamp of 102. This would cause the logical clocks of the two data entities within the module to be in reverse order. This meant that the logical clock of a later event was less than the logical clock of an earlier event. This severely undermined the causal order consistency within the module, causing the logical clock system to fail and compromising the integrity of the system data.

[0188] Regarding S106 above:

[0189] In order to clearly illustrate the relationship between the steps in the embodiment of the present application, the relationship between S106 and the technical features in S101 to S105 is specifically explained below.

[0190] Specifically, steps S101 to S105 describe the full-process data processing method, from order data acquisition to financial voucher node generation. S101 is responsible for acquiring order data from the order management module as the initial input for the process; S102 generates a skeleton settlement document node as the core data entity of the process; S103 and S104 further generate sub-item nodes based on the skeleton settlement document node and establish clear bidirectional associations; S105 uses the sub-item node information to aggregate and generate financial voucher nodes, and constructs a causal traceability path covering orders, sub-items, and vouchers.

[0191] After the above process is completed, S106, as an important link in subsequent audits and data verification, performs batch data consistency analysis, especially for the skeleton settlement order nodes and their corresponding voucher nodes that belong to the common business context. Specifically, S106 uses the clear association between the business time series information generated and recorded in steps S101 to S105 and the nodes to dynamically evaluate and detect anomalies in the consistency of financial amounts between nodes. In other words, S106 explicitly relies on the data foundation and causal relationship structure constructed in the preceding steps S101 to S105, especially on the nodes stored in the graph database and the edge relationships between them. Through the data structure provided by the graph database, the system can efficiently retrieve and evaluate the consistency of the amounts between the nodes, thereby achieving effective auditing and anomaly location of the business data processing results.

[0192] It is understandable that a clear sequential dependency is formed between S106 and S101 to S105. The preceding steps provide the necessary data input and structural guarantees, while the subsequent steps provide a continuous verification of the accuracy and consistency of the processing results and an exception handling mechanism. This design ensures the reliability, stability, and efficiency of the overall system process. As an optional implementation, the batch data consistency analysis is a detection method based on heuristic rules, including:

[0193] Constructing an order coupling matrix for quantifying the degree of coupling between the skeleton settlement order nodes;

[0194] identifying a coupling cluster based on the order coupling matrix, wherein the coupling cluster is a group of skeleton settlement order nodes having a coupling degree greater than a preset coupling threshold;

[0195] For the coupling cluster, when there is a missing amount or an amount difference greater than a first preset threshold value in each voucher node corresponding to the same financial account within the coupling cluster, a multi-order parallel anomaly is detected.

[0196] In smart logistics scenarios, there are numerous concurrent orders, and different orders may have close business connections or interdependencies. These connections may be reflected in characteristics such as the same customer, the same carrier, the same or similar transportation routes, similar payment terms, or similar cargo types. This type of business connection is called business coupling between orders.

[0197] In order to accurately analyze and identify potential data consistency anomalies caused by this business coupling relationship, this embodiment proposes a batch data consistency analysis method based on heuristic rules to ensure that data anomalies are quickly discovered and handled in a batch business processing environment.

[0198] In its implementation, batch data consistency analysis first dynamically evaluates skeleton settlement document nodes and their corresponding voucher nodes within a common business context to identify voucher nodes that indicate data anomalies. Specifically, this dynamic evaluation utilizes business time series information that reflects the causal order between skeleton settlement document nodes within the group. The system explicitly records the logical clock timestamps of each node to construct a complete business time series sequence, which is then used to evaluate the dynamic trends and stability of the amount distribution across each voucher node.

[0199] The system clearly identifies abnormal nodes by comparing the deviation between the actual voucher node amount and the historical trend or predicted value based on business time series information. For example, if the system detects that the amount of a voucher node deviates significantly from the expected dynamic trend or historical normal range, such as the amount change exceeds a preset second threshold, such as more than 10% of the historical average, the system will immediately mark the voucher node as abnormal for further analysis and processing.

[0200] Next, the batch data consistency analysis method explicitly constructs an order coupling matrix to quantify the degree of coupling between orders. The order coupling matrix is ​​a square matrix where each row and column corresponds to a skeleton settlement order node, and the value of each matrix element represents the business coupling strength between the corresponding two skeleton settlement order nodes.

[0201] When constructing the order coupling matrix, this embodiment explicitly adopts a multi-dimensional feature quantification method to quantify the multi-dimensional business features between orders into numerical values. Specifically, the multi-dimensional business features include but are not limited to customer ID, carrier ID, transportation route, cargo type, order payment period, order creation time, etc.

[0202] For example, if the customer identification of two orders is the same and the transportation routes are highly similar, the system will assign a higher coupling value; if there is no obvious overlap in business characteristics between the two orders, the system will assign a lower or even zero coupling value.

[0203] Specifically, the order coupling matrix can be constructed using quantitative methods such as feature weighted summation or vector space similarity calculation (such as cosine similarity). For example, the order coupling degree can be calculated using the following formula:

[0204] Coupling degree = a1 × customer consistency + a2 × carrier consistency + a3 × transportation route similarity + a4 × cargo type consistency + a5 × order payment period proximity;

[0205] Among them, a1, a2, a3, a4 and a5 are weight coefficients, which can be determined by business personnel based on experience or historical data analysis.

[0206] After constructing the order coupling matrix, this embodiment further identifies order coupling clusters based on the matrix. Specifically, the system applies a cluster analysis algorithm, such as a density-based spatial clustering algorithm (e.g., DBSCAN) or a hierarchical clustering algorithm, to the order coupling matrix. This algorithm clusters skeleton settlement order nodes with coupling degrees exceeding a preset coupling threshold into several distinct coupling clusters. Each coupling cluster clearly represents a set of skeleton settlement order nodes with closely related business relationships.

[0207] The system then performs further data consistency checks on each coupled cluster. Specifically, for each financial account, the system explicitly checks the amount distribution between voucher nodes within the same coupled cluster.

[0208] If the system finds that there is a clear missing amount in the voucher node of a financial account within the coupling cluster, that is, the amount attribute of a voucher node is empty or zero, or there is an amount difference that significantly exceeds the first preset threshold, for example, the difference exceeds 500 yuan or the difference exceeds 5%, it will be clearly identified as a multi-order parallel exception.

[0209] For example, when the system detects that the voucher node amounts of the "Basic Freight" account corresponding to the three skeleton settlement order nodes in a coupling cluster are 1,200 yuan, 1,180 yuan and 0 yuan respectively (obviously missing amounts), the system will immediately identify and clearly mark this abnormal situation so that subsequent business personnel or audit systems can quickly handle it.

[0210] Through the above-mentioned batch data consistency analysis method, the system can quickly and clearly detect and identify financial data inconsistencies caused by data anomalies or business coupling in the parallel processing of multiple orders, significantly improving the consistency, reliability and audit efficiency of business data in smart logistics scenarios.

[0211] As an optional implementation, the detecting of multiple orders in parallel anomaly includes:

[0212] Construct a business snapshot data matrix, wherein its rows are composed of the skeleton settlement document nodes in the coupling cluster, its columns are composed of the financial accounts in the financial account template, and its element values ​​are the voucher amounts under the financial accounts of the skeleton settlement document nodes;

[0213] Decomposing the business snapshot data matrix through a preset mathematical model to generate a basic business pattern matrix and a sparse anomaly matrix, wherein the basic business pattern matrix is ​​defined as a low-rank matrix and the sparse anomaly matrix is ​​defined as a sparse matrix;

[0214] The multi-order parallel exception is identified based on the non-zero elements in the sparse exception matrix.

[0215] This embodiment further provides a refined processing method for parallel anomaly detection of multiple orders, so as to significantly improve the accuracy and efficiency of anomaly identification of the system in complex business scenarios.

[0216] In its implementation, the method first explicitly constructs a business snapshot data matrix to represent and quantify the financial data characteristics of each order. Specifically, the rows of this business snapshot data matrix correspond to the skeleton settlement document nodes within the coupled cluster, while its columns correspond to each financial account in the pre-set financial account template. The matrix elements represent the actual voucher amounts generated for each financial account at each skeleton settlement document node.

[0217] For example, for a coupling cluster containing 5 skeleton settlement order nodes, if the financial account template includes "basic freight", "fuel surcharge", "storage fee", etc., then the business snapshot data matrix is ​​a matrix with 5 rows and 3 columns, and each element clearly represents the amount of the corresponding order under the financial account.

[0218] Next, to further detect business anomalies, this embodiment explicitly introduces a pre-defined mathematical model, such as the Robust Principal Component Analysis (Robust PCA), to perform a matrix decomposition operation on the business snapshot data matrix. This decomposition explicitly generates two matrices: a basic business pattern matrix and a sparse anomaly matrix.

[0219] Specifically, the basic business pattern matrix is ​​strictly limited to a low-rank matrix, which represents relatively stable and frequently occurring business amount patterns in the matrix data. These patterns reflect normal or typical business behavior characteristics; while the sparse anomaly matrix is ​​strictly limited to a sparse matrix, in which most elements are zero and only a few elements are non-zero. It is specifically used to capture abnormal amounts or abnormal changes that deviate significantly from normal business patterns.

[0220] In its specific implementation, robust principal component analysis uses optimization to decompose the original business snapshot data matrix into two parts: a basic business pattern matrix and a sparse anomaly matrix. The optimization process can be exemplified in two ways: one is to minimize the rank of the basic business matrix, i.e., its information complexity, while simultaneously minimizing the number of non-zero elements in the anomaly matrix to extract stable business features and eliminate outliers; the other is to effectively distinguish between typical patterns and abnormal changes by limiting the structural complexity of the basic business matrix and controlling the amplitude distribution of the elements in the anomaly matrix. These optimization methods ensure that the basic business pattern matrix can effectively reflect regular business behavior, while the sparse anomaly matrix clearly identifies suspicious or abnormal changes in amounts.

[0221] After decomposition, this embodiment explicitly identifies multi-order parallel anomalies based on the non-zero elements in the sparse anomaly matrix. If the value of an element is significantly non-zero and exceeds a preset threshold, the system explicitly marks the corresponding skeleton settlement document node and financial account as an anomaly for subsequent audit and detailed investigation.

[0222] Through the above-mentioned matrix decomposition and sparse anomaly recognition methods, the system effectively improves the accuracy of anomaly detection and significantly reduces the false alarm rate, thereby ensuring that the business processing process is more accurate, efficient and reliable.

[0223] As an optional implementation manner, the decomposing the business snapshot data matrix by using a preset mathematical model to generate a basic business pattern matrix and a sparse anomaly matrix includes:

[0224] Obtaining the logical clock timestamp corresponding to each skeleton settlement order node in the business snapshot data matrix;

[0225] Calculating the causal proximity between the skeleton settlement order nodes in the coupling cluster based on the logical clock timestamps, and introducing a timing weight corresponding to the causal proximity into the decomposition process of the mathematical model, wherein the timing weight is set as a monotonically decreasing function of the difference between the logical clock timestamps of the skeleton settlement order nodes;

[0226] The weighted matrix decomposition is completed to generate the basic business model matrix and the sparse exception matrix.

[0227] This embodiment provides a time-series weighted matrix decomposition method based on logical clock timestamps to more accurately identify and locate abnormal situations in the parallel processing of multiple orders.

[0228] During implementation, the system first retrieves the logical clock timestamp explicitly recorded for each skeleton settlement order node from the business snapshot data matrix. Specifically, this logical clock timestamp, as one of each node's time attributes, is pre-written into the node attribute set by the upstream module when the business snapshot data matrix is ​​constructed. This timestamp is derived from the local logical counters updated by each module in the preceding process according to "event-driven" logic. Each time a dependent event is processed, the module increments the maximum dependent clock value by one, which serves as the timestamp for the current node.

[0229] For example, when generating a skeleton settlement order node, the billing engine module receives an event message from the order management module, extracts the upstream logical timestamp from the message as 101, then updates its own logical clock to 102 and stores this timestamp in the node attributes. This logical clock timestamp clearly reflects the business causal order between skeleton settlement order nodes. For example, during logistics order processing, orders processed first will have a smaller logical clock timestamp, while orders processed later will have a larger logical clock timestamp.

[0230] The system then calculates the causal proximity between each skeleton settlement order node within the coupled cluster based on the obtained logical clock timestamps. Specifically, the system calculates the difference in logical clock timestamps between any two nodes to measure the temporal relationship between them. A smaller difference indicates a closer integration of the two nodes within the business process, resulting in a higher causal proximity.

[0231] Furthermore, in order to fully reflect the temporal characteristics of the business process in the matrix decomposition model, the system introduces a temporal weight in the decomposition optimization process.

[0232] Specifically, the timing weight is defined as a monotonically decreasing function of the difference in logical clock timestamps between nodes. For example, the timing weight can be set to the inverse of the difference in logical clock timestamps between nodes. This means that node pairs with smaller timestamp differences have a greater weight in the matrix decomposition, more accurately reflecting actual business relationships.

[0233] During matrix decomposition, the system incorporates the aforementioned time-series weights through robust principal component analysis or similar matrix decomposition techniques. It's important to note that this weighted matrix decomposition method effectively highlights typical business patterns between nodes with close temporal relationships. Furthermore, anomalies are more clearly evident in a sparse anomaly matrix. For example, if two closely timed orders exhibit significant discrepancies in financial data or unusual amounts, these discrepancies will be prominently displayed in the sparse anomaly matrix, facilitating further audit or investigation.

[0234] After completing the weighted matrix decomposition described above, the system generates a basic business model matrix and a sparse anomaly matrix. It's understandable that the basic business model matrix clearly reflects normal and stable business behavior patterns, while the sparse anomaly matrix clearly highlights unusual data changes or amounts. The system then accurately identifies and locates specific abnormal nodes and amounts based on the non-zero elements in the sparse anomaly matrix. Specifically, the system indexes and tracks the position of each non-zero element in the anomaly matrix to map the corresponding skeleton settlement order node and associated financial account. Combining the node identifiers and timestamp attributes in the original graph database, the system quickly reverse-locates the order data source that caused the anomaly. For example, when a significant non-zero value appears in the "Storage Fee" column in the anomaly matrix of a coupled cluster, the system identifies the skeleton settlement order node identifier corresponding to that row and retrieves the associated sub-item and voucher node information, thereby constructing a complete anomaly tracking path.

[0235] It should be emphasized that this logical clock-driven time-weighted matrix decomposition method can significantly improve the accuracy and timeliness of anomaly detection, greatly enhancing the precision and efficiency of business auditing and data analysis in smart logistics scenarios.

[0236] Based on the same inventive concept, the embodiment of the present application also provides a process dynamic processing system based on multi-module collaboration of smart logistics scenarios corresponding to the process dynamic processing method based on multi-module collaboration of smart logistics scenarios. Since the principle of problem solving by the system in the embodiment of the present application is similar to the above-mentioned process dynamic processing method based on multi-module collaboration of smart logistics scenarios in the embodiment of the present application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be repeated.

[0237] Reference Figure 4FIG. 1 is a schematic diagram of a process dynamic processing system based on multi-module collaboration in a smart logistics scenario provided by an embodiment of the present application. The system includes:

[0238] The order management module 10 is used to obtain and output order data to the billing engine module 20, and the order data is used to generate a skeleton settlement order node;

[0239] The billing engine module 20 generates a skeleton settlement order node based on the order data and writes the skeleton settlement order node into a graph database;

[0240] The item processing module 30 generates at least one item node based on a preset item rule tree and the skeleton settlement order node, classifies and aggregates the item nodes according to the financial account template to generate voucher nodes, constructs an order coupling matrix based on the order data, detects multi-order parallel anomalies, and generates a difference node for linkage adjustment based on the multi-order parallel anomalies;

[0241] The graph database 40 is used to store skeleton settlement order nodes, item nodes, voucher nodes, difference nodes, order coupling matrix, and forward and reverse edges between nodes, and maintain the logical clock timestamps of each node and edge to form a causal traceability path covering orders, items and vouchers.

[0242] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

Claims

1. A dynamic process processing method based on multi-module collaboration in smart logistics scenarios, characterized by: include: Get order data from the order management module; In the billing engine module, a skeleton settlement order node is generated based on the order data and written into the graph database; In the item processing module, at least one item node is generated based on the preset item rule tree and the skeleton settlement order node, and the item node is written into the graph database; Generating at least one sub-item node includes: searching for a rule path corresponding to the business type information in the sub-item rule tree based on the business type information of the skeleton settlement form node; in response to successfully finding the rule path, extracting billing items and billing parameters from the rule path level by level, and performing billing calculation on the skeleton settlement form node based on the billing items and billing parameters to generate a sub-item node; generating a unique sub-item identifier for the sub-item node, and after setting the billing items, billing parameters, and sub-item identifier as node attributes of the sub-item node, writing the sub-item node and its node attributes into a graph database; In the graph database, a forward edge is created between the skeleton settlement order node and the item node, and a reverse edge is simultaneously created from the item node to the skeleton settlement order node. When creating the reverse edge, the unique item ID of the item node is written into the graph database as an attribute of the reverse edge, so that the skeleton settlement order node can be directly located to the corresponding item node based on the unique item ID. Generate voucher nodes based on item nodes, and create edges from item nodes to voucher nodes, forming a causal traceability path covering orders, items and vouchers in the graph database; generating voucher nodes includes: determining the financial account corresponding to the item node based on the mapping relationship between the preset billing item attributes and financial accounts; grouping multiple item nodes belonging to the same skeleton settlement order node according to the determined financial accounts, and generating a corresponding voucher node for each group; for each group, calculating the total amount of all item nodes in the group, and setting the total amount as the amount attribute of the corresponding voucher node; creating edges pointing to the corresponding voucher node for all item nodes in each group, and recording the unique item identifier of the item node in the attribute of the edge as the basis for tracing the source of the voucher node amount attribute; Batch data consistency analysis is performed on the skeleton settlement order nodes and their corresponding voucher nodes belonging to a common business context to identify voucher nodes indicating data anomalies, wherein the batch data consistency analysis utilizes the business timing information reflecting the causal order between the skeleton settlement order nodes in the group to dynamically evaluate the amount distribution of each voucher node in the group; the batch data consistency analysis is a detection based on heuristic rules, including: constructing an order coupling matrix for quantifying the coupling degree between the skeleton settlement order nodes; identifying coupling clusters based on the order coupling matrix, wherein a coupling cluster is a group of skeleton settlement order nodes with a coupling degree greater than a preset coupling threshold; and for the coupling cluster, when the voucher nodes corresponding to the same financial account within the coupling cluster have missing amounts or the amount difference is greater than a first preset threshold, detecting multi-order parallel anomalies; it also includes: before writing the skeleton settlement order nodes, sub-item nodes, voucher nodes and the edges between them into the graph database, assigning a logical clock timestamp to each data entity to be written, the logical clock timestamp is used to reflect the business causal order between data entities and is generated independently of the physical clock; Allocating a logical clock timestamp includes: obtaining the logical clock timestamp of the data entity that has a direct dependency relationship with the data entity to be written based on the causal dependency between the data entity to be written and the data entity that already exists in the graph database and has a direct dependency relationship with the data entity to be written; adding one to the maximum value of the local logical clock value of the current module and the logical clock timestamp of the data entity that has a direct dependency relationship with the data entity to be written, as the logical clock timestamp of the data entity to be written, setting the logical clock timestamp as the timestamp attribute of the data entity to be written, and updating the local logical clock value of the current module to the logical clock timestamp.

2. The process dynamic processing method based on multi-module collaboration of smart logistics scenarios according to claim 1 is characterized in that: Also includes: In response to receiving an adjustment instruction, the target voucher node in the graph database is located according to the voucher node identifier carried by the adjustment instruction, and the preset adjustment operation is performed on the target voucher node without modifying the original record of the target voucher node, generating an adjustment record including an offset type edge and a difference node, and writing the adjustment record into the graph database.

3. The dynamic process processing method based on multi-module collaboration of smart logistics scenarios according to claim 1 is characterized in that: Also includes: In response to not finding a rule path corresponding to the business type information in the itemized rule tree, marking the skeleton settlement order node as a pending state, and writing the skeleton settlement order node in the pending state into the graph database.

4. The dynamic process processing method based on multi-module collaboration of smart logistics scenarios according to claim 1 is characterized in that: The step of grouping multiple sub-item nodes belonging to the same skeleton settlement order node according to the determined financial subjects and generating a corresponding voucher node for each group includes: Obtaining a preset financial account template corresponding to the business type of the skeleton settlement document node, wherein the financial account template includes a full set of financial accounts to be generated for the business type; Based on the financial account template, determine whether each financial account in the financial account template has a corresponding sub-item node: If there is at least one sub-item node corresponding to the financial account, group the at least one sub-item node into a group, generate a voucher node corresponding to the financial account, and calculate the sum of the amounts of all sub-item nodes in the group as the amount attribute of the generated voucher node; If there is no item node corresponding to the financial account, a blank voucher node with an amount attribute of zero is generated; The voucher nodes generated corresponding to all financial subjects in the financial subject template are written into the graph database to form a voucher node set consistent with the structure of the financial subject template.

5. The dynamic process processing method based on multi-module collaboration of smart logistics scenarios according to claim 1 is characterized in that: The detecting of multiple orders in parallel anomaly includes: Construct a business snapshot data matrix, wherein its rows are composed of the skeleton settlement document nodes in the coupling cluster, its columns are composed of the financial accounts in the financial account template, and its element values ​​are the voucher amounts under the financial accounts of the skeleton settlement document nodes; Decomposing the business snapshot data matrix using a preset mathematical model to generate a basic business pattern matrix and a sparse anomaly matrix; The multi-order parallel exception is identified based on the non-zero elements in the sparse exception matrix.

6. The dynamic process processing method based on multi-module collaboration of intelligent logistics scenarios according to claim 5 is characterized in that: Decomposing the business snapshot data matrix by a preset mathematical model to generate a basic business pattern matrix and a sparse anomaly matrix includes: Obtaining the logical clock timestamp corresponding to each skeleton settlement order node in the business snapshot data matrix; Calculating the causal proximity between the skeleton settlement order nodes in the coupling cluster based on the logical clock timestamp, and introducing a timing weight corresponding to the causal proximity to the decomposition process of the mathematical model, wherein the timing weight is a monotonically decreasing function of the difference between the logical clock timestamps of the skeleton settlement order nodes; The weighted matrix decomposition is completed to generate the basic business model matrix and the sparse exception matrix.

7. A process dynamic processing system based on multi-module collaboration of smart logistics scenarios, used to implement the process dynamic processing method based on multi-module collaboration of smart logistics scenarios according to any one of claims 1 to 6, characterized in that: include: An order management module is used to obtain and output order data to the billing engine module. The order data is used to generate a skeleton settlement order node; A billing engine module generates a skeleton settlement order node based on the order data and writes the skeleton settlement order node into a graph database; An item processing module generates at least one item node based on a preset item rule tree and the skeleton settlement order node, classifies and aggregates the item nodes according to the financial account template to generate voucher nodes, constructs an order coupling matrix based on the order data, detects multi-order parallel anomalies, and generates a difference node for linkage adjustment based on the multi-order parallel anomalies; The graph database is used to store skeleton settlement order nodes, item nodes, voucher nodes, difference nodes, order coupling matrix, and the forward and reverse edges between nodes, and maintain the logical clock timestamps of each node and edge to form a causal traceability path covering orders, items and vouchers.

Images