Scene financial data intelligent docking method, platform and system for heterogeneous ERP (Enterprise Resource Planning) system

Abstract

The invention provides a scene financial data intelligent docking method, platform and system for a heterogeneous ERP system, and the method comprises the steps: connecting an enterprise authorization ERP through a preset interface module, and extracting original business data; performing standardized conversion on the data by using a semantic rule mapping engine with a built-in financial semantic model, and calculating a dynamic risk control index; performing security encapsulation processing on the index and the standard service data to generate a target data packet; and finally, the data packet is sent to a matched financial service party through an intelligent router so as to trigger the financial service party to make an automatic financial service decision based on the credible data packet. According to the invention, low-cost and standardized rapid docking between the financial institution and the heterogeneous ERP system can be realized. On the premise of guaranteeing enterprise data privacy and security and credibility, static financial report risk control is upgraded to dynamic intelligent risk control based on real-time business data, so that risk control accuracy and service matching efficiency are remarkably improved, and time consumption of a traditional financing approval process can be greatly shortened.

Description

Technical Field

[0001] This application relates to the field of financial data processing technology, and in particular to intelligent methods, platforms and systems for connecting financial data in heterogeneous ERP systems. Background Technology

[0002] With the deepening integration of finance and industrial digitalization, scenario-based finance has become an important development trend. Financial institutions urgently need to seamlessly embed services such as credit and payment into the real business processes of enterprises. Enterprise Resource Planning (ERP) systems, as the core data hub, carry the most valuable business data such as orders, inventory, and accounts receivable in real time, naturally becoming an ideal data source for scenario-based finance. However, existing technical solutions mainly rely on interfaces such as API gateways for shallow data transmission and format conversion, making it difficult to deeply mine the business value of ERP data and support intelligent financial applications based on dynamic scenarios.

[0003] Currently, financial institutions face a series of significant technical bottlenecks when integrating with enterprise ERP systems. First, the ERP systems used by different enterprises (such as SAP, Yonyou, and Kingdee) differ significantly in data models and interface specifications, creating serious data silos and interface heterogeneity issues. This necessitates costly customization development for each system integration, resulting in long implementation cycles and difficulties in large-scale deployment. Second, due to concerns about protecting trade secrets, enterprises are unwilling to share all their data. Existing technologies lack fine-grained data authorization and trust assurance mechanisms, making it difficult for financial institutions to verify the authenticity, completeness, and timeliness of the data obtained, posing risks of data security and trust breaches. Finally, financial institutions typically only obtain outdated, static financial statements and cannot access dynamic business data such as order flows and inventory changes in real time. This leads to insufficient accuracy in risk control models and also makes enterprise financing application processes cumbersome, approval cycles lengthy, and results in low experience and efficiency.

[0004] In summary, existing technical solutions have significant shortcomings in addressing key issues such as heterogeneous system adaptation, secure and reliable data sharing, and the matching of dynamic risk control with efficient services, thus hindering the large-scale and intelligent development of scenario-based finance. Therefore, there is an urgent need for an innovative technical solution to systematically overcome these bottlenecks. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, platform and system for intelligent docking of scenario financial data for heterogeneous ERP systems, so as to eliminate or improve one or more defects existing in the prior art.

[0006] The first aspect of this application provides a method for intelligent integration of financial data in heterogeneous ERP systems, including: Based on the target company's authorization configuration information, a secure connection is established with at least one ERP system designated by the target company through pre-built interface modules corresponding to multiple heterogeneous ERP systems. The original business data is extracted from the ERP system with the established secure connection according to the data extraction authorization scope in the authorization configuration information. Based on the semantic rule mapping engine with built-in financial semantic model, the original business data is semantically mapped and standardized to obtain standard business data, and dynamic risk control indicators for evaluating enterprise operation and financial risks are calculated based on the standard business data. The dynamic risk control indicators and the standard business data are securely encapsulated to generate a target data package that meets the preset risk control requirements of the financial service provider. The target data packet is routed to the financial service provider to trigger the financial service provider to make financial service decisions for the target enterprise based on the target data packet.

[0007] In some embodiments of this application, prior to establishing a secure connection with at least one ERP system designated by the target enterprise, the method further includes: The system receives authorization configuration information input by the target enterprise through a preset graphical configuration interface. The authorization configuration information includes: the type of ERP system specified by the target enterprise, connection parameters, and the data extraction authorization scope at the field level. Correspondingly, based on the target enterprise's authorization configuration information, a secure connection is established with at least one ERP system designated by the target enterprise through pre-built interface modules corresponding to multiple heterogeneous ERP systems. The original business data is then extracted from the ERP system with the established secure connection according to the data extraction authorization scope in the authorization configuration information. This includes: Based on the type and connection parameters of the ERP system specified by the target enterprise, the corresponding pre-set interface modules are called to establish secure connections with each ERP system specified by the target enterprise in the pre-set interface modules corresponding to multiple heterogeneous ERP systems. According to the data extraction authorization scope, the corresponding original business data is extracted from the ERP system with an established secure connection.

[0008] In some embodiments of this application, the semantic rule mapping engine based on a built-in financial semantic model performs semantic mapping and standardization transformation on the original business data to obtain standard business data, including: The original business data is input into the semantic rule mapping engine, so that the semantic rule mapping engine can identify the source fields to be transformed in the original business data according to the predefined financial semantic model containing the corresponding fields of each financial business object; and the semantic rule mapping engine can search for target fields that match the name and / or business context of the source fields in the pre-set semantic mapping rule library, and map the source fields to the matched target fields. If there is a source field that cannot be matched in the rule base, the data features corresponding to the source field are input into a preset machine learning model so that the machine learning model outputs similarity prediction results between the source field and each of the target fields in the rule base based on the data features corresponding to the source field, and determines the target field corresponding to the source field for mapping based on the similarity prediction results. After mapping, the data values ​​in the business data are standardized and cleaned to generate standard business data.

[0009] In some embodiments of this application, before calculating the dynamic risk control indicators used to assess business operations and financial risks based on the standard business data, the method further includes: Based on the authorization scope of the data fields in the authorization configuration information, the standard business data is filtered at the field level to obtain the filtered standard business data. From the filtered standard business data, predefined fields and field values ​​for constituting key business vouchers are extracted. The fields of the key business vouchers include: number-type fields and time-type fields for uniquely identifying business documents. Perform a hash operation on the field values ​​of the key business voucher to obtain the corresponding first hash value; Multiple first hash values ​​belonging to the same data processing task are constructed according to the Merkle tree data structure to obtain the corresponding Merkle root hash; The notarization record, which includes the Merkle root hash, data batch identifier, and timestamp, is sent to the consortium blockchain network jointly maintained by the participating nodes for notarization, and a notarization credential containing the transaction hash and block height is obtained. The participating nodes include at least two of the following: enterprise nodes, financial institution nodes, and regulatory agency nodes.

[0010] In some embodiments of this application, the calculation of dynamic risk control indicators based on the standard business data for assessing business operations and financial risks includes: Extract business flow data that corresponds to the target financial service scenario and is serialized according to the time dimension from the standard business data; The business flow data is input into a pre-configured dynamic risk control model so that the dynamic risk control model can obtain the corresponding quantitative value of future business trends through a time series prediction algorithm. In addition, based on preset business rules, the quantitative values ​​corresponding to the business flow data are calculated to reflect the asset status and turnover efficiency; The quantitative values ​​of future business trends and the quantitative values ​​reflecting asset status and turnover efficiency are used as the original statistical indicators for risk assessment; and based on the original statistical indicators, a dynamic risk control indicator is generated through a risk decision model, which includes at least one of quantitative risk scores, abnormal early warning signals and future risk prediction results.

[0011] In some embodiments of this application, before the secure encapsulation processing of the dynamic risk control indicators and the standard business data is performed, the following steps are also included: Set a privacy budget for the original statistical metrics and determine their global sensitivity under the definition of differential privacy; Based on the privacy budget and the global sensitivity, calculate the noise scale parameter of the Laplace mechanism; sample random noise from the Laplace distribution based on the scale parameter; add the random noise to the original value of the original statistical index to generate the privacy-preserving statistical index; Correspondingly, the process of securely encapsulating the dynamic risk control indicators and the standard business data to generate a target data package that meets the preset risk control requirements of the financial service provider includes: The privacy-protected statistical indicators, the dynamic risk control indicators, and the standard business data are securely encapsulated to generate a target data package that meets the preset risk control requirements of the financial service provider.

[0012] In some embodiments of this application, routing the target data packet to the financial service provider to trigger the financial service provider to make financial service decisions for the target enterprise based on the target data packet includes: Receive financial service requests from the target enterprise for a target financial scenario, the financial service requests including: financing amount, payment period and expected cost; Based on the dynamic risk control indicators and standard business data in the target data package, the target enterprise is verified for access eligibility in accordance with the financial service request. If the target enterprise is determined to have passed the access qualification verification, then based on the financial service request and the dynamic risk control indicators, a preset rule engine is used to match candidate service providers that meet the first condition from multiple financial service providers; wherein, the first condition includes access conditions that match the financing amount and the payment period of the financial service request. The candidate service providers are scored on at least two preset dimensions using a recommendation algorithm, and the final target financial service provider is selected based on the scoring results. The target data packet is sent to the target financial service provider via the API gateway to trigger the target financial service provider to perform financial service approval and decision-making for the target enterprise based on the target data packet.

[0013] The second aspect of this application provides a scenario-based financial data intelligent docking platform for heterogeneous ERP systems, used in conjunction with the scenario-based financial data intelligent docking method for heterogeneous ERP systems provided in the first aspect above.

