Real-time data interaction method and system between middle platform accounting system and front-end business system

Abstract

The application discloses a kind of middle station accounting system and the real-time data interaction method and system of front-end business system, the present application is by pre-storing standard bill element model in standardization data center, delivery template configured according to type and state-based external system subscription relationship, change from "point-to-point" interface development to "configuration mapping" mode, eliminate the high maintenance cost of repeated construction, improve online efficiency;At the same time, abandon minute-level timing polling, and the state transition is determined by data center in real time and is immediately pushed according to subscription relationship The standardized data is realized millisecond-level synchronization, meets strict internal control and audit timeliness;And, with uniform element model as mapping reference, ensure that field type, precision and meaning are strictly consistent across systems, eliminate data distortion from the root;In addition, by the combination of state transition and subscription relationship, the bill flow track and state transition history are recorded completely, to provide end-to-end data link support for audit supervision.

Description

Technical Field

[0001] This invention belongs to the field of enterprise information technology, specifically relating to a method and system for achieving standardized, real-time, and scalable real-time data interaction of document data between an expense reporting system and heterogeneous front-end business systems (OA, vehicle management, logistics, HR, financial systems, etc.) under a middleware architecture. Background Technology

[0002] As enterprises deepen their digital transformation, the middle platform architecture has gradually become the preferred model for large enterprises to integrate multiple heterogeneous business systems (such as OA system, vehicle management system, logistics system, human resources system, and financial system). As the core hub for financial accounting and fund payment, the expense reimbursement system needs to interact with the aforementioned numerous front-end business systems frequently and reliably to complete the entire closed loop from business application and approval to final payment and accounting.

[0003] Currently, enterprises typically use Enterprise Service Bus (ESB) or traditional ETL data integration tools to achieve data interoperability between the aforementioned systems. However, the aforementioned existing technologies have at least four significant drawbacks when handling data interaction between the middle-office expense reporting system and heterogeneous front-end systems: (1) Interface “silo” construction, high cost of repeated development; existing integration solutions usually adopt the “point-to-point” interface development mode, that is, whenever an enterprise launches a new front-end business system, it is necessary to develop a customized data transmission interface or data view separately, resulting in tight coupling between systems; practice has shown that the average delivery cycle of point-to-point interfaces of a single system is as high as 13 days, and a large amount of work is concentrated on repetitive field mapping, data verification and exception handling logic, which not only seriously slows down the rapid launch process of new businesses, but also goes against the basic principle of “avoiding repeated construction and promoting resource sharing” in enterprise information construction.

[0004] (2) Lack of data timeliness; Under the existing technology, most integration solutions rely on timed polling mechanisms (such as periodic batch extraction or timed task scanning of database tables) to perceive changes in the status of front-end documents. Due to the limited polling frequency and database performance pressure, the smallest polling granularity in the industry is usually only 5 minutes. In the context of increasingly strict financial internal control and audit supervision, minute-level delays will result in a vacuum period in the accounting reflection of key links such as business approval, budget freezing, and fund payment, making it impossible to realize the immediate discovery and real-time triggering of changes in business status.

[0005] (3) Lack of a unified semantic model, resulting in data distortion across systems; Due to the different definitions of data type, precision unit and business meaning of the same business object (such as “amount”, “tax rate”, “currency”) by various front-end business systems (such as OA, HR, and financial systems), the lack of a unified data standard leads to a distortion rate of more than 0.3% for the amount, tax rate and currency fields when the same business object is converted between different systems, which seriously affects the accuracy and compliance of financial accounting.

[0006] (4) State silos: The existing middleware only completes static field mapping and does not solve the real-time synchronization problem of "multiple systems-multiple documents-multiple states", which cannot support audit traceability.

[0007] Therefore, given the aforementioned shortcomings, how to provide a standardized and real-time data exchange method between the expense reporting system and heterogeneous front-end business systems (OA, vehicle management, logistics, HR, financial systems, etc.) under a middleware architecture has become an urgent problem to be solved. Summary of the Invention

[0008] The purpose of this invention is to provide a real-time data interaction method and system between a middle-level expense reporting system and a front-end business system, in order to solve the problems of high cost of repetitive development, lack of data timeliness, data distortion across systems, and the existence of state silos in the existing technology.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, a real-time data interaction method between a middle-office expense reporting system and a front-end business system is provided, applicable to the expense reporting middle-office, front-end system, and standardized data center. The standardized data center stores a standard document meta-model including several common header fields and several common body fields, delivery templates corresponding to different document types, several standard states corresponding to documents during the flow of documents, and pre-configured external system subscription relationships for different standard states. The method includes: The current front-end system sends document information to the expense reporting platform. The document information includes the original document fields and the current document status. The current document status is the standard status corresponding to the document information when it is circulating in the current front-end system. The reimbursement platform receives the document information sent by the current front-end system and, based on the document information, retrieves the delivery template that matches the document type from the standardized data center. Based on the retrieved delivery template, the expense reimbursement platform maps the original document fields in the document information to the corresponding standard document meta-model in the delivery template, and adds the latest document status corresponding to the document information to the delivery template to obtain standard document data. The standardized data center reads standard document data from the expense reimbursement platform and determines whether the latest document status in the standard document data has undergone a state transition. A state transition indicates that the latest document status has changed compared to the current document status. After the standardized data center determines that the latest document status has transitioned, it determines the subscription relationship of the external system corresponding to the standard document data based on the latest document status, and pushes the standard document data to the front-end system to be transferred according to the determined external system subscription relationship, so as to complete the standardized real-time data interaction between the expense reimbursement platform and different front-end systems.

