Data matching processing method based on production and sales cross-domain

Abstract

This invention relates to the field of computer data processing and time series analysis technology, and provides a data matching processing method based on cross-domain production and sales. To address the problem that the establishment of automatic cross-domain data matching relationships in traditional technologies heavily relies on predefined association rules, the method collects business operation logs from a first business system and a second business system, and splits them according to the source domain identifier. The split event streams are then constructed into event trajectories, which are then mapped to a multi-dimensional shared constraint space to generate constraint projection trajectories. Based on a dynamic time warp algorithm that satisfies constraints, the resonance intensity of the two constraint projection trajectories is calculated. The cross-domain data matching relationship between the corresponding terminal production and sales entities and bulk trade entities is determined based on the resonance intensity. This achieves automatic determination of cross-domain data matching relationships without relying on predefined cross-domain business association rules, significantly improving the coverage and accuracy of cross-domain data matching processing.

Description

Technical Field

[0001] This invention relates to the field of computer data processing and time series analysis technology, and particularly to the processing and matching verification technology of multi-source heterogeneous event streams, specifically to a data matching processing method based on cross-domain production and sales. Background Technology

[0002] Data matching processing across production and sales domains refers to the technical correlation and verification process conducted within an enterprise information system environment involving multiple business lines. This involves data flows belonging to different business areas, following different data logics, and serving different transaction purposes. With the increasing prevalence of diversified business models, it has become common for a single business entity to simultaneously engage in physical commodity supply chain operations targeting end-consumer markets and agricultural product trading operations targeting bulk trade. For example, a company might be engaged in both pet breeding and the R&D, production, and sales of pet supplies (end-consumer production and sales domain), while also engaging in large-scale procurement and distribution of agricultural products such as corn and soybeans (bulk trade domain). There is a supply-demand relationship at the business level between the raw material demand in the end-consumer production and sales domain and the agricultural product supply in the bulk trade domain. In this type of business model, business data in the end-consumer production and sales domain (such as pet supply orders and breeding batch progress) and business data in the bulk trade domain (such as raw material procurement contracts and warehousing settlement statements) are generated and managed by their respective independent business systems, resulting in a natural cross-domain data fragmentation between different businesses. However, from the perspective of data verification and risk control auditing, it is necessary to confirm whether there is logical consistency between the actual business activities in the terminal production and sales domain (such as pet food production consumption) and the corresponding transaction activities in the bulk commodity trading domain (such as soybean procurement and warehousing), in order to verify the business relevance, authenticity, and compliance. How to effectively match and cross-verify such heterogeneous, dissimilar, and heterogeneous data has become a data processing problem that urgently needs to be solved in scenarios such as enterprise data platforms, risk control auditing, and supply chain collaboration.

[0003] In traditional technologies, the matching and processing of the aforementioned cross-domain data requirements typically employs the following methods: First, using ETL (Extract, Transform, Load) tools to extract data from different business systems into a unified data warehouse on a regular or near-real-time basis. Dimensional modeling is then performed based on predefined data models, and cross-topic data correlation analysis and reporting are conducted using OLAP (Online Analytical Processing) tools or BI (Business Intelligence) platforms. Second, based on event-based association paths using rule engines, key business operations from different business domains are abstracted into events. Cross-domain association rules are pre-configured in the rule engine (e.g., "When pet food sales increase by more than a threshold and soybean inventory is below a safe level, trigger a procurement alert"). Rule matching drives cross-business domain process collaboration and data association. Third, based on knowledge graph-based relationship mining paths, entities from different business domains (such as products, raw materials, orders, contracts, and suppliers) are constructed into a knowledge graph. Graph traversal and graph algorithms are used to discover potential relationships between different entities, assisting manual cross-domain data verification and validation.

[0004] However, all the aforementioned traditional technologies share a common technical flaw: the establishment of cross-domain data matching relationships heavily relies on predefined association rules or data models. For emerging indirect associations that are not predefined, they cannot be independently established and verified at the technical level, resulting in the coverage and accuracy of matching results being limited by the completeness of the predefined rule base. The root cause of this flaw lies in the fact that traditional technical architectures are all built upon the fundamental technology that "the association logic between cross-domain data must be predefined or explicitly encoded externally (such as by domain experts or business knowledge bases)." Whether it's dimensional modeling in a data warehouse, association rules in a rule engine, or relationship definition in a knowledge graph, the core is to transform business-level association knowledge into predefined logic that the system can execute. Therefore, the system's ability to process cross-domain data matching is rigidly constrained by the factor of "the completeness of the predefined association logic," forming a technical bottleneck of "matching is possible if predefined, but not possible if not predefined."

[0005] Therefore, how to achieve automatic matching and verification of event streams belonging to different business domains without relying on predefined cross-domain business association rules has become a pressing technical problem in the field of cross-domain data matching and processing based on production and sales. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a data matching processing method based on cross-domain production and sales. By constructing event streams belonging to different business domains into independent event trajectories and mapping them to a shared constraint space decoupled from business logic, the method calculates the resonance intensity between trajectories based on a dynamic time warp algorithm that satisfies constraints to determine cross-domain data matching relationships. Unlike the static matching mode in traditional technologies that rely on predefined association rules or data models, this method can achieve automated matching and verification of cross-domain data matching relationships without relying on any preset cross-domain business association rules, significantly improving the coverage and accuracy of cross-domain data matching processing.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a data matching and processing method based on cross-domain production and sales, applied to a server, comprising: collecting business operation logs from a first business system and a second business system; encapsulating the collected business operation logs into standard events respectively; and splitting them into a first event stream and a second event stream based on the source domain identifier carried by each standard event, wherein the standard event carries a source domain identifier, an operation timestamp, and a status snapshot; aggregating the first event stream and the second event stream according to business entities and arranging them in chronological order to construct a first event trajectory and a second event trajectory; and connecting the first event trajectory and the second event trajectory... The traces are mapped to a predefined multidimensional shared constraint space to generate a first constraint projection trajectory and a second constraint projection trajectory. The dimensions of the multidimensional shared constraint space are constructed based on a general physical or economic constraint function decoupled from business logic. Based on a dynamic time warp algorithm for constraint satisfaction, the resonance intensity of the first constraint projection trajectory and the second constraint projection trajectory is calculated. The resonance intensity characterizes the degree of logical self-consistency between the two trajectories within the multidimensional shared constraint space. When the resonance intensity exceeds a preset threshold, it is determined that there is a cross-domain data matching relationship between the terminal production and sales entity corresponding to the first event trajectory and the bulk trade entity corresponding to the second event trajectory.

[0008] As a preferred embodiment of the cross-domain data matching processing method for production and sales described in this invention, the resonance intensity of the first constraint projection trajectory and the second constraint projection trajectory is calculated based on the dynamic time warp algorithm for constraint satisfaction. This includes: constructing a cumulative cost matrix with the length of the first constraint projection trajectory as the number of rows and the length of the second constraint projection trajectory as the number of columns; defining a local distance function, which is used to calculate the composite constraint violation cost between the i-th projection point in the first constraint projection trajectory and the j-th projection point in the second constraint projection trajectory across all constraint dimensions; filling the cumulative cost matrix based on the local distance function and the dynamic programming recursive formula to obtain the minimum cumulative cost path; and outputting the cumulative cost value at the endpoint of the minimum cumulative cost path as the resonance intensity after normalization transformation.

[0009] Beneficial Effects: The solution implemented in this invention, by collecting the business operation logs of the first and second business systems and encapsulating them into standard events, and then splitting them based on the source domain identifier, firstly, it achieves the unified abstraction of operation logs belonging to different business domains into standard event streams carrying source domain identifiers, operation timestamps, and status snapshots, eliminating data format differences caused by heterogeneous business systems; based on this, by aggregating the first and second event streams according to business entities and arranging them in chronological order to construct the first and second event trajectories, it further achieves the aggregation of discrete events into event trajectories with complete temporal semantics according to business entities, providing a traceable independent evolutionary history for cross-domain data comparison; on this basis, by mapping the first and second event trajectories to systems decoupled from business logic, it achieves the following: A multidimensional shared constraint space is constructed using a general physical or economic constraint function, generating a first constraint projection trajectory and a second constraint projection trajectory. This enables the projection of heterogeneous event trajectories belonging to different business domains onto a unified objective constraint benchmark space that is independent of business rules. This transforms the comparison of cross-domain data from relying on preset business rules to logical self-consistency verification based on objective constraints. Furthermore, a dynamic time warp algorithm based on constraint satisfaction is used to calculate the resonance intensity of the first constraint projection trajectory and the second constraint projection trajectory. When the resonance intensity exceeds a preset threshold, it is determined that there is a cross-domain data matching relationship between the terminal production and sales entity corresponding to the first event trajectory and the bulk trade entity corresponding to the second event trajectory. This achieves automated determination of cross-domain data matching relationships without relying on any predefined cross-domain business association rules.

[0010] By combining the above interconnected effects, an endogenous mutual verification and automated matching verification mechanism was constructed, consisting of "standardized event collection and distribution, independent event trajectory construction, constraint space projection decoupled from business logic, trajectory resonance intensity calculation, and threshold matching judgment".

[0011] Therefore, unlike the static matching mode in traditional technologies that rely on predefined association rules or data models and whose matching ability is limited by the completeness of preset rules, this invention projects cross-domain event trajectories onto a constraint space decoupled from business logic and calculates the trajectory resonance intensity based on a dynamic time warp algorithm that satisfies constraints. This transforms the traditional "rule matching" mode, which relies on external preset rules, into a "constraint resonance verification" mode based on internal logical self-consistency. Ultimately, it achieves automated determination of cross-domain data matching relationships without relying on predefined cross-domain business association rules, solving the technical problem in the background technology that "the establishment of cross-domain data matching relationships in traditional technologies is highly dependent on predefined association rules." Furthermore, it can autonomously establish and verify indirect association relationships that are not preset in traditional technologies, significantly improving the coverage and accuracy of cross-domain data matching processing. Attached Figure Description

[0012] Figure 1 A flowchart illustrating the data matching and processing method based on cross-regional production and sales provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the first sub-process of the data matching and processing method based on cross-regional production and sales provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the second sub-process of the data matching and processing method based on cross-regional production and sales provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0013] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to specific examples. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] This invention provides a data matching and processing method based on cross-domain production and sales. This method can be a data processing engine hosted on a server or cloud platform, capable of driving data application scenarios including but not limited to the following multi-dimensional scenarios: First, in an enterprise data platform system, the inherent mutual verification relationship between terminal production and sales business activities and bulk trade transactions is automatically determined through cross-domain data matching relationships, providing automated technical means for business data consistency verification. Second, in a supply chain risk control and audit system, the logical self-consistency between cross-domain data is quantified through resonance intensity, providing quantifiable reference for identifying business data anomalies and verifying the authenticity of transaction backgrounds. Third, in an integrated business and finance management system, by indexing the matching determination results with associated event trajectory data, data association support is provided for the traceability and verification of financial flows and business substance. This invention solves the problem of automated matching and verification technology for cross-domain data without relying on predefined business association rules, providing reusable core data processing capabilities for data governance, risk control compliance, and supply chain collaboration for enterprises operating across multiple business lines.

