Automatic management method of company internal control data based on smart contract

Abstract

The present invention relates to the technical field of company internal control data management, and discloses a method for automated management of company internal control data based on smart contracts. The method includes: first, collecting and accessing data from multiple source business systems, unifying the transmission protocol, eliminating format conflict data, and repeating verification based on the contract hash value to obtain a standardized data set; then extracting the business operation time, data subject identification, and control rule coding fields, dividing the data into time windows to generate a periodic operation data set; then mapping the original and target operation nodes to the preset authority level to generate a process control path map; finally, classifying and associating business operation behaviors according to rule categories, tracking the triggering frequency of different categories of rules within a specific period of the target node, and generating classification tracking indicators. This method realizes the automated management of the company's internal control data, improves data processing efficiency and internal control management level.

Description

Technical Field

[0001] This invention relates to the field of corporate internal control data management technology, specifically a method for automated management of corporate internal control data based on smart contracts. Background Technology

[0002] In today's digital age, business operations rely on the collaborative work of multiple business systems, such as financial systems, human resources systems, and supply chain management systems, each generating and storing large amounts of business data. The different data transmission protocols used by these systems make data exchange difficult, creating data silos and severely impacting the efficiency of data integration and utilization. For example, a company's financial system might use one transmission protocol while its procurement system uses another. This necessitates complex protocol conversions for data sharing between the two systems, which is not only time-consuming and labor-intensive but also prone to data loss or errors.

[0003] Multi-source data often contains a large amount of conflicting data formats, which significantly reduces the accuracy and reliability of the data. For example, in customer information management, different systems may have different requirements for the format of customer names; some require the full name, while others allow abbreviations. This leads to discrepancies in the information of the same customer across different systems, causing difficulties for enterprise decision analysis. At the same time, data duplication is also a prominent problem. The same data may be stored repeatedly in multiple systems, wasting storage resources and creating redundancy during data processing, affecting the efficiency and accuracy of data processing.

[0004] Traditional internal control data management methods struggle to effectively categorize, correlate, and track business operations. As businesses expand and become more complex, operational processes become increasingly cumbersome, involving a growing number of control rules. Traditional methods cannot accurately categorize business operations based on time, data subject identifiers, and control rules. They also struggle to track the trigger frequency of different rule categories at different points and in different periods, making it difficult for companies to promptly identify potential problems in internal control management and hindering the automation and intelligent management of internal control data.

[0005] In terms of access control, traditional methods lack effective means to map business operation nodes to a unified access level, making it impossible to construct a clear process control path map. This results in enterprises lacking intuitive reference points when allocating permissions and managing processes, making it difficult to ensure the rationality of permission allocation and the smoothness of processes, thus increasing the risks of internal control management. Summary of the Invention

[0006] The purpose of this invention is to provide an automated management method for corporate internal control data based on smart contracts, so as to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides an automated management method for corporate internal control data based on smart contracts, the method comprising:

[0008] Data is collected and accessed from multiple business systems, the data transmission protocols of each system are unified, conflicting data is eliminated, and duplicate verification is performed based on contract hash values ​​to obtain a standardized dataset.

[0009] Based on the standardized dataset, extract the business operation time field, data subject identifier field, and control rule code field for each item;

[0010] Based on the business operation time field, the data in the standardized dataset is divided into time windows to generate a periodic operation dataset;

[0011] Based on the periodic operation dataset and the data subject identifier field, the original operation node and the target operation node are mapped to the preset permission level to generate a process control path map;

[0012] Based on the process control path map, periodic operation dataset, and control rule coding field, business operation behaviors are classified and associated according to rule categories, and the triggering frequency of different categories of rules at target nodes within a specific period is tracked to generate classification tracking indicators for internal control data operations.

[0013] Preferably, data is collected and accessed from multiple business systems, the data transmission protocols of each system are unified, conflicting data is eliminated, and duplicate verification is performed based on contract hash values ​​to obtain a standardized dataset, including:

[0014] Based on the protocol characteristics of the data interface in the multi-source business system, the transmission protocol of the multi-source business system is adapted and converted to obtain the first dataset;

[0015] The duplicate fields in the first dataset are identified for format conflicts. Fields with high source credibility are retained, and fields with content conflicts are removed to obtain the second dataset.

[0016] Based on the contract hash value information corresponding to each data record in the second dataset, combined with the data subject identifier field, approximately duplicate records are identified, and redundant items are removed to obtain a standardized dataset.

[0017] Preferably, based on the periodic operation dataset and the data subject identifier field, the original operation node and the target operation node are mapped to a preset permission level to generate a flow control path graph, including:

[0018] Based on the data subject identifier field, information on the original business operation nodes and target operation nodes is extracted from the standardized dataset, and unstructured operation descriptions are converted into structured node identifiers to form a set of node identifiers;

[0019] Based on the data subject identifier field in the periodic operation dataset, the business operation records in each period are matched with the node identifier set to generate a periodic node mapping dataset, which carries both time and process information.

[0020] Based on the periodic node mapping dataset, each group of node identifiers is mapped to a unified preset permission level, and a business operation path sequence is constructed in this way to form a process path dataset.

[0021] A directed association graph is constructed based on the process path dataset, where nodes represent permission levels and edges represent operation directions and number of operations, thus generating a process control path graph.

[0022] Preferably, based on the process control path map, periodic operation dataset, and control rule coding field, business operation behaviors are classified and associated according to rule categories, and the triggering frequency of different rule categories at target nodes within a specific period is tracked to generate classification tracking indicators for internal control data operations, including:

[0023] Based on the control rule encoding field, the business operation records in the periodic operation dataset are divided into multiple rule operation subsets according to categories. Combined with the original nodes and target nodes recorded in the process control path graph, a set of operation record pairs divided by category and node is generated.

[0024] Based on the operation records, for each rule operation subset, the number of triggers and non-triggers within each target node are aggregated and statistically analyzed to construct a three-dimensional data table with a rule-node-cycle structure. Based on this data table, the trigger frequency of each category within different cycles at each node is calculated using a trigger frequency statistical method to form a trigger frequency sequence.