[0010] Based on the aforementioned disclosures, this invention transforms the access method of new front-end systems from the traditional "point-to-point" interface customization development to a "configuration-based mapping" mode by pre-storing a standard document meta-model covering common fields in the header and body of the table, delivery templates configured according to document type, and external system subscription relationships based on standard states in a standardized data center. This completely eliminates the redundant development and high maintenance costs caused by siloed interface construction, thereby greatly improving the efficiency of rapid business deployment. Simultaneously, this invention abandons the minute-level periodic polling mechanism, replacing it with a system where the standardized data center determines in real time whether a state transition has occurred in the latest document status to push standard documents. That is, once a state change is detected, standardized data is immediately pushed to the relevant front-end systems according to the pre-configured subscription relationships, achieving millisecond-level... Status synchronization avoids the accounting gaps in key stages such as approval, freezing, and payment found in traditional solutions, meeting stringent internal control and audit timeliness requirements. Furthermore, since all cross-system data interactions use a standard document meta-model as a unified mapping benchmark, field types, precision, and business meanings remain strictly consistent across systems, eliminating data distortion caused by definition differences at its source. Finally, through the introduction of a "state transition" judgment mechanism, combined with the technical means of pre-configuring external system subscription relationships for different standard states, the system can completely record the flow trajectory and status change history of documents across multiple systems. This ensures that any business transaction can be clearly traced back to its real-time status and processing nodes in each front-end system, thus providing complete and reliable data link support for enterprise audit and supervision.

[0011] In summary, this invention not only effectively solves the core pain points of existing integration solutions, such as tight coupling, high latency, large distortion, and difficulty in traceability, but also significantly improves the integration efficiency and intelligence level of the financial middle platform through a unified, real-time, and standardized data interaction mechanism, thus building a solid and reliable technical foundation for the digital transformation of large enterprises. Therefore, this invention is very suitable for large-scale application and promotion.

[0012] In one possible design, after obtaining the standard document data, the method further includes: Write the standard document data into the PostgreSQL database; Correspondingly, the standardized data center reads standard document data from the expense reimbursement platform, including: The standard document data is read from the PostgreSQL database via either a database binlog subscription or a Kafka subscription.

[0013] In one possible design, based on the established outgoing system subscription relationships, standard document data is pushed to the front-end system to be processed, including: The standard document data is encapsulated into a StandardEvent object; Based on the subscription relationship of the external system corresponding to the standard document data, at least one front-end system to which the standard document data is to be transferred is determined as the target system; The StandardEvent object is pushed to the target system to complete standardized real-time data interaction between the expense reporting platform and different front-end systems.

[0014] In one possible design, pushing the StandardEvent object to the target system includes: The StandardEvent object is pushed to the target system, and it is determined whether a message confirmation notification is received from the target system within a preset time period. If not, the StandardEvent object is pushed to the target system again, and the number of retweets is recorded until the number of retweets is less than or equal to the maximum number, and the message confirmation notification is received within a preset time after any retweet. In this case, the push of the StandardEvent object is completed. If the number of retweets is greater than the maximum number and the message confirmation notification is still not received, the StandardEvent object is transferred to the manual queue.

[0015] In one possible design, the StandardEvent object includes: the old state of the document information and the new state after the state transition, as well as the operator, operation time, and extended fields, wherein the extended fields are newly added fields in the standard document data, the old state is the current document state, and the new state is the latest document state.

[0016] In one possible design, before the current front-end system sends the document information to the reimbursement center, the method further includes: The reimbursement platform receives the registration request from the current front-end system to establish a long TCP connection with the current front-end system and obtain the system number, document type and callback Uniform Resource Locator of the current front-end system. The current front-end system stores the callback Uniform Resource Locator in the registry to complete the registration of the current front-end system. In response to a document creation operation, it generates original document information with a document number and writes the registered system number and document type into the original document information to generate the document information.

[0017] In one possible design, the standard document data includes: a document number, wherein pushing the standard document data to the front-end system to be processed, based on the determined external system subscription relationship, includes: Based on the established external system subscription relationship, at least one front-end system to which the standard document data is to be transferred is identified as the target system; Obtain the system ID registered by each target system when establishing a long TCP connection with the billing platform; Based on the system number of each target system and the document number in the standard document data, the standard document data is sent to each target system.

[0018] In one possible design, the pre-configured outbound system subscription relationship for any standard state includes: the front-end system to be transferred corresponding to the standard state, the target URL corresponding to the front-end system to be transferred, and the triggering action corresponding to the standard state. The delivery template is generated through visual drag-and-drop configuration, and the delivery template contains the field mapping relationship between the corresponding original document fields and the standard document meta-model.