[0015] The following detailed description of some embodiments of the present invention is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0016] In the following embodiments, the technical solution of the present invention is described in detail using the application scenario of an enterprise that simultaneously operates pet breeding and pet product R&D, production and sales (terminal production and sales domain) and large-scale procurement and distribution of agricultural products such as corn and soybeans (bulk trading domain). It should be understood that the above specific business scenario is only an exemplary description for ease of explanation. The technical solution provided by the present invention can be applied to any information system environment with multiple related heterogeneous business lines, and where cross-domain data matching and verification processing is required between the business lines. For example, manufacturing enterprises that simultaneously operate terminal retail and upstream raw material procurement, and supply chain platforms that take into account both self-operated sales and bulk trading, etc., and its application scope is not limited thereto.

[0017] Example 1: Data matching and processing method based on cross-regional production and sales.

[0018] In this embodiment, please refer to Figure 1 , Figure 1 This is a flowchart illustrating the data matching and processing method based on cross-domain production and sales provided in an embodiment of the present invention. Figure 1 As shown, in this embodiment, applied to a server, the steps include S11-S15: S11: Collect business operation logs from the first business system and the second business system, encapsulate the collected business operation logs into standard events, and split them into a first event stream and a second event stream based on the source domain identifier carried by each standard event. The standard event carries a source domain identifier, an operation timestamp, and a status snapshot.

[0019] Business operation logs refer to the records generated by the first and second business systems during operation, documenting the occurrence of various business operations. Business operation logs include, but are not limited to: operation type (such as "order creation," "contract signing," "warehousing confirmation," etc.), timestamp of the operation, identifier of the entity performing the operation, identifier of the business entity being operated on, and information on the status changes of that business entity before and after the operation.

[0020] Standard events refer to standardized event data structures formed by encapsulating business operation logs from different business systems with different original formats according to a unified data structure. Standard events include, but are not limited to: 1) a source domain identifier, used to distinguish whether the event originates from the first or second business system; 2) an operation timestamp, used to record the actual time when the corresponding business operation occurred; and 3) a state snapshot, used to record the changes in the business entity's state caused by the operation in key-value pairs. By uniformly encapsulating heterogeneous business operation logs into standard events, the problem of inconsistent data formats caused by differences in business systems is eliminated.

[0021] The specific implementation of this step is as follows: First, the data acquisition module deployed on the server side collects business operation logs in real time or near real time from the first business system (such as the ERP or e-commerce middleware system in the terminal production and sales domain) and the second business system (such as the transaction or warehousing management system in the bulk commodity trading domain) through a pre-configured API interface or message queue listening mechanism. The collection method can adopt a pull mode, in which the server initiates requests to the data interfaces of each business system according to a preset period and obtains incremental logs; or it can adopt a push mode, in which each business system actively pushes the log data to the message receiving endpoint of the server after generating business operation logs.

[0022] Secondly, the event standardization processor on the server side performs encapsulation operations on each collected business operation log. The specific steps of the encapsulation operation will be detailed in the subsequent embodiment 2. Its core idea is to extract key fields from the business operation log, generate globally unique digital event identifiers, and combine the source domain identifier, operation timestamp, operation type, and post-operation status information into a standard event data structure.

[0023] Third, the server-side event routing module reads the source domain identifier field carried in each standard event and distributes the standard events to different message channels or event stream topics according to the value of the source domain identifier: events whose source domain identifier indicates the first business system are routed to the first event stream, and events whose source domain identifier indicates the second business system are routed to the second event stream. The routing operation can be implemented through the partitioned routing mechanism of the message queue. The first event stream and the second event stream are physically isolated from each other, laying the data foundation for each to independently construct its own event trajectory.

[0024] It should be noted that the data collection methods described above are not limited to the API retrieval or message push modes exemplified. In one example, a database log synchronization tool can be used to monitor and capture change logs in the business system database in real time; in another example, a file transfer protocol can be used to periodically batch synchronize business operation log files. Any technical means capable of obtaining business operation logs from the business system and converting them into a standard event stream falls within the scope of protection of this invention.

[0025] For example, based on the above exemplary application scenario, suppose a data platform server of an enterprise collects a business operation log from a pet supplies e-commerce system. The log contains: order number ORD001, operation type "order creation", operation time 09:00:01, and post-operation status "pending payment". The server encapsulates this log into a standard event, generates a globally unique event identifier EVT-001, sets the source domain identifier to "RETAIL", records the operation timestamp as 09:00:01, and encapsulates the status snapshot as a key-value pair {"status": "pending payment"}. Simultaneously, another log is collected from the bulk commodity trading system: contract number CT001, operation type "contract signing", operation time 08:45:22, and post-operation status "in execution". After encapsulation, the source domain identifier is "COMMODITY", and the log is routed to the second event stream.

[0026] In step S11, by collecting the business operation logs of the first and second business systems and encapsulating them into standard events, and then splitting them based on the source domain identifier, the operation logs belonging to different business domains are uniformly abstracted into a standard event stream carrying the source domain identifier, operation timestamp, and status snapshot. This eliminates the data format differences caused by the heterogeneity of business systems, provides standardized data input for subsequent steps to process events independently by business domain, solves the technical problem of the difficulty in uniformly processing multi-source heterogeneous data in traditional technologies, and achieves the technical effect of cross-domain event stream standardization and physical isolation.

[0027] S12: Aggregate the first event stream and the second event stream by business entity and arrange them in chronological order to construct the first event trajectory and the second event trajectory.

[0028] Event trajectories refer to a sequence of events with complete temporal semantics, formed by arranging all standard events belonging to the same business entity within the same event stream according to their operation timestamps. An event trajectory depicts the state transition history of a business entity throughout its entire lifecycle, from creation to demise. The first event trajectory corresponds to a business entity in the end-user production and sales domain (e.g., the complete process of a pet food order from creation to completion), while the second event trajectory corresponds to a business entity in the bulk commodity trading domain (e.g., the complete process of a soybean purchase contract from signing to settlement). Event trajectories provide a traceable evolutionary history for subsequent cross-domain data comparisons.

[0029] The specific implementation of this step is as follows: First, the server-side event sourcing engine subscribes to the first event stream and the second event stream respectively. For each event stream, the event sourcing engine reads the standard events one by one and extracts the business entity identifier field carried in each standard event. The business entity identifier is a field in the business operation log used to uniquely identify the operated object, such as the order number in the first event stream and the contract number in the second event stream.

[0030] Secondly, the event sourcing engine groups standard events with the same business entity identifier into the same event group based on the extracted business entity identifier field. For example, all standard events carrying order number ORD001 are grouped into the same event group. Each event group corresponds to an independent business entity.

[0031] Third, within each event group, the event tracing engine arranges the events in ascending order according to the chronological order of the operation timestamps carried by each standard event, forming a time sequence from first to last. The arranged event group is the event trajectory corresponding to that business entity.

[0032] Fourth, the event tracing engine stores all event trajectories as a first event trajectory set and a second event trajectory set, respectively, for use in subsequent steps.

[0033] It should be noted that the specific implementation of the above event trajectory construction is not limited to the example of aggregating and sorting by event groups. In one example, the event time window mechanism of a streaming processing framework can be used to update the trajectory status of the corresponding entity in real time when the event arrives; in another example, a complex event processing engine can be used to dynamically construct the trajectory based on event pattern matching. Any technical means that can aggregate event streams by business entities and arrange them in chronological order to construct event trajectories falls within the protection scope of this invention.

[0034] For example, continuing the previous example, the first event stream includes multiple standard events for order ORD001: 09:00:01 Order creation, 09:05:22 Order payment, 10:30:45 Order shipment, and 15:00:12 Order completion. The server aggregates these events by business entity identifier ORD001 and arranges them in ascending order of operation timestamps, constructing the first event trajectory: Creation → Payment → Shipment → Completion. Simultaneously, the events for contract CT001 in the second event stream: 08:45:22 Contract signing and 11:20:33 Payment, construct the second event trajectory: Signing → Payment.

[0035] In step S12, by aggregating the first event stream and the second event stream according to business entities and arranging them in chronological order to construct the first event trajectory and the second event trajectory, discrete events are aggregated into event trajectories with complete temporal semantics according to business entities. This provides a traceable independent evolutionary history for cross-domain data comparison, solves the technical problem that scattered events in traditional technologies cannot form a complete business view, and obtains a structured representation capability for the state changes of the entire life cycle of business entities.

[0036] S13: Map the first event trajectory and the second event trajectory to a predefined multidimensional shared constraint space to generate a first constraint projection trajectory and a second constraint projection trajectory, wherein the dimensions of the multidimensional shared constraint space are constructed based on a general physical or economic constraint function decoupled from business logic.

[0037] Multidimensional shared constraint space: This refers to a mathematical space composed of multiple independent constraint dimensions, used to provide a unified comparison benchmark for event trajectories belonging to different business domains, independent of specific business rules. Each dimension in the multidimensional shared constraint space corresponds to a class of general, objective constraints, defined by a corresponding general physical constraint function or economic constraint function. The physical constraint function is constructed based on fundamental laws of physics (such as time irreversibility, spatial transfer continuity, and the law of conservation of matter); the economic constraint function is constructed based on basic economic principles (such as the positive correlation between transaction costs and geographical distance, and no-arbitrage pricing constraints). The most significant characteristic of the multidimensional shared constraint space is its "decoupling from business logic," meaning that its dimension definitions do not depend on any specific business terms or rules, but are based on objective physical or economic laws, thus enabling comparisons of event trajectories from different business domains on a unified, objective, and neutral scale.

[0038] Constrained projection trajectory: This refers to the sequence of projection points formed by mapping each event in an event trajectory to a multi-dimensional shared constraint space according to its performance in each constraint dimension. The constraint projection trajectory is the "footprint" of the event trajectory in the shared constraint space; each projection point records the constraint imprint value of the event in each constraint dimension. The first constraint projection trajectory corresponds to the first event trajectory, and the second constraint projection trajectory corresponds to the second event trajectory. By projecting heterogeneous event trajectories to a unified constraint space, two trajectories that were originally not directly comparable can now be quantitatively compared in the same coordinate system.

[0039] The specific implementation of this step is as follows: First, the server-side constraint projection engine loads the predefined multi-dimensional shared constraint space configuration. The dimensional composition of the shared constraint space will be detailed in the subsequent embodiment 4, and may include, but is not limited to, time causality constraint dimension, quantity conservation constraint dimension, and spatial economic constraint dimension. Each dimension is defined by a corresponding constraint function. The input of the constraint function is the attribute of the event in the event trajectory (such as event type, operation timestamp, quantity or location information in the state snapshot), and the output is the normalized constraint imprint value of the event on that dimension. The value of the constraint imprint value can be a normalized value between 0 and 1, where 0 indicates that the constraint is fully satisfied and 1 indicates that the constraint is seriously violated.

[0040] Secondly, the constraint projection engine performs mapping operations on the first and second event trajectories to be mapped, respectively. For each standard event in each event trajectory, relevant information such as its event type, operation timestamp, and state snapshot is extracted. Based on the constraint functions of each constraint dimension, the constraint imprint value of the event in each constraint dimension is calculated. Then, the constraint imprint values ​​of each dimension are combined to form the projection coordinates of the event in the shared constraint space. The specific mapping calculation process for each dimension will be detailed in subsequent embodiments 5 and 6.

