A heterogeneous financial system data conversion and interfacing method and device

Abstract

The application provides a heterogeneous financial system data conversion and interfacing method and device, relates to the technical field of enterprise information system integration, and comprises the following steps: generating a push context according to a voucher push request of a business system, wherein the push context at least contains a target financial system identifier, a voucher category and business data; matching a target adapter from an adapter set according to the push context, wherein the adapters all provide a unified interface contract, and are defined with data conversion, data push and result recording operations; executing a data conversion operation of the target adapter, converting the business data into an interface data object, and mapping a business code into a system code according to a hierarchical matching rule; executing a data push operation, and sending the interface data object to a target financial system interface; and receiving a response result and executing a result recording operation. The application solves the problems of high code coupling degree, poor expansibility and low code reuse rate caused by directly calling different financial system interfaces in the prior art.

Description

Technical Field

[0001] This invention relates to the field of enterprise information system integration technology, and more specifically, to a method and apparatus for data conversion and integration of heterogeneous financial systems. Background Technology

[0002] In practical applications, contract management systems need to interface with multiple heterogeneous financial systems (such as NCC and BIP). Different financial systems have different application programming interfaces (APIs), data formats, and field definitions, requiring separate development of interface code for each system. While field mapping can be done through configuration files, it cannot handle complex business logic transformations. The processing logic for the same business scenario also differs significantly across different financial systems. For example, NCC's accounts receivable and payment receipts have upstream and downstream relationships, while BIP does not; NCC allows red-ink reversals for negative amounts, while BIP does not. In existing technologies, directly calling the interfaces of different financial systems within the business code results in high code coupling, poor scalability, and a large amount of repetitive logic in the interface code between different systems, leading to low reusability. Summary of the Invention

[0003] The purpose of this invention is to provide a method and apparatus for data conversion and interoperability between heterogeneous financial systems, thereby improving the aforementioned problems. To achieve the above objective, the technical solution adopted by this invention is as follows: Firstly, this application provides a method for data conversion and integration of heterogeneous financial systems, including: Receive a voucher push request sent by the business system, and generate a push context based on the voucher push request. The push context includes at least the target financial system identifier, voucher type, and business data. The target adapter is matched from the adapter set according to the push context. All adapters in the adapter set provide a unified interface contract, which defines data transformation operation, data push operation and result recording operation. The target adapter performs a data conversion operation to convert the business data into an interface data object of the target financial system, and maps the business code in the business data to the system code according to a preset hierarchical matching rule during the conversion process. Perform the data push operation of the target adapter to send the interface data object to the target financial system interface; Receive the response result returned by the target financial system and perform the result recording operation of the target adapter.

[0004] Secondly, this application also provides a heterogeneous financial system data conversion and interface device, including: The request receiving module is used to receive a voucher push request sent by the business system and generate a push context based on the voucher push request. The push context includes at least the target financial system identifier, voucher type, and business data. The adapter matching module is used to match the target adapter from the adapter set according to the push context. The adapters in the adapter set all provide a unified interface contract, which defines data conversion operation, data push operation and result recording operation. The data conversion module is used to perform the data conversion operation of the target adapter, convert the business data into the interface data object of the target financial system, and map the business code in the business data to the system code according to the preset hierarchical matching rules during the conversion process; The data push module is used to perform the data push operation of the target adapter and send the interface data object to the target financial system interface; The result recording module is used to receive the response result returned by the target financial system and perform the result recording operation of the target adapter.

[0005] Thirdly, this application also provides a heterogeneous financial system data conversion and interface device, including: Memory, used to store computer programs; A processor is used to implement the steps of the heterogeneous financial system data conversion and docking method when executing the computer program.

[0006] Fourthly, this application also provides a readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described method for data conversion and interoperability based on heterogeneous financial systems.

[0007] The beneficial effects of this invention are as follows: 1. This invention abstracts the interface problem of heterogeneous systems into a unified interface contract through a three-layer adapter architecture. This allows for the addition of a new financial system by implementing only the corresponding adapter, without modifying the core business logic, thus significantly shortening the development cycle and reducing integration risks. Furthermore, by encapsulating common logic using an abstract base class, specific adapters only need to focus on the business differences, thereby achieving high reusability of common logic and reducing a large amount of duplicate code.

[0008] 2. The unified push process and exception handling mechanism provided by this invention provide standardized management for the entire data conversion and push process, enhance system reliability, and significantly improve the push success rate.