[0019] Secondly, a real-time data interaction system between the middle platform expense reporting system and the front-end business system is provided, including: expense reporting middle platform, front-end system and standardized data center. The standardized data center stores a standard document meta-model including several header common fields and several body common fields, delivery templates corresponding to different document types, several standard states corresponding to the document in the process of circulation, and external system subscription relationships pre-configured for different standard states. The current front-end system is used to send document information to the reimbursement platform. The document information includes the original document fields and the current document status. The current document status is the standard status corresponding to the document information when it is circulating in the current front-end system. The expense reimbursement platform is used to receive the document information sent by the current front-end system and, based on the document information, to find the delivery template that matches the document type in the standardized data center. The expense reporting platform is also used to map the original document fields in the document information to the corresponding standard document meta-model in the delivery template based on the found delivery template, and add the latest document status corresponding to the document information to the delivery template to obtain standard document data. The standardized data center is used to read standard document data from the expense reimbursement platform and determine whether the latest document status in the standard document data has undergone a state transition. A state transition indicates that the latest document status has changed compared to the current document status. The standardized data center is also used to determine the external system subscription relationship corresponding to the standard document data based on the latest document status after a state transition has occurred, and to push the standard document data to the front-end system to be transferred according to the determined external system subscription relationship, so as to complete the standardized real-time data interaction between the expense reimbursement platform and different front-end systems.

[0020] Thirdly, a real-time data interaction device between a middle-office expense reporting system and a front-end business system is provided. Taking an electronic device as an example, it includes a memory, a processor, and a transceiver that are connected in sequence. The memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer programs and execute the real-time data interaction method between the middle-office expense reporting system and the front-end business system as described in the first aspect or any possible design in the first aspect.

[0021] Fourthly, a storage medium is provided, on which instructions are stored, which, when executed on a computer, perform a real-time data interaction method between the middle-office expense reporting system and the front-end business system as described in the first aspect or any possible design in the first aspect.

[0022] Fifthly, a computer program product containing instructions is provided, which, when executed on a computer, causes the computer to perform a real-time data interaction method between the middle-office expense reporting system and the front-end business system, as described in the first aspect or any possible design of the first aspect.

[0023] Beneficial effects: (1) This invention pre-stores a standard document meta-model covering common fields in the header and body of the document, a delivery template configured according to document type, and an external system subscription relationship based on standard status in a standardized data center. This transforms the access method of the new front-end system from the traditional "point-to-point" interface customization development to a "configuration-based mapping" mode. This completely eliminates the repetitive development and high maintenance costs caused by the siloed interface construction, thereby greatly improving the efficiency of rapid business deployment. At the same time, this invention abandons the minute-level timed polling mechanism and instead uses the standardized data center to determine in real time whether the latest document status has changed, and pushes the standard documents accordingly. That is, once a status change is detected, standardized data is immediately pushed to the relevant front-end system based on the pre-configured subscription relationship, achieving millisecond-level status synchronization. This avoids the accounting reflection vacuum period in key links such as approval, freezing, and payment in the traditional solution, and meets the stringent internal control requirements. Audit timeliness requirements; furthermore, since all cross-system data interactions use the standard document meta-model as a unified mapping benchmark, the field types, precision, and business meanings remain strictly consistent across systems, eliminating data distortion caused by definition differences at the source; finally, through the introduction of a "state transition" judgment mechanism, combined with the technical means of pre-configuring external system subscription relationships for different standard states, the system can completely record the flow trajectory and state change history of documents across multiple systems, thereby ensuring that any business transaction can be clearly traced back to its real-time status and processing nodes in each front-end system, thus providing complete and reliable data link support for enterprise audit supervision; thus, through the above design, this invention effectively solves the core pain points of existing integration solutions such as tight coupling, high latency, large distortion, and difficulty in traceability, significantly improving the integration efficiency and intelligence level of the financial middle platform. Therefore, this invention is very suitable for large-scale application and promotion. Attached Figure Description

[0024] Figure 1 A flowchart illustrating the steps of a real-time data interaction method between a middle-office expense reporting system and a front-end business system provided in an embodiment of the present invention; Figure 2 This is a structural diagram of the real-time data interaction system between the middle-office expense reporting system and the front-end business system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the accompanying drawings is only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0026] It should be understood that although the terms first, second, etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are only used to distinguish one unit from another. For example, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit, without departing from the scope of the exemplary embodiments of the invention.

[0027] It should be understood that the term "and / or" that may appear in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" that may appear in this document describes another relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone, and A and B exist alone. In addition, the character " / " that may appear in this document generally indicates that the related objects before and after it are in an "or" relationship.

[0028] Example: See Figure 1 As shown, the real-time data interaction method between the middle-office expense reporting system and the front-end business system provided in the first aspect of this embodiment can be applied, but is not limited to, to the expense reporting middle-office, front-end systems (such as OA systems, vehicle management systems, logistics systems, human resources systems, and fund systems), and standardized data centers. The standardized data center stores a standard document meta-model including several common header fields and several common body fields, delivery templates corresponding to different document types, several standard states corresponding to documents during the flow process, and pre-configured external system subscription relationships for different standard states. Thus, this embodiment establishes a unified, real-time, and standardized data interaction mechanism through the standardized data center, thereby effectively solving the core pain points of existing technologies, such as tight coupling, high latency, large distortion, and difficulty in traceability.

