Enterprise-based data checking method and device, electronic equipment, storage medium and program product

Abstract

Embodiments of the present application provide a kind of based on enterprise's data checking method, device, electronic equipment, storage medium and program product.The method comprises: in response to obtaining the first transaction information updated in the transaction database of target enterprise, according to the expenditure party of resource, the income party of resource and the transaction data of resource carried in the first transaction information, generate first transaction voucher;Identify the first identity information of the expenditure party and the second identity information of the income party in the first transaction voucher, match first identity information, second identity information with the family tree information table corresponding to the target enterprise, obtain matching result;Wherein, the family tree information table includes the identity information of the subunit corresponding to the target enterprise;If it is determined that the matching result indicates that first identity information and second identity information are both matched successfully, it is determined that the second transaction voucher corresponding to the income party is checked with the first transaction voucher.

Description

Technical Field

[0001] This application relates to the field of data processing, and more particularly to a data verification method, apparatus, electronic device, storage medium, and program product based on an enterprise. Background Technology

[0002] As the operating environment of conglomerates becomes increasingly complex and the ways in which companies cooperate become more diversified, the management of internal related-party transactions becomes increasingly important. Internal resource transfers refer to transactions occurring within the same conglomerate, typically involving different branches and subsidiaries, requiring precise management and control. However, in related fields, financial systems often require financial personnel to manually sift through data during financial calculations to identify internal transactions, which is not only inefficient but also unable to update data in real time.

[0003] There is an urgent need to address the problem of low data processing efficiency in related fields, where data transfer within organizations can only be manually screened. Summary of the Invention

[0004] This application provides a data verification method, apparatus, electronic device, storage medium, and program product for enterprises, which aims to improve the efficiency of data information processing for resource transfer within an organization.

[0005] In a first aspect, embodiments of this application provide a data verification method based on an enterprise, comprising: responding to obtaining updated first transaction information in the transaction database of a target enterprise; generating a first transaction voucher based on the resource spender, resource recipient, and resource transaction data carried in the first transaction information; identifying the first identity information of the spender and the second identity information of the recipient in the first transaction voucher; matching the first identity information and the second identity information with a family tree information table corresponding to the target enterprise to obtain a matching result; wherein the family tree information table includes the identity information of the sub-units corresponding to the target enterprise; if it is determined that the matching result indicates that both the first identity information and the second identity information are successfully matched, then determining to perform data verification between the second transaction voucher corresponding to the recipient and the first transaction voucher.

[0006] In one possible implementation, the hierarchical relationship between the first identity information and the second identity information in the family tree information table is determined; a first verification algorithm for data verification between the first transaction voucher and the second transaction voucher is determined based on the hierarchical relationship; and the first transaction voucher and the second transaction voucher are verified based on the first verification algorithm.

[0007] In one possible implementation, the transaction type corresponding to the transaction data is identified, wherein the transaction type is used to indicate the reason for the generation of the transaction data item; a voucher corresponding to the transaction type is matched from a preset voucher identifier table, and the voucher is added to the first transaction voucher.

[0008] In one possible implementation, upon receiving a first verification instruction from the target object, the verification identifier carried by the first verification instruction is identified; the verification identifier is compared with the voucher identifier; if the verification identifier matches the voucher identifier, the first transaction voucher is determined to comply with the first verification instruction, and the first transaction voucher is allowed to enter the verification process; if the verification identifier does not match the voucher identifier, the first transaction voucher is determined to not comply with the first verification instruction, and the first transaction voucher is prohibited from entering the verification process.

[0009] In one possible implementation, all transaction vouchers corresponding to the revenue party are determined, and the voucher identifier of each transaction voucher in the all transaction vouchers is identified to obtain a voucher identifier set corresponding to the revenue party. The voucher identifier set includes: all transaction vouchers corresponding to the revenue party, multiple voucher identifiers, and a mapping relationship between all transaction vouchers and the multiple voucher identifiers. The transaction voucher in the voucher identifier set that matches the voucher identifier of the first transaction voucher is determined as the second transaction voucher.

