Logistics charging engine system and method

Abstract

The invention provides a logistics charging engine system and method, and relates to the technical field of logistics transportation, and the method comprises the steps: extracting a business field and a metering field from a charging document, matching a charging rule to generate a cost calculation scheme, and carrying out the operation of the metering field to obtain a charging result. And collecting the charging result and the related document information to form a settlement bill, and aggregating a plurality of settlement bills according to a preset merging rule to form a bill. In addition, a plurality of charging results meeting a threshold condition can be automatically combined by constructing an adjacent matrix and executing graph search on the non-zero association degree of the adjacent matrix. Carrying out individual anomaly detection on a charging result before merging, and carrying out adjacency matrix construction after abnormal orders are eliminated; and after merging is completed, group anomaly detection is executed for the whole group of orders, and if an anomaly is triggered, splitting or isolation processing is carried out. According to the invention, the method can improve the merging efficiency and abnormality prevention and control in a large-scale order scene while maintaining the charging accuracy.

Description

Technical Field

[0001] This application relates to the technical field of logistics transportation. Specifically, it relates to a logistics billing engine system and method. Background Art

[0002] In existing logistics billing systems, fixed rules are usually set to calculate the fees for transportation orders, shipping orders, etc., and after the calculation is completed, the settlement sheets are manually or semi-automatically collected and the bills are merged. However, these traditional solutions mostly adopt simple field matching or single judgment modes, and it is difficult to take into account the flexible rates in different contracts and different business scenarios. At the same time, with the continuous expansion of the logistics scale and the diversification of order types, if only relying on ordinary field equality or a small number of rules, it is very difficult to automatically identify and merge a large number of similar orders or duplicate business entries effectively. In addition, individual orders may bring potential abnormal risks due to incorrect entry, carrier anomalies or other reasons. Traditional systems often need to be manually screened to avoid miscalculation or duplicate billing, which is both time-consuming and lacks systematicness. Especially when facing a large number of orders, multiple dimensions or cross-organizational collaboration, existing methods generally lack a perfect anomaly detection mechanism and multi-dimensional automatic merging ability, and it is difficult to meet the higher requirements of the modern logistics industry for billing accuracy and settlement efficiency. Summary of the Invention

[0003] In view of the deficiencies of the prior art, this application provides a logistics billing engine system and method.

[0004] In a first aspect, this application provides a logistics billing engine method, including: Obtaining billing documents, and extracting business fields and measurement fields from the billing documents; According to the business fields and measurement fields, matching pre-configured billing rules to generate corresponding fee calculation schemes; Based on the fee calculation schemes, performing operations on the measurement fields to obtain billing results; Collecting the billing results and relevant document information, constructing multiple billing result groups based on the association of business fields, and generating corresponding settlement sheets according to each billing result group; According to pre-set merging rules, aggregating multiple settlement sheets to form a bill; The forming of the settlement sheet further includes: assigning unique identifiers to each billing result, and constructing an adjacency matrix based on the matching situation of the billing results in the business fields; performing a graph search on the non-zero association degrees in the adjacency matrix, and merging multiple billing results with association degrees meeting a preset threshold to generate a single settlement sheet; Before generating the single settlement statement, it further includes: performing individual anomaly detection on each of the billing results, and if the billing result meets the anomaly determination condition, marking it as an anomaly and excluding it from the construction of the adjacency matrix; only constructing the adjacency matrix for the billing results that are not marked as anomalies and performing graph search.

[0005] As an optional implementation manner, the matching of the pre-configured billing rules includes: Performing conditional judgment on the service fields to determine the rate field interval corresponding to the service fields; According to the rate field interval, performing segmented processing on the measurement fields and obtaining segmented rates; Based on the segmented rates, generating the cost calculation plan.

[0006] As an optional implementation manner, when generating the cost calculation plan, it further includes: Setting the minimum billing amount and the maximum billing amount, taking the minimum billing amount when the calculated billing result is less than the minimum billing amount, and taking the maximum billing amount when it is greater than the maximum billing amount; Setting the minimum billing quantity and the maximum billing quantity, taking the minimum billing quantity when the calculated quantity is less than the minimum billing quantity, and taking the maximum billing quantity when it is greater than the maximum billing quantity.

[0007] As an optional implementation manner, the aggregating the billing results and related document information, constructing multiple billing result groups based on the association of service fields, and generating corresponding settlement statements according to each billing result group includes: Filtering the billing results according to the pre-set filtering conditions, where the filtering conditions include at least one of the carrier, shipper, and transportation type; In response to the same order date, transportation route, consignee, and consignee location information, merging multiple billing results that meet the filtering conditions to generate a single settlement statement.

[0008] As an optional implementation manner, the aggregating multiple settlement statements and forming a bill according to the pre-set merging rules includes: Filtering the settlement statements according to the pre-set bill generation filtering conditions, where the bill generation filtering conditions include at least one of the customer identifier, billing cycle, or organizational dimension; In response to meeting the bill generation filtering conditions, aggregating and merging multiple single settlement statements; Summarizing the information of the merged settlement statements into a single bill.

[0009] As an alternative implementation, after merging the adjacency matrix to obtain multiple billing result groups and generating a single settlement statement, the following steps are further included: Perform group anomaly detection for each of the billing result groups. In response to the billing result group meeting the group anomaly determination condition, mark the billing result group as abnormal pending review and perform splitting or isolation processing; In response to the determination that there is no group anomaly, output the single settlement statement corresponding to the billing result group.

[0010] As an alternative implementation, the step of aggregating multiple settlement statements according to the preset merging rules to form a bill further includes: Create graph nodes in the knowledge graph database to represent business entities such as settlement statements, orders, carriers, transportation routes, and billing cycles, as well as relationship edges to represent dependencies or associations between business entities; Write the keyword field information of the settlement statement into the knowledge graph database to form a graph data structure for bill merging; According to the pre-configured business rules or inference engine, perform inference operations on the settlement statement nodes and their associated relationships in the knowledge graph database to automatically identify a set of settlement statement nodes that meet the bill merging conditions; Link the set of settlement statement nodes identified by the inference operation with the adjacency matrix or anomaly detection module. When it is determined that there is no anomaly, output the merged bill. If it is determined that there is an anomaly, perform splitting or isolation operations on the relevant settlement statements for dynamic aggregation of the bill.