[0009] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing embodiments of the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the data conversion and integration method for heterogeneous financial systems described in this embodiment of the invention; Figure 2 This is a schematic diagram of the heterogeneous financial system data conversion and docking device described in an embodiment of the present invention; Figure 3 This is a schematic diagram of the heterogeneous financial system data conversion and docking equipment described in an embodiment of the present invention.

[0012] Marked in the image: 800. Data conversion and interface equipment for heterogeneous financial systems; 801. Processor; 802. Memory; 803. Multimedia components; 804. I / O interface; 805. Communication components. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0014] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0015] Example 1: This embodiment provides a method for data conversion and integration of heterogeneous financial systems, which is applicable to information integration environments in large enterprise groups where contract management systems and multiple heterogeneous financial systems coexist.

[0016] See Figure 1 The figure shows that this method includes: S1. Receive a voucher push request sent by the business system, and generate a push context based on the voucher push request. The push context includes at least the target financial system identifier, voucher type, and business data. In this embodiment, when a business system needs to push financial vouchers to a heterogeneous financial system, preferably, the business system is a contract management system. Specifically, the voucher push request sent by the business system contains at least three essential pieces of information: the identifier of the target financial system, such as "NCC" or "BIP", the type of voucher to be pushed, such as "accounts receivable", "receipt", "payment slip" or "red-ink voucher", and the business data object.

[0017] The business data object is a collection of original documents from the business system. For example, for a payment claim business, the business data object may include fields such as business order number, contract number, customer name, claim type, payment details, amount, and settlement method.

[0018] Based on the above embodiments, this method further includes: S2. Match the target adapter from the adapter set according to the push context. All adapters in the adapter set provide a unified interface contract. The interface contract defines data conversion operation, data push operation and result recording operation. Specifically, step S2 includes: S21. Perform normalization processing on the push context, and verify the validity of the target financial system identifier, the voucher type, and the business data; Specifically, the normalization process includes: if the target financial system identifier is not explicitly specified in the push context, then the system will fill in the missing information according to the default push system preset by the system; convert the voucher type into an internally agreed enumeration value format; and standardize the field names in the business data.

[0019] After normalization, the target financial system identifier, voucher type, and business data in the push context are validated for validity. This includes verifying whether the target financial system identifier belongs to the registered system list, whether the voucher type is a supported voucher type by the financial system, and whether the business data contains the key fields necessary for conversion, such as contract code, customer tax number, and amount. If any validation fails, the matching process is terminated, and an error message is returned.

[0020] S22. According to the adapter registration order, compare the matching predicate of each adapter in the adapter set with the normalized push context in turn; Specifically, according to the registration order of the adapters in the registration container, the matching predicates declared by each adapter are compared with the push context in turn.

[0021] In this embodiment, each adapter is configured with one or more matching predicates during registration. Each matching predicate is a Boolean expression used to determine whether the adapter is suitable for the current push context.

[0022] Specifically, the matching predicate of the system-level abstract adapter is configured to: verify whether the target financial system identifier in the push context is equal to the preset target system value, and verify whether the operation type is an adjustment document.

[0023] The matching predicate of the credential-level adapter is configured to further verify whether the credential category in the push context is equal to the preset credential type value, based on the successful matching of the system-level abstract adapter.

[0024] The matching predicate of some scenario adapters is configured to: add constraint validation on specific business flag fields in business data when the aforementioned matching conditions are met.

[0025] S23. The first adapter that successfully matches is determined as the target adapter. In this embodiment, the adapter set is traversed according to the registration order. For the currently traversed adapter, all its matching predicates are compared with the actual values ​​of the corresponding fields in the push context. The adapter is designated as the target adapter only if all its matching predicates match successfully.

[0026] Specifically, before performing the data conversion operation of the target adapter, the following steps are also included: S24. Verify whether the target financial system identifier, voucher type, and business data of the push context are missing; Specifically, the process involves checking in sequence whether the target financial system identifier field is empty, whether the voucher type field has been assigned a value, and whether the business data object is a valid data structure containing the basic key-value pairs necessary to complete the subsequent conversion, such as the business order number and amount.

[0027] S25. If there are no missing data, extract the contract code, project code, customer code, and upstream accounts receivable voucher identifier from the business data, and verify whether the contract code, project code, customer code, and upstream accounts receivable voucher identifier can be successfully mapped to the system code according to the preset hierarchical matching rules. Among them, the contract code is used to identify the contract associated with the business document; the project code is used to identify the specific project under the contract; the customer code is used to identify the counterparty; and the upstream accounts receivable voucher identifier is used to locate the original accounts receivable document when red-inking or related push is required.