[0029] Optionally, the aforementioned standardized data center can be deployed, but is not limited to, on a microservice container cluster. It can include, but is not limited to, a document semantic center, a state machine center, an event capture module, a consistency guarantee module, and a horizontal scaling module. Specifically, the functions of each of the aforementioned modules are as follows: Document Semantic Center: Used to store "standard document meta-models" unrelated to business operations. It may include, but is not limited to, 32 common header fields and 68 common body fields, and supports visual drag-and-drop mapping to generate "delivery templates" for different document types. That is, the delivery templates are generated through visual drag-and-drop configuration, and the delivery templates contain the field mapping relationship between the corresponding original document fields and the standard document meta-model. In this embodiment, the field mapping relationship between the original document fields of different front-end systems and the standard document meta-model can be stored in the form of a mapping table. In this way, the standardized mapping of the original document fields of different front-end systems can be achieved according to the pre-configured standard field mapping table of different front-end systems, so that the field types, precision and business meanings are strictly consistent across systems.

[0030] Furthermore, the state machine center is used to abstract common document states of enterprises into 18 "standard states" (i.e., pre-configured different standard states corresponding to documents during the flow process), such as "first post not submitted state", "rollback state", "intermediate approval post approval state", etc. Of course, the aforementioned different states of documents during the flow process can be pre-set according to business type and actual use scenario, and this embodiment does not make specific limitations. At the same time, the state machine center also supports setting corresponding external system subscription relationships for different standard states (i.e., providing external system subscription relationship configuration interface), thereby providing a foundation for the mechanism of real-time synchronization triggered by subsequent state transitions. In this embodiment, the external system subscription relationship pre-configured for any standard state may include, but is not limited to: the front-end system to be flowed corresponding to any standard state, the target URL corresponding to the front-end system to be flowed, and the triggering action corresponding to any standard state.

[0031] Traditional middleware (ESB / ETL) only performs static field mapping, pushing "what it is". This embodiment, however, configures "trigger actions" in the state machine center and additionally pushes "what the front-end should do". Based on this, this embodiment includes an executable business semantic that directly drives the interface interaction and process flow of the front-end system. Simultaneously, when adding a new front-end system, developers only need to check or select action codes (such as "rollback", "signature", "transfer") on the configuration interface in the state machine center, without needing to hard-code new state handling classes in the front-end.

[0032] Furthermore, the event capture module is used to capture state transition events within ≤200 ms after a transaction is committed via database binlog subscription or Kafka subscription, and encapsulate the document into a StandardEvent object (the process is described in detail below).

[0033] The consistency guarantee module is used to achieve out-of-order deduplication based on the dual version number of "system number + document number" and provides 30-second timeout re-push and 5 exponential backoffs (the specific deduplication process and push process are described in detail below).

[0034] Finally, the horizontal scaling module is used to automatically increase the number of Pods based on queue backlog using Kubernetes HPA, theoretically supporting 100,000 TPS. Kubernetes HPA is an industry-standard container orchestration platform responsible for managing the lifecycle of the expense reporting platform microservices. It is the Kubernetes built-in "horizontal Pod autoscaler" controller, which can automatically increase or decrease the number of Pods (service running instances) based on preset metrics (such as CPU utilization, memory usage, or the custom business metrics described in this article). Thus, the horizontal scaling module provides elastic throughput capabilities, ensuring "sub-second" real-time pushes even during peak business periods (such as concentrated submissions of expense reports at the end of the month).

[0035] Thus, through the detailed architectural description of the standardized data center described above, this embodiment combines the aforementioned expense reporting platform and front-end system to provide a detailed interaction process of real-time data between the expense reporting platform system and the front-end business system, which may be, but is not limited to, as shown in steps S1 to S5 below.

[0036] S1. The current front-end system sends document information to the reimbursement platform. This document information includes the original document fields and the current document status, which is the standard status corresponding to the document information during its flow within the current front-end system. In practice, before sending the document information, a communication connection is established between the current front-end system and the reimbursement platform. Specifically, the reimbursement platform receives the registration request from the current front-end system to establish a long TCP connection, and simultaneously obtains the system ID and document type (e.g., welfare expense reimbursement form, pre-application form) of the current front-end system to match the corresponding delivery module. The system first registers the system and then stores the callback Uniform Resource Locator (URL) in the registry (which is the default network address provided by the front-end system to the expense reporting platform during the S1 registration step; its function is to push all state events to this default address when the state machine center has not configured a dedicated target URL address for a specific state). This completes the registration of the current front-end system. In response to the document creation operation, the system generates original document information with a document number and writes the registered system number and document type into the original document information to generate the document information.

[0037] Of course, the registration process of the other front-end systems in the reimbursement platform is the same as the aforementioned step S1, and will not be repeated here. After the front-end system completes its registration and generates document information, it can send it to the reimbursement platform. Then, the reimbursement platform can perform standardized mapping of the original document fields according to the pre-configured standard document meta-model and delivery template in the standardized data center, as shown in step S2 below.

[0038] S2. The reimbursement platform receives the document information sent by the current front-end system and, based on the document information, finds the delivery template that matches the document type in the standardized data center. In this embodiment, as explained above, the front-end system registers the document type at the time of the current interaction during registration. Therefore, the delivery template corresponding to the current document type can be determined in the standardized data center based on the document type. Then, based on the delivery template, the standardized mapping of the original document fields is performed, as shown in step S3 below.