[0011] As an alternative implementation, the step of aggregating multiple settlement statements according to the preset merging rules to form a bill further includes: Read the vectorized field information generated for each order from the storage medium and perform batch similarity calculations on the vectorized field information to form a partial block adjacency matrix, which records the non-zero similarities between order pairs; When importing the adjacency matrix into the knowledge graph database, create or update corresponding graph nodes for each order, and establish or update a relationship edge between the graph nodes according to the similarity results in the adjacency matrix. The relationship edge carries a similarity vector or association degree attribute; Generate a super node for an order set where the similarity is greater than the preset similarity threshold and the field values are the same. In the knowledge graph database, regard the super node as a single node object, and hang the differentiated fields of each order in the order set in the form of an additional vector; When performing bill aggregation, determine whether each order meets the merging conditions based on the super node and its additional vectors, and perform reasoning in combination with cross-entity information. In response to meeting the bill merging conditions, create corresponding bill nodes in the knowledge graph database and associate them with relevant order nodes.

[0012] In a second aspect, the present application provides a logistics billing engine system, including: A collection module that obtains billing documents and extracts business fields and measurement fields from the billing documents; A first calculation module that matches pre-configured billing rules according to the business fields and measurement fields to generate corresponding cost calculation plans; A second calculation module that performs operations on the measurement fields based on the cost calculation plans to obtain billing results; A settlement module that collects the billing results and related document information, constructs multiple billing result groups based on the association of business fields, and generates corresponding settlement statements according to each billing result group; A generation module that aggregates multiple settlement statements according to pre-set merging rules to form a bill.

[0013] Compared with the prior art, by introducing an adjacency matrix and multi-stage anomaly detection after obtaining the billing results, the present application can significantly improve the flexibility and accuracy of automatically merging settlement statements. First, by assigning unique identifiers to each billing result and constructing an adjacency matrix based on business fields, graph search or clustering is performed on the results that meet a certain correlation threshold with each other, and orders that are "partially similar" or "multi-dimensionally similar" can be efficiently discovered for merging, reducing manual determination. Second, individual anomalies are excluded before merging, and then group anomalies are detected after merging, which can effectively intercept single or entire groups of potential anomalies and provide security guarantees for subsequent bill aggregation. Finally, through various optional implementation methods such as minimum / maximum billing limits and segmented rates, the refinement and controllability of the cost calculation process are further enhanced, greatly improving the applicability and operation efficiency of the logistics billing engine in different business scenarios, and avoiding problems such as incorrect merging, missed merging, and untimely processing of abnormal orders caused by simple rules in traditional systems. Description of the Drawings

[0014] Figure 1 It is a flowchart of the logistics billing engine method provided by the embodiment of the present application; Figure 2 It is a schematic diagram of a billing system provided by the embodiment of the present application; Figure 3 It is a flowchart of a group anomaly detection method provided by the embodiment of the present application; Figure 4 It is a schematic diagram of the logistics billing engine system provided by the embodiment of the present application.

[0015] Reference numerals: 10, acquisition module; 20, first calculation module; 30, second calculation module; 40, settlement module; 50, generation module. Detailed implementation manners

[0016] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments.

[0017] See Figure 1 As shown, it is a flowchart of a logistics billing engine method provided by an embodiment of the present application. The method includes steps S101 to S105, where: S101: Obtain a billing document, and extract a service field and a measurement field from the billing document; S102: According to the service field and the measurement field, match a pre-configured billing rule to generate a corresponding cost calculation plan; S103: Based on the cost calculation plan, perform an operation on the measurement field to obtain a billing result; S104: Aggregate the billing result and relevant document information, construct multiple billing result groups based on the association of service fields, and generate a corresponding settlement form according to each billing result group; S105: According to a pre-set merging rule, aggregate multiple settlement forms to form a bill.

[0018] In specific implementation, first obtain a billing document from a business system. The billing document may include a transportation order or a shipping order, etc. For the convenience of subsequent cost calculation, it is necessary to extract a service field and a measurement field after obtaining the billing document. The service field is usually used to reflect the conditions required for billing (such as transportation route, vehicle type, carrier, shipper, etc.), and the measurement field is used to participate in specific numerical operations (such as weight, volume, quantity, mileage, etc.). By classifying these fields, corresponding billing rules can be matched according to the specific field types in subsequent steps.

[0019] When matching a pre-configured billing rule, the corresponding rate range can be retrieved or judged according to the value of the service field, or the measurement field can be segmented according to the combined conditions of the service field, so as to generate a cost calculation plan. The cost calculation plan includes information such as the operation method for different measurement fields, rate reference, and limiting conditions. Subsequently, based on the cost calculation plan, an operation is performed on the aforementioned measurement field to obtain a billing result. The operation process may include multiplying by a rate or performing numerical processing such as addition, capping, and guaranteeing.

[0020] After obtaining the billing result, the system will aggregate the billing result with the corresponding document information to form a settlement statement. The settlement statement can be regarded as a relatively complete record of expense details, containing all the field information and calculation process related to this calculation, providing a basis for subsequent consolidation processing or financial verification. Finally, according to the pre-set consolidation rules, multiple settlement statements meeting the corresponding conditions are consolidated to generate a bill.

[0021] In specific implementation, the consolidation rules can include organizational dimensions, billing cycles, or other filtering conditions to classify and summarize the settlement statements.

[0022] Through the above steps, the method of the logistics billing engine based on rule generation can be realized, meeting the expense calculation requirements under various business scenarios and simplifying the subsequent settlement process.

[0023] As an optional implementation manner, the matching of the pre-configured billing rules includes: Performing a conditional judgment on the business fields to determine the rate field interval corresponding to the business fields; According to the rate field interval, performing segmented processing on the measurement fields and obtaining segmented rates; Based on the segmented rates, generating the expense calculation plan.

[0024] In specific implementation, when performing a conditional judgment on the business fields, the corresponding rate field interval can be determined based on the transportation route, vehicle type, shipper, or other business-related attributes under different business scenarios.