[0028] The preset hierarchical matching rule is as follows: First, the business code in the business data is used as the key value, and the corresponding system code is read from the local mapping table; Then, when the corresponding system code is not read from the local mapping table, the master data query interface is called to obtain the corresponding system code from the master data system; Finally, when the corresponding system code is not found in the master data system, recursively matching is performed in the order of taxpayer identification number, settlement method, and department level.

[0029] If a valid system code cannot be obtained after the above three-level mapping for any of the following codes: contract code, project code, customer code, and upstream accounts receivable voucher identifier, the mapping is deemed to have failed.

[0030] S26. After successful mapping, verify whether the fields in the interface data object meet the interface requirements. The fields include financial organization code, contract master data code, project master data code, and expense item. Specifically, the interface data object is an intermediate data structure generated after the data transformation operation, and its field definitions depend on the application programming interface specification of the target financial system. The validation content includes: Verify whether the financial organization code is a valid organization configured in the target financial system; verify whether the contract master data code is a non-empty string and its length conforms to the interface specification; verify whether the project master data code has a reasonable relationship with the contract master data code; verify whether the expense item belongs to the expense item list preset by the target financial system.

[0031] If any of the fields does not meet the interface requirements, the voucher status will be marked as "draft", the failure reason will be classified as "API third-party interface failure", and the specific unmet field and its reason will be recorded.

[0032] S27. If the interface requirements are met, the data conversion operation of the target adapter is executed; the business data is converted into the interface data object of the target financial system, and during the conversion process, the business code in the business data is mapped to the system code according to the hierarchical matching rule; Specifically, based on the system code obtained from the mapping and the verified interface field structure, the original business data object is converted into an interface data object recognizable by the target financial system. During the conversion process, the business code in the business data is mapped to the corresponding system code, and then assembled into a complete interface data object according to the interface message format of the target financial system.

[0033] Based on the above embodiments, this method further includes: S3. Execute the data push operation of the target adapter to send the interface data object to the target financial system interface; In this embodiment, since the same adapter may support multiple business scenarios, and the target financial system interfaces corresponding to different scenarios are different, intelligent identification and routing based on specific fields in the business data are required before pushing the data. This embodiment uses the repayment claim business as an example for illustration.

[0034] Specifically, step S3 includes: S31. Obtain the "Claim Category" field and "Payment Item" field from the business data; wherein, the "Claim Category" field is used to identify the business category to which funds flow in, and the business category includes project repayment, security deposit, deposit or other funds; the "Payment Item" field is used to identify the specific reason for payment or type of funds, including: bank transfer, bid security deposit return, performance bond return, quality guarantee deposit return, letter of guarantee return, etc.

[0035] S32. When the target financial system is identified as the first preset system: if the claim category field is project payment and the payment item field is bank transfer, then the interface data object is routed to the payment receipt interface; In this embodiment, the first preset system is the BIP financial system. When the target financial system identifier is equal to the first preset system: If the value of the "Claim Category" field is "Project Payment" and the value of the "Payment Item" field is "Bank Transfer," then the system will route the interface data object to the BIP system's payment receipt interface. The payment receipt interface is used to process standard customer payment transactions and generate BIP payment receipt vouchers.

[0036] If the value of the "Category" field is "Project Payment," but the value of the "Payment Item" field is not "Bank Transfer," such as "Bill" or "Cash," then the interface data object will be routed to the BIP system's fund collection interface. This fund collection interface is used to handle fund collection transactions that are not based on bank transfers.

[0037] S33. When the target financial system is identified as the second preset system: if the claim category field is a security deposit and the payment item field belongs to the preset refund item set, then the interface data object is routed to the payment and refund interface; In this embodiment, the second preset system is the NCC financial system. When the target financial system identifier is equal to the second preset system: If the value of the "Claim Category" field is "Security Deposit" or "Deposit," and the value of the "Payment Item" field belongs to a preset set of refund items, then the interface data object will be routed to the payment and refund interface of the NCC system. The preset set of refund items includes, but is not limited to, bid security deposit refund, performance security deposit refund, quality security deposit refund, and letter of guarantee refund.

[0038] Based on the above embodiments, this method further includes: S4. Receive the response result returned by the target financial system and perform the result recording operation of the target adapter.