[0039] S3. Based on the retrieved delivery template, the reimbursement platform maps the original document fields in the document information to the corresponding standard document meta-model in the delivery template, and adds the latest document status corresponding to the document information to the delivery template to obtain standard document data. In specific implementation, as mentioned above, the delivery template contains the field mapping relationship between the corresponding original document fields and the standard document meta-model, and it is stored in a mapping table, that is, a pre-configured standard field mapping table for different front-end systems. Therefore, after determining the standard field mapping table according to the corresponding form type and front-end system, the standard field mapping table can be used to achieve standardized mapping of original document fields of different front-end systems, such as standard field "amount_local" = original field "bxje" × exchange rate 1.0, standard field "tax_amount" = 0 (welfare fee tax-free), etc.

[0040] After completing the standardized mapping of the original document fields, the latest document status can be obtained. As previously explained, when configuring the subscription relationship of the external system, a corresponding trigger action is configured and pushed to the front end. When the trigger action is detected to be executed (e.g., the trigger action is pressing the back button), that is, when the user presses the back button, the current document status becomes "back status". Thus, the latest document status is "back status". Based on this, the latest document status can also be written into the previously determined delivery template (the delivery template has already completed the standardized field mapping before this), thereby obtaining standard document data (when generating document data, it contains the corresponding document number, therefore, the standard document data also contains the corresponding document number).

[0041] After obtaining the standard document data, it can be written to the PostgreSQL database; then, the standardized data center can capture state transition events through database subscription, as shown in step S4 below.

[0042] S4. The standardized data center reads standard document data from the expense reimbursement platform and determines whether a state transition has occurred in the latest document status within the standard document data. A state transition indicates that the latest document status has changed compared to the current document status. In specific implementation, for example, but not limited to, within 200ms after the transaction is committed (that is, after the standard document data is written to the database), the event capture module in the standardized data center reads the standard document data from the PostgreSQL database through either a database binlog subscription method (Binlog subscription is a method of data synchronization by subscribing to the database's Binlog, mainly used to ensure the consistency between the cache and the database) or a Kafka subscription method (Kafka subscription refers to consumers subscribing to messages they are interested in from the message center (Kafka cluster). When the producer pushes data to the message center, the message center pushes the relevant data to the corresponding subscribers according to the consumer's subscription status), thereby achieving real-time capture of the state transition event. Of course, the aforementioned binlog subscription method and Kafka subscription method are commonly used database subscription methods, and their message push process will not be described in detail in this embodiment.

[0043] Thus, after reading data from the database using the database subscription method, it can be determined whether the latest document status in the standard document data has undergone a state transition, that is, whether it has changed compared to the original document status. For example, if the original current document status is "first post not submitted" and the latest document status is "rollback", then the original status and the latest status are different, and it can be determined that a state transition has occurred. After determining that a state transition has occurred, the standard document data can be pushed in real time, as shown in step S5 below.

[0044] S5. After the standardized data center determines that the latest document status has undergone a state transition, it determines the external system subscription relationship corresponding to the standard document data based on the latest document status, and pushes the standard document data to the front-end system to be transferred according to the determined external system subscription relationship, so as to complete the standardized real-time data interaction between the expense reimbursement platform and different front-end systems.

[0045] In practical implementation, the event capture module in the standardized data center can, but is not limited to, first encapsulating the standard document data into a StandardEvent object; then, based on the external system subscription relationship corresponding to the standard document data, determining at least one front-end system to which the standard document data is to be transferred, as the target system; finally, the StandardEvent object can be pushed to the target system to complete the standardized real-time data interaction between the expense reporting platform and different front-end systems; in this embodiment, the StandardEvent object is the standardized event message carrier (data transmission object) defined in the expense reporting platform, and is the core bridge connecting "status capture" and "event push", which contains standard document fields Based on this, it may also include, but is not limited to: the old state and the new state after the state transition of the document information, as well as the operator, operation time, and extended fields. The extended fields are newly added fields in the standard document data, which are fields in the extended content table pre-configured by the front-end system to which the aforementioned standard document data is to be transferred. That is to say, this embodiment pre-sets corresponding extended content tables for different front-end systems. When pushing standard document data, the content in the extended content table can be injected, thereby realizing the expansion of document content. Of course, the aforementioned extended content table can be customized for different front-end systems according to actual use. This embodiment does not make specific limitations, and the aforementioned old state is the current document state, and the new state is the latest document state.

[0046] Furthermore, this embodiment also includes a deduplication mechanism based on a dual version number of "system number + document number," providing a 30-second timeout for re-pushing and 5 exponential backoffs. Specifically, after determining at least one front-end system as the target system for the standard document data based on the established outgoing system subscription relationship, the system number registered by each target system when establishing a TCP long connection with the expense reporting platform can be obtained first. Then, based on the system number of each target system and the document number in the standard document data, the StandardEvent object corresponding to the standard document data is sent to each target system. The reason for setting up the aforementioned deduplication mechanism is that, in actual application scenarios, the expense reporting platform may contain multiple documents, and different documents may correspond to multiple front-end systems under different standard states. Thus, based on the system number + document number, the standard document data to be synchronized (i.e., its corresponding StandardEvent object) and the front-end system to which the standard document data is to be sent can be uniquely determined. This prevents incorrect document sending and ensures the accuracy of document outgoing.