[0041] Third, the constrained projection engine arranges the projected coordinates of each event in each dimension according to the time sequence of the event in the original event trajectory, forming the constrained projection trajectory corresponding to that event trajectory. The first and second constrained projection trajectories are stored separately for use in subsequent resonance intensity calculation steps.

[0042] For example, following the previous example, the event sequence of the first event trajectory (such as order ORD001) can be: creation (09:00), payment (09:05), shipment (10:30), completion (15:00). The event sequence of the second event trajectory (contract CT001) is: signing (08:45), payment (11:20). The constraint projection engine maps the two trajectories to a shared constraint space composed of three dimensions: time causality, quantity conservation, and spatial economy. For the "shipment" event of the first event trajectory, its imprint value in the time causality dimension is 0.1 (satisfying the temporal order), its imprint value in the quantity conservation dimension is 0.2 (quantity change within a reasonable range), and its imprint value in the spatial economy dimension is 0.3 (transportation cost and distance are reasonably matched), forming the projection coordinates (0.1, 0.2, 0.3) of this event in the constraint space. The projection points of each event are connected in time sequence to generate the first constraint projection trajectory and the second constraint projection trajectory.

[0043] In step S13, by mapping the first event trajectory and the second event trajectory to a multi-dimensional shared constraint space constructed by a general physical or economic constraint function decoupled from business logic and generating a constraint projection trajectory, heterogeneous event trajectories belonging to different business domains are projected into a unified objective constraint benchmark space that is independent of business rules. This transforms the comparison of cross-domain data from relying on preset business rules to logical self-consistency verification based on objective constraints. It solves the technical problem in traditional technologies that cannot objectively compare heterogeneous event trajectories due to the lack of a unified comparison benchmark, and obtains the comparability of cross-domain event trajectories under the same constraint coordinate system.

[0044] S14: Based on the dynamic time warp algorithm of constraint satisfaction, calculate the resonance intensity of the first constraint projection trajectory and the second constraint projection trajectory, wherein the resonance intensity characterizes the degree of logical self-consistency of the two trajectories in the multidimensional shared constraint space.

[0045] Constrained Dynamic Time Warping (C-DTW) is a customized algorithm that improves upon the classic Dynamic Time Warping (DTW) algorithm by replacing its local distance function with a composite function of constraint violation costs across all constraint dimensions in a shared constraint space. The classic DTW algorithm, based on dynamic programming, is used to measure the similarity between two time series by locally stretching or compressing the time axis to find the optimal alignment path between them. The C-DTW algorithm differs from the classic DTW in that its local distance function no longer uses geometric distance metrics such as Euclidean distance, but is defined as a weighted sum of constraint violation costs across all constraint dimensions. This means the algorithm calculates not simply numerical similarity, but the logical self-consistency of the two trajectories under the premise of satisfying shared constraints.

[0046] Resonance intensity: This refers to a normalized quantitative index, calculated using the dynamic time warp algorithm (DTW) for constraint satisfaction, characterizing the degree of logical self-consistency between the first and second constraint projection trajectories within a multidimensional shared constraint space. The formula for calculating resonance intensity is R = 1 / (1 + D_min), where D_min is the minimum cumulative constraint violation cost obtained by the C-DTW algorithm. The range of resonance intensity is (0, 1], meaning it is greater than 0 and less than or equal to 1. The closer the value is to 1, the higher the degree of logical self-consistency between the two trajectories in the constraint space, indicating a higher degree of mutual verification between the business activities represented by the two trajectories at the level of objective physical and economic laws. The closer the value is to 0, the lower the degree of logical self-consistency. It is defined as "resonance intensity" because the calculation process of this algorithm is isomorphic to the physical resonance phenomenon: the two constraint projection trajectories are like two vibrating systems, the alignment operation of the DTW algorithm on the time axis is like finding the resonant frequency, and the final output R value quantifies the degree of "resonance" between the two under the premise of satisfying shared constraints.

[0047] The specific implementation of this step is as follows: First, the server-side resonance calculation engine receives the first constraint projection trajectory P1 and the second constraint projection trajectory P2 as input. The resonance calculation engine constructs a cumulative cost matrix D, where the number of rows is the length of P1 |P1| and the number of columns is the length of P2 |P2|. Matrix element D(i,j) represents the minimum cumulative constraint violation cost when aligning the first i projection points of P1 with the first j projection points of P2. The specific matrix construction and filling process will be detailed in subsequent embodiment 7.

[0048] Secondly, the resonance calculation engine defines a local distance function d(i, j) to calculate the composite constraint violation cost between the i-th projection point in P1 and the j-th projection point in P2. The specific form of the local distance function will be detailed in subsequent embodiment 8. Its core is the weighted sum of constraint violation costs in each constraint dimension. The constraint violation cost in each constraint dimension is calculated through the corresponding constraint function. The output value of the constraint function is a normalized value between 0 and 1, where 0 indicates that the constraint is fully satisfied and 1 indicates that the constraint is severely violated.

[0049] Third, the resonance calculation engine, based on the local distance function and dynamic programming recursive formula, fills the cumulative cost matrix from bottom to top, calculating the minimum cumulative cost path from the starting point D(1,1) to the ending point D(|P1|,|P2|). The dynamic programming recursive formula defines the recursive relationship between matrix element D(i,j) and its adjacent elements D(i-1,j), D(i,j-1), and D(i-1,j-1). By comparing the costs of three alignment methods (insertion, deletion, and matching), the minimum cumulative cost path is selected, as detailed in the corresponding description in Example 7.

[0050] Fourth, after the cumulative cost matrix is ​​filled, the resonance calculation engine obtains the endpoint cumulative cost value D_min = D(|P1|, |P2|), and outputs the resonance intensity R = 1 / (1+D_min) after normalization transformation. Since D_min is a non-negative real number, the range of R is (0, 1). When the two trajectories are perfectly coordinated in all constraint dimensions (i.e., the local distance d(i, j) of each step alignment is close to 0), D_min approaches 0 and R approaches 1, indicating that a strong "resonance" has occurred.

[0051] It should be noted that the calculation method for the resonance intensity described above is not limited to the normalized transformation formula exemplified. In one example, an exponential decay transformation R=exp(-α×D_min) can be used, where α is the decay coefficient; in another example, a quantile mapping method can be used, mapping D_min to percentile values ​​based on historical data distribution as the resonance intensity. Any calculation method that can transform the minimum cumulative constraint violation cost into a normalized quantitative index characterizing the degree of logical consistency falls within the scope of protection of this invention.

[0052] For example, continuing from the previous example, the first constrained projection trajectory P1 contains 4 projection points, and the second constrained projection trajectory P2 contains 2 projection points. The resonance calculation engine constructs a 4x2 cumulative cost matrix. Calculations show that when the first point of P1 aligns with the first point of P2, the local distance d(1,1) = 0.15; when the second point of P1 aligns with the first point of P2, d(2,1) = 0.22, and so on. By recursively filling the matrix using dynamic programming, the endpoint value D_min = 0.35 of the minimum cumulative cost path is obtained. The resonance intensity R = 1 / (1+0.35) ≈ 0.74, indicating that the logical self-consistency of the two trajectories within the shared constraint space is approximately 74%.

[0053] In step S14, the resonance intensity of the first constraint projection trajectory and the second constraint projection trajectory is calculated by the dynamic time warp algorithm based on constraint satisfaction. This achieves a precise quantitative assessment of the logical self-consistency of cross-domain event trajectories within the shared constraint space. It transforms the traditional binary matching judgment based on preset rules into continuous intensity quantification based on constraint satisfaction, solving the technical problem that traditional technologies cannot quantify and assess the inherent logical consistency of cross-domain data. This provides a computable metric for the endogenous mutual verification relationship of cross-domain data.

[0054] S15: When the resonance intensity exceeds a preset threshold, it is determined that there is a cross-domain data matching relationship between the terminal production and sales entity corresponding to the first event trajectory and the bulk trade entity corresponding to the second event trajectory.

[0055] The specific implementation of this step is as follows: First, the matching determination module on the server side obtains the resonance intensity R calculated in step S14. Simultaneously, the matching determination module reads the preset threshold θ from the configuration storage. The preset threshold θ can be determined based on the statistical significance test of historical matching data, for example, by taking the 95% confidence lower bound of the resonance intensity distribution of known correctly matched entities in historical data as the threshold, or by being configured by the system administrator according to the business's trade-off requirements for matching precision and recall.

[0056] Secondly, the matching determination module compares the resonance intensity R with a preset threshold θ. If R ≥ θ, it is determined that there is a cross-domain data matching relationship between the terminal production and sales entity corresponding to the first event trajectory and the bulk trade entity corresponding to the second event trajectory. If R < θ, it is determined that there is no significant cross-domain data matching relationship between the two.

[0057] Third, the matching determination module outputs the determination result to the downstream processing module. If a matching relationship is determined, a cross-domain matching record can be further generated and persistently stored. The specific processing steps will be detailed in the subsequent embodiment 9.

[0058] It should be noted that the above judgment logic is not limited to the single-threshold comparison method exemplified. In one example, a dual-threshold strategy can be adopted, setting a high threshold θ_high and a low threshold θ_low: a match is directly determined when R ≥ θ_high, a mismatch is directly determined when R ≤ θ_low, and a match is marked as requiring manual review when R is between the two. In another example, the judgment can be made by combining the confidence interval of resonance intensity; a match is determined when the lower confidence limit of resonance intensity exceeds the threshold. Any technical means that can determine the matching relationship based on resonance intensity is within the protection scope of this invention.

[0059] For example, following the previous example, the server calculates the resonance intensity R = 0.74. The preset threshold θ is set to 0.70. Since 0.74 > 0.70, the matching judgment module determines that there is a cross-domain data matching relationship between order ORD001 (end-user production and sales entity) and contract CT001 (bulk trading entity). This judgment result indicates that the lifecycle activities of pet food order ORD001 and the transaction activities of soybean purchase contract CT001 are highly logically consistent in terms of objective constraints such as time causality, quantity conservation, and spatial economics, and there is an inherent supply and demand correspondence between the two.

[0060] Furthermore, the determination results of the aforementioned cross-domain data matching relationships can serve as the basis for fundamental data association in an enterprise's data governance system. For example, based on this matching relationship, a technical data index can be automatically established between business documents in the terminal production and sales domain (such as pet supply orders) and transaction vouchers in the bulk trade domain (such as raw material purchase and warehousing slips), thereby supporting the automated triggering of subsequent data processing procedures such as supply chain traceability, business and financial consistency verification, or compliance audits. It should be understood that the data processing uses listed above are merely examples, and this invention does not limit the specific technical application methods of the matching relationship determination results.

[0061] This step S15 compares the resonance intensity with a preset threshold and determines the cross-domain data matching relationship, thereby realizing the endogenous and automated determination of the cross-domain data matching relationship without relying on any predefined cross-domain business association rules. It transforms the traditional post-event manual verification mode into a pre-event automatic mutual verification mode, solving the technical problem in traditional technology that cross-domain data matching relies on preset rules and cannot autonomously discover emerging associations, and obtaining a complete technical closed loop for automated matching and verification of cross-domain heterogeneous data.