[0014] The third aspect of this application provides a scenario-based financial data processing system, including: enterprise nodes, financial institution nodes, and the scenario-based financial data intelligent docking platform for heterogeneous ERP systems provided in the second aspect above. The enterprise node and the financial institution node are respectively connected to the scenario-based financial data intelligent docking platform for heterogeneous ERP systems.

[0015] A fourth 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, wherein the processor executes the computer program to implement the aforementioned intelligent docking method for scenario-based financial data of heterogeneous ERP systems.

[0016] The fifth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned method for intelligent docking of scenario-based financial data for heterogeneous ERP systems.

[0017] The sixth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the aforementioned method for intelligent docking of scenario-based financial data for heterogeneous ERP systems.

[0018] The intelligent financial data docking method for heterogeneous ERP systems provided in this application establishes a secure connection with at least one ERP system designated by the target enterprise through pre-built interface modules corresponding to multiple heterogeneous ERP systems, based on the target enterprise's authorized configuration information. Raw business data is extracted from the ERP systems with established secure connections according to the data extraction authorization scope in the authorized configuration information. A semantic rule mapping engine based on a built-in financial semantic model performs semantic mapping and standardization transformation on the raw business data to obtain standard business data. Dynamic risk control indicators for assessing enterprise operation and financial risks are calculated based on this standard business data. The dynamic risk control indicators and the standard business data are securely encapsulated to generate a target data package that meets the preset risk control requirements of the financial service provider. The target data package is routed to the financial service provider to trigger the financial service provider to make financial service decisions for the target enterprise based on the target data package. By leveraging pre-built interface modules and a semantic rule mapping engine, it automatically adapts to different ERP systems, transforming non-standard data into a unified standard. This significantly reduces development costs and timelines, enabling rapid, large-scale deployment. While ensuring enterprise data privacy (through field-level authorization), integrated security encapsulation ensures the confidentiality, integrity, and source credibility of data transmitted and used from the data source to financial institutions, providing a reliable data foundation for financial decision-making. It upgrades the input to risk control models from static, outdated financial statements to dynamic risk indicators calculated based on real-time, standardized business data streams, making risk assessment more closely aligned with actual business operations and significantly improving the accuracy and timeliness of risk control. Through an intelligent routing mechanism, it automatically matches processed, standardized, and reliable data packets to the most suitable financial service provider, transforming traditional, lengthy, and manual processes into efficient online and automated decision-making processes, greatly improving the overall efficiency of industrial finance.

[0019] Additional advantages, objectives, and features of this application will be set forth in part in the description which follows, and will in part become apparent to those skilled in the art upon review of the following description, or may be learned by practice of the application. The objectives and other advantages of this application can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0020] Those skilled in the art will understand that the purposes and advantages that can be achieved with this application are not limited to those specifically described above, and that the above and other purposes that this application can achieve will be more clearly understood from the following detailed description. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. The components in the drawings are not drawn to scale but are merely for illustrating the principles of this application. For ease of illustration and description of certain parts of this application, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to this application. In the drawings: Figure 1 This is a flowchart illustrating a method for intelligent data docking in heterogeneous ERP systems according to an embodiment of this application.

[0022] Figure 2 This is a schematic diagram of the structure of a scenario-based intelligent financial data docking platform for heterogeneous ERP systems in one embodiment of this application.

[0023] Figure 3 This is a system architecture diagram for an application example of this application.

[0024] Figure 4 This is a schematic diagram illustrating the specific process of storing multiple contract information records on the blockchain in an application example of this application.

[0025] Figure 5 This is a schematic diagram of the differential privacy feature generation process in an application example of this application.

[0026] Figure 6 This is a schematic diagram of the interaction process of the docking platform in an application example of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit it.

[0028] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the structures and / or processing steps closely related to the solution according to this application are shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0029] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0030] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0031] In the following description, embodiments of the present application will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0032] It's important to clarify that, with the deepening of industrial digitalization in the financial sector, more and more financial institutions (such as banks, supply chain finance platforms, and factoring companies) are looking to seamlessly embed more financial services (such as financing and payment settlement) into the real-world business scenarios of enterprises—a concept known as scenario-based finance. Enterprise resource planning systems (ERP platforms), serving as the data hub for enterprise operations, carry the most authentic and core operational data (such as orders, inventory, accounts receivable, and financial statements), making them an ideal data source for scenario-based finance.

[0033] Currently, the following significant technical bottlenecks exist in data integration between financial institutions and enterprise ERP systems: (1) Data silos and interface heterogeneity issues: The ERP systems available on the market vary widely (such as Yonyou, Kingdee, Oracle, etc.). A single enterprise may purchase multiple ERP systems simultaneously, and the underlying data models, interface specifications, and database structures of these different systems are all different, lacking a unified standard. Financial institutions need to carry out customized development when integrating with different ERP systems, which is costly, time-consuming, difficult to replicate, and hard to scale.

[0034] (2) Data security issues: Because corporate ERP system data involves the company's interests, financial institutions are generally reluctant to hand over all of their data, fearing the leakage of trade secrets. At the same time, existing technologies lack sophisticated, authorized sharing mechanisms for corporate data. For financial institutions, it is difficult to ensure that data obtained from ERP systems has not been tampered with during transmission, necessitating a reliable technological means to verify the authenticity and timeliness of the data.

[0035] (3) Data dimensions are limited and risk control is poorly matched with the scenario: Financial institutions typically only have access to limited, post-hoc data (such as financial statement data) and cannot obtain real-time dynamic business process data (such as order, inventory, and accounts receivable information). This results in inaccurate risk control models, making it impossible to effectively identify risks or discover high-quality customers, and also limiting access to more financial services (such as financing and lending).

[0036] (4) Inefficient and poor user experience: When companies submit financing applications to banks and other financial institutions, they need to manually organize, export, and submit a large amount of data. The process is cumbersome and the approval cycle is long, which cannot meet the company's working capital needs.

[0037] Based on this, in order to construct an automated, secure, reliable, and intelligent end-to-end data processing and financial service triggering channel from heterogeneous ERP data sources to financial institutions, and to solve the problems of high development customization, lack of data security and trust, lagging and inaccurate risk control, and inefficient service matching in traditional docking, this application provides a scenario-based intelligent docking method for heterogeneous ERP systems, a scenario-based intelligent docking platform for heterogeneous ERP systems, a system, an electronic device, a computer-readable storage medium, and a computer program product for executing the scenario-based intelligent docking method for heterogeneous ERP systems. It can automatically adapt to multiple ERP systems, ensure data security and reliability, and drive intelligent risk control based on dynamic business data.

[0038] The following examples will provide a detailed description.

[0039] Based on this, embodiments of this application provide a method for intelligent docking of scenario-based financial data for heterogeneous ERP systems, which can be implemented by a scenario-based financial data intelligent docking platform for heterogeneous ERP systems. See [link to relevant documentation]. Figure 1 The intelligent data docking method for heterogeneous ERP systems specifically includes the following: Step 100: Based on the authorization configuration information of the target enterprise, establish a secure connection with at least one ERP system designated by the target enterprise through the pre-built interface modules corresponding to multiple heterogeneous ERP systems, and extract original business data from the ERP system with the established secure connection according to the data extraction authorization scope in the authorization configuration information.

[0040] In the business scenarios described in this application, the target enterprise specifically refers to a corporate entity that acts as a financial service demander (such as a financing applicant) and actively authorizes the platform of this invention to connect to its internal ERP system to extract data. More broadly, it refers to any enterprise that authorizes the platform and applies for financial services; this could be the core enterprise itself, its upstream supplier, or its downstream distributor. The core enterprise typically refers to a large enterprise with a high credit rating and a dominant position in the industry chain (such as a vehicle manufacturer or brand owner), whose credit can be transferred along the supply chain.

[0041] It is understood that the aforementioned authorization configuration information can refer to the precise permission instructions set by the enterprise through the user interface of the scenario-based financial data intelligent docking platform (hereinafter referred to as the platform) for heterogeneous ERP systems, allowing the platform to access its ERP data. These instructions can be refined to specific data tables and fields. For example, in the scenario of accounts receivable financing, the enterprise can authorize the opening of the invoice number, invoice amount, due date, and purchaser name fields in the accounts receivable details table, but block fields such as cost amount, profit margin, and original contract attachments.

[0042] Heterogeneous ERP systems refer to ERP (Enterprise Resource Planning) systems that differ in at least one of their underlying data models, interface protocols, or database structures. For example, a target company might use both SAP and Yonyou ERP software, which are completely different in their customer, order, and account coding and table structures.

[0043] Pre-built interface modules, also known as pre-built connectors, are standardized connector software modules pre-developed and packaged by the platform for specific types of ERP systems. The platform can also provide unique identifiers for different types of ERP systems and connector options through the user interface. Enterprises only need to select the connector for a specific type of ERP system in the graphical interface and fill in the server address, client number, username, and password to complete the configuration without writing any code.

[0044] Establishing a secure connection refers to creating a secure, encrypted, and explicitly authorized communication channel between the platform and the target enterprise's designated ERP system via a pre-built interface module. In one example, the process might be as follows: 1) Authentication: The platform uses the username or password, API key, OAuth token, or client certificate configured by the target enterprise to prove its access to the ERP system; 2) Channel Encryption: An encrypted link based on TLS / SSL (such as HTTPS) or VPN is established to ensure that data is encrypted during transmission; 3) Permission Negotiation: When the connection is established, the platform declares its access intent and data scope (based on authorization configuration), which can be verified by the ERP system; 4) Connection Instantiation: For database-based ERP systems, an encrypted JDBC / ODBC connection may be established; for API-based ERP systems, an API client session with a valid token is established. This connection object will be used to execute subsequent data queries (SQL) or API calls.