[0025] Specifically, the system first retrieves the values of the business fields. For example, when the transportation route is within a specific regional range, the corresponding rate interval table is matched; another example is when the vehicle type is a large vehicle, then another rate interval table is matched. Through this matching process, the subsequent segmented processing rules for the measurement fields can be refined.

[0026] Subsequently, based on the matched rate field interval, segmented processing is performed on the measurement fields. For example, for the weight field, 0 to 10 tons can be defined as the first rate bracket, 10 to 20 tons as the second rate bracket, and when the weight exceeds 20 tons, it enters the third rate bracket. Each rate bracket corresponds to one or more rate calculation parameters. By performing segmented processing on the measurement fields, the system can obtain segmented rates to distinguish the expense levels within different weight ranges or other numerical ranges.

[0027] Based on the segmented rates, an expense calculation plan is further generated. The expense calculation plan can include the rate values adopted by the measurement fields in each interval, the cumulative calculation method, or other additional rules (such as minimum expenses, maximum expense limits, etc.).

[0028] In this way, the solution is finally output to subsequent billing steps for calculating the fees for specific business orders or shipping orders, enabling flexible and accurate application of corresponding segmented rates under different business field conditions and achieving multi-dimensional and refined billing processing.

[0029] As an alternative implementation manner, when generating the fee calculation solution, it further includes: Setting a minimum billing amount and a maximum billing amount. When the calculated billing result is less than the minimum billing amount, the minimum billing amount is taken; when it is greater than the maximum billing amount, the maximum billing amount is taken.

[0030] Setting a minimum billing quantity and a maximum billing quantity. When the calculated quantity is less than the minimum billing quantity, the minimum billing quantity is taken; when it is greater than the maximum billing quantity, the maximum billing quantity is taken.

[0031] In specific implementation, in order to better control the upper and lower limits of fees or quantities when generating the fee calculation solution, the system can first define a minimum billing amount and a maximum billing amount. After the operation on the measurement field is completed, if the calculated billing result is less than the minimum billing amount, the billing result is corrected to the minimum billing amount; if the calculated billing result is greater than the maximum billing amount, it is corrected to the maximum billing amount. By this means, extreme situations of too low or too high fees during the billing process can be effectively avoided.

[0032] Meanwhile, the system can also control the minimum billing quantity and the maximum billing quantity involved in the billing. For example, when the quantity obtained from the operation result of the measurement field or the segmented rate is less than the minimum billing quantity, the result is corrected to the minimum billing quantity; if it is greater than the maximum billing quantity, it is corrected to the maximum billing quantity. This can ensure that the quantity value remains within a reasonable range during the operation process and avoid abnormal deviations of the order quantity or shipping quantity at the billing end.

[0033] The above-mentioned minimum billing amount, maximum billing amount, minimum billing quantity and maximum billing quantity can be configured according to fixed thresholds or dynamically adjusted according to business scenarios or seasonal changes, so as to make timely corrections to extreme billing results on the basis of not affecting the normal billing logic and improve the overall stability and rationality of billing. This implementation manner, combined with the basic segmented rate, enables the system to perform standardized billing according to interval rates when generating the fee calculation solution and can also meet more diverse business needs through effective restrictions on the upper and lower limits of fees and quantities.

[0034] As an alternative implementation manner, the collection of the billing result and related document information, the construction of multiple billing result groups based on the association of business fields, and the generation of corresponding settlement sheets according to each billing result group include: Filter the billing results according to pre-set filtering conditions, where the filtering conditions include at least one of carrier, shipper, and transportation type; In response to the order date, transportation route, consignee, and place of receipt information being the same, merge multiple billing results that meet the filtering conditions to generate a single settlement statement.

[0035] In a specific implementation, during the process of aggregating the billing results and relevant document information to form a settlement statement, the system first filters the billing results according to pre-set filtering conditions. The filtering conditions can include business dimensions such as carrier, shipper, and transportation type. Specifically, the system reads the field information such as carrier, shipper, and transportation type corresponding to each billing result, and marks the results that meet the specified conditions as mergeable objects for preliminary grouping of subsequent merge operations.

[0036] Next, the system checks the fields such as order date, transportation route, consignee, and place of receipt of these mergeable objects. If it is found that the above field values of multiple billing results are the same, they are merged to generate a single settlement statement. This merge operation can sum up or integrate key data such as expense details, quantity, and weight of relevant billing results and record them centrally in the settlement statement. Thus, the number of duplicate settlement documents can be reduced, and the efficiency in subsequent settlement or reconciliation can be improved. Once the settlement statement is generated, it can be used for subsequent processing links such as bill aggregation or financial reconciliation.

[0037] In this way, through this screening and merging mechanism based on multi-dimensional business fields, the system can simplify the settlement statement management process while maintaining billing accuracy.

[0038] As an optional implementation method, aggregating multiple settlement statements and forming a bill according to pre-set merging rules includes: Filter the settlement statements according to pre-set bill generation filtering conditions, where the bill generation filtering conditions include at least one of customer identifier, billing cycle, or organizational dimension; In response to meeting the bill generation filtering conditions, aggregate and merge multiple single settlement statements; Summarize the information of the merged settlement statements into a single bill.

[0039] In the specific implementation, after the generation of a single settlement form is completed, the system will further filter all settlement forms according to the pre-set bill generation filter conditions. The bill generation filter conditions may include business factors such as customer identification, billing cycle or organizational dimension. For example, the system can search for all settlement forms generated within a pre-defined billing cycle (such as monthly, quarterly, etc.), or it can group settlement forms generated at different time points for the same customer based on customer identification, or centrally process settlement forms belonging to the same business department based on organizational dimensions.

[0040] When the bill generation filtering conditions are met, the system will collect and merge multiple single settlement documents that meet the conditions. Specifically, the system can first verify the merging rules of these settlement documents to be merged, such as checking whether they are from the same customer or the same billing cycle, or whether they meet specific income or expense accounting requirements. If all conditions are met, the corresponding expense details, quantities, time intervals, and related field information will be summarized at the bill level. Through this merging operation, the subsequent financial reconciliation or audit process can be simplified to avoid too many scattered settlement documents for the same customer or the same billing cycle.