[0062] In this embodiment, through sequential processing of S11-S15, including standard event acquisition and diversion, independent event trajectory construction, constraint space projection decoupled from business logic, constraint satisfaction DTW resonance intensity calculation, and threshold matching determination, the data matching processing method based on cross-domain production and sales of claim 1 is fully realized, providing a core technical solution for the automated cross-domain data matching verification of multi-business line operating enterprises.

[0063] Example 2: Specific implementation of standard event encapsulation.

[0064] In this embodiment, the collected business operation logs are encapsulated into standard events, including: For each business operation log, extract the operation type, business entity identifier, operation timestamp, and post-operation status information from the business operation log. Generate a globally unique numerical event identifier for the aforementioned business operation log; The source domain identifier, the operation timestamp, the operation type, and the post-operation status information are encapsulated into a status snapshot in key-value pair format. The digital event identifier, the source domain identifier, the operation timestamp, and the state snapshot are combined into the standard event.

[0065] The specific implementation of this embodiment is as follows: First, the event standardization processor on the server side parses the original data format (such as JSON string, XML document, or database change record) of each collected business operation log, and extracts the operation type field, business entity identifier field, operation timestamp field, and post-operation status information field. The operation type field indicates the type of business operation corresponding to the log (such as "create", "update", "delete", "complete", etc.); the business entity identifier field is the unique identifier of the business object targeted by the operation (such as order number, contract number); the operation timestamp field records the precise time when the operation occurred; and the post-operation status information field describes the state of the business entity after the operation was executed.

[0066] Secondly, the event standardization processor generates a globally unique numeric event identifier for this business operation log. The numeric event identifier can be a 64-bit long integer value generated using the Snowflake algorithm, containing a timestamp, machine identifier, and sequence number, ensuring that each identifier generated in a distributed environment is globally unique. Alternatively, a 128-bit globally unique identifier can be generated using the UUID generation algorithm.

[0067] Third, the event standardization processor encapsulates the source domain identifier, operation timestamp, operation type, and post-operation status information into a state snapshot in key-value pair format. The key of each key-value pair is a string representing the field name (e.g., "sourceDomain", "timestamp", "operationType", "afterState"), and the value is the corresponding field value. This key-value pair structure facilitates flexible parsing and expansion of fields in subsequent steps.

[0068] Fourth, the event standardization processor combines the generated digital event identifier, source domain identifier, operation timestamp, and state snapshot into a standard event data structure, and outputs the standard event to the subsequent event routing module.

[0069] For example, following the previous example, the server parses a business operation log from a pet supplies e-commerce system, extracting an operation type of "order creation," a business entity identifier of "ORD001," an operation timestamp of 09:00:01, and post-operation status information of {"status": "pending payment," "amount": 1200}. The server generates a numeric event identifier "EVT-20241022-000001." The source domain identifier "RETAIL," the operation timestamp 09:00:01, the operation type "order creation," and the post-operation status information are encapsulated into a key-value pair status snapshot. The event identifier, source domain identifier, operation timestamp, and status snapshot are combined into a standard event.

[0070] In this embodiment, by extracting key log fields, generating globally unique event identifiers, encapsulating key-value pair state snapshots, and combining them into standard events, a standardized encapsulation mechanism for business operation logs to standard events is constructed. Based on the event collection and distribution achieved in Embodiment 1 above, the data structure definition and encapsulation process of standard events are further refined independently. This further solves the problem of how to unify multi-source business logs with different formats into a processable standard event format, significantly improving the standardization of event processing and the processing efficiency and accuracy of downstream modules.

[0071] Example 3: Specific implementation of event trajectory construction.

[0072] In this embodiment, the first event stream and the second event stream are aggregated by business entity and arranged in chronological order to construct a first event trajectory and a second event trajectory, including: For each event stream, extract the business entity identifier field carried in each standard event; Based on the business entity identifier field, standard events with the same business entity identifier are grouped into the same event group; Within each event group, the events are arranged in ascending order according to the chronological order of the operation timestamps carried by each standard event. The arranged event groups are determined as the event trajectories corresponding to the business entities.

[0073] The specific implementation of this embodiment is as follows: First, the server-side event sourcing engine reads the standard events in the first event stream one by one. For each standard event, the value of the business entity identifier field is extracted from the state snapshot key-value pair. The key name of the business entity identifier field can be pre-configured (such as "entityId" or "orderId") to adapt to the naming requirements of different business systems.

[0074] Secondly, the event sourcing engine groups standard events with the same extracted business entity identifier field value into the same event group. A hash table data structure can be used to maintain the event group mapping: the business entity identifier value is the key, and the list of standard events is the value. When a new standard event is read, the corresponding event group list is searched based on its business entity identifier; if it does not exist, a new list is created, and the current event is appended to the list.

[0075] Third, within each event group, the event sourcing engine sorts the events in ascending order according to the chronological order of their operation timestamps. Operation timestamps can be obtained directly from the operation timestamp field of the standard events or extracted from the state snapshot. The sorting algorithm can be implemented using well-known sorting algorithms in the field, such as merge sort or quicksort.

[0076] Fourth, the event tracing engine identifies the arranged event groups as the event trajectories corresponding to the business entity. These event trajectories can then be persistently stored in an event trajectory repository. The storage structure may include, but is not limited to, metadata such as: business entity identifier, event trajectory identifier, business domain identifier, event sequence list, and trajectory start and end timestamps. The second event stream is processed using the same workflow to construct a second set of event trajectories.

[0077] It should be noted that the above-described aggregation sorting implementation is not limited to the hash table grouping and in-memory sorting example. In one example, a streaming processing framework's state management mechanism can be used to append the event trajectory to the corresponding entity in real time as the event arrives, and event time watermarking can be used to ensure the correctness of the sorting sequence. In another example, batch aggregation sorting can be achieved using the GROUP BY and ORDER BY operations of a relational database. Any technical means that can aggregate event streams by business entities and arrange them in chronological order is within the scope of protection of this invention.

[0078] For example, following the previous example, the first event stream contains four standard events belonging to order ORD001, with operation timestamps of 09:00:01, 09:05:22, 10:30:45, and 15:00:12. The server groups these four events into the same event group according to the business entity identifier "ORD001", and after arranging them in ascending order of operation timestamps, obtains the first event trajectory: EVT001 (Create) → EVT003 (Payment) → EVT005 (Delivery) → EVT008 (Completion). This trajectory is stored, and the trajectory identifier can be TRJ-ORD001.

[0079] In this embodiment, by extracting the business entity identifier field, grouping by identifier, arranging by timestamp in ascending order within the group, and determining the event trajectory, a structured conversion mechanism from event flow to event trajectory is constructed. This further refines the aggregation and sorting process of event trajectory construction independently on the basis of standard event encapsulation implemented in Embodiment 2 above, and further solves the problem of how to efficiently organize discrete event flow into event trajectory with complete temporal semantics, significantly improving the accuracy and processing efficiency of event trajectory construction.

[0080] Example 4: Dimensional composition of a multidimensional shared constraint space.

[0081] In this embodiment, the multidimensional shared constraint space includes a time causal constraint dimension, a matter conservation constraint dimension, and a spatial economic constraint dimension; The temporal causal constraint dimension is constructed based on a partial order relation function between event type and operation timestamp; The quantity conservation constraint dimension is constructed based on the quantity logic conservation function of the same or related items during the state transition process; The spatial economic constraint dimension is constructed based on the economic rationality function between the geographical location information associated with the event and the transaction costs.

[0082] The specific implementation of this embodiment is as follows: The multidimensional shared constraint space consists of three independent constraint dimensions, each defined by a corresponding constraint function. The output values ​​of the constraint functions are all normalized values ​​between 0 and 1, where 0 indicates that the event fully satisfies the constraint conditions in that dimension, and 1 indicates that the constraint conditions are seriously violated.

[0083] First, the temporal causal constraint dimension is constructed based on the partial order relation function between event type and operation timestamp. The partial order relation function refers to the constraint function used to define and verify the temporal order relationship that should be satisfied between different event types in the event trajectory. The formal definition of the partial order relation function can be: C_time(e_curr, e_ref) → [0, 1]; Where e_curr is the standard event to be evaluated, and e_ref is a reference event in the event trajectory that has a temporal correlation with e_curr (usually a predecessor event arranged in chronological order). The input parameters of the partial order relation function include: type_curr: The event type of the current event; t_curr: The timestamp of the operation for the current event; type_ref: The event type of the reference event; t_ref: The timestamp of the operation of the reference event; The output of the partial order relation function is the normalized time constraint imprint value v_time.

[0084] Partial order relation functions are typically based on a pre-defined event type partial order rule base. They take the event type and operation timestamp of the current event, and the event type and operation timestamp of a reference event as input. By comparing the actual time difference with a pre-defined expected time difference range, they output a normalized time constraint imprint value. The time constraint imprint value ranges from [0, 1], where 0 indicates a complete fulfillment of the time partial order relation, and 1 indicates a severe violation of the time partial order relation. For example, for a business entity, the operation timestamp of the "payment" event must be later than the operation timestamp of the "create" event; the operation timestamp of the "shipment" event must be later than the operation timestamp of the "payment" event.

[0085] The specific calculation process of the partial order relation function can be as follows: Step 1: Query the preset event type partial order rule library. This library stores the temporal sequence relationships that event type pairs should satisfy. Each rule can be defined in the format "Predecessor event type → Successor event type: Expected time difference range [T_min, T_max]". For example, "Order creation → Order payment: [0 seconds, 24 hours]", "Order payment → Order shipment: [0 seconds, 72 hours]". The preset event type partial order rule library can be pre-configured based on the general temporal logic of the business process, or determined based on the statistical distribution of historical event data (e.g., taking the 95% confidence interval of the time difference under normal process conditions).

[0086] Step 2: Retrieve matching rules. Using `type_ref` as the predecessor event type and `type_curr` as the successor event type, search the partial order rule base for a matching rule. If no matching rule exists, it indicates that there is no pre-defined partial order relationship requirement between the two events, and the function outputs `v_time = 0` (assuming the constraint is satisfied by default).

[0087] Step 3: Calculate the actual time difference. If a matching rule exists, calculate the actual time difference between the current event operation timestamp and the reference event operation timestamp: Δt = t_curr - t_ref.

[0088] Step 4: Evaluate the satisfaction degree and quantify. Compare the actual time difference Δt with the expected time difference range [T_min, T_max] defined in the rule: If Δt ∈ [T_min, T_max], it is determined that the partial order relationship is fully satisfied, and v_time = 0; If Δt < T_min (the event occurs too early), calculate the degree of deviation: Degree of deviation = (T_min - Δt) / T_min, v_time = min(degree of deviation, 1.0); If Δt > T_max (the event occurs too late), calculate the degree of deviation: Degree of deviation = (Δt - T_max) / T_max, v_time = min(degree of deviation, 1.0). [[ID=,10]]

[0089] Step 5: Output the constraint imprint value. Output the calculated v_time as the projection coordinate of the current event in the dimension of time causality constraint. If the current event is the first event in the event trajectory and there is no reference event, by default, v_time = 0.

[0090] The specific mapping process of the above partial order relationship function will be elaborated in detail in Embodiment 5.

