Multi-system financial document management method and device based on unified credential management center

Abstract

The application provides a multi-system financial document management method and device based on a unified credential management center, relates to the technical field of enterprise financial informatization, and comprises the following steps: obtaining a push parameter after a contract business operation is successful, constructing a push context, writing the push context into an asynchronous task table to generate a push task; extracting an executable push task from the asynchronous task table, and executing the executable push task in sequence after the executable push task is sorted according to an operation type weight, a target system weight and a waiting time length gain; for the current task, dynamically matching an adapter according to a target financial system type and a credential type in the push context; converting a business document into a financial message through the adapter and pushing the financial message to a target financial system; when the pushing is successful, recording an association relationship between the business document and a red document in a credential record, and updating a task state to success. The application solves the problem that in the prior art, synchronous pushing leads to that a business operation depends on real-time response of a financial system and the coupling degree between systems is too high.

Description

Technical Field

[0001] This invention relates to the field of enterprise financial information technology, and more specifically, to a method and apparatus for managing multi-system financial documents based on a unified voucher management center. Background Technology

[0002] In scenarios where enterprise contract management and financial systems are integrated, the contract management system typically pushes invoices and vouchers to the financial system after a successful business operation. When multiple heterogeneous financial systems need to be integrated, the lack of standardized system interfaces necessitates developing separate push logic for each system. When business data changes, the pushed financial vouchers are difficult to automatically identify and update synchronously. Furthermore, the lack of a unified voucher lifecycle management mechanism makes it impossible to uniformly retry, rescind, or adjust failed pushes, and hinders complete traceability between business documents and financial vouchers. Moreover, existing solutions often use synchronous push methods, where the success of business operations depends on the real-time response of the financial system interface. If the financial system responds slowly or malfunctions, it directly blocks business operations, resulting in excessive coupling between systems. Summary of the Invention

[0003] The purpose of this invention is to provide a method, apparatus, device, and readable storage medium for managing multi-system financial documents based on a unified voucher management center, in order to improve the aforementioned problems. To achieve the above objective, the technical solution adopted by this invention is as follows: Firstly, this application provides a multi-system financial document management method based on a unified voucher management center, including: Obtain the push parameters generated after the successful execution of the contract business operation, construct a push context including the business document, the target financial system identifier and the voucher type based on the push parameters, and write the push context into the asynchronous task table to generate a push task; Executable push tasks are extracted from the asynchronous task table, sorted according to operation type weight, target system weight, and waiting time gain, and each push task is executed in sequence according to the sorting result. For the currently executing push task, the corresponding financial system adapter is dynamically matched based on the target financial system type and voucher type in the push context; The business documents are converted into financial messages through the financial system adapter, and the financial messages are pushed by calling the interface of the target financial system. If the push is successful, the association between the business document and the red-ink document is recorded in the preset voucher record, and the task status in the asynchronous task table is updated to success.

[0004] Secondly, this application also provides a multi-system financial document management device based on a unified voucher management center, including: The acquisition module is used to acquire the push parameters generated after the successful execution of the contract business operation, construct a push context including the business document, the target financial system identifier and the voucher type based on the push parameters, and write the push context into the asynchronous task table to generate a push task. The task scheduling module is used to extract executable push tasks from the asynchronous task table, sort the extracted push tasks according to the operation type weight, target system weight and waiting time gain, and execute each push task in sequence according to the sorting result. The adapter matching module is used to dynamically match the corresponding financial system adapter for the currently executed push task based on the target financial system type and voucher type in the push context. The push module is used to convert the business documents into financial messages through the financial system adapter, and call the interface of the target financial system to push the financial messages. The recording module is used to record the association between the business document and the red-ink document in the preset voucher record when the push is successful, and to update the task status in the asynchronous task table to success.

[0005] Thirdly, this application also provides a multi-system financial document management device based on a unified voucher management center, including: Memory, used to store computer programs; A processor is used to implement the steps of the multi-system financial document management method based on a unified voucher management center 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 multi-system financial document management method based on a unified voucher management center.

