Intelligent migration and consistency verification method based on multi-source heterogeneous financial data

Abstract

The invention provides an intelligent migration and consistency verification method based on multi-source heterogeneous financial data, relates to the technical field of financial informatization and data migration technologies, and provides a financial data migration method which comprises the steps that after a user selects a financial system manufacturer and a version, the system loads a corresponding rule base and a decryption plug-in. Simulating login through an automatic test tool, obtaining authorization information, and judging a data obtaining mode according to the authorization information: if an interface is supported, calling the interface and decrypting data; otherwise, capturing the webpage data in a headless mode and performing page turning collection. And after the collected data is stored in the original data table, cleaning and format conversion are performed according to a rule base. And importing the converted data into a target system, if no corresponding account set exists, creating a new account set, otherwise, executing coverage or increment importing. And after importing is completed, consistency verification is executed by comparing the total amount of the data before and after migration with the structure distribution, a migration report containing a verification result is generated, and it is ensured that migration is accurate and reliable.

Description

Technical Field

[0001] This application belongs to the field of financial informatization and data migration technology, specifically involving an intelligent migration and consistency verification method based on multi-source heterogeneous financial data. Background Technology

[0002] With the advancement of enterprise digital transformation, the demand for financial system upgrades, platform replacements, or cloud migrations is increasing. In practical applications, users often need to migrate historical data (such as accounting subjects, opening balances, auxiliary accounting information, voucher data, etc.) from the original financial system to a new target financial system. However, due to the different data structures, coding rules, interface protocols, and security mechanisms adopted by different vendors (such as Yonyou, Kingdee, Inspur, etc.), cross-system data migration faces many technical challenges.

[0003] Common migration methods in the existing technology mainly include: (1) manually exporting templates and re-entering them, which is inefficient and prone to errors; (2) extracting data through direct database connection, but requires obtaining database permissions and depends on specific table structures, resulting in poor universality; (3) calling the API interface of the original system to obtain data, but most systems have encrypted the interface or implemented access control, making it difficult to call directly; (4) using web automation tools to simulate user operations to obtain page display data, which can bypass interface restrictions, but lacks a systematic verification mechanism for data integrity and consistency.

[0004] In addition, existing methods generally have the following drawbacks: First, they cannot adapt to the heterogeneity of various financial systems and require separate development of adaptation logic for each vendor; second, they lack effective decryption and authentication mechanisms when facing dynamic encryption interfaces; third, they lack the ability to automatically clean and transform data quality during the migration process; and finally, they lack scientific data consistency verification methods after the migration is completed, making it difficult to ensure the accuracy and reliability of the migration results. Summary of the Invention

[0005] This application provides an intelligent migration and consistency verification method based on multi-source heterogeneous financial data to solve one of the aforementioned technical problems.

[0006] The technical solution adopted in this application is as follows: This application provides an intelligent migration and consistency verification method based on multi-source heterogeneous financial data, including: Users select the vendor and version of the target financial system, and the corresponding rule base and decryption plugin are loaded according to the vendor and version. The system uses automated testing tools to simulate user login operations, accesses the original financial system website and completes the login process, and obtains authorization information for data access. Based on the authorization information, determine whether the financial data in the original financial system can be obtained through the interface. If so, call the corresponding data interface to obtain the financial data and use the decryption plugin to decrypt the encrypted data content. If it cannot be obtained through the interface, control the automated testing tool to run in headless mode, extract the financial data displayed in the original financial system webpage, and obtain all paginated data by simulating page turning operations. The acquired financial data is stored in the raw data table, and the application processing program is started to clean and convert the raw data. The cleaning and format conversion are performed according to the preset field mapping relationship and data validation rules in the rule base. After data cleaning and transformation are completed, the processed financial data is imported into the target financial system. If the corresponding set of accounts does not exist in the target financial system, a new set of accounts is created. If it already exists, an overwrite or incremental import operation is performed. After the data import is complete, perform a data consistency check, including comparing the total amount and structural distribution of key data items before and after the migration, and generate a migration report containing the check results.

[0007] According to one embodiment of this application, the rule base includes accounting subject code conversion rules, voucher classification mapping rules, auxiliary accounting field matching rules, and target system code prefix information for different vendors' financial systems; The field mapping relationship is used to convert the data fields in the original financial system into field formats that can be recognized by the target financial system. According to one embodiment of this application, the decryption plugin is an extensible dynamic decryption module that supports multiple encryption algorithm types; The decryption process includes identifying the encryption identifier of the content returned by the data interface, and calling the corresponding decryption algorithm plugin to decrypt the data based on the encryption identifier, ensuring the correct restoration of the plaintext data.

[0008] According to one embodiment of this application, obtaining all pagination data through simulated page-turning operations specifically includes: The automated testing tool parses the pagination control information on the current page, simulates a user clicking the next page button, and continuously obtains financial data from subsequent pages until it detects the last page marker or duplicate data content on two consecutive pages, at which point it stops paginating.

[0009] According to one embodiment of this application, the data cleaning and format conversion further includes integrity verification of the financial data, specifically: For each voucher record, the total debit amount is compared with the total credit amount. If the two are not equal, the voucher is marked as abnormal data and recorded in the log. At the same time, the subsequent import process is paused, and manual confirmation or correction is required.

[0010] According to one embodiment of this application, the data consistency verification includes: Calculate the difference in distribution entropy between the original data before migration and the data in the target system after migration. When the entropy difference exceeds a preset threshold, it is determined that the data distribution has changed, and the risk of data distortion or loss is marked in the migration report.

[0011] According to one embodiment of this application, the creation of a new account set includes: Send a creation request to the account management interface of the target financial system, carrying the account name, accounting system type, activation period and basic parameter information. After the interface returns the unique identifier of the account, associate the cleaned and transformed financial data with the account and import it.

[0012] According to one embodiment of this application, the migration report includes the total amount of data migrated, the number of successfully imported entries, a list of abnormal data entries, the data difference rate, the interface call success rate, and the consistency verification results. The migration report is displayed through a graphical interface and supports exporting to a standard document format.

[0013] A second aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the steps described in the method.

[0014] A third aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described.

[0015] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows: This application pre-configures rule bases and decryption plugins for different manufacturers and versions. The system can automatically load the corresponding configuration according to the user's selection, realizing rapid adaptation to a variety of financial systems. There is no need to develop a migration program for each system, which significantly improves the system's versatility and scalability.

[0016] This application utilizes automated testing tools to simulate real user login behavior, completes identity authentication and obtains access authorization information with user authorization, which not only meets network security and data privacy requirements, but also avoids the legal and technical risks of directly cracking interfaces, ensuring the legality and stability of data acquisition.

[0017] This application dynamically selects the optimal data acquisition path by determining whether API calls are supported—if the API is supported, the data is called and decrypted; if not, the application switches to a headless webpage mode for data scraping. Combined with an automatic pagination mechanism, it ensures complete acquisition of paginated data, effectively addressing the technical blocking strategies of different systems and improving the adaptability of migration tools.

[0018] This application introduces field mapping relationships and data validation rules from the rule base, enabling the application processing program to automatically complete cleaning operations such as accounting subject code conversion, voucher structure mapping, and amount unit unification, reducing manual intervention and improving the accuracy and consistency of data processing.

[0019] This application performs data consistency verification after data import is completed. By comparing the total amount (such as general ledger balance) and structural distribution (such as account hierarchy and auxiliary item combination) of key data items before and after migration, it can promptly detect problems such as data omission, duplication, or structural distortion, and generate a migration report containing detailed verification results. This provides users with traceable and auditable migration vouchers, greatly enhancing the transparency and reliability of the migration process. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating an intelligent migration and consistency verification method based on multi-source heterogeneous financial data provided in this application embodiment; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0021] Figure label: 810, Processor; 820, Communication interface; 830, Memory; 840, Communication bus. Detailed Implementation