[0091] It should be noted that the implementation manner of the above partial order relationship function is not limited to the method based on piecewise deviation calculation exemplified. In one example, a fuzzy membership function can be adopted, and "satisfying the time partial order relationship" is defined as a fuzzy set. The membership degree is calculated according to the actual time difference, and the constraint imprint value takes "1 - membership degree"; in another example, a time decay factor can be introduced, that is, the influence of the degree of deviation on the constraint imprint value decays with the remoteness of the event timestamp. Any function that can evaluate the satisfaction degree of the time partial order relationship based on the event type and operation timestamp belongs to the protection scope of the present invention.

[0092] Secondly, the material quantity conservation constraint dimension is constructed based on the quantity logic conservation function during the state transition process of the same or related items. Among them, the quantity logic conservation function defines the logical conservation relationship that the total quantity of a specific item should satisfy during the business activity process. The formal definition of the quantity logic conservation function can be: C_mass(traj) → [0, 1]; where traj is the event trajectory to be evaluated.

[0093] The quantity logic conservation function takes a sequence of target events containing information on changes in the quantity of items in the event trajectory as input. It extracts the operation type and quantity change value of each target event, determines the direction of change, accumulates the impact along the time axis to generate a quantity accumulation curve, and outputs a normalized quantity conservation imprint value based on the degree of deviation of the accumulation curve within a preset reasonable fluctuation range. The value range is [0, 1], where 0 indicates that the quantity logic conservation relationship is fully satisfied, and 1 indicates that the quantity logic conservation relationship is seriously violated. The quantity conservation imprint value comprehensively reflects the degree of constraint violation of the entire event trajectory in the quantity conservation dimension. For example, for the soybean procurement and warehousing event in the bulk commodity trading domain and the pet food production and consumption event in the terminal production and sales domain, the cumulative consumption of the same item (soybeans or soybean meal) involved in both should not significantly exceed the cumulative procurement volume within a reasonable conversion rate and time window.

[0094] The specific calculation process of the quantitative logic conservation function can be as follows: Step 1: Identify the target event sequence. Traverse all standard events in the event trajectory, and identify whether each event's state snapshot contains fields related to the quantity of items (such as "quantity", "amount", "stock_change", etc.). Extract the events containing quantity change information as target events and sort them in ascending order by operation timestamp.

[0095] Step 2: Extract the change and determine the direction of change. For each target event, extract the quantity difference ΔQ before and after the operation from its state snapshot. Simultaneously, determine the direction of its impact on the total quantity of items based on the operation type of the event. The mapping relationship between operation type and impact direction can be pre-configured in an operation type mapping table. For example, "Inbound," "Purchase Inbound," and "Production Inbound" correspond to an increase direction; "Outbound," "Sales Outbound," and "Production Consumption" correspond to a decrease direction.

[0096] Step 3: Calculate the impact. For each target event, calculate its impact by combining the difference in quantity before and after the operation with the direction of influence: If the direction of influence is increasing, then the amount of influence is positive: impact = +|ΔQ|; If the direction of influence is decreasing, then the amount of influence is negative: impact = -|ΔQ|.

[0097] Step 4: Generate the cumulative quantity curve. Starting from the beginning of the event trajectory, sequentially accumulate the impact of each target event along the time axis. Let the initial cumulative quantity Q_0 = 0 (or obtain the initial baseline value from the beginning inventory data of the business system). For the i-th target event, the subsequent cumulative quantity is Q_i = Q_{i-1} + impact_i. The cumulative quantity curve is formed by connecting the cumulative quantity values ​​at each target event time, with the horizontal axis representing time and the vertical axis representing the cumulative quantity.

[0098] Step 5: Evaluate the cumulative curve fluctuation and calculate the imprint value. Establish a reasonable fluctuation range for the quantity [-ε, +ε], representing the acceptable range of normal fluctuation. The value of ε can be determined based on the item type, historical data fluctuation amplitude, or business tolerance. For the cumulative quantity Q(t) at each time point on the cumulative curve, calculate whether it exceeds the fluctuation range: If Q(t) ∈ [-ε, +ε], then the constraint is not violated at that moment; If Q(t) > +ε (exceeds the upper limit), calculate the excess ratio: Excess ratio = (Q(t) - ε) / ε; If Q(t) < -ε (below the lower limit), calculate the excess ratio: Excess = (ε - Q(t)) / ε.

[0099] Based on the maximum excess value (max_excess) across all time points, calculate the mass conservation imprint: v_mass = min(max_excess, 1.0). If the entire cumulative curve remains within the fluctuation range, then v_mass = 0.

[0100] When the items involved have a conversion relationship (e.g., soybean procurement and warehousing versus soybean meal production consumption), a conversion coefficient should be introduced before calculating the cumulative amount. The conversion coefficient α represents the quantity of related items that can be converted from a unit of the original item. Let the cumulative curve of the original item be Q_raw(t) and the cumulative curve of the related item be Q_rel(t). Then, before performing a conservation comparison, the two need to be unified in terms of dimensions: Q'_raw(t) = Q_raw(t) × α. The specific value of the conversion coefficient can be determined based on production process parameters or historical data statistics.

[0101] It should be noted that the implementation of the aforementioned quantity logic conservation function is not limited to the example method based on cumulative curve fluctuation assessment. In one example, a sliding window variance assessment can be used to calculate the variance of the cumulative curve within the sliding time window; if the variance exceeds a threshold, it is considered a violation of conservation. In another example, a time decay factor can be introduced, so that the influence of earlier cumulative deviations on the current imprint value weakens over time. In a third example... Any function that can assess the degree to which the quantity conservation relationship is satisfied based on information about changes in the quantity of events falls within the scope of protection of this invention.

[0102] The specific mapping process of the above-mentioned quantitative logic conservation function will be explained in detail in Example 6.

[0103] Third, the spatial economic constraint dimension is constructed based on the economic rationality function between the geographical location information associated with the event and the transaction costs.

[0104] The economic rationality function refers to a constraint function used to assess whether the geographical location information involved in an event trajectory and the associated transaction costs conform to basic economic logic. It defines the basic economic logic that the geographical location of an event association and its related transaction costs should conform to. The formal definition of the economic rationality function can be as follows: C_econ(traj) → [0, 1]; Where traj represents the event trajectory to be evaluated.

[0105] The economic rationality function takes standard events carrying geographical location information (such as the place of shipment and the place of receipt) and transaction price or cost information (such as the purchase price, the selling price, and the freight) in the event trajectory as input. It calculates the reference transportation cost between geographical locations and compares the relationship between the actual price difference and the reasonable price difference range, outputting a normalized spatial economic imprint value v_econ, with a value range of [0, 1]. 0 indicates that the economic rationality constraint is fully satisfied, and 1 indicates that the economic rationality constraint is seriously violated. For example, for goods purchased from location A and sold in location B, the difference between the selling price and the purchase price should be able to cover the unit transportation cost from location A to location B plus a reasonable capital occupation cost.

[0106] The specific calculation process of the economic rationality function can be as follows: Step 1: Extract Geographic Location and Price Information. Identify related event pairs carrying geographic location and price information from the standard events in the event trajectory. For example, extract purchase events (including purchase location loc_buy and purchase price P_buy) from the event trajectory of the bulk commodity trading domain, and extract sales or consumption events (including sales location loc_sell and sales price or cost price P_sell) from the event trajectory of the end-product production and sales domain. If there is no complete geographic location and price information pair in the event trajectory, the function defaults to outputting v_econ = 0.

[0107] Step 2: Calculate the reference transportation cost between geographical locations. Based on the geographical coordinates of the purchase location (loc_buy) and the sales location (loc_sell), calculate the geographical distance D between the two locations. The formula for calculating the reference transportation cost (Cost_trans_ref) is: Cost_trans_ref = D × unit_cost_per_distance, where unit_cost_per_distance is the reference value for transportation cost per unit distance, which can be pre-configured based on the mode of transportation (road, rail, sea) and historical freight rate data.

[0108] Step 3: Calculate the actual price difference and the reasonable price difference range. Calculate the actual price difference ΔP = P_sell - P_buy. Determine the reasonable price difference range [ΔP_min, ΔP_max], where: ΔP_min = Cost_trans_ref + Cost_capital_ref, meaning the price difference should at least cover the reference transportation cost plus a reasonable capital occupation cost; ΔP_max = Cost_trans_ref × γ, where γ is the reasonable premium coefficient (e.g., γ=1.5), indicating that the price difference is allowed to fluctuate within a certain multiple of the transportation cost.

[0109] Step 4: Assess and quantify the degree of satisfaction. Compare the actual price difference ΔP with the reasonable price difference range [ΔP_min, ΔP_max]: If ΔP ∈ [ΔP_min, ΔP_max], then it is considered that the economic rationality is fully satisfied, and v_econ = 0; If ΔP < ΔP_min (the price difference is too low, which may be due to abnormal transactions or data errors), calculate the degree of deviation: deviation = (ΔP_min - ΔP) / ΔP_min, v_econ = min(deviation, 1.0); If ΔP > ΔP_max (the price difference is too high and needs attention), calculate the degree of deviation: deviation = (ΔP - ΔP_max) / ΔP_max, v_econ = min(deviation, 1.0).

[0110] Step 5: Output the constraint imprint value. Output the calculated v_econ as the comprehensive projected coordinates of the event trajectory in the spatial economic constraint dimension. If the event trajectory contains multiple pairs of geographic location-price information, the weighted average or maximum value of each pair's calculation results can be taken as the final imprint value.

[0111] It should be noted that the implementation of the aforementioned economic rationality function is not limited to the example based on comparing transportation costs and price differences. In one example, a statistical test based on the law of one price can be used to test whether the price series of the two locations satisfy a cointegration relationship through regression analysis; in another example, a time factor can be introduced to consider the timeliness of price information, assigning higher weight to events closer to the present moment. Any function that can assess the degree of satisfaction of economic rationality based on geographical location and transaction price information falls within the protection scope of this invention.

[0112] Furthermore, the specific composition of the aforementioned constraint dimensions is not limited to the three dimensions exemplified. In one example, an information flow constraint dimension can be added, constructing a constraint function based on the time sequence logic of document and voucher flow; in another example, a quality conservation constraint dimension can be added, constructing a constraint function based on the quality balance relationship in item grade conversion; in a third example, a capital flow constraint dimension can be added, constructing a constraint function based on the time matching relationship between cash flow and goods flow; in a fourth example, an information transmission constraint dimension can be added, constructing a constraint function based on the time sequence logic of business document flow. Any technical means capable of constructing a multi-dimensional shared constraint space based on a general physical or economic constraint function decoupled from business logic falls within the protection scope of this invention.

[0113] In this embodiment, by defining the temporal causal constraint dimension, the quantity conservation constraint dimension, and the spatial economic constraint dimension, and constructing each dimension based on the partial order relation function, the quantitative logic conservation function, and the economic rationality function, a specific composition of the three-dimensional shared constraint space is constructed. Thus, based on the constraint space projection achieved in Embodiment 1 above, the specific dimension definitions and function construction basis of the constraint space are further clarified, solving the technical problem of how to concretize the abstract constraint space into a computable constraint dimension system, and significantly improving the feasibility of the constraint space and the effectiveness of the constraint effect.

[0114] Example 5: Refinement of the mapping of the temporal causal constraint dimension.