[0047] In addition, in this embodiment, the aforementioned timeout retransmission and 5 exponential backoffs are executed by the consistency fault reporting module in the standardized data center. The specific process is as follows: the StandardEvent object is pushed to the target system, and it is determined whether a message confirmation notification is received from the target system within a preset time period, such as whether an ACK (acknowledgment) is received from the target system within 30 seconds (in message communication, it represents message confirmation and is part of the communication protocol, used to indicate the confirmation or transmission of messages to ensure the reliability and integrity of data in network transmission). If the aforementioned message confirmation notification is not received within the preset time period, a timeout retransmission can be performed, that is: the StandardEvent object is re-pushed to the target system, and the number of retransmissions is recorded until the number of retransmissions is less than or equal to the maximum number (which can be set to 5 times), and the message confirmation notification is received within the preset time period after any retransmission, at which point the push of the StandardEvent object is completed.

[0048] If no ACK message is received within 30 seconds, the consistency guarantee module will automatically re-push, up to 5 times. If no message confirmation notification is received after 5 re-pushes (i.e., when the number of re-pushes is greater than the maximum number and the message confirmation notification is still not received), the push is determined to have failed. At this time, the StandardEvent object is transferred to the manual queue for manual processing.

[0049] In this embodiment, the flow trajectory and status change history of document information can be completely recorded each time, thereby generating a message log and storing it. In this way, end-to-end data link support can be provided for audit supervision.

[0050] Finally, after receiving the aforementioned StandardEvent object, each target system can execute the subsequent process according to its local state machine template (different front-end systems have their own corresponding execution processes pre-configured and stored in the local state machine template. After receiving the aforementioned StandardEvent object, they can execute the process according to their respective local state machine templates), thereby completing the end-to-end closed loop.

[0051] Thus, unlike existing technologies, this embodiment uses a three-pronged approach of "template-based configuration + event-driven streaming + dual-version idempotency" to transform the linearly increasing manpower problem into a constant-level configuration problem, thereby simultaneously solving the four major defects of slow access, poor real-time performance, data errors, and difficulty in expansion.

[0052] In addition, this embodiment provides an application example of the aforementioned method: Example 1: Employee welfare expense reimbursement form across systems in a closed loop.

[0053] The physical steps to be performed are as follows: S101. Employees submit welfare expense reimbursement forms on the OA front-end 300-1. Fields include: reimbursement person, amount 800 CNY, invoice number, and attachment URL.

[0054] S102. OA front-end 300-1 calls the "Document Receiving" RESTful interface of the expense reporting platform, carrying system number=OA and document type=welfare fee.

[0055] S103. The document semantic center completes field mapping based on the delivery template: Standard field “amount_local” = Original field “bxje” × exchange rate 1.0; The standard field "tax_amount" = 0 (welfare expenses are tax-exempt); Mapping formula: amount_local = bxje × rate tax_amount = 0.

[0056] S104. The state machine center sets the initial state to "First post not submitted".

[0057] S105. HR System 300-2 subscribes to the "Welfare Expenses & Intermediate Approval Position Approval" event; when the state transitions, the event capture module generates a StandardEvent: specifically: {“sys_id”:”OA”,“bill_no”:”BX20251212001”,“old_status”:”First post not submitted”,“new_status”:”Intermediate approval post approved”,“op_user”:”zhangsan”,“ts”:”2025-12-12 10:00:00.123”}.

[0058] S106. The expense reporting platform pushes the StandardEvent to the HR system 300-2 via HTTPS Webhook, waiting for ack=event sequence number 1024.

[0059] S107. The HR system 300-2 returned ack=1024, and the consistency assurance module marked it as delivered.

[0060] S108. Funds System 300-3 Repeat S105-S107 to complete the payment.

[0061] S109. End-to-end average delay 480 ms, loop closed.

[0062] Example 2: Add zero-code configuration for "Pre-application Form".

[0063] The physical steps to be performed are as follows: S201. Enterprises have added a "Pre-application Form" type with 45 fields.

[0064] S202. The implementation consultant logs into the document semantic center, selects "Add Template", and drags and drops to complete the 45→100 field mapping, which takes 25 minutes.

[0065] S203. Personnel select the status to be sent out in the state machine center: "First shift not submitted → Process completed" or "Process completed → Entire order payment successful".

[0066] S204. The system generates a versioned delivery template 201-12, which supports canary releases.

[0067] S205. Download template 201-12 for front-end system 300-4, complete integration, with zero lines of code throughout.

[0068] S206. Stress test verification: Kafka's peak TPS increased to 13,500, average latency was 510 ms, and CPU utilization was 42%, meeting the deployment standards.

[0069] Therefore, through the real-time data interaction method between the middle-office expense reporting system and the front-end business system described in detail in steps S1 to S5 above, the present invention has the following beneficial effects: (1) Completely end the “chimney” construction of interfaces and greatly reduce development costs and cycle; This invention abandons the traditional “point-to-point” customized development model. Through standardized delivery templates and unified standard document meta-model, the access method of the new system is changed from “interface development” to “configuration mapping”, so that the front-end system only needs to follow the standard state machine definition and does not need to care about the specific interface logic of the downstream system. In this way, this invention fundamentally solves the problem of redundant construction, realizes “one-time configuration, multiple reuse”, and significantly improves the efficiency of rapid launch of new services.