[0025] Based on the data differences in consecutive periods in the trigger frequency sequence, the periodic change is calculated, and a time series-based indicator stability calculation method is used to obtain the classification tracking indicators of internal control data operations under each category and node dimension.

[0026] Preferably, based on the protocol characteristics of the data interface in the multi-source service system, the transmission protocol of the multi-source service system is adapted and converted to obtain the first dataset, including:

[0027] Extract all data interfaces from the multi-source business system to form an interface set;

[0028] Based on the interface set and the pre-set protocol comparison table, determine whether there are interfaces with the same function but different protocols in different systems, and determine the recommended standard transmission protocol to form a standard protocol recommendation set;

[0029] Based on the recommended set of standard protocols, for transmission protocols that are determined to be functionally consistent, the transmission protocols of the multi-source business system are replaced with the corresponding standard transmission protocols by the protocol replacement method, thereby generating a set of standard protocols.

[0030] Arrange the standard protocol set according to the order set in the standard interface template to generate the first dataset.

[0031] Preferably, the duplicate field content in the first dataset is subjected to format conflict identification, and the field data with high source credibility is retained, while the content conflict fields are removed to obtain the second dataset, which includes:

[0032] Based on the field source information in the first dataset, the original system of each field is extracted, and field source priority is assigned based on the preset system credibility level to form field priority data;

[0033] Based on the field priority data, a conflict comparison is performed on fields in the first dataset that have the same function but conflicting sources. Fields with higher priority are retained, while fields with lower priority or inconsistent content are removed, generating conflict cleanup result data.

[0034] The conflict resolution results are used as output to obtain the second dataset.

[0035] Preferably, based on the contract hash value information corresponding to each data record in the second dataset, combined with the data subject identifier field, approximately duplicate records are identified, and redundant items are removed to obtain a standardized dataset, including:

[0036] Extract the contract hash value field and the data subject identifier field from the second dataset, and combine them into a unique identification key to generate record index data;

[0037] Based on the record index data and a preset hash difference tolerance threshold, it is determined whether the data record meets the duplication condition, wherein the hash difference of the duplication condition is within the preset hash difference tolerance threshold and the data subject identifier is consistent.

[0038] For data records that meet the duplication condition, retain the best record in the second dataset based on data integrity, delete the remaining records, and output a standardized dataset.

[0039] Preferably, based on the periodic node mapping dataset, each group of node identifiers is mapped to a unified preset permission level, and a business operation path sequence is constructed accordingly to form a process path dataset, including:

[0040] Based on the original node and target node identifiers contained in each business operation record in the periodic node mapping dataset, they are converted from the original permission level to process points under a unified preset permission level, forming a standardized set of node pairs.

[0041] Based on the principle of process discretization using hierarchical coding, each pair of identifiers in the standardized node pair set is encoded, and the node value is converted into an indexable hierarchical code of permissions.

[0042] Based on the data subject identifier field and the time period field, the operation direction of each business within a specific period is represented as a path sequence from the start code to the end code. The number of operations and rule category attribute information are attached to each path sequence to construct an attributed business operation path dataset.

[0043] All business operation path sequences are organized by period to generate a process path dataset with time hierarchy.

[0044] Preferably, a directed association graph is constructed based on the process path dataset, where nodes represent permission levels and edges represent operation directions and operation counts, generating a process control path graph, including:

[0045] Based on the start-point and end-point hierarchical codes carried by each operation path sequence in the process path dataset, they are assigned to standard permission groups as node identifiers in the graph, forming a permission node set.

[0046] For multiple path sequences belonging to the same time period and having the same start and end permissions, merge them and calculate the total number of operations for that path, which is then used as the edge weight of that path in the graph.

[0047] Using the set of permission nodes as nodes in the graph, and the start and end permission pairs after path aggregation as directed edges in the graph, we construct directed connections between nodes and use the total number of operations as the weighted value of the edges to form a weighted directed graph structure.

[0048] The directed association graph is output in graph form as a flow control path graph.

[0049] Preferably, a trigger frequency statistical method is used to calculate the trigger frequency of each category at each node within different periods, forming a trigger frequency sequence, including:

[0050] Based on the data table with a three-dimensional structure of rules-nodes-cycles, the number of times each category of rules is triggered and the number of times it is not triggered are extracted for each target node in each time cycle, and these are used as the measurement values ​​of the operation behavior of the rule of that category for that node in that cycle.

[0051] For each target node, extract its corresponding operation frequency threshold or rule coverage range as the benchmark parameter for frequency normalization.

[0052] Divide the measurement value of each category of operation behavior by the corresponding baseline parameter to obtain the normalized trigger frequency of each category at each target node and each time period.

[0053] The normalized trigger frequencies are arranged sequentially according to the time period to form a trigger frequency sequence.

[0054] Compared with the prior art, the beneficial effects of the present invention are:

[0055] The intelligent contract-based automated management method for corporate internal control data proposed in this invention demonstrates significant advantages in data acquisition and processing from multiple business systems. By integrating data from these systems and unifying their data transmission protocols, it effectively solves the problem of inconsistent data transmission protocols between different systems, breaking down data silos and enabling smooth data flow and integration. In this process, eliminating conflicting data and performing duplicate verification based on contract hash values ​​improves data accuracy and reliability, providing a high-quality data foundation for subsequent data processing and analysis. For example, when processing data from financial and procurement systems, unified protocols significantly improve data transmission efficiency, eliminating conflicting data enhances accuracy, and deleting duplicate data saves substantial storage resources.

[0056] In the data processing stage, business operation time fields, data subject identifier fields, and control rule code fields are extracted from standardized datasets. Then, operations such as time window segmentation, node mapping, and graph generation are performed to achieve a comprehensive overview and visualization of business operation processes. By mapping original operation nodes and target operation nodes to preset permission levels, a process control path graph is generated. This allows enterprises to clearly understand the permission levels and process flow of business operations, providing an intuitive basis for permission management and process optimization. For example, through the process control path graph, enterprises can intuitively see the permission allocation of each node in a business process, promptly identify and adjust any unreasonable permission allocations.