[0010] In one possible implementation, the on / off state of the verification switches corresponding to the expenditure party and the revenue party is obtained, wherein the on / off state is used to indicate whether all transaction information corresponding to the expenditure party and / or revenue party participates in data verification; if the on / off state of either the expenditure party or the revenue party is off, it is determined that the first transaction information does not participate in data verification; if the on / off state of both the expenditure party and the revenue party is on, it is determined that the first transaction information participates in data verification.

[0011] In one possible implementation, upon receiving a second verification instruction for a target object, the verification function carried by the second verification instruction and the item to be verified are determined; the target data of the target item in the second transaction voucher that matches the item to be verified in the first transaction voucher are identified; and the target data is verified based on the verification function.

[0012] Secondly, this application provides a data verification device based on an enterprise, including: a generation module, used to generate a first transaction voucher based on the resource spender, resource recipient, and resource transaction data carried in the first transaction information when the first transaction information updated in the transaction database of the target enterprise is obtained;

[0013] The identification module is used to identify the first identity information of the payer and the second identity information of the recipient in the transaction voucher, and to match the first identity information and the second identity information with the family tree information table corresponding to the target enterprise, wherein the family tree information table includes the identity information of all sub-units corresponding to the target enterprise;

[0014] The verification module is used to determine, if the matching result indicates that both the first identity information and the second identity information are successfully matched, to perform a data verification between the second transaction voucher corresponding to the recipient and the first transaction voucher.

[0015] Thirdly, embodiments of this application provide an enterprise-based data verification device, including: a memory and a processor;

[0016] The memory stores computer-executed instructions;

[0017] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0019] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0020] The enterprise-based data verification method, apparatus, electronic device, storage medium, and program products provided in this application automatically identify transaction information and generate transaction vouchers, reducing manual intervention and improving accuracy and efficiency. By matching the identity information carried in the transaction voucher with a family tree information table, it ensures that the identities of both parties to the transaction are known and associated with the target enterprise. Through this matching and verification process, abnormal transactions can be detected in a timely manner, thereby improving the efficiency of data information processing for internal resource transfers within the organization. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0022] Figure 1 This application provides a schematic diagram of an application scenario for enterprise-based data verification.

[0023] Figure 2 The flowchart of enterprise-based data verification provided for this application Figure 1 ;

[0024] Figure 3 The flowchart of enterprise-based data verification provided for this application Figure 2 ;

[0025] Figure 4 A schematic diagram of the enterprise-based data verification device provided in this application;

[0026] Figure 5 A schematic diagram of the equipment structure for data verification based on the enterprise provided in this application.

[0027] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0029] First, let me explain the terms used in this application:

[0030] EPR: Enterprise Resource Planning

[0031] Family Tree Information Table: A corporate family tree, also known as a corporate organizational chart, displays the hierarchical relationships and departmental divisions within a company in a tree-like structure. This type of chart is typically displayed from top to bottom, with the parent company at the top and various subsidiaries or departments at the bottom.

[0032] Figure 1 This application provides an illustration of an application scenario for enterprise-based data verification, such as... Figure 1 As shown, the specific application scenario of this application is data verification within an enterprise.

[0033] Intracompany transactions refer to transactions occurring within the same group of enterprises. These transactions typically involve different branches and subsidiaries, requiring precise management and control. However, traditional financial systems often cannot meet this need. In related fields, intracompany transactions are often identified manually by finance personnel from the business system and from the daily complex data when consolidated financial statements are required. While this method can achieve some management results, it is inefficient, error-prone, and lacks real-time data updates and recording, thus posing significant challenges to the subsequent reconciliation of intracompany transactions.

[0034] Based on the above scenarios, it is clear that in existing technologies, manually screening out which transaction data belongs to internal enterprise transactions and then using computers for calculation is inefficient and cannot update the data in real time.

[0035] The enterprise-based data verification method provided in this application automatically identifies transaction information and generates transaction vouchers, reducing manual intervention and improving accuracy and efficiency. By matching the identity information carried in the transaction vouchers with a family tree information table, it ensures that the identities of both parties in the transaction are known and associated with the target enterprise. Through this matching and verification process, abnormal transactions can be detected in a timely manner, thereby improving the efficiency of data information processing for internal resource transfers and solving the technical problem of low data information processing efficiency caused by relying solely on manual screening for data transfers within an organization.