[0070] (2) Realize the real-time perception and push of document status changes, and eliminate the "vacuum period" of data timeliness; This invention no longer relies on the inefficient timed polling mechanism, but achieves millisecond-level response to document status changes through the active push of the accounting platform and the real-time judgment and triggering of "status transition" by the standardized data center. That is, when the document status (such as approval or document rollback) changes, the data can be immediately pushed to the relevant system according to the subscription relationship, completely eliminating the minute-level delay, ensuring the immediacy of financial accounting, and meeting the high real-time internal control requirements of enterprises for fund freezing, payment execution and other links.

[0071] (3) Construct a unified semantic model to fundamentally ensure the consistency and accuracy of cross-system data; This invention provides a unified definition of type, precision and meaning for core business objects such as “amount”, “tax rate” and “currency” by standardizing the standard document meta-model stored in the data center (covering common fields in the header and body). In this way, the mapping and transformation during data interaction are strictly based on the standard data meta-model, which completely eliminates the data distortion problem caused by the difference in the definitions of each system (the distortion rate is reduced from >0.3% to 0%), and effectively ensures the accuracy and compliance of financial accounting.

[0072] (4) Breaking down state silos and building full-link audit traceability capabilities: This invention introduces a "state transition" judgment mechanism and combines it with the technical means of pre-configuring external system subscription relationships for different standard states, so that the system can completely record the flow trajectory and state change history of documents between multiple systems, thereby ensuring that any business can be clearly traced in real time in each front-end system and processing node, thus providing complete and reliable data link support for enterprise audit supervision.

[0073] like Figure 2 As shown, the second aspect of this embodiment provides a software system for implementing the real-time data interaction method between the middle-office expense reporting system and the front-end business system described in the first aspect of the embodiment. The system includes: an expense reporting middle-office, a front-end system, and a standardized data center. The standardized data center stores a standard document meta-model including several header general fields and several body general fields, delivery templates corresponding to different document types, several standard states corresponding to the documents during the circulation process, and pre-configured external system subscription relationships for different standard states.

[0074] The current front-end system is used to send document information to the reimbursement platform. The document information includes the original document fields and the current document status. The current document status is the standard status corresponding to the document information when it is circulating in the current front-end system.

[0075] The expense reporting platform is used to receive the document information sent by the current front-end system and, based on the document information, to find the delivery template that matches the document type in the standardized data center.

[0076] The expense reporting platform is also used to map the original document fields in the document information to the corresponding standard document meta-model in the delivery template based on the found delivery template, and add the latest document status corresponding to the document information to the delivery template to obtain standard document data.

[0077] The standardized data center is used to read standard document data from the expense reimbursement platform and determine whether the latest document status in the standard document data has undergone a state transition. A state transition indicates that the latest document status has changed compared to the current document status.

[0078] The standardized data center is also used to determine the external system subscription relationship corresponding to the standard document data after the latest document status has changed, based on the latest document status, and push the standard document data to the front-end system to be transferred according to the determined external system subscription relationship, so as to complete the standardized real-time data interaction between the expense reimbursement platform and different front-end systems.

[0079] The working process, working details and technical effects of the system provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0080] like Figure 3 As shown, the third aspect of this embodiment provides a real-time data interaction device between a middle-office expense reporting system and a front-end business system. Taking the device as an electronic device as an example, it includes: a memory, a processor, and a transceiver connected in sequence. The memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer programs and execute the real-time data interaction method between the middle-office expense reporting system and the front-end business system as described in the first aspect of the embodiment.

[0081] For specific examples, the memory may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out (FIFO) memory, and / or first-in-last-out (FILO) memory, etc.; specifically, the processor may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor may be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor, also known as the CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state.

[0082] In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. For example, the processor may not be limited to microprocessors of the STM32F105 series, reduced instruction set computer (RISC) microprocessors, x86 architecture processors, or processors with integrated neural network processing units (NPUs). The transceiver may be, but is not limited to, a Wi-Fi transceiver, a Bluetooth transceiver, a General Packet Radio Service (GPRS) transceiver, a ZigBee transceiver (a low-power LAN protocol based on the IEEE 802.15.4 standard), a 3G transceiver, a 4G transceiver, and / or a 5G transceiver. Furthermore, the device may also include, but is not limited to, a power module, a display screen, and other necessary components.

[0083] The working process, working details and technical effects of the electronic device provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0084] The fourth aspect of this embodiment provides a storage medium for storing instructions containing the real-time data interaction method between the middle-office expense reporting system and the front-end business system as described in the first aspect of the embodiment. That is, the storage medium stores instructions, and when the instructions are run on a computer, the real-time data interaction method between the middle-office expense reporting system and the front-end business system as described in the first aspect of the embodiment is executed.

[0085] The storage medium refers to a carrier for storing data, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or memory sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0086] The working process, working details, and technical effects of the storage medium provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0087] The fifth aspect of this embodiment provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the real-time data interaction method between the middle-office expense reporting system and the front-end business system as described in the first aspect of this embodiment. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0088] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. 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.

Claims