[0045] In step 100, raw business data refers to initial operational data extracted directly from the database or API of the target enterprise's ERP system via a secure connection, without any standardization processing. This data retains the original format, field naming, encoding rules, and storage structure of the source system; it is heterogeneous, non-standard, and contains raw information with business semantics.

[0046] Step 200: Based on the semantic rule mapping engine of the built-in financial semantic model, perform semantic mapping and standardization transformation on the original business data to obtain standard business data, and calculate dynamic risk control indicators for evaluating enterprise operation and financial risks based on the standard business data.

[0047] It's worth noting that the semantic rule mapping engine is a core processing engine with built-in financial business knowledge that can automatically identify the business meaning of different ERP fields and convert them into unified standard fields. For example, the engine has a pre-defined rule: if the source field name contains "CUST" or "NAME" and is of character type, it is mapped to the standard field "customerName". Therefore, SAP's field "KUNNR_NAME" and Yonyou's "CUST_NAME" can both be uniformly mapped to "customerName".

[0048] Standardization conversion refers to the process of unifying data formats, units, and code values ​​based on semantic mapping. For example, unit conversion can convert the SAP monetary unit "cent" to the standard unit "dollar". Code conversion can map the payment status code "A" to the standardized status "paid".

[0049] Dynamic risk control indicators are variable metrics calculated based on real-time, continuous business data streams and used to quantitatively assess a company's short-term operational and credit risks. Examples include accounts receivable turnover days (dynamically calculated based on daily accounts receivable balance and sales revenue) and projected cash flow gaps for the next 30 days (predicted based on ARIMA model data of revenue and expenditure). This differs from the static debt-to-equity ratio.

[0050] Step 300: Securely encapsulate the dynamic risk control indicators and the standard business data to generate a target data package that meets the preset risk control requirements of the financial service provider.

[0051] In step 300, the target data packet refers to a complete data set generated after secure encapsulation, containing standardized data, protected risk control indicators, and security credentials. The target data packet can be in JSON format and encrypted entirely using the SM4 algorithm.

[0052] In this context, the risk control requirements of financial service providers refer to the standardized data content, indicator dimensions, and credibility requirements that financial institutions (such as banks and factoring companies) must rely on for credit approval, risk pricing, and other decisions regarding target enterprises. Taking a commercial bank's supply chain finance risk control model as an example, its financial service provider risk control requirements explicitly require the input data to include: 1) the amount and payment term of accounts payable confirmed by the core enterprise; 2) the supplier's historical delivery fulfillment rate; and 3) verification information of transaction invoices. Therefore, in this application, when a target enterprise applies for accounts receivable financing, the target data package generated by the platform will ensure that it includes: the mapped standard fields "payableAmount" (accounts payable amount) and "dueDate" (due date or payment deadline); the calculated dynamic indicator "onTimeDeliveryRate" (on-time delivery rate); and the corresponding blockchain-based notarized hash of the invoice. The structure of this data package fully conforms to the bank's API input specifications and can directly drive its automated approval process.

[0053] Step 400: The target data packet is routed to the financial service provider to trigger the financial service provider to make financial service decisions for the target enterprise based on the target data packet.

[0054] In step 400, routing can refer to intelligent routing, which is the decision-making and transmission process that intelligently selects and directs data packets to the most suitable financial institution based on the enterprise's needs, risk control results, and institutional profile. For example, the platform can, based on the enterprise's needs of "financing 500,000, payment term of 90 days, and cost sensitivity," combined with its good dynamic risk control score, select a bank's digital finance department with a high match for the "small and quick loan" product from among its partner banks, and push the data packet to that bank's dedicated interface through an API gateway.

[0055] It is understandable that triggering the financial service provider to make financial service decisions for the target enterprise based on the target data packet can mean that, after receiving a credible and standardized target data packet, the financial service provider (such as a bank) can complete the decision-making process such as credit assessment, credit limit approval, and interest rate pricing almost automatically. For example, after receiving the data packet, the bank system automatically verifies the authenticity of the blockchain evidence, reads the noisy risk control indicators, and if it meets the internal automated approval rules (such as a score > 600 points), it returns the decision result "Approval passed, credit limit of 500,000 yuan, annualized interest rate of 5.0%" to the platform in real time and notifies the target enterprise.

[0056] As described above, the intelligent financial data docking method for heterogeneous ERP systems provided in this application automatically adapts to different ERP systems through pre-built interface modules and semantic rule mapping engines, transforming non-standard data into a unified standard. This significantly reduces docking development costs and timelines, enabling rapid large-scale deployment. While ensuring enterprise data privacy (through field-level authorization), integrated security encapsulation ensures the confidentiality, integrity, and source reliability of data from the data source to the financial institution during transmission and use, providing a reliable data foundation for financial decision-making. It upgrades the input of risk control models from static, lagging financial statements to dynamic risk indicators calculated based on real-time, standardized business data streams, making risk assessment more closely aligned with actual business operations and significantly improving the accuracy and timeliness of risk control. Through an intelligent routing mechanism, the processed standardized and reliable data packets are automatically matched to the most suitable financial service provider, transforming the traditional, lengthy, and manual process into an online, automated, and efficient decision-making process, greatly improving the overall efficiency of industrial finance.

[0057] To further improve the convenience and efficiency of enterprise users in initiating intelligent integration of scenario-based financial data, the method for intelligent integration of scenario-based financial data for heterogeneous ERP systems provided in this application embodiment includes the following content before step 100: Step 010: Receive the authorization configuration information input by the target enterprise through a preset graphical configuration interface. The authorization configuration information includes: the type of ERP system specified by the target enterprise, connection parameters, and the data extraction authorization scope at the field level.

[0058] In step 010, the graphical configuration interface can be a specific implementation of the aforementioned user interface, referring to a visual web page or client interface provided by the platform, where users complete complex configurations through non-coding methods such as clicking, selecting, and filling out forms. Its core value is to lower the barrier to entry for enterprise users, achieving zero-code or low-code configuration, enabling enterprise IT or business personnel to complete the integration themselves without development skills.

[0059] The type of ERP system refers to the brand, series, or version of the ERP system used by the target enterprise.

[0060] It should be noted that connection parameters refer to the specific network and authentication information required to establish a secure connection, and typically include: (1) Server address, IP address, or port; (2) Database instance name or SID (e.g., database connection); (3) API endpoint URL (e.g., a Web service connection); (4) Username, password, API key or client certificate; (5) Client or company code.

[0061] The field-level data extraction authorization scope is one of the core technical features of this application for achieving data minimization and privacy protection. It refers to the refined, field-level authorization that enterprises can grant to allow the platform to extract data from their ERP, rather than full authorization at the table or database level. For example, in the scenario of accounts receivable financing, the target enterprise can authorize: 1) Extraction allowed: invoice number, amount, due date, and customer name (anonymized) from the accounts receivable details table; 2) Extraction prohibited: cost price, internal profit, contact person's phone number, etc., in the same table.

[0062] Correspondingly, step 100 of the intelligent data docking method for heterogeneous ERP systems specifically includes the following: Step 110: Based on the type and connection parameters of the ERP system specified by the target enterprise, in the pre-set interface modules corresponding to the multiple heterogeneous ERP systems, call the corresponding pre-set interface modules to establish a secure connection with each ERP system specified by the target enterprise.

[0063] Step 120: Extract the corresponding original business data from the ERP system with the established secure connection, according to the data extraction authorization scope.

[0064] Specifically, a precise data query request can be sent to the ERP system through an established secure connection. The scope of this request is strictly limited to the authorized data extraction range at the field level. In one example, this could be achieved using a SELECT SQL statement containing a list of authorized fields, or an API call with the same filtering conditions. The platform only retrieves explicitly authorized field data; other fields, even if they exist in the table, will not be read, ensuring data security from the source.

[0065] To further improve the reliability, efficiency, and accuracy of semantic mapping and standardized transformation of the original business data, in the intelligent data docking method for heterogeneous ERP systems provided in this application embodiment, step 200 specifically includes the following: Step 210: Input the original business data into the semantic rule mapping engine, so that the semantic rule mapping engine can identify the source fields to be transformed in the original business data according to the predefined financial semantic model containing the corresponding fields of each financial business object; and make the semantic rule mapping engine search for the target field that matches the name and / or business context of the source field in the preset semantic mapping rule library, and map the source field to the matched target field.

[0066] In step 210, the financial semantic model is a predefined, standardized business logic framework by the platform. It specifies the set of standard fields, data types, and business meanings necessary to describe a complete business object (such as an "invoice" or "order") in specific financial business domains (such as accounts receivable financing and inventory financing). For example, the financial semantic model defines standard fields for accounts receivable financing: "invoiceNumber," "invoiceAmount," and "dueDate," each with a clear financial meaning and format requirements.

[0067] In this context, a financial business object refers to an entity with practical business significance that needs to be independently identified and processed in financial risk control and business analysis. It is a basic building block of the financial semantic model. For example, "accounts receivable voucher" is a financial business object, which consists of multiple related data entities such as invoices, contracts, and delivery notes. All its relevant standard fields are defined in the model.