[0041] After the consolidation is completed, the system will finally collect the consolidated settlement information into a single invoice. This invoice can contain all the consolidated charges corresponding to the customer ID or billing period, the summary amount and other additional information to facilitate subsequent comprehensive audit, invoicing or reconciliation operations.

[0042] In this way, by collecting and merging multiple settlement statements, on the one hand, the efficiency of bill management can be improved, and on the other hand, the consistency and integrity of bill data in the vertical and horizontal directions can be guaranteed, providing data support for subsequent financial processes.

[0043] As an optional implementation manner, the step of aggregating the billing results and related document information to form a settlement statement further includes: Assign a unique identifier to each billing result, and build an adjacency matrix based on the matching of business fields between billing results; A graph search is performed on the non-zero associations in the adjacency matrix, and multiple billing results whose associations meet a preset threshold are combined to generate a single settlement sheet.

[0044] In a specific implementation, in order to more flexibly aggregate the billing results and related document information into a single settlement form, the system may use an adjacency matrix to represent the correlation between different billing results, and automatically identify the billing results that can be merged through graph search or clustering methods, which may specifically include the following steps: First, assign a unique identifier to each billing result and record its key business fields separately. The key business fields may include transportation routes, carriers, consignees, shippers, vehicle types, and transportation times, etc. Then, for any two billing results, the system reads the values of their business fields and calculates the correlation degree. For example, it judges whether the origin and destination are continuous, whether the transportation times overlap, whether the carriers are the same, or whether the vehicle types are compatible, etc. If two billing results meet the preset conditions in at least one or more business fields, write a non-zero value at the corresponding position in the adjacency matrix to indicate that there is a potential possibility of merging between them; if the conditions are not met, assign a value of zero.

[0045] After completing the construction of the adjacency matrix, the system can perform graph search or clustering based on a preset threshold. Specifically, the system traverses each non-zero element in the adjacency matrix. If its value is greater than or equal to the threshold, it determines that the corresponding two billing results have a high correlation degree and belong to mergeable objects. Through depth-first search (DFS), breadth-first search (BFS), or other clustering algorithms, the system can group several billing results that have a high enough correlation with each other into the same group. After all the billing results in a group are identified, the system merges the information of all the billing results in that group to form a single settlement statement.

[0046] During the generation of the settlement statement, the system also merges the relevant expense details of the billing results in the group. For example, it removes duplicates from the repeated fields, accumulates and summarizes the quantities, weights, or other accumulative fields, and registers a unified settlement time or settlement identifier in the settlement statement.

[0047] Exemplarily, assign a unique identifier to each order to be processed: read the basic information and billing results of each order, and record their origins, destinations, carriers, transportation times, and other business fields that affect merging separately; Construct an adjacency matrix: create a matrix A of size N×N for N orders in the system. If there is a mergeable condition between order i and order j, write the corresponding correlation degree (such as weighted calculation based on the continuity of transportation routes, time overlap rate, vehicle matching degree, etc.) at A[i][j], otherwise record 0; Perform clustering or graph search according to the preset correlation degree threshold: group the nodes where the elements in the matrix are greater than the correlation degree threshold, and automatically identify the interrelated orders into the same aggregation set; Generate a single settlement statement: merge the expense details of the grouped orders and record them in a single settlement statement; Provide the merged settlement statement to the subsequent bill processing module: such as bill aggregation, financial reconciliation, or statistical analysis. Provide the merged settlement statement to the subsequent bill processing module: such as bill aggregation, financial reconciliation, or statistical analysis.

[0048] This method of combining the adjacency matrix with graph search can effectively break through the limitation of solely relying on the consistency of business fields for merging, and achieve grouping processing of "partially similar" or "multi-dimensional similar" billing results, further improving the collection efficiency and accuracy of settlement statements. The single settlement statement after completion of the merging can be directly incorporated into subsequent bill generation or reconciliation processes, and has a higher level of flexibility and intelligence compared with the traditional method based on complete matching of business fields.

[0049] Through the above process, the system can quickly identify orders or waybills that are related to each other according to the pre-defined correlation model and threshold in scenarios with a large number of multi-dimensional billing results, reduce manual judgment or the generation of duplicate settlement statements, and thereby improve the reconciliation and settlement efficiency.

[0050] As an alternative implementation method, before merging the billing results based on the adjacency matrix, it further includes: Performing individual anomaly detection on each of the billing results, and if the billing result meets the anomaly determination condition, marking it as an anomaly and excluding it from the construction of the adjacency matrix; Only constructing the adjacency matrix and performing graph search on the billing results that are not marked as anomalies.

[0051] As an alternative implementation method, after using the adjacency matrix to merge multiple billing result groups and generate a single settlement statement, it further includes: Performing group anomaly detection for each of the billing result groups, and if the billing result group meets the group anomaly determination condition, marking the billing result group as an anomaly to be audited and performing splitting or isolation processing; If it is determined that there is no group anomaly, outputting the single settlement statement corresponding to the billing result group.

[0052] In specific implementation, in order to reduce the interference of significantly abnormal billing results on subsequent adjacency matrix construction and merging processes, the system first performs "individual anomaly detection" before merging the billing results based on the adjacency matrix. The main steps include: Obtaining billing results and determining anomalies: After the system completes the billing calculation of billing documents, it obtains several billing results. For each billing result, the system checks according to the pre-configured "individual anomaly determination conditions", which may include: whether the weight, volume, mileage or other numerical fields far exceed the normal business scope; whether the billing amount deviates significantly from the historical average; whether it is a risky customer or a high-risk carrier; whether the input time or date field is missing or has obvious errors. When it is determined that a certain billing result meets the above anomaly conditions, it is marked as "anomaly", recorded in the anomaly list or stored separately for subsequent review.

[0053] Exclude billing results that have been marked as abnormal: The system only retains billing results that have not been marked as abnormal to participate in the subsequent adjacency matrix construction and graph search process. For those billing results that have been marked as abnormal, a temporary settlement form can be generated separately or enter the manual review stage to avoid abnormal data and normal data mixing to cause distortion of the settlement form.