1. A method for real-time data interaction between a middle-office expense reporting system and a front-end business system, characterized in that, This method is applied to expense reimbursement platforms, front-end systems, and standardized data centers. The standardized data center stores a standard document meta-model including several common header fields and several common body fields, delivery templates corresponding to different document types, several standard states corresponding to documents during their flow, and pre-configured external system subscription relationships for different standard states. The method includes: The current front-end system sends document information to the expense reporting platform. The document information includes the original document fields and the current document status. The current document status is the standard status corresponding to the document information when it is circulating in the current front-end system. The reimbursement platform receives the document information sent by the current front-end system and, based on the document information, retrieves the delivery template that matches the document type from the standardized data center. Based on the retrieved delivery template, the expense reimbursement platform maps the original document fields in the document information to the corresponding standard document meta-model in the delivery template, and adds the latest document status corresponding to the document information to the delivery template to obtain standard document data. The standardized data center reads standard document data from the expense reimbursement platform and determines whether the latest document status in the standard document data has undergone a state transition. A state transition indicates that the latest document status has changed compared to the current document status. After the standardized data center determines that the latest document status has transitioned, it determines the subscription relationship of the external system corresponding to the standard document data based on the latest document status, and pushes the standard document data to the front-end system to be transferred according to the determined external system subscription relationship, so as to complete the standardized real-time data interaction between the expense reimbursement platform and different front-end systems.

2. The method according to claim 1, characterized in that, After obtaining the standard document data, the method further includes: Write the standard document data into the PostgreSQL database; Correspondingly, the standardized data center reads standard document data from the expense reimbursement platform, including: The standard document data is read from the PostgreSQL database via either a database binlog subscription or a Kafka subscription.

3. The method according to claim 1, characterized in that, Based on the established external system subscription relationships, standard document data is pushed to the front-end systems to be processed, including: The standard document data is encapsulated into a StandardEvent object; Based on the subscription relationship of the external system corresponding to the standard document data, at least one front-end system to which the standard document data is to be transferred is determined as the target system; The StandardEvent object is pushed to the target system to complete standardized real-time data interaction between the expense reporting platform and different front-end systems.

4. The method according to claim 3, characterized in that, Pushing the StandardEvent object to the target system includes: The StandardEvent object is pushed to the target system, and it is determined whether a message confirmation notification is received from the target system within a preset time period. If not, the StandardEvent object is pushed to the target system again, and the number of retweets is recorded until the number of retweets is less than or equal to the maximum number, and the message confirmation notification is received within a preset time after any retweet. In this case, the push of the StandardEvent object is completed. If the number of retweets is greater than the maximum number and the message confirmation notification is still not received, the StandardEvent object is transferred to the manual queue.

5. The method according to claim 3, characterized in that, The StandardEvent object includes: the old state of the document information and the new state after the state transition, as well as the operator, operation time, and extended fields. The extended fields are newly added fields in the standard document data, the old state is the current document state, and the new state is the latest document state.

6. The method according to claim 1, characterized in that, Before sending document information to the reimbursement center, the current front-end system further includes the following method: The reimbursement platform receives the registration request from the current front-end system to establish a long TCP connection with the current front-end system and obtain the system number, document type and callback Uniform Resource Locator of the current front-end system. The current front-end system stores the callback Uniform Resource Locator in the registry to complete the registration of the current front-end system. In response to a document creation operation, it generates original document information with a document number and writes the registered system number and document type into the original document information to generate the document information.

7. The method according to claim 6, characterized in that, The standard document data includes: document number, wherein, based on the determined external system subscription relationship, the standard document data is pushed to the front-end system to be processed, including: Based on the established external system subscription relationship, at least one front-end system to which the standard document data is to be transferred is identified as the target system; Obtain the system ID registered by each target system when establishing a long TCP connection with the billing platform; Based on the system number of each target system and the document number in the standard document data, the standard document data is sent to each target system.

8. The method according to claim 1, characterized in that, The pre-configured external system subscription relationship for any standard state includes: the front-end system to be transferred corresponding to the standard state, the target URL corresponding to the front-end system to be transferred, and the trigger action corresponding to the standard state. The delivery template is generated through visual drag-and-drop configuration, and the delivery template contains the field mapping relationship between the corresponding original document fields and the standard document meta-model.

9. A real-time data interaction system between a middle-office expense reporting system and a front-end business system, characterized in that, include: The system consists of a reimbursement platform, a front-end system, and a standardized data center. The standardized data center stores a standard document meta-model, including several common header fields and several common body fields, delivery templates for different document types, several standard states of documents during the circulation process, and pre-configured external system subscription relationships for different standard states. The current front-end system is used to send document information to the reimbursement platform. The document information includes the original document fields and the current document status. The current document status is the standard status corresponding to the document information when it is circulating in the current front-end system. The expense reimbursement platform is used to receive the document information sent by the current front-end system and, based on the document information, to find the delivery template that matches the document type in the standardized data center. The expense reporting platform is also used to map the original document fields in the document information to the corresponding standard document meta-model in the delivery template based on the found delivery template, and add the latest document status corresponding to the document information to the delivery template to obtain standard document data. The standardized data center is used to read standard document data from the expense reimbursement platform and determine whether the latest document status in the standard document data has undergone a state transition. A state transition indicates that the latest document status has changed compared to the current document status. The standardized data center is also used to determine the external system subscription relationship corresponding to the standard document data after the latest document status has changed, based on the latest document status, and push the standard document data to the front-end system to be transferred according to the determined external system subscription relationship, so as to complete the standardized real-time data interaction between the expense reimbursement platform and different front-end systems.

10. A computer program product containing instructions, characterized in that, When the instruction is executed on the computer, it causes the computer to perform the real-time data interaction method between the middle-office expense reporting system and the front-end business system as described in any one of claims 1 to 8.

Images