[0068] Source fields refer to the fields in the raw business data extracted from an enterprise's ERP system. The names, formats, and encoding rules of these fields vary from ERP system to ERP system. For example, "DMBTR" (Fixed Currency Amount) in SAP software and "AMOUNT" (Amount) in Yonyou software. Target fields, on the other hand, refer to the standard fields defined in the financial semantic model, which have unified names and semantics. For example, regardless of the source field for transaction amount in different ERP software, it ultimately maps to "transactionAmount" (transaction amount) in the model.

[0069] Business context refers to the data table, module, or business process information in which the source field resides, used to help determine its business meaning. When the field name alone may not provide an accurate mapping, the context must be considered. For example, a field named "AMOUNT" might be mapped to "orderAmount" (order amount) if it's in a sales order table, but to "paymentAmount" (payment amount) if it's in a payment record table.

[0070] It should be noted that the semantic mapping rule base is a knowledge base that stores mapping rules from source fields of a specific ERP system to target fields of a financial semantic model. Rules can be constructed based on combinations of conditions such as field name keywords, data types, value ranges, and business context. For example, if a source field name contains "DATE" and is located in a table starting with "AR_", it will be mapped to the target field "invoiceDate" (invoice date).

[0071] Step 220: If there is a source field that cannot be matched in the rule base, the data features corresponding to the source field are input into a preset machine learning model so that the machine learning model outputs similarity prediction results between the source field and each of the target fields in the rule base based on the data features corresponding to the source field, and determines the target field corresponding to the source field for mapping based on the similarity prediction results.

[0072] In step 220, data features are a set of quantifiable attributes used to describe the source field in machine learning-assisted mapping. These typically include: 1) metadata features: field name text, data type (string, number, date); 2) content features: distribution of data values, proportion of unique values, length, numerical range, and whether it conforms to a specific regular expression (such as date format).

[0073] Similarity prediction results refer to numerical values ​​or vectors output by machine learning models that quantify the semantic probability of a source field matching each candidate target field. The model learns potential association patterns between source and target fields by analyzing data features. For example, the model might output that the source field has a similarity of 0.9 with "customerName" and a similarity of 0.1 with "transactionAmount".

[0074] Step 230: Standardize and clean the format of each data value in the mapped business data to generate standard business data.

[0075] In step 230, after field mapping is complete, post-processing operations are performed on the data values ​​themselves to ensure that all data conforms to the definition of the standard model. For example, format unification can standardize all dates to YYYY-MM-DD format; and standardize all monetary units to "yuan" (e.g., dividing "fen" by 100). Data cleaning can handle null values, remove outliers that are clearly outside the reasonable range (such as negative amounts), and convert status codes (such as "A / B / C") into standard descriptions (such as "paid / unpaid / partially paid").

[0076] To further improve the security and reliability of the data required for intelligent data docking in scenarios of financial systems, the method for intelligent docking of scenario-based financial data for heterogeneous ERP systems provided in this application embodiment includes the following additional content after step 230 in step 200: Step 241: Based on the authorization scope of the data fields in the authorization configuration information, perform field-level filtering on the standard business data to obtain the filtered standard business data.

[0077] Step 242: Extract predefined fields and field values ​​from the filtered standard business data to form key business vouchers. The fields of the key business vouchers include: number field and time field used to uniquely identify business documents.

[0078] Specifically, key business documents refer to core data units in financial business scenarios that can uniquely identify and constitute a record of an economic activity with legal effect or significant commercial meaning. It is not all business data, but rather evidence that can be used for post-event auditing, dispute resolution, and authenticity verification. For example, in accounts receivable financing, an invoice is a key business document, with its core identifying fields being the invoice number and the invoice date.

[0079] Number fields are codes or numbers used to uniquely identify key business documents. For example, number fields may include invoice numbers, contract numbers, purchase order numbers, and waybill numbers. Time fields, on the other hand, record the legal or business effective date of a key business document. For example, time fields may include invoice dates, contract signing dates, and shipment dates. The combination of number and time fields is used to uniquely anchor a specific document in retrospect.

[0080] Step 243: Perform a hash operation on the field value of the key business voucher to obtain the corresponding first hash value.

[0081] In step 243, hashing is a process of converting an input of arbitrary length (here, a field value) into a fixed-length, irreversible, unique digital fingerprint (hash value) using a cryptographic algorithm (such as SHA-256). The first hash value refers to the initial hash result obtained after hashing the field value of a single key business document (such as the string "Invoice Number INV001 + Invoice Date 2023-01-01"). Each document corresponds to one first hash value.

[0082] Step 244: Construct the corresponding Merkle root hash by taking multiple first hash values ​​belonging to the same data processing task according to the Merkle tree data structure.

[0083] In this context, a data processing task is an independent, batch-based data storage job instance within the platform. It is typically triggered by a scheduling system, with its boundaries defined by a time window or a data volume threshold. For example, a task executed daily at 2 AM might process all newly generated accounts receivable invoice data from the past 24 hours.

[0084] In step 244, the Merkle tree data structure is a tree-structured cryptographic data structure used for efficiently and securely verifying the integrity of large amounts of data. It is constructed by pairing multiple first hash values ​​together, calculating the hash of their parent nodes, iterating layer by layer until a root hash is generated at the top level. The Merkle root hash is the unique hash value at the top level of the Merkle tree. If any original data at the bottom level is tampered with, its corresponding hash value will change, causing significant changes to the hashes at the upper levels, up to the root hash.

[0085] Step 245: Send the evidence record containing the Merkle root hash, data batch identifier and timestamp to the consortium blockchain network jointly maintained by the participating nodes for evidence storage, and obtain evidence containing transaction hash and block height. The participating nodes include at least two of the following: enterprise nodes, financial institution nodes and regulatory agency nodes.

[0086] A data batch identifier is a unique identifier used to track and retrieve this evidence storage task, and it is usually generated internally by the platform. For example, "BATCH_ERP_AR_20231027_001" contains the business type (AR), date, and serial number.

[0087] The evidence storage record can contain core evidence storage information and a data structure ready to be sent to the blockchain network. It mainly includes: 1) Merkle root hash; 2) Data batch identifier: a unique identifier for this evidence storage task (such as task ID); 3) Timestamp: the time when the evidence storage operation occurred.

[0088] A consortium blockchain network is a blockchain network jointly maintained by multiple pre-authorized, clearly defined organizations. Unlike public blockchains, its node access is controlled, and its performance and privacy are more suitable for inter-enterprise collaboration scenarios.

[0089] Participant nodes are servers that run and maintain the blockchain ledger in a consortium blockchain network, and their identities represent a certain type of participant. Enterprise nodes represent data source providers (such as core enterprises); financial institution nodes represent data users (such as banks); and regulatory agency nodes represent supervisory bodies (such as financial affairs offices).

[0090] A certificate of evidence is proof returned by the blockchain network after successfully receiving and recording the evidence record, which can be used to verify the authenticity and content of the record in the future. A transaction hash is a unique hash identifier generated by the blockchain network for the operation of uploading the evidence record to the chain. The block height is the sequential position number of the block recording this evidence transaction on the blockchain. Combining the transaction hash and the blockchain hash allows for precise determination of the evidence record's position and temporal order on the chain.

[0091] To further improve the reliability and accuracy of dynamic risk control based on the data required for intelligent data docking in scenario-based financial systems, in the scenario-based financial data intelligent docking method for heterogeneous ERP systems provided in this application embodiment, the process of calculating dynamic risk control indicators based on the standard business data for assessing enterprise operation and financial risks, performed after step 245 in step 200 of the scenario-based financial data intelligent docking method for heterogeneous ERP systems, specifically includes the following: Step 250: Extract business flow data that corresponds to the target financial service scenario and is serialized according to the time dimension from the standard business data.

[0092] Specifically, the target financial service scenario refers to the specific type of financial business that triggers this data processing, determining the specific objectives and rules for the risk control model and indicator calculations. In one example, the target financial service scenario could include accounts receivable pool financing, order financing, and inventory-backed financing. Different scenarios focus on vastly different data dimensions and risk models.

[0093] The time-series-serialized business flow data refers to continuous business records that are relevant to the target scenario and strictly arranged in chronological order of timestamps, selected from standard business data. For example, in an inventory financing scenario, daily inventory quantities, inbound orders, and outbound orders for the past 180 days, sorted by date, are extracted to form a time-series dataset.

[0094] Step 260: Input the business flow data into the pre-configured dynamic risk control model so that the dynamic risk control model can obtain the corresponding future business trend quantification value through the time series prediction algorithm.

[0095] The dynamic risk control model refers to an algorithmic model pre-trained or configured by the platform for different financial scenarios, used to analyze time-series data and predict future trends. Its dynamic nature is reflected in the fact that the model input is a continuously updated business flow, and the output is a predicted value that changes over time. The time-series prediction algorithm is a mathematical and statistical algorithm used to analyze time-series data, identify trends, seasonality, and cyclical patterns, and predict future values ​​accordingly. The dynamic risk control model can employ models such as ARIMA (Autoregressive Integral Moving Average), exponential smoothing, or Prophet.

[0096] The quantitative value of future business trends is a numerical prediction result of key business indicators for a certain period in the future, output by the dynamic risk control model after applying a time series forecasting algorithm. For example, the quantitative value of future business trends may include: "It is predicted that the company's cash flow gap will reach -1.5 million yuan within the next 90 days" and "It is predicted that the monthly growth rate of sales in the next quarter will be 2.5%".

[0097] And step 270: Calculate the quantitative value corresponding to the business flow data, which reflects the asset status and turnover efficiency, based on the preset business rules.