[0054] Construct an adjacency matrix and merge: After excluding individual anomalies, the remaining normal billing results will construct an adjacency matrix based on the similarity or correlation of the business fields. Subsequently, the system executes a graph search or clustering algorithm to group the billing results whose correlation meets the preset threshold into the same settlement form. For this part of the process, please refer to the description of the adjacency matrix and graph search in the previous implementation.

[0055] Through the above approach, the system can eliminate obviously abnormal orders or billing results before constructing the adjacency matrix, reduce the probability of erroneous merging, and ensure the accuracy and credibility of subsequent settlement statements.

[0056] For further information, see Figure 3 , Figure 3 A flow chart of a group anomaly detection method provided in an embodiment of the present application; in order to further solve the problem that "group anomaly" may only appear after the order / billing results are merged, the system adds a "group anomaly detection" link after merging multiple billing result groups using the adjacency matrix and generating a single settlement form, which mainly includes steps A to D, wherein: Step A: Get the merged billing result group: Based on the aforementioned adjacency matrix and graph search algorithm, the system initially merges several billing results that meet the correlation threshold into one or more billing result groups, and generates a corresponding settlement form for each group. At this point, the billing results in the group do not show abnormalities at the individual level, but from the overall dimension, there may be potential risks such as "excessive aggregation" or "too high time overlap".

[0057] Step B: Perform group anomaly determination: The system extracts statistical indicators or feature vectors for each merged billing result group, such as: total weight, total volume, total number of orders in the group; the overlap between the number of orders and the time interval; whether they are generated in a very short time; the excessive concentration of carriers or vehicle types; whether there are unreasonable continuous jumps in route distribution, etc. If it is detected that the indicator exceeds the preset threshold or matches the "group anomaly determination condition", the group will be marked as "abnormal pending" to trigger subsequent splitting or isolation operations.

[0058] Step C: Splitting or Isolating the Abnormal Group: When a billing result group is determined to be abnormally grouped, the system can provide multiple processing methods. For example: - Whole-group Isolation: Mark all settlement bills in this group as abnormal, temporarily not output to the bill summary process, and prompt for manual review or further splitting. - Partial Splitting: If further analysis reveals that only some orders within the group cause abnormalities, these orders can be removed from the group and processed separately, so that the remaining normal orders can continue to output settlement bills.

[0059] Step D: Outputting Normal Settlement Bills: For billing result groups that have not been detected as abnormally grouped, the system directly outputs the corresponding single settlement bills, which are incorporated into the subsequent bill generation or financial reconciliation process. By performing secondary anomaly detection after merging, the system can, to the greatest extent, avoid missing "abnormally grouped" situations that only become apparent at the overall level. By adding an "abnormally grouped detection" link after merging, the system can take into account the regular anomaly detection of individual orders and the overall risk identification of order groups, effectively improving the ability to identify potential anomalies after merging, and thus ensuring the reliability and accuracy of the generated settlement bills and bills.

[0060] In this way, by combining individual anomaly detection before adjacency matrix merging and group anomaly detection after merging, the system can identify potential problems in a timely manner at different granularity levels (single billing result and overall order group), reducing the risk of missed or misjudged cases. After determining an abnormally grouped situation, the system can select splitting or isolation processing methods according to business requirements, achieving flexible isolation of abnormal order groups and preventing incorrect information from spreading to subsequent bill or reconciliation processes. This multi-stage detection scheme is applicable to large-scale, multi-scenario logistics billing systems, and can improve the prevention and control level of order anomalies and financial risks while ensuring the efficiency of automated merging.

[0061] Exemplarily, as Figure 2 shown, Figure 2 is a schematic diagram of a billing system provided by an embodiment of this application. Among them, there are currently 5 billing results to be processed, numbered O1, O2, O3, O4, and O5. The system needs to collect these billing results and generate settlement bills for subsequent bill merging or reconciliation operations.

[0062] "Risky carrier Z" in O2 means that this order has a very high risk; O3, O4, and O5 seem normal when viewed separately, but if they are shipped on adjacent routes within a short period of time, it may cause "abnormally grouped" situations (such as "excessive time overlap" or "excessive concentration") after merging.

[0063] The first stage is individual anomaly detection. The enterprise has configured several "individual anomaly" judgment rules. For example, if the carrier is on the risk list, it is regarded as a high-risk anomaly; if the weight or cost is higher than a certain limit value, it is also regarded as an anomaly; if the field is significantly missing or the timestamp is unreasonable, it is also regarded as an anomaly.

[0064] After reading the data of O1, O2, O3, O4, and O5, the system judges according to the above rules: the carrier in O2 = "Risk Carrier Z", which triggers Rule 1, so O2 is marked as an "abnormal order"; the rest of O1, O3, O4, and O5 have no significant violations or extreme value exceedances at the single data level and are temporarily judged as "normal".

[0065] The system removes O2 from the subsequent automatic merging process or puts it into the "abnormal pending review" list for further manual evaluation. Only O1, O3, O4, and O5 are retained to enter the next "adjacency matrix construction" and "graph search".

[0066] The second stage is adjacency matrix merging. Taking O1, O3, O4, and O5 as nodes, the correlation degree is calculated according to fields such as "shipping address - receiving address", "shipping time period", "vehicle type", and "carrier". For example: between O1 and O3, the shipping address is both City A, the receiving address is both City B, the shipping times are close, the vehicle types are the same, and the carrier is the same, so the correlation degree is relatively high and may reach a certain set threshold.

[0067] Another example, between O4 and O5: the shipping address is the same (City B), the receiving address is the same (City D), the shipping time periods are close, and the vehicle types and carriers are also the same, so the correlation degree is relatively high.

[0068] Another example, between O1 / O3 and O4 / O5: the shipping addresses and receiving addresses are not exactly the same, and there is a slight difference in time, so the correlation degree is relatively low or zero.