[0036] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0037] Figure 2 The flowchart of enterprise-based data verification provided for this application Figure 1 ,like Figure 2 As shown, the method includes:

[0038] S201. In response to obtaining the first transaction information updated in the transaction database of the target enterprise, generate a first transaction voucher based on the resource spender, resource revenueer, and resource transaction data carried in the first transaction information.

[0039] Optionally, the target company can be a group, a company, etc. The transaction database is a database used by the target company to store all its transactions.

[0040] Optionally, the spender of the resource can be the payee, and the receiver of the resource can be the recipient.

[0041] Optionally, the spender of the resource can be the recipient of the goods, and the receiver of the resource can be the recipient of the goods.

[0042] Transaction data shall include at least one of the following: the number of transactions, transaction amount, transaction type, transaction time, and transaction reason of the first transaction information.

[0043] It should be noted that any expenditure or income of resources related to the target company will update the transaction information in the transaction database.

[0044] S202. Identify the first identity information of the payer and the second identity information of the recipient in the first transaction voucher, and match the first identity information and the second identity information with the family tree information table corresponding to the target enterprise to obtain a matching result; wherein, the family tree information table includes the identity information of the sub-units corresponding to the target enterprise.

[0045] Optionally, the family tree information table can maintain multiple subsidiaries corresponding to a group, the hierarchical relationship between multiple subsidiaries, or multiple departments corresponding to a company, the hierarchical relationship between multiple departments.

[0046] Optionally, the first identity information and the second identity information refer to information that can identify the spender and the recipient. Both the first identity information and the second identity information include at least one of the following: company name, unified social credit code, registered address, establishment date, company account information, company number, etc.

[0047] S203. If the matching result indicates that both the first identity information and the second identity information are successfully matched, then the data of the second transaction voucher corresponding to the income party is checked against the first transaction voucher.

[0048] In other words, based on the matching results, the system will decide whether to perform data verification between the second transaction voucher corresponding to the revenue party and the first transaction voucher. Since the family tree information table can maintain multiple subsidiaries of a group, the hierarchical relationships between multiple subsidiaries, or multiple departments of a company, the matching result indicating a successful match means that both the revenue party and the expenditure party belong to the target company. This indicates that the first transaction information is an internal transaction. Further verification of the accuracy of the transaction data is possible, and the system will perform a data verification operation; otherwise, if the first transaction information is not an internal transaction, other measures may be taken or this step may be skipped.

[0049] The data verification method for enterprises provided in this application first retrieves the updated first transaction information from the target enterprise's transaction database and generates a transaction voucher. Next, the system automatically identifies the primary identity information of the payer and the secondary identity information of the recipient in the first transaction voucher. Then, this identity information is matched against the target enterprise's corresponding family tree information table to determine whether they belong to sub-units within the target enterprise. If the matching result shows that both the primary and secondary identity information match successfully, the system will verify the data of the secondary transaction voucher corresponding to the recipient against the primary transaction voucher. This solution, through automated transaction information acquisition, identity information matching, and data verification processes, improves the efficiency and accuracy of internal enterprise transaction processing, thereby enhancing the data information processing efficiency of internal resource transfers.

[0050] For example, the hierarchical relationship between the first identity information and the second identity information in the family tree information table is determined; a first verification algorithm for data verification between the first transaction voucher and the second transaction voucher is determined based on the hierarchical relationship; and the first transaction voucher and the second transaction voucher are verified based on the first verification algorithm.

[0051] In other words, when the hierarchical relationship between the first and second identity information differs, the corresponding verification algorithms may differ. Data for a higher-level identity may come from multiple different systems or departments, requiring cross-system verification. Conversely, data for a lower-level identity may come from only a single system or department. This difference in data sources may necessitate the use of different technologies and tools when processing data from different identities.