[0039] Specifically, after receiving the response result returned by the target financial system, the process also includes: S41. When the response result is push failure, extract the failure type identifier from the response result and convert the push context into a task record; In this embodiment, the failure type identifier is an error code returned by the target financial system, used to distinguish the specific reason for the failure. For example, the failure type identifier may include network timeout, connection rejection, business verification failure, duplicate submission, internal system error, etc. According to preset classification rules, the failure type identifier is divided into retryable types and non-retryable types. Retryable types are usually temporary failures, such as network timeout, connection pool exhaustion, temporary service unavailability, etc.; non-retryable types are usually business logic errors, such as invalid parameters, missing basic data, etc.

[0040] After extracting the failure type identifier, the current push context is converted into a task record. The task record contains at least the following fields: unique task identifier, serialized content of the original push context, target financial system identifier, voucher type, business order number, creation time, number of retries, and task status.

[0041] S42. When the failure type is identified as a retryable type, the business order number of the push context is read from the task record; S43. Obtain a distributed lock based on the business order number, add an idempotent key generated by the business order number and the voucher type to the interface data object, and asynchronously execute the retry push through the thread pool; Specifically, the key value of the distributed lock consists of the business order number plus a fixed prefix, and the idempotent key is a string generated from the business order number and the voucher type. The idempotent key ensures that multiple retries of the same business order number will not generate duplicate documents in the target financial system, and the target financial system should perform deduplication verification based on the idempotent key.

[0042] In summary, this embodiment successfully shields the system differences between NCC and BIP through a three-layer adapter architecture and hierarchical matching rules, significantly improving the system's scalability while ensuring data consistency.

[0043] Example 2: like Figure 2 As shown, this embodiment provides a data conversion and interface device for heterogeneous financial systems, the device comprising: The request receiving module is used to receive a voucher push request sent by the business system and generate a push context based on the voucher push request. The push context includes at least the target financial system identifier, voucher type, and business data. The adapter matching module is used to match the target adapter from the adapter set according to the push context. The adapters in the adapter set all provide a unified interface contract, which defines data conversion operation, data push operation and result recording operation. The data conversion module is used to perform the data conversion operation of the target adapter, convert the business data into the interface data object of the target financial system, and map the business code in the business data to the system code according to the preset hierarchical matching rules during the conversion process; The data push module is used to perform the data push operation of the target adapter and send the interface data object to the target financial system interface; The result recording module is used to receive the response result returned by the target financial system and perform the result recording operation of the target adapter.

[0044] Based on the above embodiments, the data conversion module includes: The local mapping unit is used to read the corresponding system code from the local mapping table, using the business code in the business data as the key value. The master data query unit is used to call the master data query interface to obtain the corresponding system code from the master data system when the corresponding system code is not read from the local mapping table. The downgrade matching unit is used to recursively match taxpayer identification number, settlement method, and department level in sequence when the corresponding system code is not obtained from the master data system.

[0045] Based on the above embodiments, a pre-verification module is also included, the pre-verification module comprising: The context verification unit is used to verify whether the target financial system identifier, voucher type, and business data of the push context are missing. The master data verification unit is used to extract the contract code, project code, customer code, and upstream accounts receivable voucher identifier from the business data when there are no missing data, and to verify whether the contract code, project code, customer code, and upstream accounts receivable voucher identifier can be successfully mapped to the system code according to the preset hierarchical matching rules. The interface field verification unit is used to verify whether the fields in the interface data object meet the interface requirements after the mapping is successful. The fields include financial organization code, contract master data code, project master data code, and expense item. The conversion triggering unit is used to trigger the data conversion module to perform the data conversion operation of the target adapter when the interface requirements are met.

[0046] Based on the above embodiments, the adapter matching module includes: The normalization processing unit is used to perform normalization processing on the push context and verify the validity of the target financial system identifier, the voucher type, and the business data. The predicate matching unit is used to compare the matching predicate of each adapter in the adapter set with the normalized push context in the order of adapter registration. An adapter determination unit is used to determine the first successfully matched adapter as the target adapter.

[0047] Based on the above embodiments, the data push module includes: The field acquisition unit is used to acquire the claim category field and payment item field from the business data. The first routing unit is used to route the interface data object to the payment receipt interface when the target financial system is identified as the first preset system, if the claim category field is project payment and the payment item field is bank transfer. The second routing unit is used to route the interface data object to the payment and refund interface when the target financial system is identified as the second preset system, if the claim category field is a security deposit and the payment item field belongs to a preset set of refund items.