[0069] According to the non-zero correlation degrees in the matrix, the system first merges O1 and O3 into a group A; then merges O4 and O5 into another group B. Each group generates a preliminary settlement form respectively: Group A: contains O1, O3; Group B: contains O4, O5; The third stage is group anomaly detection. After the preliminary merging is completed, the system further conducts a group dimension check on group A and group B: For the inspection of group A: After merging O1 + O3, the total weight = 800 + 900 = 1700 kg, the time difference is 30 minutes, and the route is from City A to City B. Comparing with historical statistics, 1700 kg is not significantly overweight in the small vehicle range; the time is highly overlapping but does not exceed the threshold (the system allows multiple orders to be sent from City A to City B within 2 hours); therefore, group A does not trigger a "group anomaly".

[0070] For the inspection of Group B: After O4 + O5 are combined, the total weight = 850 + 2000 = 2850 kg, and the shipments are all in City B and the receiving location is City D, and the time is very close (10:00 and 10:30). According to the "Group Abnormality Judgment Conditions" set by the enterprise: If a certain line exceeds 2500 kg concentrated within 1 hour, it is likely to cause overloading of transportation capacity or time limit conflict; at this time, the system detects that 2850 kg > 2500 kg threshold and determines it as "excessive aggregation". So the system marks Group B as "abnormal pending review", does not directly output the settlement statement for the time being, but triggers a notification or manual review in the system background.

[0071] In dealing with group abnormalities, the system can further split according to the strategy. For example: Check if it is possible to delay the shipping time of O5 to avoid excessive overlap; or allow manual confirmation whether this carrier can transport nearly 3 tons of goods within the same time period. If it is confirmed as abnormal, this group can be split into separate order settlement statements or delayed processing; if the business personnel confirm that the transportation capacity is sufficient, then restart the merger and output a normal settlement statement.

[0072] Group A (O1 + O3) is not detected with group abnormalities, and the system officially generates settlement statement A, accumulates the expense details (500 + 550 = 1050 yuan, etc.), and records the merger time, total quantity, etc. in the settlement statement.

[0073] Group B (O4 + O5) is marked as a group abnormality due to excessive aggregation. According to the enterprise settings, the "manual review" or "split and merge again" process can be started. Do not output the formal settlement statement B for the time being, or output a temporary settlement statement with the label of "abnormal pending review" to prevent subsequent bill data from being incorrect.

[0074] Since the carrier of O2 is on the risk list, it has already been excluded by individual abnormality detection. The system can generate an abnormal settlement statement E2 separately and wait for senior management or manual review and disposal.

[0075] In this example, through the multi-stage process of "individual abnormality first and then group abnormality": the obvious risk of O2 is identified and excluded in a timely manner; the "excessive aggregation" group risk of O4 + O5 only emerges after the preliminary merger, and the system can timely prevent the wrong merger from entering the subsequent bill process; O1 + O3 is successfully merged and a normal settlement statement is output to ensure that normal orders are not interfered with.

[0076] As an optional implementation method, in order to effectively utilize the adjacency matrix in the scenario of ultra-large-scale orders or cross-organizational multi-business, the system combines the generation and maintenance process of the adjacency matrix with the data structure of the knowledge graph, and decomposes and stores the adjacency matrix in the graph.

[0077] Specifically, for each order or billing result, corresponding nodes are created in the knowledge graph and initially partitioned into different graph partitions or subgraphs based on fields such as the shipping location, delivery location, carrier, and business scenario.

[0078] For example, orders within different legal entities, different organizational dimensions, or different billing periods can be respectively assigned to corresponding subgraphs or partitions for storage. In this way, the system does not need to include the pairwise association relationships of all orders in a single graph or a single adjacency matrix, thus greatly reducing the memory and computational burden.

[0079] Within each graph partition, the system refers to the similarity or correlation calculation methods described previously to generate a local adjacency matrix for the orders within this partition and records the corresponding edge relationships and attributes in the graph. If two orders meet the similarity conditions or have potential merger value in several business fields, a similarity edge is added for these two order nodes in the knowledge graph, or the correlation attribute of the existing edge is updated. After the construction of the local adjacency matrix is completed within the partition, the system can complete the regular merger or bill aggregation operations locally. As long as the business entities and financial rules to which the orders belong are the same, they can be directly merged to generate a single bill. For orders that still need to be settled and merged across partitions or legal entities, the system can perform a federated query or cross-subgraph retrieval at the knowledge graph level to dynamically assemble or connect the local adjacency matrix information of multiple partitions. If it is found during the inspection that the orders in multiple partitions meet the merger conditions and the deeper relationships such as the corresponding customer credit, tax system, or cooperation agreement also meet the requirements, the system will create a corresponding merged bill node in the global knowledge graph, associate the order nodes or settlement note nodes in each partition with this bill node, and mark the reasons, time, and audit information for this cross-partition merger in the graph.

[0080] In actual implementation, the system can use a hierarchical or supernode approach to reduce the overly detailed storage caused by a large number of orders. If a large number of orders within certain subgraphs are almost the same in fields such as the shipping location, vehicle type, and time window, they can be first aggregated into a supernode to represent the similarity at the top level of such orders. When more refined per-order merger or anomaly determination is required, the system then drills down to the specific order level included in the supernode to retrieve the corresponding local adjacency information or partition content. Through this combined strategy of partitioning and layering, the system can effectively manage, retrieve, and infer the correlation of millions or even hundreds of millions of orders in the knowledge graph, and can also incrementally maintain the similarity edges of relevant subgraphs or supernodes when updating order data, thus taking into account the high concurrency and real-time requirements.

[0081] After completing the maintenance of the partitioned or hierarchical adjacency matrix, when the system aggregates or processes the bills, it will further perform cross-entity reasoning and query based on the multi-entity relationships in the knowledge graph. When merging bills, in addition to referring to the similarity information of orders within the same region or the same legal entity, it will also check the contracts to which the orders belong, the customer credit scores, the historical dispute records, and whether there is a financial sharing agreement between legal entities, etc. If all the above dimensions meet the merging strategy, multiple settlement note nodes or order nodes can be merged into the same bill node across partitions and subgraphs; if the carrier risk corresponding to a certain region or legal entity is relatively high, or the customer is on the abnormal list, this part of the settlement notes can be split or isolated according to the pre-set rules to avoid incorrect merging or the spread of financial risks. In this way, the system forms a comprehensive data network covering the adjacency matrix correlation degree and semantic information such as contracts, credit, and organization within the knowledge graph, and can execute more flexible decision-making logic during the bill aggregation stage.