[0098] Specifically, the quantitative values ​​used to reflect asset status and turnover efficiency are static or cross-sectional indicators reflecting the short-term operational health of an enterprise, derived by aggregating and calculating current business flow data based on preset business rules. For example, these quantitative values ​​may include: "current accounts receivable turnover days are 65 days," "inventory turnover rate in the past 30 days is 4.2 times," and "order cancellation rate in the past week is 1.5%."

[0099] Step 280: Use the quantitative value of the future business trend and the quantitative value used to reflect the asset status and turnover efficiency as the original statistical indicators for risk assessment; and based on the original statistical indicators, generate dynamic risk control indicators through the risk decision model, which include at least one of quantitative risk score, abnormal early warning signal and future risk prediction result.

[0100] The raw statistical indicators are a collection of quantitative values ​​for future business trends and asset status and turnover efficiency. They are direct and objective data inputs for risk decision-making, but have not yet been assigned a final risk level or decision label. The risk decision-making model is an expert system or decision tree that receives raw statistical indicators as input, processes them through a built-in rule engine, scoring card, or classification model, and ultimately outputs risk signals that can be directly used for business decisions.

[0101] The quantitative risk score is a comprehensive numerical score output by the risk decision-making model, used to intuitively and comparablely measure a company's overall credit risk or risk level in a specific scenario. For example, the quantitative risk score may include outputting a company's solvency score between 300 and 900, such as "720 points".

[0102] The aforementioned abnormal warning signal is a classification or labeling signal issued by the risk decision-making model based on rules to determine the abnormal state of specific indicators. For example, an abnormal warning signal could be: when "accounts receivable turnover days increase for two consecutive weeks and exceed the threshold", a "yellow warning" signal is issued.

[0103] The future risk prediction results are qualitative or probabilistic judgments made by the risk decision-making model based on trend information in the original statistical indicators regarding possible future risk events. For example, the future risk prediction results may include outputs such as "The probability of a liquidity shortage occurring within the next 60 days is high" or "It is recommended to pay attention to the risk of its procurement concentration."

[0104] The dynamic risk control indicators are a collective term for quantitative risk scores, abnormal early warning signals, and future risk prediction results. They are intelligent signals rich in business semantics that directly drive financial institutions' decision-making.

[0105] To further improve the security and reliability of the data required for intelligent data docking in scenario-based financial systems, the method for intelligent docking of scenario-based financial data for heterogeneous ERP systems provided in this application embodiment further includes the following content between steps 200 and 300: Step 020: Set a privacy budget for the original statistical metric and determine its global sensitivity under the differential privacy definition.

[0106] Specifically, in the differential privacy framework, the privacy budget is typically represented by ε. The privacy budget is a non-negative real number used to quantify and control the strength of privacy protection. A smaller ε means greater injected noise and stronger protection of individual privacy, but the usability (accuracy) of the data decreases. A larger ε means less noise and higher data usability, but weaker privacy protection. Its selection requires a trade-off between privacy protection and data usability.

[0107] The global sensitivity under the differential privacy definition refers to the maximum absolute value that the output of the same query function (such as calculating the average or summation) may vary on any two adjacent datasets that differ by only one record.

[0108] Calculation formula (for querying the average): Global sensitivity = (maximum possible value of the indicator - minimum possible value of the indicator) / dataset size; Global sensitivity measures the maximum potential impact of a single individual's data on the overall statistical results and is a core criterion for determining the required amount of noise. The higher the sensitivity, the more noise needs to be added to achieve the same level of privacy protection.

[0109] Step 030: Calculate the noise scale parameter of the Laplace mechanism based on the privacy budget and the global sensitivity.

[0110] The Laplace mechanism is one of the most classic and commonly used noise-adding mechanisms in differential privacy theory. It is particularly suitable for protecting numerical query results (such as counts, sums, and averages). This mechanism achieves privacy protection by drawing random noise from a Laplace distribution centered at 0 with a scale parameter of b and adding it to the actual query results.

[0111] The noise scaling parameter, in the Laplace mechanism, determines the degree of dispersion of the noise distribution and is usually denoted as b or λ. It directly controls the magnitude of the noise.

[0112] The core formula for the noise scale parameter is: Scale parameter b = Global sensitivity / Privacy budget ε; This formula shows that the more sensitive the data (the higher the sensitivity), the greater the noise required (the larger b is); the stricter the privacy protection requirements (the smaller ε is), the greater the noise required (the larger b is).

[0113] Step 040: Sample from the Laplace distribution according to the scale parameter to obtain random noise.

[0114] The Laplace distribution, also known as the double exponential distribution, is a commonly used continuous probability distribution in probability theory and statistics. Its probability density function is symmetric about the origin, and its shape is determined by the scale parameter *b*. The larger *b* is, the flatter the distribution, and the larger the absolute value of the extracted noise may be. In differential privacy, this distribution is chosen because its mathematical properties perfectly satisfy the definition of privacy protection.

[0115] Sampling refers to the process of randomly generating a numerical value according to a specified probability distribution (in this case, a Laplace distribution with a scale parameter of b). This generated random number is the noise that will be added to the real data. Sampling is a key step in the algorithm implementation.

[0116] The random noise is a random value obtained through the above sampling process. This value can be positive or negative, and the probability of its absolute value is determined by the scale parameter b of the Laplace distribution.

[0117] Step 050: Add the random noise to the original value of the original statistical index to generate a privacy-protected statistical index.

[0118] The privacy-protected statistical indicators are obtained by adding random noise to the original values ​​of the original statistical indicators. This result is no longer a precise true value, but rather mathematically proven secure and publishable data that provides differential privacy.

[0119] Correspondingly, step 300 in the intelligent data docking method for heterogeneous ERP systems specifically includes the following: Step 310: Securely encapsulate the privacy-protected statistical indicators, the dynamic risk control indicators, and the standard business data to generate a target data package that meets the preset risk control requirements of the financial service provider.

[0120] To further improve the intelligence and reliability of routing the target data packet to the financial service provider, in the intelligent financial data docking method for heterogeneous ERP systems provided in this application embodiment, step 400 specifically includes the following: Step 410: Receive the financial service request from the target enterprise for the target financial scenario. The financial service request includes: financing amount, payment period and expected cost.

[0121] The financial service request is a structured description of the target company's specific financing needs, initiated proactively through the platform. Unlike vague business inquiries, it contains quantifiable parameters and technical instructions to drive automated matching by the system. The components of the financial service request include: 1) Financing amount: the amount of funds required; 2) Payment term: the expected period for using the financing, typically related to the accounts receivable period of the underlying trade; 3) Expected cost: the acceptable range or preference for financing interest rates or fees (e.g., an annualized interest rate not exceeding 6%).

[0122] Step 420: Based on the dynamic risk control indicators and standard business data in the target data packet, perform access qualification verification on the target enterprise corresponding to the financial service request.

[0123] The qualification verification is the first and fundamental risk control filter for target companies before intelligent matching is initiated. Based on core dynamic risk control indicators and standard business data in the target data package, it determines whether the company meets the minimum threshold for providing such financial services. Examples of qualification verification criteria include: 1) whether the company's credit score is higher than the minimum threshold; 2) whether the applied financing amount exceeds a certain percentage of its total related accounts receivable; and 3) whether the operating entity is legally existing (which can be verified from standardized data).

[0124] Step 430: If the target enterprise passes the access qualification verification, then based on the financial service request and the dynamic risk control indicators, a preset rule engine is used to match candidate service providers that meet the first condition from multiple financial service providers; wherein, the first condition includes access conditions that match the financing amount and the payment period of the financial service request.

[0125] The rule engine is a software system that executes logical rules. In this scenario, it is pre-defined with product admission rules for financial institutions to achieve preliminary, deterministic screening. The rule engine's workflow is as follows: the engine receives financial service requests and dynamic risk control indicators as input, runs the rule base, and outputs a list of qualified financial institutions. In one example, the rule may include: if financial institution A's product requires "single financing amount ≤ 1 million" and "target enterprise credit rating ≥ B", then A will be added to the candidate list.

[0126] The first condition is a set of core matching rules executed by the rule engine for initial screening. Specifically, it refers to admission criteria that match the financing amount and payment period in the financial service request. For example, the first condition may include: if a company requests "financing of 800,000 with a payment period of 60 days," the rule engine will filter out financial institutions whose product range covers "500,000-1,000,000 with a payment period of 30-90 days."

[0127] The candidate service providers are a set of financial institutions that initially meet the requirements, obtained by filtering based on the first condition using a rules engine.

[0128] Step 440: The candidate service providers are scored on at least two preset dimensions using a recommendation algorithm, and the final target financial service provider is selected based on the scoring results.

[0129] The recommendation algorithm is a mathematical model or program that performs refined, multi-dimensional quantitative evaluation and ranking of candidate service providers. Its purpose is to find the optimal solution based on basic matching. The input to the recommendation algorithm can be a list of candidate service providers, enterprise risk control indicators, or financial service requests; the output of the recommendation algorithm can be a comprehensive score or ranking for each candidate service provider.

[0130] The preset dimensions are standards used by the recommendation algorithm to quantify multiple evaluation angles considered by enterprises when selecting financial institutions. These typically include: 1) Financing cost dimension: comparing the interest rates and fee quotes of various institutions; 2) Financing efficiency dimension: comparing the historical average approval and disbursement time of various institutions; 3) Service experience dimension: customer satisfaction scores based on historical interactions; 4) Credit limit matching dimension: the degree of matching between the credit limit offered by the institution and the enterprise's needs.