[0115] In this embodiment, please refer to Figure 2 , Figure 2 This is a schematic diagram of the first sub-process of the data matching and processing method based on cross-domain production and sales provided in an embodiment of the present invention. Figure 2 As shown, in this embodiment, mapping the first event trajectory and the second event trajectory to a predefined multidimensional shared constraint space includes: S21: For each standard event in the event trajectory to be mapped, extract its event type and operation timestamp; S22: Based on the preset event type partial order rule base, determine the temporal sequence relationship that the event type of the current standard event should satisfy between the event types of its adjacent standard events; S23: Calculate whether the operation timestamp of the current standard event satisfies the time sequence relationship, and quantify the degree of satisfaction as a time constraint imprint value; S24: Record the time constraint imprint value as the projection coordinates of the standard event on the time causal constraint dimension.

[0116] The pre-configured event type partial order rule library refers to a set of rules that define the temporal sequence relationships between different event types. Each rule in the pre-configured event type partial order rule library adopts the format "predecessor event type → successor event type: expected time difference range". For example, "order creation → order payment: 0 seconds to 24 hours", "order payment → order shipment: 0 seconds to 72 hours". The pre-configured event type partial order rule library can be set based on the general process logic of the business domain or determined based on the statistical distribution of event occurrence time differences in historical data. The pre-configured event type partial order rule library is independent of specific business rules and only defines the basic logical relationship between event types in the time dimension.

[0117] Time constraint imprint value: This refers to a normalized value obtained after quantitatively evaluating whether the operation timestamp of the current event meets the preset time sequence relationship. The value ranges from 0 to 1. 0 indicates that the time sequence relationship is fully met (the actual time difference falls within the expected time difference range), and 1 indicates that the time sequence relationship is severely violated (the actual time difference deviates greatly from the expected range). The time constraint imprint value serves as the projected coordinate of the event on the time causal constraint dimension and participates in the subsequent resonance intensity calculation.

[0118] The specific implementation of this embodiment is as follows: First, for each standard event in the event trajectory to be mapped, the constraint projection engine on the server side extracts the event type and operation timestamp of the event from the state snapshot or the operation timestamp field of the standard event. The event type can be obtained from the "operationType" key in the state snapshot.

[0119] Secondly, the constraint projection engine obtains the preceding event (i.e., the previous event arranged in chronological order) of the current standard event in the event trajectory. It queries the preset event type partial order rule base to check if there is a rule whose preceding event type is the event type of the preceding event and whose subsequent event type is the event type of the current event. If a matching rule exists, it obtains the expected time difference range [T_min, T_max] defined by the rule.

[0120] Third, the constraint projection engine calculates the actual time difference Δt between the current event operation timestamp and the predecessor event operation timestamp. It then determines whether Δt falls within the expected time difference range [T_min, T_max]. If Δt is within the range, the time constraint imprint value is set to 0 (fully satisfied). If Δt exceeds the range, the time constraint imprint value is calculated based on the degree of deviation: Deviation ratio = min(|Δt - T_max| / T_max, 1.0); Time constraint imprint value = Deviation ratio (the larger the deviation, the closer the imprint value is to 1).

[0121] Fourth, the constraint projection engine records the calculated time constraint imprint value as the projection coordinates of the standard event on the time causality constraint dimension. If the current event is the first event in the event trajectory and has no predecessor event, its time constraint imprint value is set to 0.

[0122] For example, continuing from the previous example, the preceding event of the "Payment" event (operation timestamp 09:05:22) in the event trajectory is the "Creation" event (operation timestamp 09:00:01). The default partial order rule in the rule base is "Creation → Payment: 0 seconds to 1 hour". The actual time difference Δt = 5 minutes 21 seconds = 321 seconds, which is within the expected range of 0-3600 seconds, so the time constraint imprint value = 0. The preceding event of the "Shipping" event (10:30:45) is the "Payment" event, with the rule "Payment → Shipping: 0 seconds to 1 hour". The actual time difference Δt ≈ 85 minutes = 5100 seconds, which exceeds the upper limit of the expected range of 3600 seconds. The deviation ratio = min(|5100-3600| / 3600, 1.0) = 0.42, and the time constraint imprint value = 0.42.

[0123] In this embodiment, by extracting event types and operation timestamps, determining the temporal sequence based on a preset partial order rule base, calculating the degree of satisfaction, and quantifying it into a time constraint imprint value, a precise mapping mechanism for the time causal constraint dimension is constructed. Thus, based on the constraint space dimension definition implemented in Embodiment 4 above, the specific projection calculation process of the time causal dimension is further refined independently, solving the problem of how to accurately map the temporal attributes of events into calculable constraint imprints, and significantly improving the accuracy and quantifiability of the time constraint dimension projection.

[0124] Example 6: Refinement of the mapping of the quantity conservation constraint dimension.

[0125] In this embodiment, mapping the first event trajectory and the second event trajectory to a predefined multidimensional shared constraint space includes: For the event trajectory to be mapped, identify the target event sequence involving changes in the quantity of items; Extract the operation type and the difference in quantity before and after the operation from each target event; The direction of the impact of the target event on the total quantity of items is determined based on the operation type, and the direction of impact includes either an increase or a decrease. The impact of each target event is determined based on the difference in quantity before and after the operation and the direction of influence. The influence of each target event is accumulated along the time axis to generate the event trajectory on the mass conservation constraint dimension as a mass accumulation curve, and each point on the mass accumulation curve is used as the projected coordinate of that dimension.

[0126] The specific implementation of this embodiment is as follows: First, the server-side constraint projection engine traverses the standard event sequence of the event trajectory to be mapped, identifying target events involving changes in item quantity. The criteria for determining changes in item quantity are: the state snapshot of the standard event contains quantity-related fields such as "quantity" or "amount," and the value of this field changes before and after the operation. The identified target events are arranged in chronological order to form a target event sequence.

[0127] Secondly, the constraint projection engine extracts the operation type and the difference in quantity before and after the operation recorded in each target event. The difference in quantity before and after the operation is the quantity value after the operation minus the quantity value before the operation. This difference can be obtained from the comparison of the state before and after in the state snapshot, or directly from the change field of the business operation log.

[0128] Third, the constraint projection engine determines the direction of the target event's impact on the total quantity of items based on the operation type. The direction of impact is divided into an increasing direction and a decreasing direction: when the operation type is an operation that increases inventory or holdings, such as receiving, purchasing, or production receiving, the direction of impact is increasing; when the operation type is an operation that decreases inventory or holdings, such as issuing, selling, or production consumption, the direction of impact is decreasing. The mapping relationship between operation type and direction of impact can be pre-configured in the operation type mapping table.

[0129] Fourth, the constraint projection engine determines the impact of each target event based on the difference in quantity before and after the operation and the direction of influence. When the direction of influence is increasing, the impact is a positive difference in quantity before and after the operation (+ΔQ); when the direction of influence is decreasing, the impact is a negative difference in quantity before and after the operation (-ΔQ).

[0130] Fifth, the constraint projection engine accumulates the influence of each target event along the time axis, generating a cumulative mass curve of the event trajectory on the mass conservation constraint dimension. The horizontal axis of the cumulative curve represents time, and the vertical axis represents the cumulative influence. The calculation method for the cumulative curve is as follows: starting from the initial moment (cumulative amount is 0), for each target event encountered, its influence is added to the current cumulative amount, and the cumulative amount value at that moment is recorded. Connecting the cumulative amount values ​​at each moment forms the mass accumulation curve. Each point on the mass accumulation curve is the projected coordinate of the event trajectory on the mass conservation constraint dimension.

[0131] Sixth, the constraint projection engine calculates the quantity conservation imprint value based on the fluctuation of the quantity accumulation curve. Specifically, a reasonable quantity fluctuation range [-ε, +ε] is set, where ε can be set according to the item type and historical data. For each projection point on the accumulation curve, it calculates whether its accumulated value exceeds the fluctuation range. If it is within the range, the imprint value is 0; if it exceeds the range, the imprint value is mapped to between 0 and 1 according to the excess ratio. The imprint value is used as an additional attribute of the projection coordinates of that dimension, or the accumulated value is directly normalized and used as the projection coordinates.

[0132] It should be noted that the specific methods for determining the impact quantity and generating the cumulative curve are not limited to the simple summation method exemplified above. In one example, a time decay factor can be introduced, where the impact of earlier events gradually decreases over time to reflect the timeliness or consumption cycle of the goods. In another example, different conversion coefficients can be set for different types of goods, such as the conversion rate from soybeans to soybean meal, to more accurately reflect the cross-category quantity conservation relationship. Any technical means capable of generating a quantity cumulative curve based on information about changes in the quantity of events falls within the scope of protection of this invention.

[0133] For example, following the previous example, the target event sequence of the bulk commodity trading domain event trajectory (contract CT001) includes: 08:45 soybean purchase and warehousing, with a quantity difference of +500 tons before and after the operation, the direction of influence is increase, and the amount of influence is +500 tons; 11:20 no quantity change event. The cumulative quantity curve of this trajectory jumps to +500 tons at 08:45 and remains unchanged thereafter. The terminal production and sales domain event trajectory (order ORD001) involves pet food production consumption, with the target event being 10:30 production input, with a quantity difference of -50 tons before and after the operation (consumption of soybean meal), the direction of influence is decrease, and the amount of influence is -50 tons. The cumulative curve decreases by 50 tons at 10:30. The cumulative amounts of the two curves correspond to each other within a reasonable conversion rate range, and the imprint value is low.

[0134] In this embodiment, by identifying quantity change events, extracting the quantity difference before and after the operation, determining the direction of influence and calculating the amount of influence, and accumulating along the time axis to generate a material quantity accumulation curve, a precise mapping mechanism for the material quantity conservation constraint dimension is constructed. Thus, based on the constraint space dimension definition implemented in Embodiment 4 above, the specific projection calculation process of the material quantity conservation dimension is further refined independently, solving the problem of how to accurately map the quantity change information of events into a calculable material quantity trajectory, and significantly improving the accuracy and quantifiability of the material quantity conservation dimension projection.

[0135] Example 7: Refinement of DTW for resonance intensity calculation.

[0136] In this embodiment, please refer to Figure 3 , Figure 3This is a schematic diagram of the second sub-process of the data matching and processing method based on cross-domain production and sales provided in an embodiment of the present invention. For example... Figure 3 As shown, in this embodiment, based on the dynamic time warp algorithm for constraint satisfaction, the resonance intensity of the first constraint projection trajectory and the second constraint projection trajectory is calculated, including: S31: Construct a cumulative cost matrix with the length of the first constrained projection trajectory as the number of rows and the length of the second constrained projection trajectory as the number of columns; S32: Define a local distance function, which is used to calculate the composite constraint violation cost between the i-th projection point in the first constraint projection trajectory and the j-th projection point in the second constraint projection trajectory in each constraint dimension; S33: Based on the local distance function and the dynamic programming recursive formula, fill the cumulative cost matrix to obtain the path with the minimum cumulative cost; S34: The cumulative cost value at the end of the minimum cumulative cost path is normalized and then output as the resonance intensity.

[0137] The cumulative cost matrix is ​​a two-dimensional matrix data structure used in the dynamic time warp algorithm to store the minimum cumulative cost from the starting point to any pair of aligned points. The row index i of the cumulative cost matrix corresponds to the i-th projection point of the first constraint projection trajectory P1, and the column index j corresponds to the j-th projection point of the second constraint projection trajectory P2. Matrix element D(i, j) represents the minimum cumulative constraint violation cost when optimally aligning the first i points of P1 with the first j points of P2. The cumulative cost matrix is ​​the core data structure for solving the optimal alignment path in dynamic programming.