[0052] Optionally, in enterprise or organizational management, family tree information tables are typically used to represent hierarchical relationships between different entities (such as departments, branches, or individuals). This structure helps clarify the roles and responsibilities of each entity, thereby facilitating effective management and decision-making. Determining hierarchical relationships requires identifying the positions of primary and secondary identity information within the family tree information table. This is done by locating the node in the family tree corresponding to each identity information and determining the hierarchical relationship between these nodes. For example, if one department is the parent department of another, then a hierarchical relationship exists between these two departments. Based on the determined hierarchical relationships, a data verification algorithm is developed. The purpose of this algorithm is to ensure that transaction documents related to these entities are processed according to the correct procedures and rules.

[0053] The algorithm described above is used to verify the data on the first and second transaction vouchers. This process may involve comparing the information on the two vouchers to ensure their accuracy and consistency. For example, if both vouchers relate to the same transaction, it is necessary to verify that their amounts, dates, and other relevant information match.

[0054] For example, the transaction type corresponding to the transaction data is identified, wherein the transaction type is used to indicate the reason for the generation of the transaction data item; a voucher corresponding to the transaction type is matched from a preset voucher identifier table, and the voucher is added to the first transaction voucher.

[0055] Optionally, when processing transaction data, it is first necessary to identify the transaction type corresponding to each transaction. Transaction type is typically used to indicate the reason for the generation of transaction data items, such as sales revenue, procurement expenditure, and salary payment. In order to accurately record and track these transactions, a pre-defined voucher identifier table is used, which lists various transaction types and their corresponding voucher identifiers.

[0056] Optionally, the transaction data item is generated for reasons such as: purchase of goods or salary expenditure. The voucher identifier corresponding to either of these reasons is determined from a pre-defined voucher identifier table to be an expenditure voucher, with the corresponding voucher identifier being "ZC" or "001".

[0057] When a transaction occurs, the system identifies the transaction type based on the transaction data. Then, the system searches a pre-defined voucher identifier table for the corresponding transaction type. This voucher identifier is a unique code or number used to identify a specific type of transaction. Once the corresponding voucher identifier is found, the system adds it to the first transaction voucher for use in subsequent accounting processing and reporting. This approach helps ensure the consistency and accuracy of transaction data, and allows for subsequent determination of whether the current transaction voucher is the target transaction voucher based on the voucher identifier. It also facilitates auditing and supervision.

[0058] For example, upon receiving a first verification instruction from the target object, the verification identifier carried in the first verification instruction is identified; the verification identifier is compared with the voucher identifier; if the verification identifier and the voucher identifier are consistent, the first transaction voucher is determined to conform to the first verification instruction, and the first transaction voucher is allowed to enter the verification process; if the verification identifier and the voucher identifier are inconsistent, the first transaction voucher is determined to not conform to the first verification instruction, and the first transaction voucher is prohibited from entering the verification process.

[0059] In other words, upon receiving the first verification instruction from the target object, the system identifies the verification identifier carried in the instruction. This verification identifier is then compared with the voucher identifier of the first transaction voucher. If the two identifiers match, it means the first transaction voucher meets the requirements of the first verification instruction, and therefore the first transaction voucher is allowed to enter the verification process. Conversely, if the two identifiers do not match, the first transaction voucher does not meet the requirements of the first verification instruction, and it is prohibited from entering the verification process.

[0060] For example, all transaction vouchers corresponding to the revenue party are determined, and the voucher identifier of each transaction voucher in the all transaction vouchers is identified to obtain a set of voucher identifiers corresponding to the revenue party. The set of voucher identifiers includes: all transaction vouchers corresponding to the revenue party, multiple voucher identifiers, and a mapping relationship between all transaction vouchers and the multiple voucher identifiers. The transaction voucher in the set of voucher identifiers that is consistent with the voucher identifier of the first transaction voucher is determined as the second transaction voucher.

[0061] Optionally, all transaction records related to the revenue party can be retrieved from a database or data storage system. A unique identifier corresponding to the revenue party will be specified as a filter to obtain all related transaction information. After obtaining all transaction records for the revenue party, the next step is to extract the unique identifier for each transaction. These identifiers are key to distinguishing different transactions; they can be numbers, strings, or other forms of identification to ensure the uniqueness of each transaction in the system. All voucher identifiers identified in the previous step are aggregated into a set. This set not only contains all voucher identifiers but also implicitly implies the association between these vouchers and specific revenue parties. The set can be in the form of a list, array, or other data structure, depending on the system design and requirements. In the voucher identifier set, each voucher identifier corresponds to a specific transaction type. This correspondence is bidirectional: on the one hand, the corresponding transaction record can be quickly found through the voucher identifier; on the other hand, the voucher identifier can also be found by reverse-engineering the transaction record. Among all transaction vouchers, if there is a voucher with the same voucher identifier as the first transaction voucher, then that voucher is identified as the second transaction voucher.