[0022] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0023] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0024] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0025] Example 1 like Figure 1 As shown, an intelligent migration and consistency verification method based on multi-source heterogeneous financial data includes: Users select the vendor and version of the target financial system, and the corresponding rule base and decryption plugin are loaded according to the vendor and version.

[0026] As mentioned above, when a user selects the financial system vendor (such as Yonyou, Kingdee, Inspur, Speedata, etc.) and its specific version (such as Yonyou T3, T6, U8, Changjetong T+, etc.) of the source of the data to be migrated in the interactive interface of the migration tool, the system automatically loads the matching rule base and decryption plugin from the preset configuration resources based on the selection information.

[0027] The rule base contains data structure definitions and field mapping logic for the vendor and version of the financial system, such as the coding rules for accounting subjects (e.g., 4-2-2 structure), the classification method for voucher types, the storage format for auxiliary accounting items (customers, suppliers, departments, etc.), and the representation method for opening balances. This information is used to guide subsequent cleaning, format conversion, and integration with the target system of the raw data.

[0028] Decryption plugins are functional modules designed to address the encryption mechanisms used by different financial systems during interface communication or data transmission. To ensure data security, some vendors use encryption algorithms (such as AES, SM4, HMAC signatures, etc.) when returning data from API interfaces or loading data on front-end pages. The role of decryption plugins is to, after obtaining encrypted data, restore the ciphertext to readable plaintext data according to a preset key management strategy and decryption logic, ensuring the parsability of the data content.

[0029] The core of this step is to achieve "one-time development, multi-terminal adaptation" of the migration system. Through modular resource configuration, the same migration engine can flexibly cope with a variety of heterogeneous financial systems, avoiding the need to develop independent data processing logic for each system, thereby improving the system's versatility and maintenance efficiency.

[0030] For example, let's take the case where a user needs to migrate their financial data from the "Yonyou Changjie T+" system to the "Inspur Cloud Accounting" system: Users select "Vendor: Yonyou" and "Version: Changjetong T+" from the drop-down menu in the migration tool; After recognizing the combination, the system automatically loads a rule base file named "rule_yonyou_tplus.json" from the local or remote configuration center, which defines: The maximum length of the subject code is 10 digits, and the structure is "4 digits for Level 1 + 3 digits for Level 2 + 3 digits for Level 3"; Voucher type code correspondence: 1=Accounting voucher, 2=Receipt voucher, 3=Payment voucher; The naming convention for auxiliary accounting fields in the data table is "f_aux_customer", "f_aux_department", etc.; The subject prefix for the target system (Inspur Cloud Accounting) is "YUN-".

[0031] Meanwhile, the system loads a dynamic decryption plugin named "decrypt_plugin_yonyou.so". This plugin incorporates the HMAC-SHA256 signature verification mechanism and AES-128-CBC decryption process used by the Yonyou T+ system API interface, and pre-configures key switching logic between the test environment and the production environment.

[0032] After the above loading is completed, the system will have the ability to identify, parse and transform data from the specific financial system, laying the foundation for subsequent steps such as login, data collection and cleaning.

[0033] It should be noted that, in specific implementation scenarios, the rule base can be automatically downloaded and updated via the network based on the above solution. When a financial system releases a new version or adjusts its data structure, the migration platform can push a new rule configuration package, allowing users to support the new system without upgrading the main program, thus achieving seamless compatibility.

[0034] In specific implementation scenarios, based on the above solutions, the decryption plugin can support a hot-swappable architecture. Third-party developers or system service providers can develop dedicated decryption modules in compliance with security standards and integrate them into the migration tool after digital signature authentication, thereby enhancing support for private encryption protocols.

[0035] In specific implementation scenarios, based on the above solutions, the system can automatically recommend the most likely manufacturer and version options based on the user's input of the original system login URL or screenshot information, combined with the built-in fingerprint recognition algorithm, thereby reducing the error rate of manual selection by the user.

[0036] In specific implementation scenarios, the rule base can also support an inheritance structure of "vendor level → product line level → version level" based on the above solution. For example, "Yonyou" can be the root rule, "U8" can inherit Yonyou's general rules and extend specific fields, and "U8 10.1" can further inherit U8 rules and correct known defects, thereby improving the hierarchy and reusability of rule management.

[0037] In specific implementation scenarios, based on the above solution, when multiple rule sources (such as local rules and cloud rules) conflict, the system can automatically detect and prompt the user to select the priority, or enter the manual review mode to ensure the accuracy and security of the configuration.

[0038] In specific implementation scenarios, based on the above solutions, the rule base can be written using a standardized lightweight description language (such as YAML or XML format), which makes it easier for non-technical personnel to read, edit and verify, thus reducing the maintenance threshold.

[0039] The automated testing tool simulates user login operations, accesses the original financial system website, completes the login, and obtains authorization information for data access.

[0040] As described above, the system invokes a testing tool with automated control capabilities (such as Playwright, Puppeteer, and similar technologies) to launch a controllable browser instance, automatically navigating to the login page of the user's selected financial system. Subsequently, the tool simulates keyboard input of the username and password based on preset or user-inputted account information, triggering the login button click action to complete the login process. During this process, the system can recognize and handle common security verification mechanisms, such as image verification codes, SMS verification codes, QR code login, and swipe verification. Some complex verifications can be completed with user assistance through a human-machine collaboration mechanism.

[0041] After successful login, the automated tool extracts key authorization information from the browser session, including but not limited to session tokens, authentication cookies, and OAuth authorization codes. This information serves as authentication credentials for subsequent access to protected pages or calls to restricted APIs, ensuring that the system can legally obtain the user's financial data within the scope of the user's authorization and avoiding the risk of unauthorized access.

[0042] Based on user authorization, data access is achieved by simulating legitimate operation paths. This not only avoids the barriers of interface encryption and authentication, but also complies with relevant regulations on network security and data privacy protection, providing a feasible technical path for scenarios where data cannot be obtained through traditional APIs or databases.

[0043] For example, suppose a user needs to migrate financial data from the "Kingdee Cloud Star" system: The system launches the automated testing tool, opens a browser window, and redirects to the Kingdee Cloud Star login URL (e.g., https: / / cloud.kingdee.com). The tool automatically fills in the user's pre-configured username and password and simulates clicking the "Login" button. A pop-up SMS verification code input box appears on the page. The system prompts the user to enter the verification code received on their mobile phone in the migration tool interface. After the user enters the code, the tool fills the verification code into the webpage and submits it. After successful login, the browser redirects to the financial data homepage. At this point, the automated tool captures a cookie named "KDSessId" and a Bearer Token from the "Authorization" header in the current session. The system saves this authorization information for subsequent access to protected resources such as accounting subjects and opening balances, while closing the visible browser window and switching to a headless background mode to continue performing data collection tasks.

[0044] The entire process fully simulates the real user operation flow, ensuring that data access rights within the user's authorized scope are legally obtained without compromising the original system's security mechanisms.

[0045] It should be noted that, in specific implementation scenarios, the system can also integrate a general verification adaptation layer on the basis of the above solution, which can support the identification and processing of various secondary verification methods, such as time-based dynamic passwords (TOTP), hardware UKeys, biometric prompts, etc. For verification steps that require manual intervention, a standardized human-computer interaction interface is provided to ensure that login can still be completed under complex security policies.