[0138] Local distance function: This refers to the function used to calculate the alignment cost between the i-th projection point in P1 and the j-th projection point in P2. In this invention, the local distance function is defined as the weighted sum of constraint violation costs across all constraint dimensions, and its specific form will be detailed in Example 8. The value d(i, j) output by the local distance function represents the "degree of constraint violation" generated when aligning these two projection points; the smaller the value, the more compatible they are in the constraint space.

[0139] Dynamic Programming (DTW) recurrence relation: This refers to the recurrence relation used to calculate the elements of the cumulative cost matrix. The classic DTW recurrence relation is: D(i,j) = d(i,j) + min{D(i-1,j), D(i,j-1), D(i-1,j-1)}. This means that the minimum cumulative cost to reach (i,j) is equal to the local distance d(i,j) of the current alignment point, plus the minimum cumulative cost to reach that point from its three possible predecessor states. The three predecessor states correspond to three alignment operations: up (insertion), left (deletion), and top-left (matching).

[0140] The specific implementation of this embodiment is as follows: First, the server-side resonance calculation engine obtains the first constraint projection trajectory P1 and the second constraint projection trajectory P2. Let the length of P1 be M=|P1|, and the length of P2 be N=|P2|. Construct a cumulative cost matrix D with (M+1) rows and (N+1) columns. To facilitate the handling of boundary conditions, add a 0th row and a 0th column. Initialize D(0,0)=0; for i=1 to M, D(i,0)=∞; for j=1 to N, D(0,j)=∞.

[0141] Secondly, the resonance calculation engine defines a local distance function d(i, j) to calculate the cost of the composite constraint violation between P1[i] and P2[j]. The specific calculation method of the local distance function will be explained in detail in Example 8.

[0142] Third, the resonance calculation engine fills the cumulative cost matrix using a dynamic programming recursive formula in the order of i=1 to M and j=1 to N. The recursive formula is: D(i,j) = d(i,j) + min{ D(i-1,j), D(i,j-1), D(i-1,j-1)}. If Sakoe-Chiba constraints are used to reduce the amount of computation, the search range of j can be limited to [iw, i+w], where w is the window width.

[0143] Fourth, when the matrix is ​​filled, the cumulative cost value at the endpoint, D_min = D(M, N), is the minimum cumulative constraint violation cost of the two constraint projection trajectories under the optimal alignment path.

[0144] Fifth, the resonance calculation engine outputs the resonance intensity R after normalizing D_min. In this embodiment, the transformation formula R = 1 / (1 + D_min) can be used. Since D_min is a non-negative real number, the range of R is (0, 1). When D_min approaches 0, R approaches 1, indicating that the two trajectories are highly resonant and logically consistent; when D_min is large, R approaches 0, indicating that the consistency between the two trajectories is low.

[0145] It should be noted that the dynamic programming recursive formulas described above are not limited to the classic DTW recursive relation exemplified. In one example, weighted DTW can be used, assigning different penalty weights to insertion, deletion, and matching operations; in another example, derivative DTW can be used, first differentiating the sequence before calculating DTW, to better capture trend similarity. Any algorithm capable of solving the minimum cumulative cost path based on the local distance function and dynamic programming falls within the scope of protection of this invention.

[0146] For example, continuing from the previous example, P1 contains 4 points, and P2 contains 2 points. Construct a 5x3 cumulative cost matrix, initializing the boundary to ∞. d(1,1)=0.15, d(1,2)=0.30, d(2,1)=0.22, and so on. Calculate using the recursive formula: D(1,1)=0.15+min(∞,∞,0)=0.15; D(2,1)=0.22+min(D(1,1),∞,∞)=0.37. Finally, D(4,2)=0.35. Calculate R=1 / (1+0.35)=0.74.

[0147] In this embodiment, by constructing a cumulative cost matrix, defining a local distance function, filling the matrix based on a dynamic programming recursive formula, and normalizing the output resonance intensity, a complete algorithm implementation mechanism for calculating the resonance intensity that satisfies the constraints of DTW is constructed. Based on the resonance intensity calculation implemented in Embodiment 1 above, the specific steps and data structure of the algorithm are further refined independently, solving the problem of how to specifically implement "resonance intensity", and significantly improving the feasibility and computational efficiency of resonance intensity calculation.

[0148] Example 8: Refinement of the composite structure of local distance functions.

[0149] In this embodiment, the local distance function is a weighted sum of constraint violation costs across all constraint dimensions; The constraint violation cost for each constraint dimension is calculated using the corresponding constraint function. The output value of the constraint function is a normalized value between 0 and 1, where 0 indicates that the constraint is fully satisfied and 1 indicates that the constraint is seriously violated. The weighting coefficients of the weighted sum are pre-configured according to the importance of each constraint dimension in the multidimensional shared constraint space.

[0150] The specific implementation of this embodiment is as follows: First, when the resonant calculation engine on the server side calculates the local distance function d(i,j), for each constraint dimension k, it calls the constraint function C_k of that dimension to calculate the constraint violation cost c_k between P1[i] and P2[j] in that dimension.

[0151] The definition and calculation method of the constraint function C_k are related to the properties of each constraint dimension. For the time causality constraint dimension, c_time can be defined as the root mean square or the larger value of the time constraint imprint values ​​of P1[i] and P2[j] respectively; for the quantity conservation constraint dimension, c_quantity can be defined as the normalized value of the cumulative difference between the two quantity accumulation curves at the alignment time; for the spatial economic constraint dimension, c_space can be defined as the normalized value of the deviation between the price difference between the two locations and the reasonable price difference range. The output of each constraint function is normalized to between 0 and 1, where 0 indicates that the constraint is fully satisfied and 1 indicates that the constraint is seriously violated.

[0152] Secondly, the resonance calculation engine obtains the preset weight coefficients w_k for each constraint dimension. These weight coefficients reflect the relative importance of each constraint dimension within the shared constraint space and can be pre-configured according to the application scenario. For example, in scenarios emphasizing temporal logic verification, the weight of the temporal causality constraint dimension can be set higher (e.g., 0.5); in scenarios emphasizing material balance verification, the weight of the material conservation constraint dimension can be set higher (e.g., 0.6). The weight coefficients should satisfy the normalization condition Σw_k=1.

[0153] Third, the resonance calculation engine calculates the local distance function d(i,j) = Σ(w_k × c_k). Since c_k∈[0,1] and the sum of w_k is 1, the range of d(i,j) is also [0,1]. The smaller d(i,j) is, the more compatible P1[i] and P2[j] are in each constraint dimension; the larger d(i,j) is, the higher the degree of constraint violation when they are aligned.

[0154] It should be noted that the construction of the aforementioned local distance function is not limited to the simple weighted sum exemplified. In one example, a weighted Euclidean distance can be used, treating c_k of each constraint dimension as spatial coordinates to calculate the weighted Euclidean distance between two points; in another example, a fuzzy logic synthesis operator, such as an AND operator, can be used to take the maximum value of each c_k to reflect the "weakest link effect." Any function form that can synthesize the constraint violation costs across all constraint dimensions and output a normalized composite cost falls within the scope of protection of this invention.

[0155] For example, following the previous example, the weight coefficients of the three constraint dimensions are configured as follows: time causality weight w_t=0.4, quantity conservation weight w_m=0.4, and spatial economic weight w_e=0.2. For the alignment of P1[2] and P2[1], the constraint violation costs of each dimension are calculated as follows: c_t=0.1, c_m=0.2, c_e=0.3. The local distance d(2,1)=0.4×0.1+0.4×0.2+0.2×0.3=0.04+0.08+0.06=0.18.

[0156] In this embodiment, by defining the local distance function as a weighted sum of constraint violation costs across all constraint dimensions and clarifying the output range and weight coefficient configuration of the constraint function, a composite structure refinement mechanism for the local distance function is constructed. Based on the DTW algorithm flow implemented in Embodiment 7 above, the internal structure and parameter configuration of the local distance function are further refined independently, solving the problem of how to integrate the degree of violation of multiple heterogeneous constraint dimensions into a single comparable cost metric. This significantly improves the configurability of resonance intensity calculation and its adaptability to different application scenarios.

[0157] Example 9: Record generation and storage after matching relationship determination.

[0158] In this embodiment, after determining that there is a cross-domain data matching relationship between the terminal production and sales entity corresponding to the first event trajectory and the bulk trade entity corresponding to the second event trajectory, the method further includes: Generate a cross-domain matching record, which includes the globally unique identifier of the terminal production and sales entity, the globally unique identifier of the bulk trade entity, the value of the resonance intensity, and the timestamp of the determination time; The cross-domain matching records are persistently stored in a preset matching relationship database; Establish a data index association between the cross-domain matching record and the first event trajectory and the second event trajectory.

[0159] The specific implementation of this embodiment is as follows: First, after the matching judgment module outputs the judgment result of "a matching relationship exists", the matching record generation module on the server side creates a cross-domain matching record. The cross-domain matching record includes, but is not limited to, the following fields: a globally unique identifier of the terminal production and sales entity, used to uniquely identify the first business domain entity in the matching relationship (such as order number ORD001); a globally unique identifier of the bulk trade entity, used to uniquely identify the second business domain entity in the matching relationship (such as contract number CT001); the numerical value of the resonance intensity, that is, the R value calculated in step S14; and the timestamp of the judgment time, recording the precise time when the matching relationship was judged by the system.

[0160] Secondly, the matching record generation module persistently stores the generated cross-domain matching records in a preset matching relationship database. The matching relationship database can be a relational database (such as MySQL or PostgreSQL) or a document-oriented database (such as MongoDB). The database table structure can be designed to include, but is not limited to, fields such as: auto-incrementing primary key, terminal entity identifier, bulk entity identifier, resonance intensity value, judgment timestamp, and record status.

[0161] Third, the matching record generation module establishes a data index association between the cross-domain matching record and the first and second event trajectories. This can be achieved by storing the storage path or identifier of the corresponding event trajectory (such as TRJ-ORD001 and TRJ-CT001) in the matching record, or through a foreign key association in the event trajectory repository. The establishment of the index association enables subsequent auditing or tracing to quickly locate the original event trajectory data supporting the judgment result from the matching record.

[0162] It should be noted that the storage and indexing methods described above are not limited to the relational database schemes exemplified. In one example, a graph database can be used to store matching relationships, with end-product production and sales entities and bulk trade entities as nodes, matching records as connecting edges, and resonance intensity as the weight attribute of the edges. In another example, a distributed file system can be used to store event trajectories, with only file path references stored in the matching records. Any technical means that can achieve persistent matching records and index association are within the scope of protection of this invention.

[0163] For example, following the previous example, after the server determines that order ORD001 matches contract CT001, it generates a matching record: {"matchId": "M-001", "retailEntity": "ORD001", "commodityEntity": "CT001", "resonanceStrength": 0.74, "timestamp": "2024-10-22T15:30:00Z"}. This record is inserted into the cross_domain_match table of the MySQL database. In the event track repository, an index is created to associate the matching record ID with the tracks TRJ-ORD001 and TRJ-CT001.