[0131] Step 450: Send the target data packet to the target financial service provider through the API gateway to trigger the target financial service provider to perform financial service approval and decision-making for the target enterprise based on the target data packet.

[0132] The API gateway is a systematic and unified API traffic management, routing, and security component. In this invention, it serves as the sole, controlled technical exit point for the platform's external data output.

[0133] The core functions of the API gateway may include: 1) Protocol conversion and routing: converting internal data formats into the format required by the target financial institution's API and accurately sending it to its interface address; 2) Traffic control and monitoring: managing concurrent API calls to ensure stability; 3) Security authentication: signing and encrypting outbound requests to ensure secure transmission.

[0134] Triggering the target financial service provider to execute financial service approval and decision-making for the target enterprise based on the target data packet refers to a series of automated or semi-automated financial business operations triggered by the target financial service provider within its internal system after receiving a structured and trusted target data packet pushed through an API gateway. A typical action chain can be: automatically verifying data credibility, rapidly reviewing the risk control model, automatically outputting approval results (credit limit, interest rate) to generating an electronic contract.

[0135] From a software perspective, this application also provides a platform for intelligent financial data docking with heterogeneous ERP systems, used to execute all or part of the aforementioned method for intelligent docking of scenario-based financial data with heterogeneous ERP systems. See [link to relevant documentation]. Figure 2 The intelligent financial data docking platform for heterogeneous ERP systems specifically includes the following components: The ERP multi-source adaptation layer module 10 is used to establish a secure connection with at least one ERP system specified by the target enterprise through pre-built interface modules corresponding to multiple heterogeneous ERP systems, based on the authorization configuration information of the target enterprise. It extracts original business data from the ERP system with the established secure connection according to the data extraction authorization scope in the authorization configuration information. Based on the semantic rule mapping engine with built-in financial semantic model, it performs semantic mapping and standardization transformation on the original business data to obtain standard business data.

[0136] The scenario-based financial intelligent engine 20 is used to calculate dynamic risk control indicators for assessing business and financial risks based on the standard business data.

[0137] The data security and privacy computing module 30 is used to perform secure encapsulation processing on the dynamic risk control indicators and the standard business data to generate a target data package that meets the preset risk control requirements of the financial service provider.

[0138] The intelligent routing and API gateway 40 is used to route the target data packet to the financial service provider, thereby triggering the financial service provider to make financial service decisions for the target enterprise based on the target data packet.

[0139] The embodiments of the intelligent financial data docking platform for heterogeneous ERP systems provided in this application can be used to execute the processing flow of the embodiments of the intelligent financial data docking method for heterogeneous ERP systems in the above embodiments. Its functions will not be repeated here, but can be referred to the detailed description of the embodiments of the intelligent financial data docking method for heterogeneous ERP systems in the above embodiments.

[0140] The intelligent financial data docking platform for heterogeneous ERP systems can perform the intelligent docking of financial data for heterogeneous ERP systems on either a server or a client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are performed on the client device, the client device may further include a processor for the specific processing of the intelligent docking of financial data for heterogeneous ERP systems.

[0141] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0142] The server and the client device can communicate using any suitable network protocol, including those not yet developed as of the date of this application. Such network protocols may include, for example, TCP / IP, UDP / IP, HTTP, HTTPS, etc. Furthermore, such network protocols may also include RPC (Remote Procedure Call Protocol) and REST (Representational State Transfer Protocol) protocols used on top of the aforementioned protocols.

[0143] As described above, the intelligent financial data docking platform for heterogeneous ERP systems provided in this application, through pre-built interface modules and a semantic rule mapping engine, automatically adapts to different ERP systems, transforming non-standard data into a unified standard. This significantly reduces docking development costs and timelines, enabling rapid large-scale deployment. While ensuring enterprise data privacy (through field-level authorization), integrated security encapsulation ensures the confidentiality, integrity, and source reliability of data from the data source to financial institutions during transmission and use, providing a reliable data foundation for financial decision-making. It upgrades the input of risk control models from static, lagging financial statements to dynamic risk indicators calculated based on real-time, standardized business data streams, making risk assessment more closely aligned with actual business operations and significantly improving the accuracy and timeliness of risk control. Through an intelligent routing mechanism, it automatically matches processed, standardized, and reliable data packets to the most suitable financial service provider, transforming traditional, lengthy, and manual processes into efficient online and automated decision-making processes, greatly improving the overall efficiency of industrial finance.

[0144] Based on the above embodiments of the intelligent financial data docking platform and / or method for heterogeneous ERP systems, this application also provides an embodiment of a scenario-based financial data processing system, see [link to embodiment]. Figure 2 The scenario-based financial data processing system specifically includes the following components: The system includes enterprise nodes, financial institution nodes, and the scenario-based financial data intelligent docking platform for heterogeneous ERP systems provided in the aforementioned embodiments; the enterprise nodes and the financial institution nodes are respectively connected to the scenario-based financial data intelligent docking platform for heterogeneous ERP systems.

[0145] To further illustrate the above embodiments, this application also provides a specific application example of using a scenario-based financial data intelligent docking platform for heterogeneous ERP systems to execute a scenario-based financial data intelligent docking method for heterogeneous ERP systems. This involves the intersection of financial technology and enterprise information management system technology, and is mainly used to break down the barriers between different external third-party ERP platforms and enterprise data information. It serves as a platform for achieving integrated intelligent data collection, processing, encrypted transmission, and risk control early warning for scenario-based financial services. The objective of using the scenario-based financial data intelligent docking platform for heterogeneous ERP systems to execute a scenario-based financial data intelligent docking method for heterogeneous ERP systems is: (1) To achieve standardized, low-cost, and rapid integration between financial institutions and heterogeneous ERP systems; (2) Under the premise of obtaining enterprise authorization, automatically and tamper-proofly collect multi-dimensional real-time business data of enterprises; (3) Transform the original ERP data into scenario-based data indicators that meet the needs of financial risk control, thereby improving the accuracy of risk control; (4) Build an open platform ecosystem and create a scenario-based financial platform that supports a variety of financial products.

[0146] See Figure 3 The scenario-based financial data intelligent docking platform for heterogeneous ERP systems can be simply referred to as the scenario-based financial data docking platform. This platform communicates and connects with both the enterprise ERP system and the financial service application market to form a complete system architecture. The enterprise ERP system can include different types of ERPs, such as Kingdee ERP, Yonyou ERP, and JianDaoYun ERP; the financial service application market can include banks, factoring (insurance claims) companies, and billing platforms; the scenario-based financial data docking platform comprises four modules: an ERP adaptation layer, data security and privacy computing, intelligent routing and API gateway, and a scenario-based financial intelligent engine. The ERP adaptation layer includes a configurable connector and a semantic rule mapping engine; the data security and privacy computing performs field-level permission control, data anonymization and encryption, and blockchain notarization; the intelligent routing and API gateway performs unified, standardized, high-concurrency, and highly available processing; and the scenario-based financial intelligent engine includes a dynamic risk control model and an intelligent risk control decision model.

[0147] The scenario-based financial data intelligent integration platform for heterogeneous ERP systems includes an ERP multi-source adaptation layer, data security and privacy computing, intelligent routing and API gateway, and a scenario-based financial intelligent engine. Details are as follows: 1. ERP Multi-Source Adaptation Layer Module (1) Provides pre-built connectors for mainstream ERP systems. Within the authorized scope, users can configure database addresses, API interface information, authentication information, etc. through a graphical interface to achieve "out-of-the-box use" without writing code.

[0148] (2) Standardization method for heterogeneous ERP data based on semantic rule mapping engine: The engine has a built-in financial business semantic model. Through predefined business object models and rules, it automatically extracts, cleans and converts heterogeneous data from different ERP systems into standardized data formats (such as json, xml and other formats) that meet the requirements of financial institutions. The semantic rule mapping engine is implemented as follows: Step 1: Define a standard model: The platform internally develops a standard model based on the vocabulary accumulated in the current financial field, such as: customerName, transactionAmount, and transactionDate.

[0149] Step 2: Collect metadata from different ERP systems.

[0150] Suppose we have collected data from two ERP systems: SAP and Yonyou.

[0151] SAP system: NAME1 (customer name), DMBTR (amount), BLDAT (document date).

[0152] Yonyou system: ACCOUNT_NAME (customer name), INVOICE_AMOUNT (invoice amount), INVOICE_DATE (invoice date).

[0153] Step 3: Establish semantic rules: Rule 1: Customer name mapping; Rule 2: Transaction amount mapping.

[0154] Step 4: Perform mapping and conversion; some fields may have inconsistent formats, which need to be standardized to a standard format; for example, transactionAmount, if the amount unit in the SAP source system is cents, it needs to be converted to yuan.

[0155] Advanced features: When there are many source fields and the rules are unclear, machine learning is used to assist in mapping, including: similarity based on field name: calculating the similarity between the source field and the standard field name (using word vectors); and similarity based on data content: analyzing the data distribution, format, number of unique values, etc. of the source field and matching it with the expected pattern of the standard field.

[0156] The prediction results of machine learning models are combined with semantic rules to map fields from different ERP systems to a unified standard field.

[0157] 2. Data Security and Privacy Computing Module (1) Field-level permission control: Enterprises can authorize the opening of specific data fields according to the financial scenario, rather than the entire database. For example, when financing, only the amount and payment period of "accounts receivable" are opened, while supplier information, inventory and other information are blocked.