[0046] In specific implementation scenarios, based on the above solutions, the system can switch to a visible browser mode during the debugging or exception handling phase to observe the operation process; during normal operation, it automatically switches to headless mode to improve execution efficiency and reduce resource consumption.

[0047] In specific implementation scenarios, based on the above solutions, the system can monitor the validity period of authorization information and automatically trigger a silent refresh mechanism (such as calling the refresh token interface) before it expires, maintaining a long connection session and avoiding data collection failure due to session interruption.

[0048] In specific implementation scenarios, based on the above solutions, for enterprise environments that adopt a unified identity authentication platform, the system can simulate the SSO login process, first logging into the unified portal and then jumping to the financial subsystem, to achieve seamless access to the integrated system.

[0049] In specific implementation scenarios, based on the above solution, all simulated operations (such as clicking, inputting, and jumping) can be recorded as operation logs, supporting post-event auditing and anomaly playback, which facilitates the investigation of login failure reasons or meets compliance review requirements.

[0050] In specific implementation scenarios, in addition to the above solutions, to address the detection and blocking of automated tools by some financial systems, the system can be configured with browser feature spoofing functionality to simulate the User-Agent, screen resolution, plugin list, and other characteristics of a real user's browser, thereby improving the login success rate.

[0051] In specific implementation scenarios, based on the above solution, parallel login and data collection of multiple accounts under the same vendor can also be supported. The system can maintain a separate session context for each account to avoid permission confusion.

[0052] Based on the authorization information, determine whether the financial data in the original financial system can be obtained through the interface. If so, call the corresponding data interface to obtain the financial data and use the decryption plugin to decrypt the encrypted data content. If it cannot be obtained through the interface, control the automated testing tool to run in headless mode, extract the financial data displayed on the original financial system webpage, and obtain all paginated data by simulating page turning operations.

[0053] As mentioned above, after completing user login and obtaining valid authorization information, the system first determines whether the target financial system has opened data interfaces that can be accessed programmatically (such as RESTful APIs, GraphQL interfaces, etc.). This determination can be achieved in various ways, such as: sending a lightweight request to a preset interface probe address to detect the response status code and data format; or querying the local rule base for the identifier field regarding whether the vendor version supports interface calls.

[0054] If the system determines that it supports API calls, it uses the previously obtained authorization information (such as a token or cookie) as identity credentials to send a request to the corresponding financial data interface (such as "Get Accounting Subject", "Query Opening Balance", "Export Voucher List", etc.) to obtain structured data. Since most financial systems' interface return data is encrypted (such as AES encrypted response body, HMAC signature verification), the system needs to call the pre-loaded decryption plugin to restore the ciphertext according to the vendor's specific decryption logic, obtain readable plaintext data, and temporarily store it for subsequent processing.