[0048] Based on the above embodiments, a retry compensation module is also included, the retry compensation module comprising: The failure handling unit is used to extract the failure type identifier from the response result when the response result is a push failure, and to convert the push context into a task record; The business order number reading unit is used to read the business order number of the push context from the task record when the failure type is identified as a retryable type. The asynchronous retry unit is used to acquire a distributed lock based on the business order number, add an idempotent key generated by the business order number and the voucher type to the interface data object, and asynchronously execute the retry push through a thread pool.

[0049] It should be noted that the specific manner in which each module performs its operation in the apparatus described in the above embodiments has been described in detail in the embodiments of the method, and will not be elaborated here.

[0050] Example 3: Corresponding to the above method embodiments, this embodiment also provides a heterogeneous financial system data conversion and docking device. The heterogeneous financial system data conversion and docking device described below and the heterogeneous financial system data conversion and docking method described above can be referred to each other.

[0051] Figure 3 This is a block diagram illustrating a heterogeneous financial system data conversion and interfacing device 800 according to an exemplary embodiment. For example... Figure 3 As shown, the heterogeneous financial system data conversion and interface device 800 may include: a processor 801 and a memory 802. The heterogeneous financial system data conversion and interface device 800 may also include one or more of the following: a multimedia component 803, an I / O interface 804, and a communication component 805.

[0052] The processor 801 controls the overall operation of the heterogeneous financial system data conversion and docking device 800 to complete all or part of the steps in the aforementioned heterogeneous financial system data conversion and docking method. The memory 802 stores various types of data to support the operation of the heterogeneous financial system data conversion and docking device 800. This data may include, for example, instructions for any application or method operating on the heterogeneous financial system data conversion and docking device 800, as well as application-related data such as contact data, sent and received messages, images, audio, video, etc. The memory 802 can be implemented using any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 803 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in the memory 802 or transmitted via the communication component 805. The audio component also includes at least one speaker for outputting audio signals. I / O interface 804 provides an interface between processor 801 and other interface modules, such as keyboards, mice, and buttons. These buttons can be virtual or physical. Communication component 805 is used for wired or wireless communication between the heterogeneous financial system data conversion and interface device 800 and other devices. Wireless communication includes Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination thereof. Therefore, the corresponding communication component 805 may include a Wi-Fi module, a Bluetooth module, and an NFC module.

[0053] In an exemplary embodiment, the heterogeneous financial system data conversion and interfacing device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described heterogeneous financial system data conversion and interfacing method.

[0054] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided. When executed by a processor, these program instructions implement the steps of the heterogeneous financial system data conversion and interfacing method described above. For example, the computer-readable storage medium may be the memory 802 including the program instructions described above. These program instructions may be executed by the processor 801 of the heterogeneous financial system data conversion and interfacing device 800 to complete the heterogeneous financial system data conversion and interfacing method described above.

[0055] Example 4: Corresponding to the above method embodiments, this embodiment also provides a readable storage medium. The readable storage medium described below and the heterogeneous financial system data conversion and docking method described above can be referred to in correspondence.

[0056] A readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the heterogeneous financial system data conversion and interoperation method described in the above method embodiments.

[0057] Specifically, the readable storage medium can be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

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

[0059] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for data conversion and integration of heterogeneous financial systems, characterized in that, include: Receive a voucher push request sent by the business system, and generate a push context based on the voucher push request. The push context includes at least the target financial system identifier, voucher type, and business data. The target adapter is matched from the adapter set according to the push context. All adapters in the adapter set provide a unified interface contract, which defines data transformation operation, data push operation and result recording operation. The target adapter performs a data conversion operation to convert the business data into an interface data object of the target financial system, and maps the business code in the business data to the system code according to a preset hierarchical matching rule during the conversion process. Perform the data push operation of the target adapter to send the interface data object to the target financial system interface; Receive the response result returned by the target financial system and perform the result recording operation of the target adapter.

2. The method for data conversion and integration of heterogeneous financial systems according to claim 1, characterized in that, The preset hierarchical matching rule is as follows: Use the business code in the business data as the key value, and read the corresponding system code from the local mapping table; When the corresponding system code is not read from the local mapping table, the master data query interface is called to obtain the corresponding system code from the master data system. When the corresponding system code is not obtained from the master data system, recursively matching is performed in the order of taxpayer identification number, settlement method, and department level.