[0158] (2) Data desensitization and encryption: Sensitive data (such as customer name and mobile phone number) is desensitized before transmission. The transmission method uses national cryptographic algorithms or internationally recognized encryption algorithms to encrypt the data throughout the process.

[0159] (3) Blockchain evidence storage service: One of the innovations is to store key data extracted from the ERP system (such as contracts, invoices, warehouse entry slips, etc.) on the blockchain to ensure that the data has not been tampered with at the source and to provide post-audit traceability capabilities.

[0160] See Figure 4 For example, the specific process of storing multiple contract information on the blockchain: a. Batch data processing: Calculate the hash value (SHA-256) for each contract information to obtain the hash value; construct these hash values ​​into a Merkle tree to obtain the Merkle root hash.

[0161] b. Construct a record of evidence: Package the metadata such as the Merkle root hash, the start and end times of the batch data, and the data source identifier into a record of evidence.

[0162] c. Sending a transaction: The transaction is packaged into a block and a timestamp is generated.

[0163] d. Proof of delivery result: Returns the transaction hash and block height. At the same time, the system will save the proof path of each data hash and Merkle tree in the batch for subsequent verification of individual data. The execution frequency of on-chain proof of delivery is generally carried out by xxljob scheduled task, which is executed once a day at a fixed time, with a maximum of 1,000 data entries per execution.

[0164] The evidence verification process includes: a. Provide verification data: original data, data hash (optional), and evidence (transaction hash and block height); b. Retrieve evidence records from the blockchain: Obtain the Merkle root hash; c. Compare hash values: Verify whether the data hash is in the Merkle tree; d. Verification result: If the results are consistent, it proves that the data has not been tampered with and the storage time is reliable.

[0165] Among them, since it involves the financial sector, the blockchain evidence storage service adopts a consortium blockchain model: it is jointly maintained by core enterprises, financial institutions such as banks, and regulatory agencies.

[0166] (4) Differential privacy technology is used to avoid leaking sensitive original data of enterprises when outputting data indicators to financial institutions, and only the processed irreversible feature values ​​are provided.

[0167] The differential privacy feature generation process is as follows: Figure 5 As shown. In a specific example, taking accounts receivable days as an example, accounts receivable turnover days = (average accounts receivable × 365) / annual credit sales; the actual statistical values ​​include: average turnover days: 93.75 days; standard deviation of turnover: 44.87 days; median turnover days: 112.5 days; select an appropriate privacy protection level: 0.5. The specific process is as follows: Determine privacy parameters and sensitivity: Assume that the maximum possible turnover days for a single supplier is 365 days and the minimum possible turnover days is 1 day. Assume there are 8 suppliers. The average sensitivity = (365-1) / 8 = 45.5 days. That is to say, if any supplier's data is replaced with an extreme value, the maximum impact on the average is 45.5 days. Injecting Laplace noise: Laplace noise scale parameter: scale = sensitivity / privacy protection level = 45.5 / 0.5 = 91 days; Randomly drawing noise from the Laplace distribution: -18 days; Generate protected statistics: Protected average turnover days = actual average + noise = 93.75 - 18 = 75.75 days, approximately 76 days; Processing other relevant indicators: Adding noise to the standard deviation: Sensitivity ≈ 30 days, noise = +12 days; Protected standard deviation = 44.87 + 12 = 56.87 days, approximately 57 days; Adding protection to distribution characteristics: Using an exponential mechanism to generate protected distribution intervals: True distribution (not published): Excellent (≤60 days): 3 suppliers; Good (61-90 days): 0 suppliers; Average (91-120 days): 2 suppliers; Poor (>120 days): 3 suppliers; Protected distribution (published): Excellent (≤60 days): 2 suppliers; Good (61-90 days): 1 supplier; Average (91-120 days): 2 suppliers; Poor (>120 days): 3 suppliers; Data provided to external parties: Key indicators: Average accounts receivable turnover days: approximately 76 days; Turnover days volatility: standard deviation approximately 57 days; Overall risk assessment: Supply chain collection efficiency is at a medium level in the industry.

[0168] 3. Scenario-based Financial Intelligence Engine (1) Dynamic risk control model: It does not rely solely on static financial statements, but instead constructs different financial risk control models based on multi-dimensional and dynamic business data streams obtained in real time from the ERP system. For example, in the supply chain finance scenario, dynamic indicators such as "order confirmation rate" and "accounts payable turnover days" are automatically calculated based on information such as purchase orders, warehouse receipts, and invoices.

[0169] (2) Intelligent risk control decision model: When specific risk control rules and business conditions are met (such as accounts receivable period exceeding 60 days and debtor credit is good), the decision engine will automatically send financial business signals (such as “financing limit suggestion”, “loan indicator”) or generate risk assessment reports to the financial institution’s business system to realize automated and intelligent approval of financial services.

[0170] Let's take predicting corporate cash flow risk as an example to illustrate the risk control decision model: a. Construct a time-series dataset: Create a linear series based on inventory turnover days in days; b. Analysis models used: a) Trend analysis: Exponential smoothing is used to determine whether inventory turnover days are continuously deteriorating; b) Seasonal / cyclical analysis: STL decomposition is used to distinguish between long-term trends, seasonal fluctuations and random noise. Some indicators, such as accounts receivable, will show an upward trend during the peak sales season at the end of the year, but this is reasonable and seasonal factors need to be removed to determine the trend.

[0171] c. Prediction model: The ARIMA (Autoregressive Integral Moving Average) time series analysis model is adopted: This model is more suitable for processing time series data with trends and seasonality for prediction.

[0172] d. Forecasting Future Cash Flow: a) Constructing Cash Flow Driver Forecasts: Forecasting sales revenue for the next 1-3 months (based on a time series model of historical orders); Forecasting accounts receivable collection for the next 1-3 months: Using ARIMA to predict inventory turnover days for each month in the future, combined with sales revenue forecasts, to estimate the amount of collection; Forecasting cash outflows for the next 1-3 months (based on time series models of accounts payable, purchase orders, and fixed costs); Synthetic Cash Flow Forecast: Forecast ending cash flow = beginning cash + forecasted sales revenue collection + other inflows - forecasted cash outflows - other outflows; Risk Assessment: Based on the final forecast results, it can be predicted whether there will be a cash flow gap in the next 1-3 months. If the cash balance is lower than the safety line in the next 3 months, a risk warning will be triggered.

[0173] The risk decision-making system will be further constructed based on the above example of predicting future cash flows: a. Several risk indicators will be constructed: Abnormal order indicators: Order cancellation rate rises for two consecutive weeks; Abnormal inventory indicators: Inventory turnover days continue to increase over the next two months (ARIMA model); Abnormal accounts receivable indicators: Accounts receivable turnover days exceed 60 days, and the proportion of accounts receivable aged over 90 days exceeds 15%; b. If any of the above indicators are abnormal, an early warning report will be generated and sent to the enterprise and financial institutions simultaneously.

[0174] 4. Intelligent Router and API Gateway (1) Provide standardized financial data service interfaces to external parties in a unified manner; (2) Based on the enterprise's financial scenario, the processed data indicators are intelligently routed to the most suitable financial institution or financial product to achieve a business closed loop; (3) Supports high-concurrency and high-availability API calls to ensure data transmission stability and efficiency.

[0175] The following is a detailed discussion of the principles of intelligent gateway routing: (1) Admission filtering layer; (2) Rule matching layer; (3) Intelligent recommendation layer.

[0176] Let's take the financing of accounts receivable vouchers of supplier companies as an example to illustrate: a. First, assess the authenticity of the core enterprise's credit endorsement, transaction orders, invoices, and contracts to confirm whether the financing access threshold is met; b. Obtain financing needs from supplier companies: accounts receivable of 500,000, with a payment term of 90 days, they hope to obtain funds as soon as possible, with controllable costs; c. Filtering based on the rules engine: Matching qualified financial institutions and banks based on information such as buyer credit rating, accounts receivable voucher amount, due date, and years of cooperation with core enterprises. Eight financial platforms may meet the requirements.

[0177] d. Recommendation algorithm rating: Based on the 8 selected financial platforms, ratings are given from four dimensions: financing cost, financing efficiency, financing ratio, and service experience, and the platforms are ranked according to their scores.

[0178] e. Intelligent Recommendation: Based on the rating, the system recommends the financial platform with the highest rating and pushes it to the supplier platform through the API gateway.

[0179] See Figure 6 The interaction process with the platform is as follows: (1) Authorization and Connection: Enterprise users authorize and configure their ERP systems on the platform and establish a secure connection through the ERP adapter; (2) Data extraction and encryption: The adapter extracts authorized data from the ERP system according to preset rules and encrypts it locally; (3) Data upload and storage: While the encrypted data is transmitted to the platform, the data is hashed and uploaded to the blockchain for storage. (4) Scenario-based indicator calculation: Based on the type of financial application initiated by the enterprise (such as order financing), the corresponding data model is called to calculate and generate scenario-based financial data indicators in real time; (5) Push financial data to the relevant financial institutions based on intelligent routing and API gateway; (6) Financial service trigger: Financial institutions receive the pushed data, approve it, and return the approval result (loan amount) to the platform. The platform then notifies the corresponding corporate clients.

[0180] In other words, the application examples in this application provide a method for standardizing heterogeneous ERP data based on a semantic rule mapping engine, combined with a data security and trusted transmission mechanism that integrates blockchain notarization and field-level permission control; and a method for constructing a financial risk control model based on dynamic ERP business data, which has the following beneficial effects: 1. High efficiency and universality: Through the ERP adaptation layer, it enables rapid and low-cost integration with various heterogeneous ERP systems, reducing complexity and solving the problem of large-scale promotion.