[0082] In the above process, the system can combine the existing graph database and big data framework, deploy the calculation and partition storage of the local adjacency matrix as distributed tasks, and use multiple nodes to calculate the order similarity in parallel or perform large-scale graph traversal. For federated queries or cross-partition reasoning, the multi-graph retrieval or joint index of the graph database can be used to obtain order, settlement note, and contract information across legal entities, accounting periods, or geographical regions in a timely manner.

[0083] In this way, while maintaining the fast response of each partition to local orders, it can also achieve global-scale merging decisions and audit tracking when unified reconciliation or financial analysis is required. By decomposing the adjacency matrix and embedding it into the knowledge graph, the system realizes data scale expansion and real-time high-concurrency access in multi-business scenarios, and can use graph reasoning to judge deeper business rules and abnormal situations, thus providing strong scalability and accuracy in the face of large-scale logistics billing and multi-dimensional financial accounting.

[0084] Exemplarily, first, a large amount of data files containing order information are received and parsed in the background. Each order stores the values of its key fields in vector form, including the shipping location, receiving location, vehicle type, carrier, billing amount, etc. The system calculates the similarity between orders from these vectors, for example, by comparing the matching degree of the same fields or the vector distance, and stores the similarity results in the distributed file system to form a block-based adjacency matrix representation. Each block may correspond to the pairing information between tens of thousands of orders, recording the identifiers of the two orders, the similarity vector, and its characteristic scores, etc.

[0085] At the knowledge graph level, a globally unique ID is assigned to each order node, and the order pairing information in the similarity block is mapped into edges in the graph. When the system imports these edges, according to the business logic partitioning rules, the order nodes belonging to the same legal entity or grouped by similar fields are stored on the same database shard. The import process traverses the block file, reads each line (Order A, Order B, similarity value) and creates or updates an edge entity, setting its attributes such as similarity = a certain value or time_overlap = a certain time difference. To avoid overloading a single shard, the system disperses the order nodes according to the pre-configured sharding strategy by organization, geographical region, or billing period range, and marks the partition information to which the nodes and edges belong in the metadata of the graph.

[0086] Exemplarily, when importing order nodes and their matching relationships into the knowledge graph, in addition to recording the identifiers of Order A and Order B for each edge entity, two key attributes are also set: similarity and time_overlap. The similarity represents the cosine similarity between the feature vectors V_A and V_B corresponding to Order A and Order B. The value range of similarity is from 0 to 1, and the larger the value, the higher the matching degree of the two orders in key fields such as the shipping location, receiving location, vehicle type, carrier, and billing amount.

[0087] The time_overlap represents the degree of proximity of the two orders in the time dimension, obtained by calculating the difference in their timestamps (which can be in Unix timestamp, minutes, or hours). The smaller the value of time_overlap, the closer the two orders are in time.

[0088] In subsequent sharding strategies and replenishment task generation, the system can set thresholds based on the above attribute values to batch merge or prioritize the processing of orders that are highly similar and close in time, so as to avoid overloading a single shard and improve scheduling efficiency.

[0089] At runtime, if the system detects that a certain shard contains a large number of orders with highly similar and almost identical fields, a "supernode" will be established within the shard to store the common attributes of these orders in vector form, and the remaining personalized fields are regarded as a list of subvectors for subsequent retrieval when performing more refined merging or splitting of some orders. This can reduce the number of nodes that actually need to be maintained within the shard and also reduce the traversal scale during graph retrieval or update. The supernode still appears as an ordinary node at the graph database level, but it will have a structured field that references the list of sub-orders internally and is incrementally updated according to changes in similarity.

[0090] In the operation of bill aggregation, if it is necessary to merge orders across multiple partitions or shards, the system will first retrieve the cross-shard locations of these orders in the central scheduling module, and then initiate a query to the corresponding graph database instance to obtain similarity edges and other business information of the orders. The engine reads the order vector data and similarity fields from different shards, and merges or calculates them again to confirm whether they can belong to the same bill node. If the order nodes involved all have contracts with similar or the same business entity, and additional conditions such as credit rating and tax rules match the merger criteria in the knowledge graph, the system will generate or update a bill node, establish an association relationship with the relevant order nodes, and mark the new aggregation status at the "super node" layer or vector block layer. If the data returned from any shard is abnormal or it is found that the legal person to which the order belongs is incompatible with other orders, the system will perform splitting or isolation according to the exception handling strategy, and will not perform cross-shard bill merging.

[0091] After the order or similarity data is updated, the system can trigger an incremental calculation to correct the attributes of the block adjacency matrix and the knowledge graph edges. For example, when the carrier field of a certain order is changed, or when the similarity between a new order and an existing order exceeds the threshold, the corresponding entries will be added to the original adjacency matrix block, and an edge will be added or updated between the order nodes in the corresponding shard of the graph database, and fields such as similarity or time overlap will be synchronously rewritten to ensure that the knowledge graph is consistent with the underlying adjacency blocks. Finally, this method of decomposing and managing the adjacency matrix in the graph enables the system to maintain good computational efficiency and storage scalability even under a large amount of order data, and by associating similarity vectors with business fields in the same graph, it provides a unified data basis and a dynamically scalable processing mode for subsequent multi-dimensional bill merging, anomaly detection, or reconciliation.

[0092] Based on the same inventive concept, an embodiment of the present application also provides a logistics billing engine system corresponding to the logistics billing engine method. Since the principle of the system in the embodiment of the present application for solving problems is similar to the above-mentioned logistics billing engine method 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 described again.

[0093] Refer to Figure 4 As shown in The acquisition module 10 obtains billing documents and extracts business fields and measurement fields from the billing documents; The first calculation module 20 matches the pre-configured billing rules according to the business fields and measurement fields, and generates a corresponding cost calculation plan; The second calculation module 30 performs operations on the measurement fields based on the cost calculation plan to obtain a billing result; The settlement module 40 collects the billing results and related document information, constructs multiple billing result groups based on the association of business fields, and generates corresponding settlement statements according to each billing result group; The generation module 50 aggregates multiple settlement statements and forms a bill according to the preset merging rules.