[0057] In terms of business operation behavior analysis, based on process control path maps, periodic operation datasets, and control rule coding fields, business operation behaviors are categorized and correlated. The trigger frequency of different rule categories at target nodes within specific periods is tracked, generating classification and tracking indicators for internal control data operations. This helps enterprises gain a deeper understanding of the patterns and characteristics of business operation behaviors and promptly identify potential problems in internal control management. By analyzing trigger frequency sequences, enterprises can grasp the execution status of different rule categories at different nodes and periods, providing strong data support for internal control decision-making. For example, by analyzing trigger frequency sequences, enterprises can identify abnormal trigger frequencies of a certain control rule at specific nodes and periods, allowing for timely improvement measures and reducing internal control risks.

[0058] In the specific steps of data processing, the adaptation and conversion of transmission protocols from multiple business systems, the handling of data with format conflicts, and the identification and deletion of duplicate data are all closely linked, jointly ensuring data quality. Protocol adaptation and conversion ensure smooth data transmission, format conflict handling guarantees data accuracy, and duplicate data deletion improves data uniqueness and storage efficiency. In the node mapping and graph generation process, from extracting node information to constructing the directed association graph, each step is strictly carried out according to preset rules and methods, ensuring the accuracy and reliability of the process control path graph. In the generation of classification and tracking indicators, by dividing the rule operation subset, statistically analyzing the number of triggers, and calculating the trigger frequency, the characteristics and patterns of business operation behavior are comprehensively and accurately reflected. Attached Figure Description

[0059] Figure 1 This is a schematic diagram illustrating the working principle of the automated management method for company internal control data based on smart contracts described in this invention.

[0060] Figure 2 The flowchart generated for the process control path graph;

[0061] Figure 3 A flowchart for generating categorized tracking metrics;

[0062] Figure 4 A flowchart generated for the first dataset;

[0063] Figure 5 A flowchart generated for the process path dataset. Detailed Implementation

[0064] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. 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.

[0065] See also Figures 1-5 This invention provides an automated management method for company internal control data based on smart contracts, and the specific implementation steps are as follows:

[0066] Data is collected and accessed from multiple business systems, the data transmission protocols of each system are unified, conflicting data is eliminated, and duplicate verification is performed based on contract hash values ​​to obtain a standardized dataset.

[0067] Based on the standardized dataset, extract the business operation time field, data subject identifier field, and control rule code field for each record.

[0068] Based on the business operation time field, the data in the standardized dataset is divided into time windows to generate a periodic operation dataset.

[0069] Based on the periodic operation dataset and the data subject identifier field, the original operation node and the target operation node are mapped to the preset permission level to generate a process control path graph.

[0070] Based on the process control path map, periodic operation dataset, and control rule coding field, business operation behaviors are classified and associated according to rule categories, and the triggering frequency of different categories of rules at target nodes within a specific period is tracked to generate classification tracking indicators for internal control data operations.

[0071] Example 1: In this example, the implementation method for collecting and accessing data from multiple business systems, unifying the transmission protocol, eliminating conflicting data, and performing duplicate verification based on contract hash values ​​to obtain a standardized dataset is as follows:

[0072] Extract all data interfaces from the multi-source business systems to form an interface set. These multi-source business systems encompass various business systems within the company, covering different departments and functions, such as the financial system, human resources system, and supply chain management system. Each system has its own data interfaces. The interface set contains information about all interfaces from these systems that can be used for data collection, such as the interface name, function description, and data transmission format.

[0073] Based on the interface set and a pre-defined protocol lookup table, it is determined whether there are interfaces with the same function but different protocols in different systems, and the recommended standard transmission protocol is determined, forming a standard protocol recommendation set. The pre-defined protocol lookup table stores the protocol characteristics of each interface and its corresponding standard transmission protocol. For example, for an interface that implements customer information query functionality, the financial system may use the HTTP protocol, while the supply chain management system may use the FTP protocol. The protocol lookup table will clearly state that the standard transmission protocol corresponding to this function is the HTTP protocol. By comparing each interface in the interface set with the protocol lookup table, interfaces with the same function but different protocols are identified, and a recommended standard transmission protocol is determined for each such interface, thus forming the standard protocol recommendation set.

[0074] Based on the recommended set of standard protocols, for transport protocols deemed functionally identical, a protocol replacement method is used to replace the transport protocols of multi-source business systems with the corresponding standard transport protocols, generating a standard protocol set. During the protocol replacement process, specific configuration and adjustments are required for each interface whose protocol needs to be replaced. For example, for a customer information query interface that originally used the FTP protocol, its configuration parameters need to be modified to use the HTTP protocol for data transmission. Simultaneously, it must be ensured that the interface functions correctly after the protocol replacement, and that the accuracy and integrity of data transmission are not affected. After completing the protocol replacement for all functionally identical interfaces, a standard protocol set is generated, in which each interface adopts a unified standard transport protocol.

[0075] Next, the standard protocol set is arranged according to the order defined in the standard interface template to generate the first dataset. The standard interface template specifies the order and format requirements for the interfaces in the dataset. For example, the template may require arranging basic information interfaces first, followed by business operation interfaces, with each interface's information arranged sequentially according to fields such as interface name, function description, and standard transmission protocol. Arranging the interfaces in the standard protocol set according to the template requirements forms an ordered first dataset for subsequent data processing and analysis.

[0076] Based on the source information of the fields in the first dataset, the original system of each field is extracted, and field source priorities are assigned according to a preset system credibility level, forming field priority data. The preset system credibility level is determined in advance based on factors such as the importance of each business system in the company, the accuracy and reliability of the data, etc. For example, the credibility level of core business systems such as the financial system is set to high, while the credibility level of some auxiliary business systems is set to medium or low. For each field in the first dataset, its original system is determined through its source information, and then a priority is assigned to the field according to the system's credibility level, forming field priority data, which records the priority information of each field.

[0077] Based on field priority data, conflict comparisons are performed on fields in the first dataset that have the same function but conflicting sources. Fields with higher priority are retained, while those with lower priority or inconsistent content are removed, generating conflict-resolved data. In the first dataset, there may be fields with the same function provided by different systems, but these fields may have conflicting data, such as different values ​​or inconsistent descriptions. By comparing these conflicting fields using field priority data, field data from systems with higher credibility levels is retained first, while field values ​​with lower priority or inconsistent content with higher priority fields are removed. For example, for the customer balance field, the financial system provides a value of 10,000 yuan, while the auxiliary system provides a value of 8,000 yuan. Because the financial system has a higher credibility level, the field data from the financial system is retained, and the field value from the auxiliary system is removed. After processing all conflicting fields, conflict-resolved data is generated.