[0007] The beneficial effects of this invention are as follows: 1. This invention decouples business operations from financial push notifications. After a business operation is completed, only a push notification task is generated, without directly calling the financial system interface. This avoids the impact of financial system failures on business operations and significantly improves business efficiency.

[0008] 2. This invention defines standardized multi-dimensional matching rules, enabling the integration of new financial systems with only the development of corresponding adapters, without requiring modifications to existing code, thus providing excellent scalability. Through contract change event monitoring, distributed locks, and differentiated impact scope determination using field change bitmap generation, automatic synchronization of vouchers after business changes is achieved, reducing manual intervention.

[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 multi-system financial document management method based on a unified voucher management center as described in this embodiment of the invention; Figure 2 This is a schematic diagram of the structure of the multi-system financial document management device based on a unified voucher management center as described in this embodiment of the invention; Figure 3 This is a schematic diagram of the structure of a multi-system financial document management device based on a unified voucher management center, as described in an embodiment of the present invention.

[0012] Marked in the image: 800. Multi-system financial document management equipment based on a unified voucher management center; 801. Processor; 802. Memory; 803. Multimedia component; 804. I / O interface; 805. Communication component. 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 multi-system financial document management method based on a unified voucher management center, which is used in an IT environment where multiple systems coexist and it is necessary to push financial documents generated by business operations such as contract addition and modification to the corresponding financial system.

[0016] See Figure 1 The figure shows that this method includes: S1. Obtain the push parameters generated after the successful execution of the contract business operation, construct a push context including business document, target financial system identifier and voucher type based on the push parameters, and write the push context into the asynchronous task table to generate a push task; Specifically, the contract business operations include adding contracts, editing contracts, or modifying contracts. Taking contract modification as an example in this embodiment, when a user modifies the project code, supplier, or business category of a contract in the contract management system, the contract management system saves the modified data.

[0017] The unified voucher management center obtains the push parameters generated after the successful execution of the contract business operation. Specifically, the push parameters include the business document, the target financial system identifier, and the voucher type. The management center constructs a push context based on these parameters. The push context at least includes the business document, the target financial system identifier, and the voucher type. Subsequently, the unified voucher management center writes the push context into an asynchronous task table and generates a push task that corresponds one-to-one with the push context. Simultaneously, it initializes voucher records used to record push history and document association relationships.

[0018] Specifically, step S1 includes: S11. Monitor the change events published by the business system after the contract business operation is saved, the change events include the object before the change and the object after the change; In this embodiment, after the contract data is successfully saved, the contract management system publishes a change event. The change event body carries the object before the change, the object after the change, and the operator's identifier. The object before the change and the object after the change represent the contract data before and after the modification, respectively. The unified credential management center listens for the change event. For example, for a contract with contract number "HT2024001", its item code changes from "P001" to "P002". The item code in the object before the change is "P001", and the item code in the object after the change is "P002".

[0019] S12. Apply for a distributed fair lock using the contract number corresponding to the contract business operation as the key, and trigger a listener after a delay after the transaction in which the contract business operation is located is committed. Standardize the key fields in the object before the change and the object after the change, and generate a field change bitmap. Specifically, the unified credential management center uses the contract number "HT2024001" as the key to request a distributed fair lock from the distributed coordination service, ensuring that only one change event is processed for the same contract at any given time. Since the transaction for the contract business operation has not yet been committed, the unified credential management center triggers a delayed listening mechanism after the upper-level transaction is committed to avoid reading uncommitted data. After triggering, the unified credential management center standardizes the key fields in the object before and after the change. These key fields include the project code, the contracting party's entity code, the business category, the department, and the accounting items.

[0020] In this embodiment, the standardization process includes removing leading and trailing spaces, standardizing capitalization, and converting null values ​​to default values. Subsequently, a field change bitmap is generated based on the key fields. For example, 8 key fields are represented by 8-bit binary numbers, where 1 indicates a change and 0 indicates no change.

[0021] S13. Query the historical vouchers under the contract number that have not been reversed and have been successfully pushed, and perform reverse matching of the project field, department field, customer field and accounting item field in the original push message of the historical voucher with the corresponding fields in the object before the change to obtain the filtered voucher; Specifically, the Unified Voucher Management Center searches the asynchronous task table and voucher records for all historical vouchers under contract number "HT2024001" with a status of "successfully pushed" and not yet reversed. For each historical voucher, it extracts the project field, department field, customer field, and accounting item field from the original push message. The values ​​of these fields are then compared one by one with the corresponding fields in the object before the change.

[0022] In this embodiment, assuming that the original push message of the historical voucher contains the following fields: project field "P001", department field "D001", customer field "C001", and accounting item field "A001", and the project code in the object before the change is "P001", department is "D001", customer is "C001", and accounting item is "A001" - a perfect match, then the historical voucher is retained.

[0023] S14. Based on the filtered voucher and the changed fields in the field change bitmap, determine the operation type to be performed on the voucher, wherein the operation type includes re-push after red-ink reversal, re-push of all red-ink reversals, re-push, generating an adjustment order, or maintaining the original voucher.

[0024] Specifically, step S14 includes: S141. When the voucher type is a delivery note or a settlement note, and the changed fields include project code, supplier code, or business category, determine the operation type as red-ink reversal and then push it again; for example, if the contract project code corresponding to the delivery note changes from "P001" to "P002", the unified voucher management center first calls the red-ink reversal interface of the financial system to cancel the original voucher of the delivery note, and then generates a new delivery note voucher based on the changed contract object and pushes it.

[0025] S142. When the voucher type is a purchase invoice and the changed fields include project, supplier or business category, determine the operation type as full red-ink re-push; S143. When the voucher type is a purchase invoice, and the changed fields include department or accounting item and there are normal invoice lines, the operation type is determined to be re-push; for example, if the department changes from "Finance Department" to "Sales Department", and there are still normal invoice lines on the purchase invoice that have not been reversed, then there is no need to reverse the invoice, and the invoice voucher is directly regenerated and pushed based on the new department information.

[0026] S144. When the document type is a payment order and the changed fields include project, supplier or business category, determine the operation type as generating an adjustment order; Furthermore, for accounts receivable, revenue receipts, and invoices / reverse invoices on the sales side, the Unified Voucher Management Center determines the operation type based on whether there is downstream payment recognition and whether there have been changes in the project or customer. If there is no downstream payment recognition and the project or customer has changed, the operation type is determined to be a re-push; if there is downstream payment recognition, the operation type is determined to be maintaining the original voucher.

[0027] Based on the above embodiments, this method further includes: S2. Extract executable push tasks from the asynchronous task table, sort the extracted push tasks according to operation type weight, target system weight and waiting time gain, and execute each push task in sequence according to the sorting result. Specifically, step S2 includes: S21. Extract all push tasks with an executable status from the asynchronous task table, and obtain the operation type, target system type, and waiting time of each push task in the asynchronous task table; In this embodiment, there are three tasks in the asynchronous task table, as shown in Table 1: Table 1

[0028] S22. Assign a corresponding first weight value based on the operation type of each push task. Among them, the first weight value of the red-charge re-push task is higher than that of the red-charge task, and the first weight value of the red-charge task is higher than that of the ordinary push task. S23. Assign a corresponding second weight value based on the target system type of each push task. Among them, the second weight value of the real-time interface call task is higher than that of the batch push task; S24. Calculate the waiting time gain based on the waiting time of each push task; S25. Determine the priority of each push task based on the first weight value, the second weight value, and the waiting time gain value, and execute each push task in order of priority from high to low. Specifically, the priority calculation formula is as follows: ; In the formula, Indicates priority. Indicates the first weight. Indicates the second weight. This indicates the gain of waiting time.

[0029] Based on the above embodiments, this method further includes: S3. For the currently executing push task, dynamically match the corresponding financial system adapter based on the target financial system type and voucher type in the push context; Specifically, the Unified Voucher Management Center extracts the target financial system type, voucher type, whether it is an adjustment order flag, and operation type from the push context to construct a matching vector. Then, the adapter is selected according to the following multi-level matching algorithm: First, a primary filtering is performed based on the target system type to isolate NCC links from BIP links. For example, if the target system type is "NCC", only the NCC adapter set is retained.

[0030] Secondly, a secondary filtering method is used based on whether it's an adjustment order, distinguishing adjustment order adapters from regular push adapters. For example, if this push is for an adjustment order, only adapters that support adjustment orders will be retained.

[0031] Finally, perform a three-level precise matching based on document type, such as: delivery note, settlement note, purchase invoice, payment note, etc.

[0032] Based on the above embodiments, this method further includes: S4. Convert the business document into a financial message through the financial system adapter, and push the financial message by calling the interface of the target financial system; Specifically, step S4 includes: S41. Call the financial system adapter to map and encapsulate the fields in the business document according to the target financial system, and generate a financial message; S42. Obtain the interface address URL and authentication credentials of the target financial system from the push context to establish a communication connection with the target financial system; S43. Through the communication connection, call the interface of the target financial system to send the financial message to the target financial system, and receive the response data returned by the target financial system as the push result; Specifically, the system uses an HTTP client to send a POST request, and the target financial system processes the request and returns a response, which includes a status code and a response body.

[0033] Based on the above embodiments, this method further includes: S5. If the push is successful, record the association between the business document and the red-ink document in the preset voucher record, and update the task status in the asynchronous task table to success.

[0034] Specifically, step S5 includes: S51. Receive the push success response returned by the target financial system, and extract the identification information of the red-ink document from the push success response; Specifically, the push is considered successful when the response status code is 200 and the "success" field in the response body is true. If this push operation is a red-ink reversal or a re-push after a red-ink reversal, the response body will contain the identification information of the red-ink reversal document.

[0035] S52. Locate the identification information of the business document in the voucher record, establish an association between the identification information of the red-ink document and the identification information of the business document, and write the association information into the voucher record; Specifically, search the voucher record for the record entry corresponding to the current contract number HT2024001 and voucher type. If found, write the identification information of the red-inked document as an associated field into the voucher record.

[0036] S53. Locate the task record in the asynchronous task table that corresponds to the currently pushed task, and update the task status field in the task record to a success status.

[0037] Furthermore, this embodiment also includes: If the push fails, a retry or manual intervention process will be executed based on the type of failure reason. Specifically, the failure reason types include financial system failures and basic data issues. For financial system failures, an exponential backoff retry strategy can be adopted; for basic data issues, the "status" field in the voucher record will be updated to "draft," and the specific failure reason will be recorded in the "failReason" field. At the same time, the task status in the asynchronous task table will be updated to "suspended."

[0038] In this embodiment, by implementing layered processing, the system avoids misjudging unrecoverable data errors as system failures, thus preventing invalid retries and improving system stability and operational efficiency.

[0039] Example 2: like Figure 2 As shown, this embodiment provides a multi-system financial document management device based on a unified voucher management center. The device includes: The acquisition module is used to acquire the push parameters generated after the successful execution of the contract business operation, construct a push context including the business document, the target financial system identifier and the voucher type based on the push parameters, and write the push context into the asynchronous task table to generate a push task. The task scheduling module is used to extract executable push tasks from the asynchronous task table, sort the extracted push tasks according to the operation type weight, target system weight and waiting time gain, and execute each push task in sequence according to the sorting result. The adapter matching module is used to dynamically match the corresponding financial system adapter for the currently executed push task based on the target financial system type and voucher type in the push context. The push module is used to convert the business documents into financial messages through the financial system adapter, and call the interface of the target financial system to push the financial messages. The recording module is used to record the association between the business document and the red-ink document in the preset voucher record when the push is successful, and to update the task status in the asynchronous task table to success.

[0040] Based on the above embodiments, the acquisition module includes: The listening unit is used to listen for change events published by the business system after the contract business operation is saved. The change event includes the object before the change and the object after the change. The locking bitmap generation unit is used to apply for a distributed fair lock with the contract number corresponding to the contract business operation as the key, and to trigger a listening after a delay after the transaction in which the contract business operation is committed, and to perform standardization processing on the key fields in the object before the change and the object after the change, and generate a field change bitmap. The reverse matching unit is used to query historical vouchers that have not been reversed and have been successfully pushed under the contract number, and to reverse match the project field, department field, customer field and accounting item field in the original push message of the historical voucher with the corresponding fields in the object before the change to obtain the filtered voucher. The type determination unit is used to determine the type of operation to be performed on the voucher based on the filtered voucher and the changed fields in the field change bitmap.

[0041] Based on the above embodiments, the type determination unit includes: The arrival settlement unit is used to determine the operation type as red-ink reversal and re-push when the document type is arrival note or settlement note and the changing fields include project code, supplier code or business category; The Purchase Invoice Full Reversal Unit is used to determine the operation type as Full Reversal and Re-push when the document type is a purchase invoice and the changed fields include project, supplier or business category; The purchase invoice re-push unit is used to determine the operation type as re-push when the voucher type is a purchase invoice, and the changed fields include department or accounting item and there are normal invoice lines; The payment adjustment unit is used to determine the operation type as generating an adjustment order when the document type is a payment order and the changed fields include project, supplier or business category.

[0042] Based on the above embodiments, the task scheduling module includes: The task extraction unit is used to extract all push tasks with an executable status from the asynchronous task table, and obtain the operation type, target system type, and waiting time of the push task in the asynchronous task table for each push task. The weight allocation unit is used to allocate a corresponding first weight value according to the operation type of each push task, wherein the first weight value of the re-push task after the red alert is higher than that of the red alert task, and the first weight value of the red alert task is higher than that of the normal push task; and to allocate a corresponding second weight value according to the target system type of each push task, wherein the second weight value of the real-time interface call task is higher than that of the batch re-push task. The gain calculation unit is used to calculate the waiting time gain based on the waiting time of each push task; The priority sorting unit is used to determine the priority of each push task based on the first weight value, the second weight value, and the waiting time gain value, and to execute each push task in order of priority from high to low.

[0043] Based on the above embodiments, the push module includes: The message generation unit is used to call the financial system adapter to map and encapsulate the fields in the business document according to the target financial system and generate financial messages; A connection establishment unit is used to obtain the interface address and authentication credentials of the target financial system from the push context in order to establish a communication connection with the target financial system. The sending and receiving unit is used to send the financial message to the target financial system by calling the interface of the target financial system through the communication connection, and to receive the response data returned by the target financial system as the push result.

[0044] Based on the above embodiments, the recording module includes: The response receiving unit is used to receive the push success response returned by the target financial system and extract the identification information of the red-inked document from the push success response; The associated record unit is used to find the identification information of the business document in the voucher record, establish an association relationship between the identification information of the red-ink document and the identification information of the business document, and write the association information into the voucher record; The status update unit is used to find the task record corresponding to the currently pushed task in the asynchronous task table and update the task status field in the task record to a success status.

[0045] 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.

[0046] Example 3: Corresponding to the above method embodiments, this embodiment also provides a multi-system financial document management device based on a unified voucher management center. The multi-system financial document management device based on a unified voucher management center described below and the multi-system financial document management method based on a unified voucher management center described above can be referred to in correspondence.

[0047] Figure 3 This is a block diagram illustrating a multi-system financial document management device 800 based on a unified voucher management center, according to an exemplary embodiment. Figure 3 As shown, the multi-system financial document management device 800 based on a unified voucher management center may include: a processor 801 and a memory 802. The multi-system financial document management device 800 based on a unified voucher management center may also include one or more of the following: a multimedia component 803, an I / O interface 804, and a communication component 805.

[0048] The processor 801 controls the overall operation of the multi-system financial document management device 800 based on the unified voucher management center to complete all or part of the steps in the aforementioned multi-system financial document management method based on the unified voucher management center. The memory 802 stores various types of data to support the operation of the multi-system financial document management device 800 based on the unified voucher management center. This data may include, for example, instructions for any application or method operating on the multi-system financial document management device 800 based on the unified voucher management center, 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 multi-system financial document management device 800 based on a unified voucher management center and other devices. Wireless communication includes, for example, 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.

[0049] In an exemplary embodiment, the multi-system financial document management device 800 based on the unified voucher management center 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 execute the aforementioned multi-system financial document management method based on the unified voucher management center.

[0050] 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 multi-system financial document management method based on a unified voucher management center 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 multi-system financial document management device 800 based on a unified voucher management center to complete the multi-system financial document management method based on a unified voucher management center described above.

[0051] Example 4: Corresponding to the above method embodiments, this embodiment also provides a readable storage medium. The readable storage medium described below can be referred to in conjunction with the multi-system financial document management method based on a unified voucher management center described above.

[0052] A readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the multi-system financial document management method based on a unified voucher management center as described in the above method embodiments.

[0053] 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.

[0054] 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.

[0055] 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 multi-system financial document management method based on a unified voucher management center, characterized in that, include: Obtain the push parameters generated after the successful execution of the contract business operation, construct a push context including the business document, the target financial system identifier and the voucher type based on the push parameters, and write the push context into the asynchronous task table to generate a push task; Obtain the push parameters generated after the successful execution of the contract business operation, construct a push context including the business document, the target financial system identifier and the voucher type based on the push parameters, and write the push context into the asynchronous task table to generate a push task; For the currently executing push task, the corresponding financial system adapter is dynamically matched based on the target financial system type and voucher type in the push context; The business documents are converted into financial messages through the financial system adapter, and the financial messages are pushed by calling the interface of the target financial system. If the push is successful, the association between the business document and the red-ink document is recorded in the preset voucher record, and the task status in the asynchronous task table is updated to success.

2. The multi-system financial document management method based on a unified voucher management center according to claim 1, characterized in that, Obtain the push parameters generated after the successful execution of the contract business operation, construct a push context including the business document, target financial system identifier, and voucher type based on the push parameters, and write the push context into the asynchronous task table to generate a push task, including: Listen for change events published by the business system after the contract business operation is saved. The change event includes the object before the change and the object after the change. A distributed fair lock is applied for using the contract number corresponding to the contract business operation as the key, and a listening is triggered after a delay after the transaction in which the contract business operation is committed. The key fields in the object before the change and the object after the change are standardized to generate a field change bitmap. Query the historical vouchers under the contract number that have not been reversed and have been successfully pushed, and perform reverse matching of the project field, department field, customer field and accounting item field in the original push message of the historical voucher with the corresponding fields in the object before the change to obtain the filtered voucher; Based on the filtered voucher and the changed fields in the field change bitmap, determine the type of operation to be performed on the voucher.

3. The multi-system financial document management method based on a unified voucher management center according to claim 2, characterized in that, Determining the type of operation to be performed on the credential includes: When the document type is a delivery note or settlement note, and the changed fields include project code, supplier code, or business category, determine the operation type as red-ink reversal and re-push. When the voucher type is a purchase invoice, and the changing fields include project, supplier, or business category, the operation type is determined to be all red-ink re-push. When the voucher type is a purchase invoice, and the changed fields include department or accounting item and there are normal invoice lines, the operation type is determined to be a re-push. When the document type is a payment order and the changing fields include project, supplier, or business category, the operation type is determined to be generating an adjustment order.

4. The multi-system financial document management method based on a unified voucher management center according to claim 1, characterized in that, Executable push tasks are extracted from the asynchronous task table, sorted according to operation type weight, target system weight, and waiting time gain, and then each push task is executed sequentially according to the sorting result, including: Extract all push tasks that are in the executable state from the asynchronous task table, and obtain the operation type, target system type, and waiting time of each push task in the asynchronous task table. Each push task is assigned a first weight value based on its operation type. The first weight value of a push task re-push after a red alert is higher than that of a red alert task, and the first weight value of a red alert task is higher than that of a regular push task. Each push task is assigned a corresponding second weight value based on the target system type, with the second weight value of real-time interface call tasks being higher than that of batch push tasks. The waiting time gain is calculated based on the waiting time of each push task; The priority of each push task is determined based on its first weight value, second weight value, and waiting time gain value, and each push task is executed in order of priority from high to low.

5. The multi-system financial document management method based on a unified voucher management center according to claim 1, characterized in that, The business documents are converted into financial messages through the financial system adapter, and the financial messages are pushed by calling the interface of the target financial system, including: The financial system adapter is invoked to map and encapsulate the fields in the business document according to the target financial system, thereby generating a financial message; Obtain the interface address and authentication credentials of the target financial system from the push context to establish a communication connection with the target financial system; Through the communication connection, the financial message is sent to the target financial system by calling the interface of the target financial system, and the response data returned by the target financial system is received as the push result.

6. A multi-system financial document management device based on a unified voucher management center, characterized in that, include: The acquisition module is used to acquire the push parameters generated after the successful execution of the contract business operation, construct a push context including the business document, the target financial system identifier and the voucher type based on the push parameters, and write the push context into the asynchronous task table to generate a push task. The task scheduling module is used to extract executable push tasks from the asynchronous task table, sort the extracted push tasks according to the operation type weight, target system weight and waiting time gain, and execute each push task in sequence according to the sorting result. The adapter matching module is used to dynamically match the corresponding financial system adapter for the currently executed push task based on the target financial system type and voucher type in the push context. The push module is used to convert the business documents into financial messages through the financial system adapter, and call the interface of the target financial system to push the financial messages. The recording module is used to record the association between the business document and the red-ink document in the preset voucher record when the push is successful, and to update the task status in the asynchronous task table to success.

7. The multi-system financial document management device based on a unified voucher management center according to claim 6, characterized in that, The acquisition module includes: The listening unit is used to listen for change events published by the business system after the contract business operation is saved. The change event includes the object before the change and the object after the change. The locking bitmap generation unit is used to apply for a distributed fair lock with the contract number corresponding to the contract business operation as the key, and to trigger a listening after a delay after the transaction in which the contract business operation is committed, and to perform standardization processing on the key fields in the object before the change and the object after the change, and generate a field change bitmap. The reverse matching unit is used to query historical vouchers that have not been reversed and have been successfully pushed under the contract number, and to reverse match the project field, department field, customer field and accounting item field in the original push message of the historical voucher with the corresponding fields in the object before the change to obtain the filtered voucher. The type determination unit is used to determine the type of operation to be performed on the voucher based on the filtered voucher and the changed fields in the field change bitmap.

8. The multi-system financial document management device based on a unified voucher management center according to claim 6, characterized in that, The type determination unit includes: The arrival settlement unit is used to determine the operation type as red-ink reversal and re-push when the document type is arrival note or settlement note and the changing fields include project code, supplier code or business category; The Purchase Invoice Full Reversal Unit is used to determine the operation type as Full Reversal and Re-push when the document type is a purchase invoice and the changed fields include project, supplier or business category; The purchase invoice re-push unit is used to determine the operation type as re-push when the voucher type is a purchase invoice, and the changed fields include department or accounting item and there are normal invoice lines; The payment adjustment unit is used to determine the operation type as generating an adjustment order when the document type is a payment order and the changed fields include project, supplier or business category.

9. The multi-system financial document management device based on a unified voucher management center according to claim 6, characterized in that, The task scheduling module includes: The task extraction unit is used to extract all push tasks with an executable status from the asynchronous task table, and obtain the operation type, target system type, and waiting time of the push task in the asynchronous task table for each push task. The weight allocation unit is used to allocate a corresponding first weight value according to the operation type of each push task, wherein the first weight value of the re-push task after the red alert is higher than that of the red alert task, and the first weight value of the red alert task is higher than that of the normal push task; and to allocate a corresponding second weight value according to the target system type of each push task, wherein the second weight value of the real-time interface call task is higher than that of the batch re-push task. The gain calculation unit is used to calculate the waiting time gain based on the waiting time of each push task; The priority sorting unit is used to determine the priority of each push task based on the first weight value, the second weight value, and the waiting time gain value, and to execute each push task in order of priority from high to low.

10. The multi-system financial document management device based on a unified voucher management center according to claim 6, characterized in that, The push module includes: The message generation unit is used to call the financial system adapter to map and encapsulate the fields in the business document according to the target financial system and generate financial messages; A connection establishment unit is used to obtain the interface address and authentication credentials of the target financial system from the push context in order to establish a communication connection with the target financial system. The sending and receiving unit is used to send the financial message to the target financial system by calling the interface of the target financial system through the communication connection, and to receive the response data returned by the target financial system as the push result.

Images