[0062] In an exemplary embodiment, an inter-company sales group sells 100 tons of products to its subsidiary, receiving payment of 700,000 yuan. The cost of the products is 500,000 yuan. After receiving the goods, the subsidiary sells all of the products to a third-party company outside the group, receiving 1 million yuan. The voucher details are as follows:

[0063] Table 1

[0064]

[0065] Table 2

[0066]

[0067] As shown in Table 1, it can be identified that the expenditure party of the resources corresponds to the parent company, and the revenue party corresponds to the subsidiary. The transaction types corresponding to the transaction data include: cost of goods sold, inventory, accounts receivable from internal units, and revenue from main business operations. Among them, the voucher identifier for "cost of goods sold" and "inventory" is "WA", and the voucher identifier for "accounts receivable from internal units" and "revenue from main business operations" is "RV".

[0068] The target entity can identify the transaction documents to be verified by sending a verification instruction. For example, if the verification identifier carried in the first verification instruction issued by the target entity is "WA", then transaction documents with the identifier "WA" are allowed to enter the data verification. That is, transaction documents with the account "6401 Cost of Goods Sold" and transaction documents with the account "1405 Inventory".

[0069] In practical applications, the primary and secondary identity information can be directly determined by retrieving the table header information. For example, in Table 1, the header indicates that the parent company is selling products to its subsidiary. Therefore, in the corresponding transaction vouchers for Table 1, the payer is always the parent company, and the recipient is always the subsidiary. Similarly, in Table 3, the header indicates that the subsidiary is selling products to a third-party company. Thus, in the corresponding transaction vouchers for Table 3, the payer is always the subsidiary, and the recipient is always the third-party company. For clarity, we use "subsidiary," "parent company," and "third-party company" to refer to these entities. However, in actual applications, the table header can be represented by the company's code or similar identifier.

[0070] Optionally, to further illustrate the above scheme, the following will be combined with... Figure 3 To explain, Figure 3 The flowchart of enterprise-based data verification provided for this application Figure 2 , specifically:

[0071] S301: First, it involves generating or receiving financial vouchers from the business system, which form the basis of transaction records. Next, based on the nature of the voucher, it's determined whether it belongs to an internal or non-internal transaction. Then, the specific type of voucher is determined, such as a service catalog or family tree mapping dictionary. Pre-defined voucher identification rules are applied to identify and classify the vouchers, and family tree information is maintained to ensure data accuracy and completeness. Finally, identified internal transactions are reconfirmed and adjusted to ensure transaction accuracy.

[0072] Internal Transaction Switch: The system checks the internal transaction switch. If the switch is off, it means this is a transaction between the company's internal and external entities, and the process ends. If the switch is on, it means this is a transaction between companies within the same company, and the process continues.

[0073] Voucher type: The system will determine the voucher type to be processed based on the status of the internal transaction switch.

[0074] Step S302: Perform specific processing operations based on the data provided in step S301, including using a transaction hierarchy dictionary to distinguish and manage transactions at different levels, classifying and processing vouchers according to information in the service catalog, and using a family tree mapping dictionary to map entities in vouchers to nodes on the family tree.

[0075] In addition, a basic framework for credential recognition needs to be built, including recognition algorithms, rule sets, and related data structures. Throughout the process, the family tree information must be continuously updated and maintained to ensure it reflects the latest transaction and relationship status.

[0076] Service Catalog: The system will provide a service catalog for users to view and use.

[0077] Transaction tier dictionary: The system will provide a transaction tier dictionary to help users understand transaction information at different tiers.

[0078] Family Tree Mapping Dictionary: The system provides a family tree mapping dictionary to help users understand the structure of the family tree.