[0078] The conflict-clearing results are used as output to obtain the second dataset. The second dataset is obtained by clearing field conflicts based on the first dataset. The data in fields with consistent functionality are more accurate and consistent, reducing data inconsistencies and conflicts, and providing a better foundation for subsequent data processing.

[0079] The contract hash value field and the data subject identifier field are extracted from the second dataset and combined into a unique identification key to generate record index data. The contract hash value is a unique hash value used in a smart contract to identify a data record, and the data subject identifier field identifies the data subject, such as customer number or employee number. Combining these two fields forms a unique identification key for each data record. This key allows for accurate identification and location of each data record, generating record index data for subsequent duplicate record identification.

[0080] Based on the record index data and a preset hash difference tolerance threshold, it is determined whether the data records meet the duplication condition. This duplication condition is that the hash difference is within the preset hash difference tolerance threshold and the data subject identifier is consistent. The preset hash difference tolerance threshold is a threshold pre-set according to the actual application scenario and data characteristics, used to determine whether the hash values ​​of two contracts are approximately duplicated. For example, if the hash difference tolerance threshold is set to 5%, when the difference between the contract hash values ​​of two data records is within 5% and the data subject identifier is consistent, these two records are considered to be approximately duplicated.

[0081] For data records that meet the duplicate criteria, the best record in the second dataset is retained based on data integrity, while the remaining records are deleted, resulting in a standardized dataset. After identifying nearly duplicate records, the record with the highest data integrity is selected as the best record to retain. Data integrity can be determined based on the fill status of each field in the record; for example, records with fewer missing fields have higher integrity. The remaining redundant records are deleted, and the final standardized dataset is output. This dataset has undergone a series of processes, including data collection, protocol standardization, format conflict removal, and duplicate record verification, resulting in significantly improved data quality and providing a reliable data foundation for subsequent automated management of internal control data within the company.

[0082] Example 2: In this example, the implementation method for mapping the original operation node and the target operation node to a preset permission level based on the periodic operation dataset and the data subject identifier field to generate a flow control path graph is as follows:

[0083] Based on the data subject identifier field, information on the original and target operation nodes of the business is extracted from the standardized dataset. Unstructured operation descriptions are then converted into structured node identifiers, forming a node identifier set. The standardized dataset stores various types of pre-processed business data. The data subject identifier field is used to distinguish different data subjects, such as specific departments, positions, or users. Information on the original and target operation nodes corresponding to each business operation is extracted from the data. This information may exist in unstructured forms such as natural language descriptions, for example, "Zhang San from the Finance Department submits a reimbursement application" or "General Manager Li Si approves the reimbursement application." These unstructured descriptions need to be converted into structured node identifiers. For example, "DEPT001_OPR001" represents the operation node where the Finance Department submits a reimbursement application, and "MAN001_APP001" represents the target node where the General Manager approves. This conversion forms a node identifier set containing the structured node information for all business operations.

[0084] Based on the data subject identifier field in the periodic operation dataset, business operation records within each period are matched with the node identifier set to generate a periodic node mapping dataset. This dataset carries both time and process information. The periodic operation dataset is generated by dividing the time window, such as by day, week, or month. For each business operation record within a period, the data subject identifier field is matched with nodes in the node identifier set to determine the original operation node and target operation node identifier corresponding to each operation record. For example, if the subject of an operation record is Zhang San from the finance department and the corresponding operation is submitting an expense reimbursement application, the matching finds the corresponding node "DEPT001_OPR001" in the node identifier set. After matching, the operation records of each period are associated with the corresponding node identifiers to generate a periodic node mapping dataset carrying both time (e.g., the first week of July 2025) and process (node ​​identifier) ​​information. This dataset clearly records the node mapping of each business operation within each period.

[0085] Based on the periodic node mapping dataset, each set of node identifiers is mapped to a unified preset permission level, and a business operation path sequence is constructed accordingly, forming a process path dataset. Specifically, based on the original node and target node identifiers contained in each business operation record in the periodic node mapping dataset, they are first converted from their original permission levels to process points under a unified preset permission level, forming a standardized set of node pairs. The preset permission level is a predefined unified permission system, such as being divided into basic operation level, department management level, and company decision-making level. Original nodes and target nodes may belong to different original permission levels, and they need to be converted to a unified preset permission level. For example, the original node "DEPT001_OPR001" belongs to the basic operation level, and the target node "MAN001_APP001" belongs to the company decision-making level. After conversion, they correspond to the "L1" and "L3" points in the preset permission level, respectively, forming a standardized node pair (L1, L3).

[0086] Based on the principle of hierarchical coding for process discretization, each pair of identifiers in the standardized node pair set is encoded, converting the node values ​​into indexable hierarchical permission codes. The hierarchical coding principle assigns a unique code to each level in the preset permission hierarchy; for example, the basic operational level is coded as "01", the department management level as "02", and the company decision-making level as "03". Each node in the standardized node pair is encoded, such as the node pair (L1, L3) above being encoded as (01, 03), to facilitate subsequent indexing and processing.

[0087] Based on the data subject identifier field and the time period field, the operation direction of each business within a specific period is represented as a path sequence from the starting point code to the ending point code. Operation count and rule category attribute information are appended to each path sequence to construct an attributed business operation path dataset. For example, if a business's operation in the first week of July 2025 is from the grassroots operation level (01) to the company decision-making level (03), with 5 operations and the rule category being financial approval, then this path sequence is represented as "01→03," with the appended attribute information such as 5 operations and the rule category "financial approval." The operation path sequences and attribute information of all businesses within each period are collected to form an attributed business operation path dataset.

[0088] All business operation path sequences are organized by period to generate a time-level process path dataset. The business operation path sequences within each period are organized and stored in chronological order, for example, first by year, then by month, and finally by week, forming a time-level process path dataset for easy subsequent querying and analysis by time dimension.