[0094] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this application can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

Claims

1. Logistics billing engine method, characterized in that: include: Obtaining a billing document, and extracting a business field and a metering field from the billing document; According to the service field and the metering field, a pre-configured charging rule is matched to generate a corresponding fee calculation plan; Based on the fee calculation scheme, the metering field is operated to obtain a billing result; The billing results and related document information are collected, multiple billing result groups are constructed based on the association of business fields, and corresponding settlement documents are generated according to each billing result group; Aggregate multiple settlement documents and form an invoice according to pre-set consolidation rules; The forming of the settlement form further includes: assigning a unique identifier to each billing result, and constructing an adjacency matrix based on the matching of the billing results in the business field; performing a graph search on the non-zero association degree in the adjacency matrix, and merging multiple billing results whose association degrees meet a preset threshold to generate a single settlement form; Before the merging to generate a single settlement statement, it also includes: performing individual anomaly detection on each of the billing results, and in response to the billing result satisfying the anomaly judgment condition, marking it as an anomaly and excluding it from the construction of the adjacency matrix; only constructing the adjacency matrix and performing graph search for the billing results that are not marked as abnormal.

2. The logistics billing engine method according to claim 1, characterized in that: The matching of pre-configured charging rules includes: Performing conditional judgment on the service field to determine a rate field interval corresponding to the service field; According to the rate field interval, the meter field is segmented and segmented rates are obtained; Based on the segmented rates, the fee calculation scheme is generated.

3. The logistics billing engine method according to claim 1, characterized in that: When generating the fee calculation scheme, it also includes: Set a minimum billing amount and a maximum billing amount. If the calculated billing result is less than the minimum billing amount, the minimum billing amount is used; if the calculated billing result is greater than the maximum billing amount, the maximum billing amount is used; Set the minimum billing quantity and the maximum billing quantity. When the calculated quantity is less than the minimum billing quantity, the minimum billing quantity is taken; when the calculated quantity is greater than the maximum billing quantity, the maximum billing quantity is taken.

4. The logistics billing engine method according to claim 1, characterized in that: The step of aggregating the billing results and related document information, constructing a plurality of billing result groups based on the association of business fields, and generating a corresponding settlement form according to each billing result group includes: Filtering the billing results according to a pre-set filtering condition, wherein the filtering condition includes at least one of a carrier, a shipper, and a transportation type; In response to the same order date, transportation route, consignee and destination information, multiple billing results that meet the filtering conditions are merged to generate a single settlement statement.

5. The logistics billing engine method according to claim 4, characterized in that: The step of aggregating multiple settlement documents and forming a bill according to a preset merging rule includes: Filtering the settlement form according to a preset bill generation filtering condition, wherein the bill generation filtering condition includes at least one of a customer identifier, a bill cycle, or an organization dimension; In response to satisfying the bill generation filtering condition, aggregating and merging a plurality of the single settlement bills; Combine consolidated statement information into a single bill.

6. The logistics billing engine method according to claim 5, characterized in that: After the adjacency matrix is ​​used to merge multiple billing result groups and generate a single settlement form, the method further includes: Performing group anomaly detection on each of the billing result groups, and in response to the billing result group meeting the group anomaly determination condition, marking the billing result group as abnormal to be reviewed and performing splitting or isolation processing; In response to determining that there is no group abnormality, a single settlement statement corresponding to the billing result group is output.

7. The logistics billing engine method according to claim 6, characterized in that: The step of aggregating multiple settlement documents and forming a bill according to a pre-set merging rule further includes: Create graph nodes in the knowledge graph database to represent business entities such as settlement orders, orders, carriers, transportation routes, and billing cycles, as well as relationship edges to represent dependencies or associations between business entities; Writing the key field information of the settlement form into the knowledge graph database to form a graph data structure for bill merging; Performing reasoning operations on the settlement order nodes and their associations in the knowledge graph database according to pre-configured business rules or an inference engine to automatically identify a set of settlement order nodes that meet bill consolidation conditions; The set of settlement order nodes identified by the reasoning operation is linked with the adjacency matrix or the anomaly detection module for processing. When it is determined that there is no anomaly, the merged bill is output. If it is determined that there is an anomaly, the relevant settlement orders are split or isolated to dynamically aggregate the bills.

8. The logistics billing engine method according to claim 7, characterized in that: The step of aggregating multiple settlement documents and forming a bill according to a pre-set merging rule further includes: Reading the vectorized field information generated for each order from the storage medium, and performing batch similarity calculation on the vectorized field information to form an adjacency matrix of the partial blocks, wherein the adjacency matrix records the non-zero similarity between the order pairs; When importing the adjacency matrix into the knowledge graph database, a corresponding graph node is created or updated for each order, and a relationship edge is established or updated between the graph nodes according to the similarity result in the adjacency matrix, and the relationship edge carries a similarity vector or a correlation attribute; Generate a supernode for an order set whose similarity is greater than a preset similarity threshold and whose field values ​​are the same, regard the supernode as a single node object in the knowledge graph database, and attach the differentiated fields of each order in the order set in the form of an additional vector; When performing bill aggregation, it is determined whether each order meets the merging condition based on the super node and its additional vector, and reasoning is performed in combination with cross-entity information. In response to meeting the bill merging condition, a corresponding bill node is created in the knowledge graph database and associated with the relevant order node.

9. A logistics billing engine system, used to implement the logistics billing engine method according to any one of claims 1 to 8, characterized in that: include: The acquisition module obtains the billing document and extracts the business field and the metering field from the billing document; A first calculation module, matching a pre-configured charging rule according to the service field and the metering field, and generating a corresponding fee calculation scheme; A second calculation module, based on the fee calculation scheme, performs calculations on the metering field to obtain a billing result; The settlement module collects the billing results and related document information, constructs multiple billing result groups based on the association of business fields, and generates a corresponding settlement document according to each billing result group; The generation module aggregates multiple settlement documents and forms an invoice according to pre-set merging rules.

Images