[0079] Family Tree Information Basic Configuration: The system provides a basic configuration tool for family tree information, allowing users to customize the information of their family tree.

[0080] Family Tree Information Maintenance: Users can update and maintain family tree information in the family tree information maintenance tool.

[0081] Optionally, first obtain the company field value from the header table. Based on the system number and company, obtain the voucher identification rules. If no voucher identification rules are configured, the identification process will end, and this voucher will be identified as a non-internal transaction. The voucher identification rules can be used for flexible filtering. As shown in Table 3, if the counterparty is identified as C001, C001 is matched against the family information table. If C001 is not found in the family information table, the identification process ends. Optionally, parse the identification rules one by one. If any line item of the voucher satisfies the defined identification rules, this voucher is identified as an internal transaction.

[0082] Optionally, if multiple identification rules are configured, the credential will be identified as an internal transaction as long as one of the identification rules is met.

[0083] Optionally, voucher recognition rules can be set. Based on the field information in the business system header and line item table, recognition rules are set to determine whether it is an internal transaction. For example, the system's recognition rules can be set to include company 1000 and 2000, voucher type RV and RE, and information such as counterparty A001 and B001, and profit center 1001000001 and 2001000001. After the system generates a voucher, it automatically matches the information in the family tree dictionary. If it matches, it is considered an internal transaction, and the system records the voucher transaction information (voucher numbers: 5000000001 and 3000000001).

[0084] It should be noted that identifying transaction vouchers requires retrieving information from the vouchers. The methods for retrieving these information include: constants, field values, and SQL values.

[0085] ① A constant is a fixed value.

[0086] ② Field value, which corresponds to the field name on the voucher line item.

[0087] ③ SQL value retrieval primarily addresses situations where constants and field values ​​are not supported. Custom SQL retrieval can retrieve various business data information from the database where the application resides. Some data may not be directly usable; to resolve this, a custom function can be created in the database to handle complex logic such as data transformation. Using custom functions for SQL data retrieval can meet a wider range of business needs.

[0088] Table 3

[0089]

[0090] For example, the on / off state of the verification switches corresponding to the expenditure party and the revenue party is obtained respectively, wherein the on / off state is used to indicate whether all transaction information corresponding to the expenditure party and / or revenue party participates in data verification; if the on / off state of either the expenditure party or the revenue party is off, it is determined that the first transaction information does not participate in data verification; if the on / off state of both the expenditure party and the revenue party is on, it is determined that the first transaction information participates in data verification.

[0091] The system first retrieves the status of the reconciliation switches for both the spending and revenue sides. These switch statuses indicate whether all transaction information from the spending and / or revenue sides is allowed to participate in data reconciliation. If the switch status for either the spending or revenue side is "off," then the first transaction information is determined not to participate in data reconciliation. This means that participation in data reconciliation can be determined in advance by setting the switch status for either the spending or revenue side.

[0092] Optionally, if either the payer or the payee is not in the family tree information table, the switch can be set to off. Optionally, if both the payer and the payee are in the family tree information table, but one of them is not participating in this data verification, the switch can be set to off.

[0093] In other words, the participating companies or units can be adjusted by changing the transaction switch status at any time. When the switch is off, subsequent steps can be omitted.

[0094] For example, upon receiving a second verification instruction for a target object, the verification function carried by the second verification instruction and the item to be verified are determined; the target data of the target item in the second transaction voucher that is consistent with the item to be verified in the first transaction voucher are identified; and the target data is verified based on the verification function.

[0095] A check function is a logical or algorithmic method used to compare whether items in two or more datasets are consistent. For example, it can be a simple equality comparison (equal to, contain, fuzzy match, etc.) or a complex pattern match or regular expression match. The items to be checked are the specific data points or records that need to be verified. This might include fields in transaction documents such as date, amount, participant identifier, etc. Target data matching the items to be checked is extracted from the first and second transaction documents. This data will be used in subsequent check processes. The extracted target data is then checked using the previously determined check function.

[0096] The following are embodiments of the apparatus of the present invention, which can be used to execute embodiments of the method of the present invention. For details not disclosed in the embodiments of the apparatus of the present invention, please refer to the embodiments of the method of the present invention.