[0089] A directed association graph is constructed based on the process path dataset. Nodes represent permission levels, and edges represent operation directions and operation counts, generating a process control path graph. Specifically, based on the start-point and end-point level codes carried by each operation path sequence in the process path dataset, each sequence is assigned to a standard permission group, which serves as a node identifier in the graph, forming a set of permission nodes. The standard permission groups correspond to various levels of a preset permission hierarchy. For example, code "01" is assigned to a basic operation level node, and "03" is assigned to a company decision-making level node. These nodes constitute the set of permission nodes.

[0090] Multiple path sequences belonging to the same time period and having the same starting and ending permissions are merged. The total number of operations for each path is calculated and used as the edge weight in the graph. For example, in the first week of July 2025, there are 3 path sequences from the basic operation layer (01) to the company decision-making layer (03), with 2, 1, and 2 operations respectively. After merging, the total number of operations is 5, and this total is used as the edge weight.

[0091] Using the set of permission nodes as nodes in the graph, and the start and end permission pairs after path aggregation as directed edges, a directed connection relationship between nodes is constructed, and the total number of operations is used as the weight value of the edges to form a weighted directed graph structure. For example, there is a directed edge between the basic operation layer (01) and the company decision-making layer (03), with the direction from 01 to 03 and the weight of the edge being 5, indicating that there are 5 operations from the basic operation layer to the company decision-making layer in this period.

[0092] The directed relationship graph is output as a graph format, serving as a process control path graph. The graph can be displayed using visualization tools, with nodes using different shapes or colors to represent different permission levels, edges using arrows to indicate the direction of operation, and edge thickness or labeled values ​​indicating the number of operations. This intuitively presents the flow and frequency of business operations between different permission levels, providing a clear process control reference for the automated management of the company's internal control data.

[0093] Example 3: In this example, the implementation method for classifying and associating business operation behaviors according to rule categories based on the process control path map, periodic operation dataset, and control rule encoding field, and tracking the triggering frequency of different rule categories at the target node within a specific period to generate classification tracking indicators for internal control data operations is as follows:

[0094] Based on the control rule encoding field, the business operation records in the periodic operation dataset are divided into multiple rule operation subsets according to categories. Combined with the original and target nodes recorded in the process control path graph, a set of operation record pairs divided by category and node is generated. The periodic operation dataset stores business operation records divided by time windows. Each record contains a control rule encoding field, which identifies the control rule category corresponding to the operation, such as financial approval rules, data access rules, etc. Using the control rule encoding field, all operation records are grouped according to rule categories. For example, all records belonging to financial approval rules are grouped into one subset, and those belonging to data access rules are grouped into another subset, thus forming multiple rule operation subsets. Simultaneously, the process control path graph records the original and target node information for each business operation. This node information is associated with the rule operation subsets to determine the corresponding original and target nodes for each operation record, thereby generating a set of operation record pairs divided by category and node. Each element in this set contains the rule category, original node, target node, and corresponding operation record information.

[0095] Based on the operation records, for each subset of rule operations, the number of triggers and non-triggers within each target node are aggregated and statistically analyzed to construct a three-dimensional data table with a rule-node-cycle structure. Based on this data table, a trigger frequency statistical method is used to calculate the trigger frequency of each category within different cycles at each node, forming a trigger frequency sequence. Specifically, for each subset of rule operations, all operation records are traversed, and for each target node, the number of triggers and non-triggers of that rule at that node within a specific cycle is statistically analyzed. For example, for the financial approval rule subset, within the target node "General Manager Approval Node" and the cycle "Week 1 of July 2025," the number of triggers is 5, and the number of non-triggers is 3. These statistical results are organized according to three dimensions: rule category, target node, and time cycle, constructing a three-dimensional data table with a rule-node-cycle structure. Each cell in this table corresponds to a rule category, a target node, and a time cycle, storing the number of triggers and non-triggers of that rule at that node and within that cycle.

[0096] Based on this data table, a trigger frequency statistical method is used to calculate the trigger frequency of each category at each node within different periods, forming a trigger frequency sequence. The specific steps are as follows: Based on the rule-node-period three-dimensional data table, extract the number of triggers and non-triggers for each target node for each rule category in each time period, and use these as the measurement values ​​of the operational behavior of that rule category at that node in that period. Let the number of triggers be... The number of times it was not triggered is ,in This indicates the number of times a rule is triggered within a specific rule category, target node, and time period. This indicates the number of times the rule was not triggered under the same conditions.

[0097] For each target node, extract its corresponding operation frequency threshold or rule coverage range as a baseline parameter for frequency normalization. Let the baseline parameter be... , It can be the operation frequency threshold of the target node that is pre-set according to business needs, or it can be the theoretical value of the rule coverage of the corresponding node. For example, the operation frequency threshold of the target node "General Manager Approval Node" is 10 times per week.

[0098] Divide the metric value of each category of operational behavior by the corresponding baseline parameter to obtain the normalized trigger frequency for each category at each target node and each time period. The formula for calculating the normalized trigger frequency is:

[0099]

[0100] in, Indicates the normalized trigger frequency. This represents the actual triggering frequency of the rule at this node and in this cycle, divided by the baseline parameter. The normalized result is then obtained. For example, a certain rule is triggered 5 times at the target node "General Manager Approval Node" and the period "Week 1 of July 2025", and is not triggered 3 times, with the baseline parameter... If the value is 0.5, then the actual triggering frequency is The normalized trigger frequency is .

[0101] The normalized trigger frequencies are arranged sequentially according to the time period to form a trigger frequency sequence. For example, for the financial approval rule at the "General Manager Approval Node", the normalized trigger frequency sequence arranged by week is 1.25 (week 1), 1.10 (week 2), 0.95 (week 3), etc. This sequence reflects the trigger frequency of the rule at this node as time changes.