[0181] 2. Data Security and Trustworthiness: By using field-level access control and blockchain notarization technology, combined with mature encryption algorithms, it protects corporate data privacy while providing financial institutions with an immutable and trustworthy data source, greatly reducing the credit risk and fraud risk of financial institutions.

[0182] 3. Intelligent and precise: Upgrade static financial report data risk control to dynamic business flow data risk control. Through scenario-based data indicators, financial services can better match the actual operating conditions of enterprises, thereby improving the accuracy of risk control and service efficiency.

[0183] 4. Improve industry efficiency: Enable one-click and automation of corporate financing applications, shortening the traditional financing approval process of several weeks or even months to several hours or even minutes, significantly improving the capital turnover efficiency of the industrial chain.

[0184] This application also provides an electronic device, which may include a processor, a memory, a receiver, and a transmitter. The processor is used to execute the intelligent financial data docking method for heterogeneous ERP systems mentioned in the above embodiments. The processor and memory can be connected via a bus or other means, taking a bus connection as an example. The receiver can be connected to the processor and memory via wired or wireless means.

[0185] The processor can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0186] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the scenario-based intelligent financial data docking method for heterogeneous ERP systems in the embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby realizing the scenario-based intelligent financial data docking method for heterogeneous ERP systems in the above method embodiments.

[0187] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0188] The one or more modules are stored in the memory, and when executed by the processor, the intelligent financial data docking method for heterogeneous ERP systems in the embodiment is executed.

[0189] In some embodiments of this application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected via a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0190] As one implementation method, the functions of the receiver and transmitter in this application can be implemented by transceiver circuits or dedicated transceiver chips, and the processor can be implemented by dedicated processing chips, processing circuits or general-purpose chips.

[0191] As another implementation approach, the server provided in this application embodiment can be implemented using a general-purpose computer. That is, the program code implementing the processor, receiver, and transmitter functions is stored in memory, and the general-purpose processor implements the processor, receiver, and transmitter functions by executing the code in memory.

[0192] This application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps of the aforementioned intelligent financial data docking method for heterogeneous ERP systems. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0193] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the aforementioned intelligent docking method for scenario-based financial data of heterogeneous ERP systems.

[0194] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave.

[0195] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0196] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0197] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to the embodiments of this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for intelligent data integration in heterogeneous ERP systems, characterized in that, include: Based on the target company's authorization configuration information, a secure connection is established with at least one ERP system designated by the target company through pre-built interface modules corresponding to multiple heterogeneous ERP systems. The original business data is extracted from the ERP system with the established secure connection according to the data extraction authorization scope in the authorization configuration information. Based on the semantic rule mapping engine with built-in financial semantic model, the original business data is semantically mapped and standardized to obtain standard business data, and dynamic risk control indicators for evaluating enterprise operation and financial risks are calculated based on the standard business data. The dynamic risk control indicators and the standard business data are securely encapsulated to generate a target data package that meets the preset risk control requirements of the financial service provider. The target data packet is routed to the financial service provider to trigger the financial service provider to make financial service decisions for the target enterprise based on the target data packet.

2. The intelligent data docking method for heterogeneous ERP systems according to claim 1, characterized in that, Before establishing a secure connection with at least one ERP system designated by the target enterprise, the following is also included: The system receives authorization configuration information input by the target enterprise through a preset graphical configuration interface. The authorization configuration information includes: the type of ERP system specified by the target enterprise, connection parameters, and the data extraction authorization range at the field level. Correspondingly, based on the target enterprise's authorization configuration information, a secure connection is established with at least one ERP system designated by the target enterprise through pre-built interface modules corresponding to multiple heterogeneous ERP systems. The original business data is then extracted from the ERP system with the established secure connection according to the data extraction authorization scope in the authorization configuration information. This includes: Based on the type and connection parameters of the ERP system specified by the target enterprise, the corresponding pre-set interface modules are called to establish secure connections with each ERP system specified by the target enterprise in the pre-set interface modules corresponding to multiple heterogeneous ERP systems. According to the data extraction authorization scope, the corresponding original business data is extracted from the ERP system with an established secure connection.

3. The intelligent data docking method for heterogeneous ERP systems according to claim 1, characterized in that, The semantic rule mapping engine based on the built-in financial semantic model performs semantic mapping and standardization transformation on the original business data to obtain standard business data, including: The original business data is input into the semantic rule mapping engine, so that the semantic rule mapping engine can identify the source fields to be transformed in the original business data according to the predefined financial semantic model containing the corresponding fields of each financial business object; and the semantic rule mapping engine can search for target fields that match the name and / or business context of the source fields in the pre-set semantic mapping rule library, and map the source fields to the matched target fields. If there is a source field that cannot be matched in the rule base, the data features corresponding to the source field are input into a preset machine learning model so that the machine learning model outputs similarity prediction results between the source field and each of the target fields in the rule base based on the data features corresponding to the source field, and determines the target field corresponding to the source field for mapping based on the similarity prediction results. After mapping, the data values ​​in the business data are standardized and cleaned to generate standard business data.

4. The intelligent data docking method for heterogeneous ERP systems according to claim 3, characterized in that, Before calculating the dynamic risk control indicators used to assess business operations and financial risks based on the standard business data, the following steps are also included: Based on the authorization scope of the data fields in the authorization configuration information, the standard business data is filtered at the field level to obtain the filtered standard business data. From the filtered standard business data, predefined fields and field values ​​for constituting key business vouchers are extracted. The fields of the key business vouchers include: number-type fields and time-type fields for uniquely identifying business documents. Perform a hash operation on the field values ​​of the key business voucher to obtain the corresponding first hash value; Multiple first hash values ​​belonging to the same data processing task are constructed according to the Merkle tree data structure to obtain the corresponding Merkle root hash; The notarization record, which includes the Merkle root hash, data batch identifier, and timestamp, is sent to the consortium blockchain network jointly maintained by the participating nodes for notarization, and a notarization credential containing the transaction hash and block height is obtained. The participating nodes include at least two of the following: enterprise nodes, financial institution nodes, and regulatory agency nodes.

5. The intelligent data docking method for heterogeneous ERP systems according to claim 1, characterized in that, The dynamic risk control indicators calculated based on this standard business data to assess enterprise operational and financial risks include: Extract business flow data that corresponds to the target financial service scenario and is serialized according to the time dimension from the standard business data; The business flow data is input into a pre-configured dynamic risk control model so that the dynamic risk control model can obtain the corresponding quantitative value of future business trends through a time series prediction algorithm. In addition, based on preset business rules, the quantitative values ​​corresponding to the business flow data are calculated to reflect the asset status and turnover efficiency; The quantitative values ​​of future business trends and the quantitative values ​​reflecting asset status and turnover efficiency are used as the original statistical indicators for risk assessment; and based on the original statistical indicators, a dynamic risk control indicator is generated through a risk decision model, which includes at least one of quantitative risk scores, abnormal early warning signals and future risk prediction results.

6. The intelligent data docking method for heterogeneous ERP systems according to claim 5, characterized in that, Before performing secure encapsulation processing on the dynamic risk control indicators and the standard business data, the method further includes: Set a privacy budget for the original statistical metrics and determine their global sensitivity under the definition of differential privacy; Based on the privacy budget and the global sensitivity, calculate the noise scale parameter of the Laplace mechanism; sample random noise from the Laplace distribution based on the scale parameter; add the random noise to the original value of the original statistical index to generate the privacy-preserving statistical index; Correspondingly, the process of securely encapsulating the dynamic risk control indicators and the standard business data to generate a target data package that meets the preset risk control requirements of the financial service provider includes: The privacy-protected statistical indicators, the dynamic risk control indicators, and the standard business data are securely encapsulated to generate a target data package that meets the preset risk control requirements of the financial service provider.

7. The intelligent data docking method for heterogeneous ERP systems according to claim 1, characterized in that, The step of routing the target data packet to the financial service provider to trigger the financial service provider to make financial service decisions for the target enterprise based on the target data packet includes: Receive financial service requests from the target enterprise for a target financial scenario, the financial service requests including: financing amount, payment period and expected cost; Based on the dynamic risk control indicators and standard business data in the target data package, the target enterprise is verified for access eligibility corresponding to the financial service request. If the target enterprise is determined to have passed the access qualification verification, then based on the financial service request and the dynamic risk control indicators, a preset rule engine is used to match candidate service providers that meet the first condition from multiple financial service providers; wherein, the first condition includes access conditions that match the financing amount and the payment period of the financial service request. The candidate service providers are scored on at least two preset dimensions using a recommendation algorithm, and the final target financial service provider is selected based on the scoring results. The target data packet is sent to the target financial service provider via the API gateway to trigger the target financial service provider to perform financial service approval and decision-making for the target enterprise based on the target data packet.

8. A scenario-based intelligent financial data docking platform for heterogeneous ERP systems, characterized in that, Used to perform the intelligent docking method for scenario-based financial data of heterogeneous ERP systems as described in any one of claims 1 to 7.

9. A scenario-based financial data processing system, characterized in that, include: Enterprise nodes, financial institution nodes, and the scenario-based intelligent financial data docking platform for heterogeneous ERP systems as described in claim 8; The enterprise node and the financial institution node are respectively connected to the scenario-based financial data intelligent docking platform for heterogeneous ERP systems.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the intelligent financial data docking method for heterogeneous ERP systems as described in any one of claims 1 to 7.

Images