[0097] Figure 4 The schematic diagram of the enterprise-based data verification device provided in this application is as follows: Figure 4 As shown, the enterprise-based data verification device 40 of this embodiment includes: a generation module 401, an identification module 402, and a verification module 403. Wherein:

[0098] The generation module 401 is used to generate a first transaction voucher based on the resource spender, resource recipient, and resource transaction data carried in the first transaction information when the first transaction information updated in the transaction database of the target enterprise is obtained.

[0099] The identification module 402 is used to identify the first identity information of the payer and the second identity information of the recipient in the transaction voucher, and to match the first identity information and the second identity information with the family tree information table corresponding to the target enterprise, wherein the family tree information table includes the identity information of all sub-units corresponding to the target enterprise;

[0100] The verification module 403 is used to determine, if the matching result indicates that both the first identity information and the second identity information are successfully matched, to perform a data verification between the second transaction voucher corresponding to the recipient and the first transaction voucher.

[0101] In one possible implementation, the verification module 403 is further configured to: determine the hierarchical relationship between the first identity information and the second identity information in the family tree information table; determine a first verification algorithm for data verification between the first transaction voucher and the second transaction voucher based on the hierarchical relationship; and perform data verification between the first transaction voucher and the second transaction voucher based on the first verification algorithm.

[0102] In one possible implementation, the generation module 401 is further configured to: identify the transaction type corresponding to the transaction data, wherein the transaction type is used to indicate the reason for the generation of the transaction data item; match the voucher identifier corresponding to the transaction type from a preset voucher identifier table, and add the voucher identifier to the first transaction voucher.

[0103] In one possible implementation, the generation module 401 is further configured to, upon receiving a first verification instruction from a target object, identify a verification identifier carried in the first verification instruction; compare the verification identifier with the voucher identifier; if the verification identifier matches the voucher identifier, determine that the first transaction voucher conforms to the first verification instruction and allow the first transaction voucher to enter the verification process; if the verification identifier does not match the voucher identifier, determine that the first transaction voucher does not conform to the first verification instruction and prohibit the first transaction voucher from entering the verification process.

[0104] In one possible implementation, the generation module 401 is further configured to: determine all transaction vouchers corresponding to the revenue party, and identify the voucher identifier of each transaction voucher in the all transaction vouchers to obtain a voucher identifier set corresponding to the revenue party, wherein the voucher identifier set includes: all transaction vouchers corresponding to the revenue party, multiple voucher identifiers, and a mapping relationship between all transaction vouchers and the multiple voucher identifiers; and determine the transaction voucher in the voucher identifier set that is consistent with the voucher identifier of the first transaction voucher as the second transaction voucher.

[0105] In one possible implementation, the verification module 403 is further configured to: obtain the on / off state of the verification switches corresponding to the expenditure party and the revenue party respectively, wherein the on / off state is used to indicate whether all transaction information corresponding to the expenditure party and / or revenue party participates in data verification; if the on / off state of either the expenditure party or the revenue party is off, determine that the first transaction information does not participate in data verification; if the on / off state of both the expenditure party and the revenue party is on, determine that the first transaction information participates in data verification.

[0106] In one possible implementation, the verification module 403 is further configured to, upon receiving a second verification instruction for a target object, determine the verification function carried by the second verification instruction and the item to be verified; identify the target data of the target item in the second transaction voucher that is consistent with the item to be verified in the first transaction voucher; and verify the target data based on the verification function.

[0107] The enterprise-based data verification device provided in this embodiment can execute the methods provided in the above-described method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0108] Figure 5 This is a schematic diagram of the equipment structure for enterprise-based data verification provided in this application. (For example...) Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0109] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0110] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0111] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0112] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0113] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0114] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0115] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0116] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0117] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0118] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0119] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0120] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0121] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0122] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0123] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A data verification method based on enterprises, characterized in that, include: In response to obtaining the first transaction information updated in the target enterprise's transaction database, a first transaction voucher is generated based on the resource spender, resource revenueer, and resource transaction data carried in the first transaction information. Identify the first identity information of the payer and the second identity information of the recipient in the first transaction voucher, and match the first identity information and the second identity information with the family tree information table corresponding to the target enterprise to obtain a matching result; wherein, the family tree information table includes the identity information of the sub-units corresponding to the target enterprise; If the matching result indicates that both the first identity information and the second identity information are successfully matched, then it is determined that the second transaction voucher corresponding to the revenue party will be compared with the first transaction voucher.