[0102] Based on the data differences across consecutive periods in the trigger frequency sequence, the periodic variation is calculated, and a time-series-based indicator stability calculation method is used to obtain a classification tracking indicator for internal control data operations across various categories and nodes. For each time point in the trigger frequency sequence, the difference between the current period and the normalized trigger frequency of the previous period is calculated, which is the periodic variation. For example, the variation between week 2 and week 1 is 1.10 - 1.25 = -0.15. By analyzing these periodic variations, time-series analysis methods, such as moving averages and exponential smoothing, are used to calculate the stability of the indicator, thus obtaining the classification tracking indicator. This indicator is used to measure the stability and regularity of operational behavior under different rule categories at each target node, providing a quantitative tracking basis for the automated management of the company's internal control data.

[0103] Example 4: In this example, the implementation method for processing the protocol characteristics of the data interface in a multi-source business system to obtain the first dataset is described in detail below with specific examples:

[0104] Suppose a company has three main business systems: a financial system, a human resources system, and a supply chain management system. The company needs to process the data interfaces of these systems using protocols. Extract all data interfaces from these multiple business systems to form an interface set. For example, the financial system has interface A for querying customer account information and interface B for exporting transaction records; the human resources system has interface C for querying employee information and interface D for uploading attendance data; the supply chain management system includes interface E for supplier information management and interface F for querying inventory status. Summarize the names, function descriptions, and current transmission protocols used by these interfaces to form an interface set containing interfaces A, B, C, D, E, and F. Interface A currently uses the HTTP protocol, interface C uses the FTP protocol, and interface E uses the SOAP protocol, etc.

[0105] Based on the interface set and a pre-defined protocol lookup table, it is determined whether there are interfaces with the same function but different protocols in different systems, and the recommended standard transmission protocol is determined, forming a standard protocol recommendation set. The pre-defined protocol lookup table specifies the standard transmission protocol for interfaces with different functions. Taking the customer information query function as an example, the lookup table clearly states that the standard protocol for this function is HTTP. In the interface set, interface A of the financial system is a customer account information query interface, using the HTTP protocol; the supply chain management system may have an interface E1 (assumed to be a sub-function of interface E in the example), whose function is also customer information query, but uses the SOAP protocol. In this case, by comparing with the protocol lookup table, it is determined that interface A and interface E1 have the same function but different protocols. According to the lookup table, the recommended standard transmission protocol is HTTP, and this determination result and the recommended protocol are recorded to form the standard protocol recommendation set. Similarly, if interface C (employee information query) of the human resources system uses the FTP protocol, and the standard protocol for the employee information query function in the lookup table is HTTP, then interface C will also be included in the standard protocol recommendation set, and the recommended protocol is HTTP.

[0106] Based on the recommended set of standard protocols, for transport protocols deemed functionally consistent, a protocol replacement method is used to replace the transport protocols of multi-source business systems with the corresponding standard transport protocols, generating a standard protocol set. Taking interface E1 as an example, it originally used the SOAP protocol and now needs to be replaced with the HTTP protocol. During the replacement process, the code configuration of interface E1 needs to be adjusted, modifying the request format and response processing method of data transmission to conform to the HTTP protocol specification. For example, the original SOAP request based on XML messages is converted to an HTTP GET or POST request, and the URL path and parameter passing method of the interface are adjusted to ensure that the interface can correctly receive and send data after the replacement. For interface C, when replacing the FTP protocol with the HTTP protocol, the data transmission method needs to be changed from file transfer mode to HTTP-based data interaction mode, and the interface access method and data format need to be redesigned. After completing the protocol replacement of all functionally consistent interfaces, a standard protocol set is obtained. Interfaces A, E1, and C all use the HTTP protocol, while interfaces B, D, and F may correspond to different standard protocols depending on their functions. For example, interface B (transaction record export) may be recommended to use the FTP protocol, and after replacement, it should be configured according to the standard protocol.

[0107] Next, the standard protocol set is arranged according to the order defined in the standard interface template to generate the first dataset. The standard interface template specifies the order in which the interfaces are arranged; for example, customer-related interfaces are arranged first, followed by internal management interfaces, and finally transaction interfaces. Assume the order of the standard interface template is customer information interfaces, employee information interfaces, transaction record interfaces, inventory management interfaces, etc. In the standard protocol set, interfaces A and E1 belong to the customer information interface category, interface C belongs to the employee information interface category, interface B belongs to the transaction record interface category, and interface F belongs to the inventory management interface category. Following the template order, interfaces A and E1 are arranged first, followed by interface C, then interface B, and finally interface F. The information for each interface in the dataset is arranged sequentially according to fields such as interface name, function description, standard transmission protocol, and interface parameters. For example, the information for interface A is: interface name "Customer Account Information Query", function description "Query customer account balance and transaction details", standard transmission protocol "HTTP", and interface parameters "Customer ID, Query Time Range", etc. Arrange all interfaces in this format and order to form a structured first dataset. The interface protocols within this dataset are unified and arranged in an orderly manner, which facilitates subsequent data processing.

[0108] During processing, you may encounter situations where multiple interfaces have the same function but are distributed across different systems. For example, both the financial system and the supply chain management system have customer information update interfaces, each using different protocols. In this case, after determining the standard protocol using a protocol comparison table, both interfaces are replaced with the correct protocol to ensure they use the same standard protocol. This allows for unified processing during data collection and avoids data transmission obstacles caused by protocol differences. As another example, the attendance data upload interface D in the human resources system originally used the SFTP protocol, while the standard protocol for this function in the template is HTTPS. Therefore, interface D is replaced with the HTTPS protocol to ensure the security and standardization of data transmission.

[0109] Through these steps—starting with extracting the interface set, comparing and replacing protocols, and then arranging them according to templates—the first dataset is finally generated. This process ensures the uniformity and standardization of the data interfaces of multi-source business systems in terms of transmission protocols, providing a standardized foundation for subsequent data collection and processing. This enables smoother data interaction and integration between different systems, facilitating the company's automated management of internal control data.

[0110] Example 5: In this example, the implementation method for identifying format conflicts in duplicate fields of the first dataset to obtain the second dataset is as follows:

[0111] Assume the first dataset contains field data from the finance system, human resources system, and supply chain management system. Based on the field source information in the first dataset, extract the original system for each field and assign field source priorities based on a preset system credibility level, forming field priority data. For example, the finance system, as a core business system, has a preset credibility level of high; the human resources system, as an important business system, has a medium credibility level; and the supply chain management system, as an auxiliary business system, has a low credibility level. For the "Employee Salary" field, if its source information shows it comes from the finance system, it is assigned a high priority; the "Employee Name" field comes from the human resources system, and is assigned a medium priority; the "Supplier Contact Person" field comes from the supply chain management system, and is assigned a low priority. Record the original system and corresponding priority of all fields to form field priority data, which clearly defines the priority order of each field.

[0112] Based on field priority data, fields in the first dataset that have the same function but conflicting sources are compared for conflict resolution. Fields with higher priority are retained, while those with lower priority or inconsistent content are removed, generating conflict-cleared data. For example, the first dataset contains a "Employee Onboarding Date" field from both the finance and human resources systems. The value of this field in the finance system is "2023-05-10," while in the human resources system it is "2023-06-10." These two fields have the same function but conflicting sources and inconsistent content. Based on field priority data, the finance system's priority is higher than the human resources system's; therefore, the "2023-05-10" from the finance system is retained, and the "2023-06-10" from the human resources system is removed. Similarly, the "Customer Credit Limit" field has a value of "50,000 yuan" from both the finance and supply chain management systems. Although the sources are different, the content is the same. In this case, because the finance system has higher priority, the field value from the finance system is retained, and the field value from the supply chain management system is removed. For the "Employee Department" field, the value from the Human Resources system is "Technology Department" and the value from the Supply Chain Management System is "Marketing Department". The content is conflicting and the Human Resources system has a higher priority, so "Technology Department" is retained and "Marketing Department" is removed.

[0113] When performing conflict comparisons, the source and content of each functionally consistent field must be compared in detail. For fields with different sources but the same content, even if their priorities differ, only the field value from the higher-priority system is retained to ensure data consistency and authority. For fields with the same source but different content, the original data needs further verification; here, only preset priority rules are applied. For example, if a field comes from two sub-modules of the financial system and a content conflict occurs, it can be considered a conflict within the same system and needs to be handled through other rules. However, in this embodiment, only field conflicts between different systems are handled.

[0114] After processing all fields with consistent functionality but conflicting sources, conflict resolution result data is generated. In this data, only the highest priority and accurate field values ​​are retained for each functionally consistent field, while low priority or inconsistent field values ​​are removed, effectively resolving field conflict issues and improving data accuracy and consistency.

[0115] The conflict resolution results are used as output to obtain the second dataset. The fields in the second dataset have undergone conflict identification and resolution, ensuring clear field origins, explicit priorities, and accurate and consistent content. For example, the "Employee Salary" field retains only high-priority data from the financial system, the "Employee Start Date" field retains the correct value from the financial system, the "Customer Credit Limit" field uses data from the financial system, and the "Employee Department" field uses information from the human resources system.

[0116] In practice, you may encounter situations where multiple systems describe the same functional field differently. For example, the finance system might use "Customer Number" while the human resources system uses "Customer ID," even though they serve the same function. In this case, you need to first unify the field name, and then assign priorities and handle conflicts. Assuming the unified field name is "Customer Number," data from the finance system has higher priority than data from the human resources system. If there is a conflict between the two, the data from the finance system will be retained based on priority.

[0117] For example, the "Product Inventory Quantity" field has a value of "100" from the supply chain management system and "105" from the financial system. They serve the same function but have different content. Based on the system's trust level, the financial system has higher priority than the supply chain management system; therefore, the "105" from the financial system is retained, while the "100" from the supply chain management system is removed. The actual inventory can be verified later through methods such as inventory checks, but during the data processing stage, data consistency is ensured according to preset rules.

[0118] This implementation method ensures effective resolution of data conflicts by seamlessly integrating each step: extracting field source information, assigning priorities, comparing conflicting fields, retaining high-priority data, and generating the second dataset. The process does not rely on complex formulas or experimental data; instead, it uses preset system credibility levels and priority rules to logically process field conflicts in the first dataset, making the second dataset more accurate and reliable. This provides a high-quality data foundation for subsequent data processing steps such as contract hash value duplication verification, guaranteeing the smooth implementation of the company's automated internal control data management methods.

[0119] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0120] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for automated management of corporate internal control data based on smart contracts, characterized in that, The method includes: Data is collected and accessed from multiple business systems, the data transmission protocols of each system are unified, conflicting data is eliminated, and duplicate verification is performed based on contract hash values ​​to obtain a standardized dataset. Based on the standardized dataset, extract the business operation time field, data subject identifier field, and control rule code field for each item; Based on the business operation time field, the data in the standardized dataset is divided into time windows to generate a periodic operation dataset; Based on the periodic operation dataset and the data subject identifier field, the original operation node and the target operation node are mapped to the preset permission level to generate a process control path map; Based on the process control path map, periodic operation dataset, and control rule coding field, business operation behaviors are classified and associated according to rule categories, and the triggering frequency of different categories of rules at the target node within a specific period is tracked to generate classification tracking indicators for internal control data operations. The control rule encoding field identifies the control rule category corresponding to the operation, including financial approval rules and data access rules; Based on the periodic operation dataset and the data subject identifier field, the original operation node and the target operation node are mapped to a preset permission level, generating a flow control path graph, including: Based on the data subject identifier field, information on the original business operation nodes and target operation nodes is extracted from the standardized dataset, and unstructured operation descriptions are converted into structured node identifiers to form a set of node identifiers; Based on the data subject identifier field in the periodic operation dataset, the business operation records in each period are matched with the node identifier set to generate a periodic node mapping dataset, which carries both time and process information. Based on the periodic node mapping dataset, each group of node identifiers is mapped to a unified preset permission level, and a business operation path sequence is constructed in this way to form a process path dataset. A directed association graph is constructed based on the process path dataset, where nodes represent permission levels and edges represent operation directions and number of operations, thus generating a process control path graph.