[0164] In this embodiment, by generating cross-domain matching records containing entity identifiers, resonance intensity, and judgment timestamps, persistently storing them in a database, and establishing an index association with the event trajectory, a structured recording and traceability mechanism for matching judgment results is constructed. Thus, based on the matching judgment achieved in Embodiment 1 above, the persistent and traceable capabilities of the matching results are further independently realized, solving the problem of how to transform instantaneous matching judgment results into queryable and auditable data assets, and significantly improving the usability and integrability of the cross-domain data matching processing method in actual data governance scenarios.

[0165] Example 10: Audit status marking and data packet encapsulation based on matching records.

[0166] In this embodiment, after generating the cross-domain matching record, the method further includes: Obtain the business status identifiers of the terminal production and sales entity and the bulk commodity trading entity respectively; When all the business status identifiers indicate that the corresponding entity is in a terminated state, the cross-domain matching record is marked as auditable. In response to a data retrieval request from the auditing system, the cross-domain matching records marked as auditable and the associated event trajectory data are encapsulated into an audit data packet and returned.

[0167] The specific implementation of this embodiment is as follows: First, after generating cross-domain matching records, the server-side status monitoring module queries the first and second business systems for the current business status identifiers of the terminal production and sales entity and the bulk commodity trading entity. The business status identifier indicates the stage of the business entity in its lifecycle, such as "in progress," "completed," "closed," or "cancelled." The query can be performed by calling the status query interface provided by each business system.

[0168] Secondly, the status monitoring module determines whether the business status identifiers of the two entities both indicate that the corresponding entities are in a terminated state. A terminated state refers to the final state in which a business entity has completed all its business processes and no new status changes occur. For example, the order status is "completed" or "cancelled," and the contract status is "settled" or "terminated." When both entities are in a terminated state, it indicates that the business activities supporting the matching determination have all been completed, the event trajectory no longer increases, and the matching relationship has stabilized.

[0169] Third, the status monitoring module marks cross-domain matching records that meet the conditions as auditable. This marking can be done by adding an "auditStatus" field to the cross-domain matching record table in the database and updating its value to "AUDITABLE". Marking a record as auditable means that the matching record and its associated data are ready and can be retrieved by external auditing systems.

[0170] Fourth, the server-side data interface module listens for data request requests from the auditing system. These requests may include query conditions such as time range, entity type, and resonance intensity threshold. Based on these conditions, the data interface module retrieves cross-domain matching records marked as auditable from the matching relationship database.

[0171] Fifth, the data interface module reads the associated first and second event trajectory data from the event trajectory repository based on the index association between the matching record and the event trajectory, encapsulates the cross-domain matching record and the two event trajectory data into an audit data packet according to a preset format. The encapsulation format can adopt standard data exchange formats such as JSON or XML, and returns the encapsulated audit data packet to the audit system.

[0172] It should be noted that the above-mentioned audit data encapsulation and return methods are not limited to the synchronous request-response mode exemplified. In one example, an asynchronous message queue approach can be used, whereby the audit data packet is actively pushed to the audit system's message queue when a matching record is marked as auditable. In another example, a download link for the audit data file can be generated, and the audit system obtains the data through the link. Any technical means capable of providing auditable matching records and associated data to the audit system falls within the protection scope of this invention.

[0173] In this embodiment, by acquiring business status identifiers, marking auditable status after determining the termination status, responding to audit requests, and encapsulating and returning audit data packets, an audit readiness status management and data external service mechanism for matching records is constructed. Thus, based on the matching record generation and storage implemented in Embodiment 9 above, the ability to automatically and standardizedly output matching results to the audit system is further realized. This solves the technical problem of how to securely and standardizedly provide internal matching results to external systems to meet risk control and compliance requirements, and significantly enhances the practical value of cross-domain data matching processing methods in enterprise audit and compliance scenarios.

[0174] The data matching and processing methods based on cross-domain production and sales described in the above embodiments can be recombined as needed to obtain combined implementation schemes, but all are within the protection scope claimed by this invention.

[0175] In one embodiment, a computer device is provided, which may be a server, such as a server-side device, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a server-side data matching processing method based on cross-domain production and sales.

[0176] Those skilled in the art will understand that the methods provided in the embodiments of the present invention can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. The methods can also be implemented as a computer program product stored in one or more computer-readable storage media, including but not limited to: disks, optical disks, read-only memory (ROM), random access memory (RAM), flash memory, etc. When the computer program product is executed by one or more data processing devices (such as computers), the devices perform the steps as described in any of the foregoing method embodiments.

[0177] The software tools, components, or models not belonging to our company that appear in the embodiments of this invention are merely illustrative examples and do not represent actual use.

[0178] The data collection in this embodiment of the invention complies with the requirements of relevant laws and regulations, such as the Data Security Law of the People's Republic of China, the Personal Information Protection Law of the People's Republic of China, GDPR (General Data Protection Regulation of the European Union), or information security standards of other countries and regions.

[0179] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A data matching and processing method based on cross-domain production and sales, applied to a server, characterized in that, include: Business operation logs from the first business system and the second business system are collected, and the collected business operation logs are encapsulated into standard events. Based on the source domain identifier carried by each standard event, they are split into a first event stream and a second event stream. The standard event carries a source domain identifier, an operation timestamp, and a status snapshot. The first event stream and the second event stream are aggregated by business entity and arranged in chronological order to construct the first event trajectory and the second event trajectory. The first event trajectory and the second event trajectory are respectively mapped to a predefined multidimensional shared constraint space to generate a first constraint projection trajectory and a second constraint projection trajectory. The dimensions of the multidimensional shared constraint space are constructed based on a general physical or economic constraint function decoupled from business logic. Based on the dynamic time warp algorithm of constraint satisfaction, the resonance intensity of the first constraint projection trajectory and the second constraint projection trajectory is calculated, wherein the resonance intensity characterizes the degree of logical self-consistency of the two trajectories in the multidimensional shared constraint space. When the resonance intensity exceeds a preset threshold, it is determined that there is a cross-domain data matching relationship between the terminal production and sales entity corresponding to the first event trajectory and the bulk trade entity corresponding to the second event trajectory.

2. The data matching and processing method based on cross-regional production and sales as described in claim 1, characterized in that, The collected business operation logs are encapsulated into standard events, including: For each business operation log, extract the operation type, business entity identifier, operation timestamp, and post-operation status information from the business operation log. Generate a globally unique numerical event identifier for the aforementioned business operation log; The source domain identifier, the operation timestamp, the operation type, and the post-operation status information are encapsulated into a status snapshot in key-value pair format. The digital event identifier, the source domain identifier, the operation timestamp, and the state snapshot are combined into the standard event.

3. The data matching and processing method based on cross-regional production and sales as described in claim 1, characterized in that, The first event stream and the second event stream are aggregated by business entity and arranged in chronological order to construct the first event trajectory and the second event trajectory, including: For each event stream, extract the business entity identifier field carried in each standard event; Based on the business entity identifier field, standard events with the same business entity identifier are grouped into the same event group; Within each event group, the events are arranged in ascending order according to the chronological order of the operation timestamps carried by each standard event. The arranged event groups are determined as the event trajectories corresponding to the business entities.

4. The data matching and processing method based on cross-regional production and sales as described in any one of claims 1-3, characterized in that, The multidimensional shared constraint space includes the temporal causal constraint dimension, the material conservation constraint dimension, and the spatial economic constraint dimension. The temporal causal constraint dimension is constructed based on a partial order relation function between event type and operation timestamp; The quantity conservation constraint dimension is constructed based on the quantity logic conservation function of the same or related items during the state transition process; The spatial economic constraint dimension is constructed based on the economic rationality function between the geographical location information associated with the event and the transaction costs.

5. The data matching and processing method based on cross-regional production and sales as described in claim 4, characterized in that, Mapping the first event trajectory and the second event trajectory to a predefined multidimensional shared constraint space, including: For each standard event in the event trajectory to be mapped, extract its event type and operation timestamp; Based on a pre-defined event type partial order rule base, determine the temporal sequence relationship that the event type of the current standard event should satisfy between the event types of its adjacent standard events; Calculate whether the operation timestamp of the current standard event satisfies the time sequence relationship, and quantify the degree of satisfaction as a time constraint imprint value; The time constraint imprint value is recorded as the projected coordinates of the standard event on the time causal constraint dimension.

6. The data matching and processing method based on cross-regional production and sales as described in claim 4, characterized in that, Mapping the first event trajectory and the second event trajectory to a predefined multidimensional shared constraint space, including: For the event trajectory to be mapped, identify the target event sequence involving changes in the quantity of items; Extract the operation type and the difference in quantity before and after the operation from each target event; The direction of the impact of the target event on the total quantity of items is determined based on the operation type, and the direction of impact includes either an increase or a decrease. The impact of each target event is determined based on the difference in quantity before and after the operation and the direction of influence. The influence of each target event is accumulated along the time axis to generate the event trajectory on the mass conservation constraint dimension as a mass accumulation curve, and each point on the mass accumulation curve is used as the projected coordinate of that dimension.

7. The data matching and processing method based on cross-regional production and sales as described in any one of claims 1-3, characterized in that, Based on a dynamic time warp algorithm that satisfies constraints, the resonance intensity of the first constraint projection trajectory and the second constraint projection trajectory is calculated, including: Construct a cumulative cost matrix with the length of the first constrained projection trajectory as the number of rows and the length of the second constrained projection trajectory as the number of columns; Define a local distance function, which is used to calculate the composite constraint violation cost between the i-th projection point in the first constraint projection trajectory and the j-th projection point in the second constraint projection trajectory in each constraint dimension; Based on the local distance function and the dynamic programming recursive formula, the cumulative cost matrix is ​​filled to obtain the path with the minimum cumulative cost. The cumulative cost value at the end of the minimum cumulative cost path is normalized and then output as the resonance intensity.

8. The data matching and processing method based on cross-regional production and sales as described in claim 7, characterized in that, The local distance function is a weighted sum of constraint violation costs across all constraint dimensions; The constraint violation cost for each constraint dimension is calculated using the corresponding constraint function. The output value of the constraint function is a normalized value between 0 and 1, where 0 indicates that the constraint is fully satisfied and 1 indicates that the constraint is seriously violated. The weighting coefficients of the weighted sum are pre-configured according to the importance of each constraint dimension in the multidimensional shared constraint space.

9. The data matching and processing method based on cross-regional production and sales as described in claim 1, characterized in that, After determining that there is a cross-domain data matching relationship between the terminal production and sales entity corresponding to the first event trajectory and the bulk trade entity corresponding to the second event trajectory, the process further includes: Generate a cross-domain matching record, which includes the globally unique identifier of the terminal production and sales entity, the globally unique identifier of the bulk trade entity, the value of the resonance intensity, and the timestamp of the determination time; The cross-domain matching records are persistently stored in a preset matching relationship database; Establish a data index association between the cross-domain matching record and the first event trajectory and the second event trajectory.

10. The data matching and processing method based on cross-regional production and sales as described in claim 9, characterized in that, After generating cross-domain matching records, the following is also included: Obtain the business status identifiers of the terminal production and sales entity and the bulk commodity trading entity respectively; When all the business status identifiers indicate that the corresponding entity is in a terminated state, the cross-domain matching record is marked as auditable. In response to a data retrieval request from the auditing system, the cross-domain matching records marked as auditable and the associated event trajectory data are encapsulated into an audit data packet and returned.

Images