2. The method according to claim 1, characterized in that, If the matching result indicates that both the first identity information and the second identity information are successfully matched, then the second transaction voucher corresponding to the revenue party is retrieved and compared with the first transaction voucher, including: Determine the hierarchical relationship between the first identity information and the second identity information in the family tree information table; Based on the aforementioned hierarchical relationship, a first verification algorithm is determined for data verification between the first transaction voucher and the second transaction voucher; The first transaction voucher and the second transaction voucher are verified according to the first verification algorithm.

3. The method according to claim 1, characterized in that, Based on the resource spender, resource recipient, and first transaction data carried in the first transaction information, a first transaction voucher is generated, including: Identify the transaction type corresponding to the transaction data, wherein the transaction type is used to indicate the reason for the generation of the transaction data item; The voucher identifier corresponding to the transaction type is matched from the preset voucher identifier table, and the voucher identifier is added to the first transaction voucher.

4. The method according to claim 3, characterized in that, Before determining whether to perform data verification between the second transaction voucher corresponding to the revenue party and the first transaction voucher, the method further includes: Upon receiving a first verification instruction from the target object, identify the verification identifier carried in the first verification instruction; The verification identifier is compared with the voucher identifier. If the verification identifier and the voucher identifier are consistent, the first transaction voucher is determined to be in accordance with the first verification instruction, and the first transaction voucher is allowed to enter the verification process. If the verification identifier does not match the voucher identifier, it is determined that the first transaction voucher does not comply with the first verification instruction, and the first transaction voucher is prohibited from entering the verification process.

5. The method according to claim 4, characterized in that, Before determining whether to perform data verification between the second transaction voucher corresponding to the revenue party and the first transaction voucher, the method further includes: All transaction vouchers corresponding to the revenue party are determined, and the voucher identifier of each transaction voucher in the total transaction vouchers is identified to obtain the voucher identifier set corresponding to the revenue party. The voucher identifier set includes: all transaction vouchers corresponding to the revenue party, multiple voucher identifiers, and the mapping relationship between all transaction vouchers and the multiple voucher identifiers. The transaction voucher in the voucher identifier set that matches the voucher identifier of the first transaction voucher is identified as the second transaction voucher.

6. The method according to any one of claims 1-5, characterized in that, After generating a first transaction voucher based on the resource spender, resource recipient, and resource transaction data carried in the first transaction information, the method further includes: Obtain the on / off status of the verification switches corresponding to the expenditure party and the revenue party respectively, wherein the on / off status is used to indicate whether all transaction information corresponding to the expenditure party and / or revenue party participates in data verification; If the switch status of either the payer or the receiver is off, it is determined that the first transaction information will not participate in data verification. If both the spending and revenue sides are in an "on" state, the first transaction information is determined to participate in data verification.

7. The method according to any one of claims 1-5, characterized in that, Determining whether to allow the retrieval of the second transaction voucher corresponding to the revenue party for data verification with the first transaction voucher includes: Upon receiving a second verification instruction for the target object, determine the verification function carried by the second verification instruction and the item to be verified; Identify the target data of the target item in the second transaction voucher that matches the target item to be verified in the first transaction voucher; The target data is verified based on the verification function.

8. A data verification device based on an enterprise, characterized in that, include: The generation module is used to generate a first transaction voucher based on the resource spender, resource recipient, and resource transaction data carried in the first transaction information when the first transaction information updated in the target enterprise's transaction database is obtained. The identification module is used to identify the first identity information of the payer and the second identity information of the recipient in the transaction voucher, and to match the first identity information and the second identity information with the family tree information table corresponding to the target enterprise, wherein the family tree information table includes the identity information of all sub-units corresponding to the target enterprise; The verification module is used to determine, if the matching result indicates that both the first identity information and the second identity information are successfully matched, to perform a data verification between the second transaction voucher corresponding to the recipient and the first transaction voucher.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

11. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

Images