2. The method for automated management of internal control data based on smart contracts according to claim 1, characterized in that, Data is collected and accessed from multiple business systems, the data transmission protocols of each system are unified, conflicting data is eliminated, and duplicate verification is performed based on contract hash values ​​to obtain a standardized dataset, including: Based on the protocol characteristics of the data interface in the multi-source business system, the transmission protocol of the multi-source business system is adapted and converted to obtain the first dataset; The duplicate fields in the first dataset are identified for format conflicts. Fields with high source credibility are retained, and fields with content conflicts are removed to obtain the second dataset. Based on the contract hash value information corresponding to each data record in the second dataset, combined with the data subject identifier field, approximately duplicate records are identified, and redundant items are removed to obtain a standardized dataset.

3. The method for automated management of internal control data based on smart contracts according to claim 1, characterized in that, Based on the process control path map, periodic operation dataset, and control rule coding fields, business operation behaviors are categorized and associated according to rule types. The trigger frequency of different rule categories at target nodes within a specific period is tracked to generate classification tracking indicators for internal control data operations, including: Based on the control rule encoding field, the business operation records in the periodic operation dataset are divided into multiple rule operation subsets according to categories. Combined with the original nodes and target nodes recorded in the process control path graph, a set of operation record pairs divided by category and node is generated. Based on the operation records, for each rule operation subset, the number of triggers and non-triggers within each target node are aggregated and statistically analyzed to construct a three-dimensional data table with a rule-node-cycle structure. Based on this data table, the trigger frequency of each category within different cycles at each node is calculated using a trigger frequency statistical method to form a trigger frequency sequence. Based on the data differences in consecutive periods in the trigger frequency sequence, the periodic change is calculated, and a time series-based indicator stability calculation method is used to obtain the classification tracking indicators of internal control data operations under each category and node dimension.

4. The method for automated management of internal control data of a company based on smart contracts according to claim 2, characterized in that, Based on the protocol characteristics of the data interfaces in the multi-source business system, the transmission protocol of the multi-source business system is adapted and converted to obtain the first dataset, which includes: Extract all data interfaces from the multi-source business system to form an interface set; Based on the interface set and the pre-set protocol comparison table, determine whether there are interfaces with the same function but different protocols in different systems, and determine the recommended standard transmission protocol to form a standard protocol recommendation set; Based on the recommended set of standard protocols, for transmission protocols that are determined to be functionally consistent, the transmission protocols of the multi-source business system are replaced with the corresponding standard transmission protocols by the protocol replacement method, thereby generating a set of standard protocols. Arrange the standard protocol set according to the order set in the standard interface template to generate the first dataset.

5. The method for automated management of corporate internal control data based on smart contracts according to claim 4, characterized in that, The first dataset is used to identify format conflicts in duplicate fields. Fields with high source credibility are retained, while fields with content conflicts are removed, resulting in the second dataset, which includes: Based on the field source information in the first dataset, the original system of each field is extracted, and field source priority is assigned based on the preset system credibility level to form field priority data; Based on the field priority data, a conflict comparison is performed on fields in the first dataset that have the same function but conflicting sources. Fields with higher priority are retained, while fields with lower priority or inconsistent content are removed, generating conflict cleanup result data. The conflict resolution results are used as output to obtain the second dataset.

6. The method for automated management of corporate internal control data based on smart contracts according to claim 5, characterized in that, Based on the contract hash value information corresponding to each data record in the second dataset, combined with the data subject identifier field, approximately duplicate records are identified, and redundant items are removed to obtain a standardized dataset, including: Extract the contract hash value field and the data subject identifier field from the second dataset, and combine them into a unique identification key to generate record index data; Based on the record index data and a preset hash difference tolerance threshold, it is determined whether the data record meets the duplication condition, wherein the hash difference of the duplication condition is within the preset hash difference tolerance threshold and the data subject identifier is consistent. For data records that meet the duplication condition, retain the best record in the second dataset based on data integrity, delete the remaining records, and output a standardized dataset.

7. The method for automated management of internal control data of a company based on smart contracts according to claim 1, characterized in that, Based on the periodic node mapping dataset, each group of node identifiers is mapped to a unified preset permission level, and a business operation path sequence is constructed accordingly, forming a process path dataset, including: Based on the original node and target node identifiers contained in each business operation record in the periodic node mapping dataset, they are converted from the original permission level to process points under a unified preset permission level, forming a standardized set of node pairs. Based on the principle of process discretization using hierarchical coding, each pair of identifiers in the standardized node pair set is encoded, and the node value is converted into an indexable hierarchical code of permissions. Based on the data subject identifier field and the time period field, the operation direction of each business within a specific period is represented as a path sequence from the start code to the end code. The number of operations and rule category attribute information are attached to each path sequence to construct an attributed business operation path dataset. All business operation path sequences are organized by period to generate a process path dataset with time hierarchy.

8. The method for automated management of corporate internal control data based on smart contracts according to claim 7, characterized in that, A directed association graph is constructed based on the process path dataset, where nodes represent permission levels and edges represent operation directions and number of operations, generating a process control path graph, including: Based on the start-point and end-point hierarchical codes carried by each operation path sequence in the process path dataset, they are assigned to standard permission groups as node identifiers in the graph, forming a permission node set. For multiple path sequences belonging to the same time period and having the same start and end permissions, merge them and calculate the total number of operations for that path, which is then used as the edge weight of that path in the graph. Using the set of permission nodes as nodes in the graph, and the start and end permission pairs after path aggregation as directed edges in the graph, we construct directed connections between nodes and use the total number of operations as the weighted value of the edges to form a weighted directed graph structure. The directed association graph is output in graph form as a flow control path graph.

9. The method for automated management of corporate internal control data based on smart contracts according to claim 3, characterized in that, The trigger frequency is calculated for each category at each node within different periods using a trigger frequency statistical method, forming a trigger frequency sequence, including: Based on the data table with a three-dimensional structure of rules-nodes-cycles, the number of times each category of rules is triggered and the number of times it is not triggered are extracted for each target node in each time cycle, and these are used as the measurement values ​​of the operation behavior of the rule of that category for that node in that cycle. For each target node, extract its corresponding operation frequency threshold or rule coverage range as the benchmark parameter for frequency normalization. Divide the measurement value of each category of operation behavior by the corresponding baseline parameter to obtain the normalized trigger frequency of each category at each target node and each time period. The normalized trigger frequencies are arranged sequentially according to the time period to form a trigger frequency sequence.

Images