3. The method for data conversion and integration of heterogeneous financial systems according to claim 1, characterized in that, Before performing the data conversion operation of the target adapter, the following is also included: Verify whether the target financial system identifier, voucher type, and business data of the push context are missing; If there are no missing data, extract the contract code, project code, customer code, and upstream accounts receivable voucher identifier from the business data, and verify whether the contract code, project code, customer code, and upstream accounts receivable voucher identifier can be successfully mapped to the system code according to the preset hierarchical matching rules; After successful mapping, the fields in the interface data object are checked to see if they meet the interface requirements. These fields include financial organization code, contract master data code, project master data code, and expense items. If the interface requirements are met, the data conversion operation of the target adapter is performed.

4. The method for data conversion and integration of heterogeneous financial systems according to claim 1, characterized in that, Based on the push context, the target adapter is matched from the adapter set, including: Normalization processing is performed on the push context, and the validity of the target financial system identifier, the voucher type, and the business data is verified. According to the adapter registration order, the matching predicate of each adapter in the adapter set is compared with the normalized push context in turn; The first adapter that is successfully matched is identified as the target adapter.

5. The method for data conversion and integration of heterogeneous financial systems according to claim 1, characterized in that, Performing the data push operation of the target adapter, sending the interface data object to the target financial system interface, includes: Retrieve the claim category field and payment item field from the business data; When the target financial system is identified as the first preset system: If the claimed category field is project payment and the payment item field is bank transfer, then the interface data object will be routed to the payment receipt interface; When the target financial system is identified as the second preset system: If the claimed category field is a security deposit and the payment item field belongs to a preset set of refund items, then the interface data object will be routed to the payment and refund interface.

6. A data conversion and interface device for heterogeneous financial systems, characterized in that, include: The request receiving module is used to receive a voucher push request sent by the business system and generate a push context based on the voucher push request. The push context includes at least the target financial system identifier, voucher type, and business data. The adapter matching module is used to match the target adapter from the adapter set according to the push context. The adapters in the adapter set all provide a unified interface contract, which defines data conversion operation, data push operation and result recording operation. The data conversion module is used to perform the data conversion operation of the target adapter, convert the business data into the interface data object of the target financial system, and map the business code in the business data to the system code according to the preset hierarchical matching rules during the conversion process; The data push module is used to perform the data push operation of the target adapter and send the interface data object to the target financial system interface; The result recording module is used to receive the response result returned by the target financial system and perform the result recording operation of the target adapter.

7. The heterogeneous financial system data conversion and interface device according to claim 6, characterized in that, The data conversion module includes: The local mapping unit is used to read the corresponding system code from the local mapping table, using the business code in the business data as the key value. The master data query unit is used to call the master data query interface to obtain the corresponding system code from the master data system when the corresponding system code is not read from the local mapping table. The downgrade matching unit is used to recursively match taxpayer identification number, settlement method, and department level in sequence when the corresponding system code is not obtained from the master data system.

8. The heterogeneous financial system data conversion and interface device according to claim 6, characterized in that, It also includes a pre-verification module, which includes: The context verification unit is used to verify whether the target financial system identifier, voucher type, and business data of the push context are missing. The master data verification unit is used to extract the contract code, project code, customer code, and upstream accounts receivable voucher identifier from the business data when there are no missing data, and to verify whether the contract code, project code, customer code, and upstream accounts receivable voucher identifier can be successfully mapped to the system code according to the preset hierarchical matching rules. The interface field verification unit is used to verify whether the fields in the interface data object meet the interface requirements after the mapping is successful. The fields include financial organization code, contract master data code, project master data code, and expense item. The conversion triggering unit is used to trigger the data conversion module to perform the data conversion operation of the target adapter when the interface requirements are met.

9. The heterogeneous financial system data conversion and interface device according to claim 6, characterized in that, The adapter matching module includes: The normalization processing unit is used to perform normalization processing on the push context and verify the validity of the target financial system identifier, the voucher type, and the business data. The predicate matching unit is used to compare the matching predicate of each adapter in the adapter set with the normalized push context in the order of adapter registration. An adapter determination unit is used to determine the first successfully matched adapter as the target adapter.

10. The heterogeneous financial system data conversion and interface device according to claim 6, characterized in that, The data push module includes: The field acquisition unit is used to acquire the claim category field and payment item field from the business data. The first routing unit is used to route the interface data object to the payment receipt interface when the target financial system is identified as the first preset system, if the claim category field is project payment and the payment item field is bank transfer. The second routing unit is used to route the interface data object to the payment and refund interface when the target financial system is identified as the second preset system, if the claim category field is a security deposit and the payment item field belongs to a preset set of refund items.

Images