[0055] If the system determines that API calls are not supported (e.g., the system's API is not open, API permissions are restricted, or the response is abnormal), the system switches to web page data extraction mode. In this mode, the automated testing tool runs in the background in "headless mode," meaning it does not display a visual browser window but only loads the page content into memory. The tool uses authorized information to access the financial system's data display pages (such as the account list page and voucher query page), extracting the financial data displayed on the page by parsing tables, tags, or DOM elements rendered by JavaScript in the HTML structure. For large datasets displayed in paginated formats, the system automatically identifies pagination controls (such as "next page" buttons and page number bars), simulates user clicks, loads and collects all paginated content page by page until the last page or duplicate data is detected, ensuring data integrity.

[0056] A dual-mode data acquisition mechanism was built, which dynamically switches between interface calls and web page crawling according to the system environment, balancing efficiency and compatibility. This solves the data acquisition obstacles caused by closed or encrypted interfaces and improves the adaptability of migration tools in complex real-world scenarios.

[0057] For example, let's take the case where a user needs to migrate accounting subject data from the "Yonyou U8+" system: The system detected that this version supports REST API interfaces, and the rule base is marked "api_enabled=true"; Use the OAuth2.0 Token obtained during the login phase to send a GET request to the " / api / v2 / financial / chart-of-accounts" interface; The interface returns an encrypted JSON data packet. The system calls the "Yonyou U8 Dedicated Decryption Plugin" to decrypt the data based on the preset AES key and IV vector to obtain the plaintext subject list. After the data is parsed, it is stored in the original data table, completing the interface mode data collection.

[0058] Let's take another example: a user migrating voucher data from a "small financial SaaS platform": The system attempted to access the preset interface address but returned a 404 error. Based on the rule base flag "api_enabled=false", it was determined that the interface call was not supported. The system control automation tool opens the voucher query page (e.g., / finance / voucher / list) in headless mode. Tool analysis page

[0059]

[0060]

[0061]

[0062]

[0063]

[0064]

[0065]

[0066]

[0067]

[0068]

[0069]

[0070]

[0071]

[0072]

[0073]

[0074]

[0075]

[0076]

[0077]

[0078]

[0079]

[0080]

[0081]

[0082]

[0083]

[0084]

[0085]

[0086]

[0087]

[0088]

[0089]

[0090]

[0091]

[0092]

[0093]

[0094]

[0095]

[0096]

[0097]

[0098]

[0099]

[0100]

[0101]

[0102]

[0103]

[0104]

[0105]

[0106]

[0107]

[0108]

[0109]

[0110]

[0111]

[0112]

[0113]

[0114]

[0115]

[0116]

[0117]

[0118]

[0119]

[0120]

[0121]

[0122]

[0123]

[0124]

[0125]

[0126]

[0127]

[0128]

[0129]

[0130]

[0131]

[0132]

[0133]

[0134]

[0135]

[0136]

[0137]

[0138]

[0139]

[0140]

[0141]

[0142]

[0143]

[0144]

[0145]

[0146]

[0147]

[0148]

[0149]

[0150]

[0151]

[0152]

[0153]

[0154]

[0155]

[0156]

[0157]

[0158]

[0159]

[0160]

[0161]

[0162]

[0163]

[0164]

[0165] Figure 2 Figure 2

[0166]

[0167]

[0168]

[0169]

[0170]

[0171]

[0172]

[0173]

[0174]

[0175]

[0176]

[0177]

[0178]

[0179]

[0180]

[0181]

[0182]

[0183]

[0184]

[0185]

[0186]

[0187]

[0188]

[0189]

[0190]

[0191]

[0192]

[0193] The system extracts the date, number, summary, account, and amount fields for each voucher from all rows of data within the page. Upon detecting a "Next Page" link at the bottom of the page, it simulates clicking to load the second page of data and continues extraction. If the data content remains unchanged after two consecutive page turns or a "No more data" message appears, page turning stops, confirming that all vouchers have been collected. The system automatically switches between these two paths based on its capabilities, ensuring data acquisition can be completed regardless of whether an open interface is available. It should be noted that in specific implementation scenarios, the system can record historical availability data for each vendor's interface, forming an interface stability model. This allows for prioritizing highly available paths during subsequent migrations, improving overall execution efficiency. Furthermore, in specific implementation scenarios, the system can also allow some data to be acquired via interfaces (e.g., account) and some data to be extracted via web pages (e.g., auxiliary accounting details) within the same migration task, enabling multi-source collaborative data collection. In specific implementation scenarios, building upon the above solutions, when updates to the financial system's page layout render the original data extraction rules invalid, the system can activate a DOM structure comparison function to automatically match the paths of elements in the old and new pages, or prompt the user to re-mark the positions of key fields, thus improving robustness. In specific implementation scenarios, building upon the above solutions, the system can also record the page numbers or timestamps obtained during pagination data collection. If the task is interrupted, execution can resume from the last collection position, avoiding duplicate crawling and improving fault tolerance. In specific implementation scenarios, building upon the above solutions, the system can also support users setting the collection order (e.g., subject before voucher). The system can rationally schedule interface calls and web page crawling tasks based on dependencies, avoiding subsequent conversion failures due to data loss. In specific implementation scenarios, building upon the above solutions, the system can also monitor interface response latency and web page loading speed in real time. If the interface response times out or the error rate is too high, the system can dynamically degrade to web page mode to ensure the task continues. In specific implementation scenarios, based on the above solutions, the system can be configured with strategies such as request interval control, proxy IP rotation, and behavior randomization to address anti-scraping mechanisms such as frequency limits and IP blocking set by certain systems, thereby improving the success rate of data collection while remaining legal and compliant. In specific implementation scenarios, real-time collection logs and progress displays can also be provided, allowing users to view whether they are currently in the interface call or webpage extraction stage, as well as the amount and number of pages of data already acquired, enhancing operational transparency. The acquired financial data is stored in a raw data table, and the application processing program is started to clean and convert the raw data. The cleaning and format conversion are performed according to the preset field mapping relationships and data validation rules in the rule base. As mentioned above, after data collection is completed, the system first stores the raw data uniformly in an intermediate-level raw data table. This table serves as a temporary storage area for data processing, retaining all field contents and their original format obtained from the collection, forming a traceable data snapshot for easy subsequent auditing and problem investigation.The original data table is designed to support dynamically expanded fields, accommodating diverse data structures output by different vendors' systems without requiring a pre-fixed table structure. Subsequently, the system automatically triggers the application processing program, initiating the data cleaning and format conversion process. This program performs multi-dimensional processing on the original data based on the field mapping relationships and data validation rules defined in the pre-loaded rule base: Field Mapping: Converting field names, encoding methods, and classification logic from the original system to the format required by the target system according to the corresponding relationships in the rule base. For example, mapping "Subject Code" to "Accounting Subject Code," and converting "Customer Auxiliary" to "Business / Relationship Providers," etc. Data Cleaning: Removing invalid, duplicate, or incorrectly formatted data entries, correcting null values, abnormal characters, and inconsistent units, ensuring data integrity and accuracy. Format Standardization: Unifying basic data formats such as date format, amount precision, and text encoding to conform to the input requirements of the target system. Logical Validation: Checking the rationality of key fields according to preset data validation rules, such as whether the hierarchical structure of accounting subjects is compliant, whether auxiliary accounting items are complete, and whether the initial direction is correct. The entire cleaning and conversion process is executed automatically in the background without manual intervention, which improves processing efficiency and reduces the risk of errors caused by human operation. The processed data will be organized into a structured format that meets the requirements of the target financial system's import interface or template, preparing it for subsequent system import. For example, suppose the system collects a batch of accounting subject data from "Kingdee KIS Professional Edition". The original data includes fields such as: "Subject Code", "Subject Name", "Subject Type", "Balance Direction", and "Whether it is the Last Level". The system writes all this data into the original data table, preserving the original records. The application processor starts and reads the mapping rules from the rule base for "Kingdee KIS → Inspur Cloud Accounting": "Subject Code" → "Accounting Subject Code" (length extended to 12 digits, padded with zeros if necessary). When the "Subject Type" value is "Asset", it is mapped to "1", "Liability" is mapped to "2", and so on. In "Balance Direction", "Debit" is converted to "Debit", and "Credit" is converted to "Credit". If "Whether it is the final level" is "No", the flag of its subordinate detailed subjects is prohibited from being activated. At the same time, the verification rules are executed: check whether the codes of all first-level subjects begin with "1", "2", "3", "4", or "5" (representing assets, liabilities, equity, costs, and profits and losses); verify whether highly liquid subjects such as "Cash" and "Bank Deposits" have the "Journal" flag set; remove subject records with empty or duplicate codes; after the above processing, a new dataset that conforms to the import template of the Inspur Cloud Accounting system is generated, ready to enter the import stage. This process enables automated conversion from heterogeneous source data to a standard target format, ensuring semantic consistency and system compatibility of the migrated data.It should be noted that, in specific implementation scenarios, the above solutions can be further enhanced by dividing the cleaning process into two stages: "preliminary cleaning" (duplicate and empty data removal) and "deep transformation" (mapping and validation). Users can choose to execute these stages step by step or complete them with a single click, improving operational flexibility. In specific implementation scenarios, advanced users or administrators can add custom validation logic to the rule base, such as "Accounts receivable must enable customer-assisted accounting," and the system will automatically execute such business rule checks during the conversion process. In specific implementation scenarios, for data that does not meet the validation rules but does not meet the direct discard criteria, the system can move it to the "data pending review area" and generate an anomaly report for manual review to determine whether to correct or skip it. In specific implementation scenarios, when different customers of the same vendor use slightly different customized systems, the rule base supports configuring a "basic rules + customer-customized rules" overlay mode to achieve personalized adaptation. In specific implementation scenarios, based on the above solutions, the system can record the transformation trajectory of each data point (i.e., the "original value → target value" mapping chain), supporting reverse restoration to the original data when necessary, enhancing the traceability and security of data operations. In specific implementation scenarios, based on the above solutions, for system versions accessed for the first time, if some fields lack explicit mapping rules, the system can automatically recommend possible mapping schemes based on features such as field name semantic similarity and data type matching, assisting users in quick configuration. In specific implementation scenarios, based on the above solutions, for large-scale data migration tasks, the system can process the original data in chunks, starting multiple transformation threads to execute in parallel, significantly improving processing speed. In specific implementation scenarios, based on the above solutions, before formal execution, a small sample data transformation preview interface can be provided, allowing users to intuitively view the before-and-after comparison of cleaning, confirming that the rule configuration is correct before starting full processing. After data cleaning and transformation are completed, the processed financial data is imported into the target financial system. If the corresponding account set does not exist in the target financial system, a new account set is created; if it already exists, an overwrite or incremental import operation is performed. As mentioned above, after data cleaning and transformation are completed, the system enters the import preparation phase. First, the system checks whether a matching set of accounts already exists in the target environment through the target financial system's open interface or standard import mechanism. The matching criteria typically include key identifying information such as the account set name, accounting system type, accounting period, and organizational unit code. This check is performed by querying the target system's account set management module, ensuring the accuracy and reliability of the results. If the system determines that a corresponding account set does not exist in the target environment, it automatically triggers the new account set creation process.The system submits a creation request to the target system based on a pre-defined account set configuration template. This request includes basic parameters such as account set name, affiliated unit, accounting standards (e.g., Enterprise Accounting Standards or Small Business Accounting Standards), functional currency, accounting period settings, and permission model. Once the target system returns a confirmation of successful account set creation and a unique account set identifier, the system associates the cleaned and transformed financial data (e.g., accounting subjects, opening balances, auxiliary accounting items, etc.) with the new account set and performs an import operation. If the system determines that a corresponding account set already exists in the target environment, it selects to perform either an overwrite import or an incremental import based on the user-defined import strategy or system default rules: Overwrite import: Clears existing related data (e.g., account system, opening balances, etc.) in the target account set and rewrites it using the data from this migration as the sole source. This is suitable for data initialization or re-migration scenarios. Incremental import: While retaining the original data, it only appends newly added or changed data entries to the target account set. This is suitable for multiple migrations or data entry supplementation scenarios, avoiding the loss of historical data due to duplicate data overwriting. The entire import process supports transaction control. That is, if any step fails during the import of key data modules (such as accounts + beginning balances), the system can roll back the imported part to ensure the consistency and integrity of the accounting data. For example, suppose a user is migrating financial data from the "Yonyou T3" system to the "Inspur Cloud Accounting" platform: Data cleaning and transformation have been completed, generating a list of accounts and opening balance data conforming to the Inspur Cloud Accounting format; the system connects to the Inspur Cloud Accounting platform and checks if an account set named "XX Co., Ltd._2025" exists; if the query result is empty, the system automatically calls the "Create Account Set" interface, requiring the user to fill in the company name, activation period as "January 2025", accounting system as "Small Enterprise Accounting Standards", and functional currency as "RMB"; after the account set is successfully created, the system imports the transformed accounting accounts one by one, and simultaneously writes the opening balance and direction of each account; if the account set already exists, the system prompts the user to choose: Select "Overwrite Import": the system first clears the accounts and opening data in the original account set, and then re-imports the new data to ensure complete consistency with the source system; Select "Incremental Import": the system only imports newly added accounts in the source system (such as adding a "Research and Development Expenditure" account), and the existing account data remains unchanged; after the import is completed, the system records the operation log and notifies the user of the task status. This process achieves a seamless transition from intermediate data to the target system, ensuring the migration results are implementable and manageable. It's worth noting that in specific implementation scenarios, based on the above solution, users can customize account set matching conditions, such as matching only by name or combining the activation period with accounting regulations to improve matching accuracy and avoid misjudgments that could lead to the overwriting of incorrect account sets. In specific implementation scenarios, in addition to the above solution, the system can provide preset import strategy templates such as "Initial Migration," "Re-initialization," and "Supplementary Update," which users can select with a single click, and the system will automatically match the corresponding account set creation or import method, reducing operational complexity.In specific implementation scenarios, based on the above solutions, users can choose to cover only specific module data (e.g., update only accounting subjects while retaining existing vouchers) to achieve refined data management and avoid the risks associated with full coverage. In specific implementation scenarios, based on the above solutions, before performing coverage or incremental import, the system can compare key fields (such as account codes and auxiliary item names) in the source data and target accounting set for conflicts and generate a conflict report for user confirmation of handling methods. In specific implementation scenarios, based on the above solutions, the import process can be broken down into multiple stages such as "basic data → opening balance → auxiliary accounting → vouchers," allowing users to execute step by step for easier progress monitoring and problem identification. In specific implementation scenarios, based on the above solutions, after import completion, the system can mark successfully migrated data as "synchronized" and update the status in the source system or migration tool to prevent duplicate migrations. In specific implementation scenarios, based on the above solutions, for group enterprises, it supports merging and importing multiple original system accounting sets into different sub-accounts or consolidated reporting systems of the target system, achieving organizational-level data integration. In specific implementation scenarios, in addition to the above solutions, visualization information such as real-time import progress bars, processed data volume, and number of failed entries can be provided, allowing users to monitor the migration status at any time and pause or terminate the operation if necessary. Furthermore, in specific implementation scenarios, before creating an account set or performing an overwrite import, the system can verify the current user's operational permissions in the target system and record audit information such as the operator, time, and IP address to meet compliance requirements. After data import is complete, data consistency verification is performed, including comparing the total amount and structural distribution of key data items before and after migration, and generating a migration report containing the verification results. As mentioned above, after financial data is successfully imported into the target system, the system automatically initiates a data consistency verification mechanism, evaluating the migration quality by comparing key financial data in the source system (before migration) and the target system (after migration) from multiple dimensions. The verification content mainly includes two levels: Total consistency verification: numerical comparison of key data items with summable properties before and after migration. For example: Are the sum of the debit and credit balances of all accounting subjects equal at the beginning of the period? Are the sum of the balances of the general ledger subjects and their subordinate subsidiary accounts consistent? Does the sum of the balances of customer auxiliary accounting items match the balance of the "Accounts Receivable" account? Are statistical indicators such as the number of vouchers and the total number of subjects consistent? Structure distribution consistency verification: Check the correspondence between the data in logical structure and classification distribution. For example: Is the hierarchical structure of accounting subjects (level 1, level 2, level 3) completely retained? Are the activation status and combination methods of auxiliary accounting items consistent with the original system? Are the subject attributes (such as cash subjects, bank subjects, quantity accounting, etc.) correctly migrated? Have the distribution characteristics of data types (such as the distribution of amount ranges and the proportion of subject categories) changed significantly?After verification, the system summarizes all comparison results and automatically generates a structured migration report. This report not only includes overall assessment conclusions such as "pass," "warning," and "failure," but also details the specific content of any anomalies, their discrepancies, possible causes, and suggested solutions, providing users with traceable and auditable migration credentials. This builds a consistency verification system oriented towards financial semantics, going beyond simple field comparisons to ensure the credibility of data migration from a business logic perspective, thus overcoming the shortcomings of traditional migration methods that are "operation-heavy and verification-light." For example, suppose a user migrates the 2025 accounting data from the "Kingdee K3" system to the "Inspur Cloud Accounting" platform: After the data import is complete, the system automatically performs a consistency check: The opening balance of the "Accounts Receivable" account in the source system is 1,200,000 yuan, and the corresponding account balance in the target system is also 1,200,000 yuan, so it is determined to be consistent; Checking the total balance of customer auxiliary details under "Accounts Receivable", the source system is 1,200,000 yuan, and the target system is 1,195,000 yuan, a difference of 5,000 yuan is found; Further investigation reveals that the 5,000 yuan balance of "Customer A" was not successfully written, and the system marks this entry as "auxiliary accounting data lost"; Checking the account structure, the source system has 286 accounts at 3 levels, and the target system has 286 accounts, and the coding rules at each level are consistent, so the structure distribution is correct; The total number of vouchers in the source system is 1,542, and the target system has 1,542, so the quantity is consistent. The system generates a migration report, which includes: Overall Assessment: Basically passed, with 1 warning; Difference Details: Customer A's accounts receivable auxiliary balance is missing 5,000 yuan; Suggested Action: It is recommended to re-execute the partial migration of this customer's data or manually supplement it; Attachment: A difference data comparison table can be exported. Based on the report's prompts, users can decide whether to re-migrate or accept the current result, ensuring the reliability of the final accounting data. It should be noted that in specific implementation scenarios, based on the above solution, users or administrators can customize the thresholds and weights of verification items according to the actual needs of the enterprise. For example, setting "a difference rate exceeding 0.1% is considered a failure," or "missing non-critical auxiliary items can be downgraded to a warning." In specific implementation scenarios, based on the above solution, it can also support performing verification at different nodes in the migration process, such as "post-collection verification," "post-cleaning verification," and "post-import verification," forming a full-process quality monitoring chain to facilitate problem localization. In specific implementation scenarios, based on the above solutions, the system can intelligently recommend repair solutions based on common error patterns (such as field truncation and encoding mapping errors), such as "suggest adjusting the subject code length limit" or "re-enabling customer auxiliary accounting." In specific implementation scenarios, statistical methods can also be introduced to analyze data distribution trends, such as calculating data entropy values ​​and standard deviation change rates before and after migration, to identify potential data distortion or structural aberrations.In specific implementation scenarios, building upon the above solutions, for scenarios involving merging multiple original system accounts into a single target account, the system can add a "merger logic verification" to ensure that the total amount after merging matches the sum of each source account. In specific implementation scenarios, based on the severity of the verification results, different levels of notification can be triggered. For example, an SMS reminder can be sent for "failure," while a "warning" notification can only be displayed within the system, improving operational efficiency. In specific implementation scenarios, based on the above solutions, users can select different migration report templates (such as simplified, audit, and technical versions) and add information such as the company logo and responsible person's signature to meet internal and external reporting needs. In specific implementation scenarios, when conditions permit, the system can call the target system's internal verification interface (such as "trial balance check") to obtain the system's native verification results and cross-compare them with the verification results of the migration tool, enhancing credibility. In specific implementation scenarios, for multiple migration tasks, the system can save verification reports from each migration, supporting horizontal comparison of the quality change trends of migration results across different versions, assisting in optimizing migration strategies. According to one embodiment of this application, the rule base includes accounting subject code conversion rules, voucher classification mapping rules, auxiliary accounting field matching rules, and target system code prefix information for different vendors' financial systems. The field mapping relationship is used to convert data fields in the original financial system into field formats recognizable by the target financial system. As mentioned above, the rule base is a core configuration set used to support format conversion and semantic mapping of financial data between different systems. This rule base contains adaptation rules for different financial system vendors and their specific versions, ensuring that the migration process can accurately identify and process the data characteristics of each system. Among them, the accounting subject code conversion rules define how the subject code structure in the original financial system corresponds to that in the target financial system. For example, if the source system uses a 4-2 structure coding method, while the target system requires a 4-3 structure, then this rule determines the conversion method of padding, truncating, or re-classifying to make the subject code conform to the hierarchical requirements of the target system. The voucher classification mapping rules are used to map the voucher types (such as receipt vouchers, payment vouchers, transfer vouchers, journals, etc.) in the original system to the corresponding voucher categories in the target system. Because different vendors have different naming and classification methods for voucher types, this rule ensures that vouchers can still be correctly classified after migration, without affecting subsequent accounting processing. The auxiliary accounting field matching rule clarifies how auxiliary accounting items (such as customers, suppliers, departments, employees, projects, etc.) enabled in the original system are matched with auxiliary accounting dimensions in the target system. This rule includes not only name correspondence but also mapping of attributes such as accounting level, data format, and whether fields are required, ensuring the integrity and usability of auxiliary accounting data.The target system encoding prefix information refers to the fixed characters added during the conversion process to distinguish the data source or adapt to the target system's encoding system. For example, a unified prefix is ​​added to all migrated accounts in the target system to avoid conflicts with existing accounts or to facilitate later management and identification. Field mapping relationships are specific correspondences established based on the above rules, used to guide the system in automatically converting each data field in the original financial system into a field format that the target financial system can recognize and accept during the data cleaning and conversion phase. This mapping process covers a comprehensive conversion of field names, data types, lengths, precision, and business meanings, ensuring accurate data migration in semantics and structure. According to one embodiment of this application, the decryption plugin is an extensible dynamic decryption module that supports multiple encryption algorithm types; the decryption processing includes identifying the encryption identifier of the content returned by the data interface, and calling the corresponding decryption algorithm plugin to decrypt the data based on the encryption identifier, ensuring the correct restoration of plaintext data. As mentioned above, the decryption plugin is an extensible dynamic decryption module used to process encrypted data obtained from the original financial system during data migration. Since different vendors' financial systems often use different encryption algorithms to protect sensitive information when providing interface data or transmitting web page content, it is necessary to have decryption capabilities compatible with multiple encryption methods. This decryption module adopts a plug-in architecture, supporting multiple encryption algorithm types, such as symmetric encryption algorithms (e.g., AES, SM4), asymmetric encryption algorithms (e.g., RSA), and data signature verification mechanisms (e.g., HMAC-SHA256). Each encryption algorithm corresponds to an independent decryption algorithm plugin. These plugins can be dynamically loaded and invoked during system runtime without recompiling the main program, facilitating the subsequent expansion of new decryption functions. During decryption processing, the system first analyzes the received data content to identify the encryption identifiers it contains. These identifiers can be specific fields in the response header, flag bits within the data packet, or preset protocol features, indicating the encryption method used for the current data. Based on the identified encryption identifier, the system automatically matches and invokes the corresponding decryption algorithm plugin. For example, when the identifier indicates that the data is encrypted using AES-128-CBC mode, the system loads the AES decryption plugin and decrypts the ciphertext using a pre-configured key and initialization vector parameters; if the identifier indicates the SM4 national cryptographic algorithm, the national cryptographic decryption plugin is invoked for processing. In this way, the system can accurately select the correct decryption method to restore ciphertext to plaintext, ensuring that subsequent data parsing and conversion operations are based on real and complete original data. The entire decryption process is executed in a controlled environment, guaranteeing data security and the correctness of the restoration results.According to one embodiment of this application, the step of obtaining all paginated data by simulating page-turning operations specifically includes: an automated testing tool parses the pagination control information in the current page, simulates a user clicking the next page button, and continuously obtains financial data from subsequent pages until a last page marker is detected or two consecutive pages of data content are duplicated, at which point page-turning stops. As mentioned above, when obtaining financial data through a webpage, due to the large amount of data, the original financial system usually displays the data in pages, with each page showing only a fixed number of records. In order to obtain all financial data completely, the system needs to simulate the user's continuous page-turning operation and extract information page by page. In the specific execution process, after loading the current data page, the automated testing tool first parses the pagination control information in the page. This control is usually represented by a "next page" button, page number links, page-turning arrows, or text prompts such as "Total X pages". The system identifies the existence of these elements and their clickable status to determine whether there are any subsequent pages to load. Subsequently, the tool simulates the user clicking the "next page" button, triggering a page update, and waits for the new page to load completely. After the new page is rendered, the system extracts the financial data displayed therein, such as accounting subjects, voucher entries, or auxiliary accounting information, and temporarily stores them. This process is repeated cyclically. After each page turn and data extraction, the system continues to check the status of the new pagination control. The page turn operation continues until either of the following termination conditions is met: first, a clear last page indicator is detected on the page, such as the "Next Page" button becoming unclickable or displaying a "This is the last page" message; second, the extracted data content of two consecutive pages is found to be completely identical, indicating that the system has no new data to load, possibly indicating a pagination logic anomaly or that all data has been displayed. Through the above mechanism, the system can automatically and completely obtain all financial data displayed in the pagination, avoiding information loss due to only collecting data from the first page, and ensuring the comprehensiveness and accuracy of the migrated data. According to one embodiment of this application, the data cleaning and format conversion also includes integrity verification of the financial data, specifically: comparing the total debit amount with the total credit amount in each voucher record; when the two are not equal, the voucher is marked as abnormal data and recorded in the log, while the subsequent import process is paused, awaiting manual confirmation or correction. As described above, during the financial data cleaning and format conversion process, the system performs integrity verification on the data to ensure that it complies with basic accounting rules. One key verification step is checking the debit and credit balance of each voucher record. Specifically, when processing each accounting voucher, the system calculates the sum of all debit entries and the sum of all credit entries. According to the double-entry bookkeeping principle, the total debit amount of each valid voucher must equal the total credit amount; otherwise, the voucher is not logically valid. The system performs a comparison operation, and if it finds that the total debit amount of a voucher is not equal to the total credit amount, it determines that the voucher has data anomalies.At this point, the system marks the voucher as "abnormal data" and writes its relevant information to the system log. The log records information such as the voucher number, date, involved accounts, debit and credit amounts, difference values, and the time the abnormality was discovered, facilitating subsequent tracing and analysis. Simultaneously, to prevent erroneous data from entering the target system and causing accounting distortion, the system automatically pauses subsequent data import processes. No new import operations will continue until the abnormal voucher is processed. The system prompts the user to view the abnormal log and provides correction suggestions, such as re-verifying the original voucher, manually adjusting the amount, or re-exporting the data from the source system. The system will only resume the import process after the user confirms that the abnormality has been processed or explicitly chooses to skip the voucher and continue. This mechanism effectively ensures the correctness of the accounting logic of the migrated data, avoiding the impact of a single unbalanced voucher on the accuracy of the overall accounting system. According to one embodiment of this application, the data consistency verification includes: calculating the difference in distribution entropy between the original data before migration and the data in the target system after migration; when the entropy difference exceeds a preset threshold, it is determined that the data distribution has changed, and a risk item indicating data distortion or loss is marked in the migration report. As mentioned above, data consistency verification is a crucial step in assessing whether financial data remains complete and stable before and after migration. Specifically, calculating the entropy difference in data distribution allows for a quantitative assessment of whether abnormal changes have occurred in the data structure. Before migration, the system analyzes the distribution characteristics of the original data and calculates its distribution entropy value. Distribution entropy is a statistical indicator that measures the degree of data dispersion and information uniformity, reflecting the distribution of data across different categories or intervals. For example, in accounting subject data, entropy reflects the balanced distribution of the number of subjects at each level; in monetary data, entropy reflects the distribution characteristics of the number of vouchers across different monetary intervals. After the data is imported into the target system, the system collects data of the same type again and calculates the distribution entropy value of the migrated data. The entropy value after migration is then compared with the entropy value before migration to obtain the entropy difference. The system sets a preset threshold, pre-configured based on the actual business scenario and data type, to determine whether the entropy change is within an acceptable range. When the calculated entropy difference exceeds this threshold, it indicates a significant change in the data distribution, potentially indicating problems such as data centralization, data loss, duplicate writes, or classification errors. At this point, the system determines that this type of data poses a potential risk and marks the data category in the generated migration report, indicating the possibility of data distortion or loss. For example, a significant decrease in the subject distribution entropy value may mean that a large number of detailed subjects have not been migrated correctly; a sudden change in the distribution entropy value of the amount range may indicate that some voucher data is missing or the amount has been incorrectly grouped. This method not only focuses on whether the total amount of data is consistent, but also deeply analyzes the stability of its internal structure, enabling it to discover hidden data problems that traditional simple comparisons cannot identify, thereby improving the credibility of the migration results and the comprehensiveness of the verification.According to one embodiment of this application, creating a new account set includes: sending a creation request to the account set management interface of the target financial system, carrying the account set name, accounting system type, activation period, and basic parameter information; after the interface returns a unique identifier for the account set, the cleaned and transformed financial data is associated with the account set for import. As mentioned above, creating a new account set in the target financial system is a key operation in the data migration process, applicable to scenarios where a corresponding account set has not yet been established in the target system. This operation is completed by programmatically calling the account set management interface of the target system, avoiding reliance on manual creation and improving migration efficiency and accuracy. Specifically, the system sends a creation request to the account set management interface provided by the target financial system according to the information configured in the migration task. This request contains the basic parameters required to create the account set, mainly including: account set name, used to identify the unit and period to which the account set belongs; accounting system type, such as enterprise accounting standards, small business accounting standards, or specific industry accounting systems, to ensure consistent accounting rules; activation period, i.e., the accounting year and month in which the account set begins to be used, used to initialize period settings; and other necessary basic parameters, such as local currency, accounting subject system version, voucher numbering rules, and auxiliary accounting activation status. After receiving the creation request, the target financial system verifies the validity of the parameters and performs an internal account set initialization operation. Upon successful creation, the system returns a unique account set identifier, which is used to accurately point to the account set in subsequent operations and serves as the sole credential for data writing and management. After obtaining the unique account set identifier, the migration system associates the cleaned and format-converted financial data, including accounting subjects, opening balances, and auxiliary accounting information, with this identifier. Subsequently, according to the target system's import rules, the data is written to the account set in batches, ensuring that all data belongs to the correct account set environment. This process automates the connection between account set creation and data import, ensuring the continuity of the migration process and the accuracy of data attribution, and is a crucial step in achieving unattended financial data migration. According to one embodiment of this application, the migration report includes the total amount of data migrated, the number of successfully imported items, a list of abnormal data items, the data difference rate, the interface call success rate, and the consistency verification results. The migration report is displayed through a graphical interface and supports export to a standard document format. As mentioned above, the migration report is a comprehensive summary of the entire financial data migration process and results, used to evaluate the execution quality and data accuracy of the migration task. This report includes several key metrics reflecting the progress of each stage of the migration. The total data migration volume represents the total number of original financial data entries involved in this migration task, including the total number of various data types such as accounting subjects, opening balances, vouchers, and auxiliary accounting items. The number of successfully imported entries refers to the number of valid data entries actually written into the target financial system after cleaning, transformation, and verification, used to measure the migration completion rate. The list of abnormal data entries details data items identified as non-compliant or erroneous during the migration process.Each anomaly record includes data type, original number, cause of the anomaly (e.g., missing field, format error, debit / credit imbalance), and processing status, facilitating user tracing and correction of issues. The data discrepancy rate is calculated by comparing key data items (e.g., general ledger balance, total number of vouchers) before and after migration, used to quantify the accuracy of the migration results. A lower discrepancy rate indicates higher migration consistency. The interface call success rate reflects the success rate of system calls to the original financial system or target system interfaces during the data acquisition phase. It is calculated as the ratio of successful responses to total requests, used to assess the stability of network communication and system integration. The consistency verification results summarize the conclusions of various data comparisons performed after migration, including the pass / fail status of verification items such as total consistency, structural distribution consistency, and debit / credit balance, as well as risk warnings regarding potential data distortion or loss. All of the above is displayed through a graphical interface, allowing users to view migration progress charts, anomaly distribution maps, verification result summaries, and other visual information to intuitively understand the migration status. Simultaneously, the system supports exporting migration reports to standard document formats such as PDF, Excel, or Word files for archiving, printing, or submission to auditing and financial management personnel for review. The exported report maintains a clear format and complete content, meeting the enterprise's requirements for traceability and auditability of the data migration process. A second aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the method described in any of the embodiments of the first aspect above. An example of the physical structure of an electronic device is shown. As illustrated, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840.The processor 810 can call logical instructions in the memory 830 to execute the method in any embodiment of the first aspect described above. The method includes: a user selecting the vendor and version of a target financial system; loading the corresponding rule base and decryption plugin according to the vendor and version; simulating user login operations using an automated testing tool, accessing the original financial system website and completing the login, and obtaining authorization information for data access; based on the authorization information, determining whether financial data in the original financial system can be obtained through an interface; if so, calling the corresponding data interface to obtain the financial data, and using the decryption plugin to decrypt the encrypted data content; if not, controlling the automated testing tool to run in headless mode to extract... The financial data displayed on the original financial system webpage is obtained by simulating page-turning operations to acquire all paginated data. The acquired financial data is stored in the original data table, and the application processing program is launched to clean and convert the original data. The cleaning and format conversion are performed according to the preset field mapping relationships and data validation rules in the rule base. After the data cleaning and conversion are completed, the processed financial data is imported into the target financial system. If the corresponding account set does not exist in the target financial system, a new account set is created. If it already exists, an overwrite or incremental import operation is performed. After the data import is completed, data consistency verification is performed, including comparing the total amount and structural distribution of key data items before and after the migration, and a migration report containing the verification results is generated. In addition, the logic instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present 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 described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the methods provided by the above-described methods. The method includes: a user selecting the vendor and version of a target financial system; loading the corresponding rule base and decryption plugin according to the vendor and version; simulating user login operations using an automated testing tool, accessing the original financial system website and completing the login, and obtaining authorization information for data access; based on the authorization information, determining whether financial data in the original financial system can be obtained through an interface; if so, calling the corresponding data interface to obtain the financial data, and using the decryption plugin to decrypt the encrypted data content; if not... The system obtains data via an interface, then controls the automated testing tool to run in headless mode, extracting the financial data displayed on the original financial system webpage and obtaining all paginated data through simulated page-turning operations. The obtained financial data is stored in the original data table, and the application processing program is started to clean and convert the original data. The cleaning and format conversion are performed according to the preset field mapping relationships and data validation rules in the rule base. After data cleaning and conversion, the processed financial data is imported into the target financial system. If the corresponding account set does not exist in the target financial system, a new account set is created; if it already exists, an overwrite or incremental import operation is performed. After the data import is complete, data consistency verification is performed, including comparing the total amount and structural distribution of key data items before and after the migration, and a migration report containing the verification results is generated.Furthermore, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the cigarette box image recognition method provided by the above-described methods. This method includes: a user selecting the vendor and version of a target financial system; loading the corresponding rule base and decryption plugin according to the vendor and version; simulating user login operations using an automated testing tool, accessing the original financial system website and completing the login, and obtaining authorization information for data access; based on the authorization information, determining whether financial data in the original financial system can be obtained through an interface; if so, calling the corresponding data interface to obtain the financial data, and using the decryption plugin to decrypt the encrypted data content; if it cannot be obtained through the interface, controlling the automatic... The automated testing tool runs in headless mode, extracting financial data displayed on the original financial system webpage and obtaining all paginated data through simulated page-turning operations. The acquired financial data is stored in the original data table, and the application processing program is started to clean and convert the original data. The cleaning and format conversion are performed based on preset field mapping relationships and data validation rules in the rule base. After data cleaning and conversion, the processed financial data is imported into the target financial system. If the corresponding account set does not exist in the target financial system, a new account set is created; if it already exists, an overwrite or incremental import operation is performed. After the data import is complete, data consistency verification is performed, including comparing the total amount and structural distribution of key data items before and after migration, and generating a migration report containing the verification results. Example 2, Step 1: Select the target financial system and load the rule base. Input: The user selects the target financial system vendor (e.g., Yonyou) and version (e.g., Yonyou T3). Operation: The system loads the corresponding rule base (e.g., rule_yonyou_t3.json) and decryption plugin (e.g., decrypt_plugin_yonyou.so) according to the vendor and version. Formula: Define field mapping relationships in the rule base (such as subject code conversion rules): Target code = source code prefix + source code. For example: if the source code is 1001 and the target code prefix is ​​YUN-, then the target code is YUN-1001. Step 2: Simulate user login and obtain authorization information. Input: The user enters the login account and password of the original financial system. Operation: The automated testing tool simulates the user login operation, parses the login page and submits the form. Formula: Authorization information extraction rule: Token = SHA256(username + password + timestamp). The system saves the Token for subsequent interface calls. Step 3: Determine the data acquisition method. Input: The system checks whether the original financial system supports interface calls. Operation: If interface calls are supported, the interface is called and the data is decrypted; if not, the data is captured through web scraping and page turning is simulated. Formula: Calculate the interface call success rate: Interface success rate = (total number of requests / number of successful responses) × 100%. Step 4: Data cleaning and format conversion. Input: Financial data in the original data table.Step 5: Data Import to Target System Input: Cleaned financial data. Operation: If the target system does not have a corresponding account set, a new account set will be created; if the account set already exists, an overwrite or incremental import will be performed. Step 6: Data Consistency Verification Input: Distribution characteristics of data before and after migration. Operation: Calculate the difference in distribution entropy values ​​before and after migration. Formula: Information Entropy Calculation: Where is the proportion of the i-th type of data. Entropy value before migration: ; Entropy value after migration: ; Entropy difference: If ΔH > threshold ΔH > threshold (e.g., 0.1), the data distribution is considered abnormal. Formula: Data Difference Calculation: Difference Rate = |Total Debits - Total Credits| / max(Total Debits, Total Credits) × 100% If the difference rate exceeds the threshold (e.g., 1%), it is marked as abnormal data. Step 7: Generate Migration Report Input: Migration result data (such as abnormal data entries, difference rate). Operation: Generate a migration report containing the following: Total data migration:; Number of successfully imported entries:; List of abnormal data entries:; Data difference rate:; Interface call success rate:; Consistency verification result:. Any parts not described in this application can be implemented using or by referencing existing technologies. The various embodiments in this specification are described in a progressive manner; similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. The above descriptions are merely embodiments of this application and are not intended to limit this application. For those skilled in the art, this application can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A method for intelligent migration and consistency verification based on multi-source heterogeneous financial data, characterized in that, include: Users select the vendor and version of the target financial system, and the corresponding rule base and decryption plugin are loaded according to the vendor and version. The system uses automated testing tools to simulate user login operations, accesses the original financial system website and completes the login process, and obtains authorization information for data access. Based on the authorization information, determine whether the financial data in the original financial system can be obtained through the interface. If so, call the corresponding data interface to obtain the financial data, and use the decryption plugin to decrypt the encrypted data content. If the data cannot be obtained through the interface, the automated testing tool will be controlled to run in headless mode to extract the financial data displayed on the original financial system webpage and obtain all paginated data by simulating page turning operations. The acquired financial data is stored in the raw data table, and the application processing program is started to clean and convert the raw data. The cleaning and format conversion are performed according to the preset field mapping relationship and data validation rules in the rule base. After data cleaning and transformation are completed, the processed financial data is imported into the target financial system. If the corresponding set of accounts does not exist in the target financial system, a new set of accounts is created. If it already exists, an overwrite or incremental import operation is performed. After the data import is complete, perform a data consistency check, including comparing the total amount and structural distribution of key data items before and after the migration, and generate a migration report containing the check results.

2. The method according to claim 1, characterized in that, The rule base includes accounting subject code conversion rules, voucher classification mapping rules, auxiliary accounting field matching rules, and target system code prefix information for different vendors' financial systems. The field mapping relationship is used to convert the data fields in the original financial system into field formats that can be recognized by the target financial system.

3. The method according to claim 1, characterized in that, The decryption plugin is an extensible dynamic decryption module that supports multiple encryption algorithm types; The decryption process includes identifying the encryption identifier of the content returned by the data interface, and calling the corresponding decryption algorithm plugin to decrypt the data based on the encryption identifier, ensuring the correct restoration of the plaintext data.

4. The method according to claim 1, characterized in that, The process of obtaining all pagination data through simulated page-turning operations specifically includes: The automated testing tool parses the pagination control information on the current page, simulates a user clicking the next page button, and continuously obtains financial data from subsequent pages until it detects the last page marker or duplicate data content on two consecutive pages, at which point it stops paginating.

5. The method according to claim 1, characterized in that, The data cleaning and format conversion also includes the integrity verification of financial data, specifically: For each voucher record, the total debit amount is compared with the total credit amount. If the two are not equal, the voucher is marked as abnormal data and recorded in the log. At the same time, the subsequent import process is paused, and manual confirmation or correction is required.

6. The method according to claim 1, characterized in that, The data consistency verification includes: Calculate the difference in distribution entropy between the original data before migration and the data in the target system after migration. When the entropy difference exceeds a preset threshold, it is determined that the data distribution has changed, and the risk of data distortion or loss is marked in the migration report.

7. The method according to claim 1, characterized in that, The creation of a new account set includes: Send a creation request to the account management interface of the target financial system, carrying the account name, accounting system type, activation period and basic parameter information. After the interface returns the unique identifier of the account, associate the cleaned and transformed financial data with the account and import it.

8. The method according to claim 1, characterized in that, The migration report includes the total amount of data migrated, the number of successfully imported items, a list of abnormal data items, the data difference rate, the interface call success rate, and the consistency verification results. The migration report is displayed through a graphical interface and can be exported to a standard document format.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-8.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-8.

Images