Voucher file processing method and device, electronic equipment and readable storage medium

Abstract

The invention provides a voucher file processing method and device, electronic equipment and a readable storage medium, and the voucher file processing method relates to the field of data processing, and can be applied to the financial and medical fields, such as payment and settlement scenes in the financial or medical field. The voucher file processing method comprises the following steps: receiving service configuration information sent by a service system, and generating a target voucher file according to the service configuration information; sending the target voucher file to an intermediate storage system, and obtaining a file identifier fed back by the intermediate storage system; obtaining a verification token from the target system, generating a notification message according to the file identifier and the verification token, and sending the notification message to the target system, so that the target system obtains and processes the target certificate file from the target system based on the notification message; receiving a response file fed back by the target system, wherein the response file comprises a verification result and a storage state of the target voucher file by the target system; and updating the file state of the target voucher file according to the response file.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, electronic device, and readable storage medium for processing credential documents. Background Technology

[0002] In enterprise information management, the generation and uploading of accounting vouchers are crucial steps in the financial process. In related technologies, voucher files are typically generated by the accounting system and then directly uploaded to the general ledger system for processing via encryption or other methods.

[0003] Then, the general ledger system often relies on a scheduled mechanism to scan and process the uploaded voucher files, such as scanning every few hours or at a fixed time each day. This non-real-time processing method causes voucher files to be unable to be obtained and processed by the general ledger system in a timely manner, thereby delaying the progress of subsequent business processes and affecting the overall business flow efficiency.

[0004] In the financial sector, such as in the transaction settlement systems of banks or securities institutions, delayed processing of voucher documents can lead to untimely fund clearing, affecting customer transaction experience and even triggering compliance risks. Similarly, in the medical field, in scenarios such as medical insurance reimbursement or hospital financial management, inefficient voucher document processing can delay medical insurance settlement or financial reconciliation, thereby affecting patient services and the operational efficiency of medical institutions.

[0005] Therefore, how to improve the processing efficiency of voucher files in order to enhance the business efficiency of industries such as finance and healthcare has become an urgent technical problem to be solved. Summary of the Invention

[0006] In view of this, this application provides a method, apparatus, electronic device and readable storage medium for processing voucher files, which improves the timeliness, reliability and controllability of uploading voucher files, and is especially suitable for scenarios with certain requirements for the timeliness of voucher file processing, such as high-frequency transaction settlement in the financial industry and real-time reimbursement in the medical field.

[0007] In a first aspect, embodiments of this application provide a method for processing credential files, applied to a credential management system, including:

[0008] Receive service configuration information sent by the business system, and generate a target credential file based on the service configuration information;

[0009] The target credential file is sent to the intermediate storage system, and the file identifier returned by the intermediate storage system is obtained;

[0010] Obtain a verification token from the target system, generate a notification message based on the file identifier and the verification token, and send it to the target system so that the target system can obtain and process the target credential file from the intermediate storage system based on the notification message;

[0011] Receive a response file from the target system, the response file including the processing result of the target system on the target credential file;

[0012] Update the file status of the target credential file according to the response file.

[0013] Secondly, embodiments of this application provide a credential document processing apparatus, the processing apparatus comprising:

[0014] The receiving module is used to receive business configuration information sent by the business system;

[0015] The processing module is used to generate a target credential file based on the business configuration information;

[0016] The sending module is used to send the target credential file to the intermediate storage system, and the receiving module is also used to obtain the file identifier fed back by the intermediate storage system;

[0017] The processing module is also used to obtain a verification token from the target system, generate a notification message based on the file identifier and the verification token, and send it to the target system, so that the target system can obtain and process the target credential file from the intermediate storage system based on the notification message;

[0018] The receiving module is further configured to receive a response file fed back by the target system, the response file including the processing result of the target system on the target credential file;

[0019] The processing module is also used to update the file status of the target credential file based on the response file.

[0020] Thirdly, embodiments of this application provide a method for processing credential files, applied to a target system, including:

[0021] Receive a notification message from the credential management system, which includes a file identifier and a verification token;

[0022] The target credential file is retrieved from the intermediate storage system based on the file identifier.

[0023] The target credential file is processed to generate a response file showing the verification result and storage status of the processed target file;

[0024] The response file is sent to the credential management system.

[0025] Fourthly, embodiments of this application provide an electronic device including a processor and a memory, the memory storing programs or instructions executable on the processor, the programs or instructions, when executed by the processor, implementing the steps of the methods as described in the first and second aspects.

[0026] Fifthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the methods as described in the first and second aspects.

[0027] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the methods as described in the first and second aspects.

[0028] In a seventh aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the methods of the first and second aspects.

[0029] In this embodiment, the method for processing voucher files provided can be widely applied to payment and settlement scenarios, supply chain finance scenarios, and also to financial transaction scenarios with certain requirements for timeliness and security (such as securities clearing and cross-border payment settlement), as well as business scenarios in the healthcare field such as medical insurance reimbursement and cross-institutional medical treatment settlement. The voucher management system dynamically generates and uploads target voucher files to the target system according to the requests of the business system, introducing an intermediate storage system as a secure transmission hub to ensure the integrity and confidentiality of the target voucher files. Specifically, the voucher file processing method provided in this embodiment also establishes a feedback mechanism for the target system's processing of target voucher files. For example, in securities trading, it provides real-time feedback on the clearing status; in medical insurance settlement, it returns the reimbursement progress in real-time, enabling the voucher management system to monitor the dynamic status changes of each target voucher file, including key nodes such as file generation, transmission progress, and processing results. When an abnormal state is detected, the voucher management system can trigger an alarm, allowing the abnormal problem to be handled as quickly as possible. This satisfies both the financial system's requirements for transaction security and real-time performance, and the healthcare field's needs for data privacy and settlement efficiency, improving the real-time performance and reliability of voucher business processing.

[0030] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0031] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0032] Figure 1 A flowchart illustrating a method for processing credential documents according to an embodiment of this application is shown;

[0033] Figure 2 A schematic diagram of the structure of a credential document processing apparatus according to an embodiment of this application is shown;

[0034] Figure 3 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown; Detailed Implementation

[0035] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0036] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0037] The processing method for credential documents provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0038] The first aspect of this application provides a method for processing voucher files. The executing entity can be a voucher management system or an electronic device within the voucher management system used for data processing. The voucher management system can be a system for uniformly managing the generation, uploading, and status synchronization of financial vouchers. This application will explain and illustrate the method for processing voucher files using an electronic device within a voucher management system as the executing entity. Figure 1 As shown, the methods for processing voucher documents include:

[0039] Step 101: Receive the business configuration information sent by the business system and generate the target credential file based on the business configuration information.

[0040] Business systems can be front-end business modules of an enterprise (such as payment domains and non-payment domain systems). In the financial sector, business systems can be securities trading systems, core banking systems, or insurance claims systems. In the healthcare sector, business systems can encompass hospital HIS systems, medical insurance settlement platforms, etc. Business systems are responsible for initiating financial transactions and generating raw business data. Business systems can transmit business configuration information to the voucher management system through event-driven interfaces (rather than timed control using related technologies), improving the efficiency of generating target voucher files.

[0041] Business configuration information is used to trigger the generation of financial vouchers. When a business system initiates a voucher processing request, it sends business configuration information, including complete business attributes, to the voucher management system. Business configuration information mainly includes fields such as account set (unitid), company segment (gsd), and management scope (glkj). The account set field represents an independent financial accounting unit, such as a bank branch account set or a medical insurance pooling area account set. The company field distinguishes business data from different companies, thus supporting fund transfers across legal entities within financial groups or cross-hospital settlements within medical institutions. The management scope field specifies the detailed financial accounting rules, such as applicable accounting standards or tax policies.

[0042] The voucher management system can be an independent middleware system. After receiving configuration information from various business systems, electronic devices can parse key fields in the business configuration information, extract corresponding transaction data from the business systems based on the account set field and legal entity field, and perform data conversion and verification according to the accounting rules specified in the management caliber field, thereby generating voucher files. These voucher files can include original voucher files and target voucher files. In scenarios involving the voucher management system connecting to new and old general ledger systems, the target voucher file is the voucher file that needs to be sent to the new general ledger system (i.e., the target system), while the original voucher file is the voucher file that needs to be sent to the old general ledger system. For example, the target voucher file can be a real-time transaction clearing voucher in the financial field or a medical insurance payment voucher in the medical field.

[0043] Specifically, the electronic device determines the online mode of the voucher files based on the account set field and legal entity field of the business configuration information. The online mode can be configured in multiple ways to guide the voucher management system in sending the voucher files to the corresponding general ledger system.

[0044] In practical implementation, when the deployment mode is "dual-track mode," the electronic device generates original voucher files and target voucher files suitable for both the old and new general ledger systems in parallel, and sends these files to the old and new general ledger systems respectively through different file transfer paths. When the deployment mode is "single-track mode," the electronic device only generates target voucher files conforming to the new general ledger system's format and sends them to the new general ledger system through a new process. If the deployment mode is "original mode" (sending to the old general ledger system), the electronic device only generates original voucher files conforming to the old general ledger system, without generating target voucher files, and sends them to the old general ledger system through the original encrypted process. This allows the electronic device to achieve a smooth transition from the old to the new general ledger system while ensuring business continuity.

[0045] The final target voucher file output by the electronic device includes complete financial elements and verification information, enabling it to be correctly parsed and processed by the target system.

[0046] Step 102: Send the target credential file to the intermediate storage system and obtain the file identifier returned by the intermediate storage system.

[0047] Intermediate storage systems can be independently deployed file storage service platforms (such as IOBS systems). Intermediate storage systems provide secure and reliable file storage services for the voucher management system and the target system (new general ledger system).

[0048] Electronic devices can send the generated target credential file to the intermediate storage system via an encrypted channel to trigger the file storage process. The intermediate storage system can ensure the secure transmission of the target credential file. Upon receiving the target credential file, the intermediate storage system can perform security checks such as target credential file integrity verification and virus scanning, and generate a unique file identifier (file KEY) for each successfully stored target credential file.

[0049] Storing target voucher files through an intermediate storage system ensures the security of sensitive financial data and facilitates subsequent file retrieval and status tracking. The voucher management system and the target system are loosely coupled, avoiding network risks associated with direct file transfer and providing reliable assurance for asynchronous communication between systems.

[0050] Step 103: Obtain the verification token from the target system, generate a notification message based on the file identifier and the verification token, and send it to the target system so that the target system can obtain and process the target credential file from the intermediate storage system based on the notification message.

[0051] The target system can serve as the final platform for receiving and processing voucher files, and can be flexibly configured according to business needs. In the financial sector, the target system may include securities registration and settlement systems, commercial bank core accounting systems, etc., and can be used to complete core financial operations such as transaction clearing, fund transfer, and accounting records. In the healthcare sector, the target system may include medical insurance settlement platforms at all levels, hospital financial management systems, etc., and can undertake important functions such as medical insurance fund settlement, medical expense reimbursement, and inter-institutional financial reconciliation.

[0052] Furthermore, the target system can be the aforementioned new general ledger system, which is the system that receives and processes financial documents. Electronic devices obtain a verification token from the target system through a secure interface. The verification token is a temporary access credential issued by the target system, possessing time-limited validity and uniqueness. The verification token is used to ensure the security of cross-platform communication and typically includes security elements such as digital signatures and expiration dates.

[0053] A notification message is a processing request carrier initiated by an electronic device to a target system, including a file identifier and a verification token. When generating a notification message, the electronic device can perform the following operations: bind the file identifier to the verification token, then add auxiliary information such as a timestamp and request ID, and serialize and encapsulate it according to the format required by the target system (such as JSON or XML).

[0054] Upon receiving the notification message, the target system verifies the validity of the verification token to ensure the legitimacy and security of the notification request source. After successful verification, the target system can use the file identifier provided in the notification message to request the intermediate storage system to download the encrypted target credential file. Once the target credential file is obtained, the target system executes a data verification process, including checking the file's digital signature, checksum, and other integrity indicators to ensure the target credential file has not been tampered with during transmission.

[0055] After verification, the target system can parse the voucher content, including performing financial verification on information such as account matching and amount reconciliation, ensuring that each transaction recorded in the target voucher complies with established accounting standards and business rules. Verified target vouchers will be written to the target system's database, and the target system will generate a corresponding processing result receipt (response file) as proof of completion of the target voucher processing.

[0056] It is worth noting that the target system maintains a loosely coupled interaction with the intermediate storage system through file identifiers. This clearly defines the boundaries between systems while reserving space for future horizontal expansion. The introduction of verification tokens and notification messages enables secure cross-system communication, ensuring that every step of the target credential file processing is traceable, thus improving the reliability and traceability of target credential file processing.

[0057] Step 104: Receive the response file from the target system. The response file includes the processing result of the target system on the target credential file.

[0058] The response file is a feedback file generated by the target system after processing the target voucher file, used to transmit the processing result to the voucher management system. The response file uses a standardized data format (such as XML or JSON).

[0059] The processing result is the final processing result of the target credential file in the target system, which includes status values ​​such as "processing successful", "processing in progress", and "verification failed".

[0060] For example, the generation of the response file follows these rules: After the target system completes processing the target credential file, it will generate the corresponding processing result based on the actual processing status. For instance, for a successfully processed target credential file, the response file may include a "status" field with the "SUCCESS" status code; for a target credential file that is being processed, the status will be "status" with the "PROCESSING" status code; if an exception is found during processing, a specific error status code will be returned, such as "status" with the "VALIDATE_FAILED" status code.

[0061] Step 105: Update the file status of the target credential file according to the response file.

[0062] File status is used to indicate the processing progress of the target voucher file in the voucher management system. File status can be managed using a standardized state machine model. File status can include the following status values: Uploading, Uploaded, and FAILED.

[0063] For example, the electronic device updates the status of the locally stored target credential file based on the processing result in the response file. For instance, when the processing result is "SUCCESS", the electronic device updates the file status of the target credential file to "uploaded"; when the processing result is "VALIDATE_FAIL", the electronic device updates the file status of the target credential file to "upload failed" and records the specific error code, and triggers an exception handling process and generates an alarm.

[0064] The voucher management system achieves real-time control over the processing status of target voucher files through feedback from response files. Electronic devices can dynamically track the entire process of each target voucher file from generation to final processing, including key information such as upload progress and processing results. This allows administrators to monitor the actual processing status of target voucher files at any time, such as which files have been successfully uploaded, which are being processed, and which have encountered anomalies. Especially in dual-track operation mode, the electronic devices can monitor the processing status feedback from the new and old general ledger systems in parallel, and evaluate the operational stability of the target systems through comparative analysis.

[0065] Therefore, the document processing method provided in this application can be widely applied to payment and settlement scenarios, supply chain finance scenarios, and also to financial transaction scenarios with certain requirements for timeliness and security (such as securities clearing and cross-border payment settlement), as well as business scenarios in the medical and health field such as medical insurance reimbursement and cross-institutional medical treatment settlement. The document management system dynamically generates and uploads target document files to the target system according to the requests of the business system, introducing an intermediate storage system as a secure transmission hub to ensure the integrity and confidentiality of the target document files. In particular, the document processing method provided in this embodiment also establishes a feedback mechanism for the target system's processing of target document files. For example, in securities trading, it provides real-time feedback on the clearing status; in medical insurance settlement, it returns the reimbursement progress in real-time, enabling the document management system to monitor the dynamic status changes of each target document file, including key nodes such as file generation, transmission progress, and processing results. When an abnormal state is detected, the document management system can trigger an alarm, allowing the abnormal problem to be handled as quickly as possible. This satisfies the financial system's requirements for transaction security and real-time performance, meets the medical and health field's needs for data privacy and settlement efficiency, and improves the real-time performance and reliability of document processing.

[0066] In some embodiments, the method for processing credential files provided in this application further includes:

[0067] Step 106: Monitor the file status of the target voucher file;

[0068] Step 107: If the target credential file remains in the upload state for more than the first preset time, or if the file status is upload failed, trigger the first alarm event.

[0069] When an electronic device triggers the first alarm event, the alarm can be reported through the internal devices of the credential management system or by calling a third-party monitoring platform.

[0070] The third-party monitoring platform, as an independent distributed monitoring system, is used to centrally collect and process alarm events from various business systems, including the operational status of related systems such as the credential management system and the target system. The first alarm event reported by the credential management system will include key information such as file identifier, anomaly type, and duration. The third-party monitoring platform will push the alarms to different levels of operations and maintenance personnel according to the preset hierarchical alarm strategy via SMS, email, or system notifications.

[0071] For example, the electronic device detects the file status of the target voucher file and continuously polls and monitors all target voucher files whose file status is "uploading". In the interbank bond trading scenario, if the target voucher file has not been transmitted for more than 30 minutes; or in the hospital emergency settlement scenario, if the target voucher file has not been sent to the medical insurance platform for more than 15 minutes, the electronic device can trigger the first alarm event.

[0072] For example, for a target credential file whose file status is "upload failed", the electronic device can immediately trigger the first alarm event and record error information (such as network interruption, intermediate storage system abnormality, etc.). At the same time, the electronic device can automatically start a retry mechanism to attempt to resume transmission within a preset maximum number of retries.

[0073] In this way, monitoring the file status of target voucher files shortens the time for anomaly detection, effectively improves the timeliness of risk handling in high-frequency financial transactions or medical emergency scenarios, transforms the traditional passive response into proactive prevention, and enables the voucher processing system to achieve a significant improvement in processing efficiency and response speed while ensuring data security.

[0074] In some embodiments, the method for processing credential files provided in this application further includes:

[0075] Step 108: When the preset conditions are met, trigger the second alarm event.

[0076] The preset conditions include any of the following: no response file is received after a first preset time period since the target system received the notification message; the target credential file has been stored in the intermediate storage system for more than a second preset time period without being downloaded; or the validity period of the verification token has expired and no response file has been received.

[0077] The second alarm event serves as a high-level monitoring method for the voucher management system, used to report anomalies during system interactions. Electronic devices triggering the second alarm event can issue alerts through the voucher management system's internal devices or by calling a third-party monitoring platform. In the financial sector, when a large-value target voucher (e.g., a payment voucher) expires without confirmation, a fund risk warning will be triggered. In the healthcare sector, if a target voucher (e.g., a reimbursement application) expires without being processed, the voucher management system will automatically freeze the target voucher.

[0078] The third-party monitoring platform will push alarms to different levels of operations and maintenance personnel through SMS, email or system notifications according to the preset hierarchical alarm policy, and notify the operations and maintenance personnel to check the operation status of infrastructure such as network connectivity, interface availability, and intermediate storage system.

[0079] For example, if the target system fails to return a response file after receiving the notification message for more than a first preset time period (which can be configured according to business needs, such as 60 minutes), the electronic device will trigger a second alarm event. The second alarm time event may include complete interaction trajectory information, including key data such as the notification message sending time, the target system's receipt confirmation, and the file identifier.

[0080] For example, if a target credential file has been stored in the intermediate storage system for more than a second preset time (e.g., 2 hours) and has not been downloaded, the electronic device will mark the target credential file as a "stagnant file" and trigger a second alarm event. Furthermore, the electronic device can send a cleanup command to the intermediate storage system to release its storage space.

[0081] For example, if the verification token expires and the credential management system has not received a response file, the electronic device will determine that there is a communication error and trigger a second alarm event. In addition, the electronic device can automatically re-initiate the complete credential processing flow.

[0082] Thus, the document processing method provided in this application embodiment can improve the timeliness of abnormal response and ensure transaction stability when applied to financial real-time clearing scenarios; when applied to medical expense settlement scenarios, it can realize full-process monitoring and avoid delays in the diagnosis and treatment process or settlement disputes caused by document issues.

[0083] In some embodiments, step 102 above, which involves sending the target credential file to the intermediate storage system and obtaining the file identifier returned by the intermediate storage system, further includes steps 1021 and 1022:

[0084] Step 1021: Call the security gateway interface to send the target credential file to the intermediate storage system.

[0085] A security gateway can provide secure proxy services between an enterprise's intranet and internet systems, performing cross-system protocol conversion, request forwarding, and security verification. Since the credential management system can be an intranet system, while the intermediate storage system is an internet file storage platform, the two cannot communicate directly due to network security restrictions. However, transferring files through a security gateway ensures the security and reliability of file transfers.

[0086] In practice, electronic devices can call the security gateway's upload interface to send the target credential file to the intermediate storage system in chunks. The security gateway compresses and encrypts the target credential file, adding timestamps, request IDs, and other information to trace the transmission link. If communication is interrupted, the security gateway can automatically trigger a resume mechanism to ensure the integrity of the target credential file. Through the isolation function of the security gateway, both the security requirements of the internal network system and efficient interaction with external systems are met.

[0087] Step 1022: Receive the file identifier sent by the intermediate storage system. The file identifier includes the storage path of the target credential file and encryption verification information.

[0088] The file identifier is data generated by the intermediate storage system after successfully receiving the target credential file. It serves as a unique index of the target credential file within the intermediate storage system. The file identifier is generated using an encryption algorithm and includes core information such as the storage path and file hash value. Upon receiving the response from the intermediate storage system, the security gateway decrypts and converts the file identifier to conform to the credential management system's interface specifications.

[0089] In practice, electronic devices receive file identifiers via asynchronous callbacks. After processing the target credential file, the intermediate storage system can push the file identifier to the credential management system through the security gateway's receiving interface.

[0090] The electronic device then verifies the validity of the file identifier, for example, by checking whether the storage path conforms to preset rules and by confirming that the target credential file has not been tampered with during transmission through encrypted verification information (such as a hash value). If the verification fails, the electronic device will trigger a second alarm message and record an error log; if the verification passes, the file identifier will be associated with and stored with the local task serial number for use when generating notification messages later.

[0091] Thus, through the bridging function of the security gateway, the file identification transmission process satisfies both the security audit requirements of the intranet system and is compatible with the communication protocol differences of the Internet system. Electronic devices do not need to directly access the physical storage structure of the intermediate storage system; precise file location and access control can be achieved through logical identifiers.

[0092] In some embodiments, step 103 above, which involves obtaining a verification token from the target system, generating a notification message based on the file identifier and the verification token, and sending it to the target system, further includes steps 1031 to 1034:

[0093] Step 1031: Invoke the security gateway to send a signature verification request to the target system.

[0094] After the target credential file is successfully stored in the intermediate storage system, the electronic device sends a signature verification request to the target system through the security gateway. The signature verification request is used to verify the legitimacy of the credential management system, ensuring that the source of the request issued by the credential management system is trustworthy.

[0095] During the signature verification process, the target system verifies the signature of the verification request based on a preset key or certificate. If the verification passes, a verification token is generated; otherwise, an error message is returned.

[0096] Step 1032: Receive the verification token sent by the target system through the security gateway.

[0097] The verification token is used to identify the identity of the target credential file, which is then allowed to be downloaded from the intermediate storage system based on the verification token.

[0098] After the target system verifies the signature, it generates a unique verification token and returns it to the credential management system through the security gateway. The verification token can be regarded as the authorization credential for the target system to process the request.

[0099] Verification tokens typically have a short validity period to ensure the timeliness and security of communication. Combined with the file identifier returned by the intermediate storage system, the verification token and file identifier together constitute the authorization credentials for the target system to download the target credential file.

[0100] Step 1033: Generate a notification message based on the file identifier and verification token. The notification message includes instructions for instructing the target system to download the target credential file.

[0101] Electronic devices assemble file identifiers and verification tokens into structured notification messages. These messages may include information such as the storage path of the target credential file in the intermediate storage system. The purpose of the notification message is to trigger the target system to actively retrieve the file from the intermediate storage system, mitigating network load issues caused by directly transferring large files. After assembly through a security gateway, the notification message format must conform to the target system's interface specifications, such as adding necessary protocol headers and signature information.

[0102] Step 1034: Send the notification message to the target system through the security gateway.

[0103] The security gateway forwards the assembled message to the target system. Upon receiving the message, the target system can synchronously return a response status to achieve real-time notification. If the target system returns abnormal data, the electronic device can trigger a second alarm event.

[0104] Thus, compared to the timed scanning method of original voucher files in related technologies, the method of uploading target voucher files improves the processing efficiency and reliability of target voucher files.

[0105] In some embodiments, step 101, receiving service configuration information sent by the service system and generating a target credential file based on the service configuration information, may further include steps 1011 and 1012:

[0106] Step 1011: Query the pre-configured switching configuration table based on the account set field and financial entity field in the business configuration information to obtain the online mode field.

[0107] The "Go-Live Mode" field indicates whether the data is deployed to the target system or the original system in parallel or individually. The "Account Set" field is used to distinguish the financial data of different accounting entities, while the "Legal Entity" field is used to identify different branches or business units under the same account set.

[0108] The switching configuration table is stored in the core database of the voucher management system. Electronic devices use this table to make decisions regarding business configuration information. Fields in the switching configuration table include unitid, company segment (gsd), management scope (glkj), module identifier (mk), and deployment mode (sxms).

[0109] In this system, a "dual-track mode" (where the online mode field value is 1) guides the electronic device to generate voucher files compatible with both the old and new general ledger systems in parallel, and then send these files to the old and new general ledger systems respectively via different file transfer paths. A "single-track mode" (where the online mode field value is 2) guides the electronic device to generate only target voucher files compatible with the new general ledger system, and then send these target voucher files to the new general ledger system via a new process. A "raw mode" (where the online mode field value is 0) guides the electronic device to generate only original voucher files compatible with the old general ledger system, and then send these original voucher files to the old general ledger system via the original encryption process.

[0110] Electronic devices should query the upload mode field corresponding to the business configuration information in the switching configuration table based on the account set field and financial entity field to determine the processing flow of voucher files. In actual business scenarios, querying only a single field cannot accurately locate the business entity. The reason is as follows: the same group may include multiple subsidiaries, that is, there may be business configuration information with the same account set field but different legal entity fields.

[0111] Therefore, electronic devices need to perform combined queries using the account set field and financial entity field of the business configuration information to obtain more accurate query results, which can guide the electronic devices to determine the correct processing flow of voucher documents.

[0112] In this way, electronic devices can dynamically obtain the online mode field of each business configuration information by querying the switching configuration table, thereby determining the processing flow of the target voucher file, that is, whether it should be sent to the old general ledger system or the target system, or uploaded to both systems simultaneously. This achieves a smooth transition between the new and old general ledger systems, and effectively avoids the systemic risks brought about by a full migration through a phased migration strategy of batches and business modules.

[0113] It can also verify the consistency of processing results between the new and old systems in parallel, and only switch to single-track mode after confirming that there are no errors, so as to ensure the integrity and accuracy of financial data during the migration process.

[0114] Step 1022: If the online mode field indicates that the data is sent to the target system in parallel or separately, generate the target credential file.

[0115] After retrieving the online mode field from the switching configuration table, the electronic device executes differentiated voucher file generation logic. For example, when the online mode field value is 1 (representing dual-track mode), the electronic device can simultaneously generate original voucher files conforming to the old general ledger system and target voucher files conforming to the target system. When the online mode field value is 2 (representing single-track mode), only the target voucher file is generated.

[0116] In this way, electronic devices can obtain the online mode field of business configuration information by dynamically querying the switching configuration table, which realizes a smooth transition and parallel verification between the new and old general ledger systems. This not only ensures business continuity, but also reduces the risk of system migration through configuration, and improves the reliability and controllability of financial system upgrades in complex accounting environments of large enterprises.

[0117] In some embodiments, the switching configuration table supports dynamic updates, which are performed through the following process steps 1011a to 1011d:

[0118] 1011a receives batch configuration data, which includes the account set field, financial entity field, and online mode field.

[0119] The configuration data originates from the business system and is used to update the "switch configuration table" (e.g., for adding or modifying account set fields). The configuration data is transmitted to the voucher management system via a secure, encrypted channel. The configuration data includes at least account set fields, legal entity fields, and online mode fields.

[0120] 1011b extracts the account set field and financial entity field from each configuration data as joint query conditions.

[0121] After receiving batch configuration data, the electronic device extracts the account set field and financial entity field from each configuration data set as conditions for a joint query. The combination of the account set field and financial entity field has a unique constraint in the switching configuration table, and efficient querying is achieved through a predefined joint index.

[0122] 1011c: When there is no configuration record in the switching configuration table that matches the joint query conditions, the current configuration data will be written to the switching configuration table as new content.

[0123] A configuration record is a set of related data fields stored in the switching configuration table. After confirming that a configuration record matching the join query conditions does not exist in the switching configuration table, the electronic device will perform a new record insertion operation. The electronic device will write all required fields of the current configuration data, including the account set field, legal entity field, and management scope field, to the switching configuration table. This operation can be achieved using the "insert...on duplicate update" syntax, ensuring both atomicity and improved data processing efficiency.

[0124] 1011d: When a configuration record matching the joint query conditions exists in the switching configuration table, update the online mode field in the configuration record according to the configuration data.

[0125] If the query confirms that a corresponding configuration record already exists in the switch configuration table, the electronic device will then update the online mode field. This process is also based on the "insert...on duplicate update" syntax. When the electronic device finds that the combination of the account set field and the legal entity field already exists, it will automatically switch to an update operation instead of an insert operation.

[0126] Thus, the voucher text processing method provided in this application embodiment achieves an efficient and reliable target voucher file processing flow through a dynamically updated switching configuration table, ensuring the integrity and consistency of configuration data updates. It also enables fast multi-account configuration queries through a joint index of the account set field and the financial entity field, thereby improving the efficiency and reliability of voucher processing in financial scenarios.

[0127] In some embodiments, prior to step 1011d, the processing method further includes step 1011e:

[0128] Step 1011e: Verify the validity of the online mode field; if the verification fails, update the status field of the corresponding configuration record in the switching configuration table to abnormal and trigger the third alarm event.

[0129] Before updating the online mode field of the corresponding configuration record in the configuration table, the electronic device can perform a validity verification process.

[0130] In practice, the electronic device checks whether the value of the online mode field is within the allowed range (0 - upload only to the old general ledger system, 1 - dual-track mode, 2 - upload to the target system). If the field value is not within the allowed range, the electronic device will mark the status field (syzt) of the corresponding configuration record in the switching configuration table as "abnormal" and record the detailed reason for the error.

[0131] In addition, electronic devices can simultaneously trigger a third alarm event through a message queue. The third alarm event is used to alert on configuration data verification failure and can include configuration details, operator information, and the reason for verification failure, so that maintenance personnel can handle it in a timely manner.

[0132] The second aspect of this application also provides a method for processing credential documents. The method is executed by a target system or an electronic device within the target system that has data processing capabilities. The method includes:

[0133] Step 10: Receive a notification message from the credential management system, which includes a file identifier and a verification token.

[0134] The target system listens for notification messages sent by the credential management system from the security gateway through a pre-configured security interface. These notification messages contain a file identifier and a verification token. The file identifier has a one-to-one mapping with the target credential file in the intermediate storage system. The verification token is valid for 15-30 minutes.

[0135] Step 20: Obtain the target credential file from the intermediate storage system based on the file identifier.

[0136] Upon receiving the notification message, the target system verifies the token's signature and validity period. If verification is successful, it parses the file identifier and downloads the target credential file from the intermediate storage system. The intermediate storage system performs secondary authentication on the download request to ensure that only systems holding a valid token can obtain the target credential file.

[0137] Step 30: Process the target credential file and generate a response file showing the verification results and storage status of the processed target file.

[0138] The target system parses and downloads the target voucher file, requiring data verification, such as checking the validity of the digital signature and timestamp to ensure the voucher file has not been tampered with and is within the specified time limit. Subsequently, accounting entries are processed according to the account set fields and management scope fields to complete the business logic operation.

[0139] After processing, the target system generates a response file containing key fields such as processing status (success / failure), error code (if present), and processing time. The response file can be encapsulated in XML format and a checksum can be generated to ensure its integrity and reliability during transmission, as well as the accuracy and traceability of the data processing results.

[0140] Step 40: Send the response file to the credential management system.

[0141] The target system sends the response file back to the credential management system via an asynchronous message queue. Upon receiving the response file, the credential management system updates the status field of the target credential file. If no response is received within 30 seconds, the credential management system triggers a second alarm event.

[0142] Thus, the credential processing method provided in this application ensures data transmission security through token verification and secondary authentication, and guarantees the reliability and traceability of the processing process by using structured response files and asynchronous message queues. While improving processing efficiency, it meets the requirements of enterprise-level financial systems for security, reliability and audit compliance.

[0143] As a specific implementation of the credential file processing method provided in the first aspect embodiment above, this application embodiment provides a credential file processing apparatus 200. For example... Figure 2 As shown, the device for processing the credential document includes: a receiving module 201, a sending module 202, and a processing module 203.

[0144] The receiving module 201 is used to receive business configuration information sent by the business system, and the processing module 203 generates a target credential file based on the business configuration information.

[0145] The sending module 202 is used to send the target credential file to the intermediate storage system, and the receiving module 201 is used to obtain the file identifier fed back by the intermediate storage system.

[0146] The processing module 203 is used to obtain a verification token from the target system, generate a notification message based on the file identifier and the verification token, and send it to the target system so that the target system can obtain and process the target credential file from the intermediate storage system based on the notification message.

[0147] The receiving module 201 is also used to receive a response file from the target system, the response file including the processing result of the target system on the target credential file;

[0148] Processing module 203 is also used to update the file status of the target credential file based on the response file.

[0149] In some embodiments, the processing module 203 is further configured to:

[0150] Monitor the file status of the target voucher file;

[0151] If the target credential file remains in the upload state for more than the first preset time, or if the file status shows upload failure, the first alarm event is triggered.

[0152] In some embodiments, the processing module 203 is further configured to trigger a second alarm event when any preset condition is met;

[0153] The preset conditions include any of the following: no response file is received after a first preset time period since the target system received the notification message; the target credential file has been stored in the intermediate storage system for more than a second preset time period without being downloaded; or the validity period of the verification token has expired and no response file has been received.

[0154] In some embodiments, the sending module 202 is further configured to call the security gateway interface to send the target credential file to the intermediate storage system;

[0155] The receiving module 201 is also used to receive a file identifier sent by the intermediate storage system call, the file identifier including the storage path of the target credential file and encryption verification information.

[0156] In some embodiments, the sending module 202 is further configured to invoke the security gateway to send a signature verification request to the target system;

[0157] The receiving module 201 is also used to receive a verification token sent by the target system through the security gateway. The verification token is used to identify the identity of the target credential file, and the target credential file is allowed to be downloaded from the intermediate storage system based on the verification token.

[0158] Processing module 203 is also used to generate a notification message based on the file identifier and the verification token, the notification message including instructions for instructing the target system to download the target credential file;

[0159] The sending module 202 is also used to send notification messages to the target system through a security gateway.

[0160] In some embodiments, the processing module 203 is further configured to query a pre-configured switching configuration table based on the account set field and financial entity field in the business configuration information to obtain the online mode field, which indicates whether to go online to the target system or the original system in parallel or separately; and generate a target voucher file if the online mode field indicates that the system is to go online to the target system in parallel or separately.

[0161] In some embodiments, the switching configuration table supports dynamic updates. The processing module 203 is also used to receive batches of configuration data, which includes an account set field, a financial entity field, and an online mode field. The account set field and financial entity field in each configuration data are extracted as joint query conditions. When there is no configuration record in the switching configuration table that matches the joint query conditions, the current configuration data is written to the switching configuration table as new content. When there is a configuration record in the switching configuration table that matches the joint query conditions, the online mode field in the configuration record is updated according to the configuration data.

[0162] In some embodiments, the processing module 203 is also used to verify the validity of the online mode field; when the verification fails, the status field of the corresponding configuration record in the switching configuration table is updated to abnormal, and a third alarm event is triggered.

[0163] The credential processing device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0164] The credential processing device provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0165] This application also provides an electronic device, such as... Figure 3 As shown, the electronic device 300 includes a processor 301 and a memory 302. The memory 302 stores a program or instruction that can run on the processor 301. When the program or instruction is executed by the processor 301, it implements the various steps of the above-described embodiment of the credential document processing method and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0166] The memory 302 can be used to store software programs and various data. The memory 302 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 302 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 302 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0167] Processor 301 may include one or more processing units; optionally, processor 301 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 301.

[0168] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described method for processing credential documents and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0169] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described credential document processing method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0170] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0171] This application also provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described method for processing credential documents, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0172] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0173] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for processing voucher documents, characterized in that, Applied to the voucher management system, including: Receive service configuration information sent by the business system, and generate a target credential file based on the service configuration information; The target credential file is sent to the intermediate storage system, and the file identifier returned by the intermediate storage system is obtained; Obtain a verification token from the target system, generate a notification message based on the file identifier and the verification token, and send it to the target system so that the target system can obtain and process the target credential file from the intermediate storage system based on the notification message; Receive a response file from the target system, the response file including the processing result of the target system on the target credential file; Update the file status of the target credential file according to the response file.

2. The method for processing voucher documents according to claim 1, characterized in that, The processing method further includes: Monitor the file status of the target credential file; If the file status of the target credential file remains in the upload state for more than a first preset time, or if the file status is "upload failed", a first alarm event is triggered.

3. The method for processing voucher documents according to claim 1, characterized in that, The method further includes: When preset conditions are met, a second alarm event is triggered; The preset conditions include any one of the following: the target system has not received the response file after a first preset time period since receiving the notification message; the target credential file has been stored in the intermediate storage system for more than a second preset time period without being downloaded; or the validity period of the verification token has expired and the response file has not been received.

4. The method for processing voucher documents according to claim 1, characterized in that, The step of sending the target credential file to the intermediate storage system and obtaining the file identifier returned by the intermediate storage system includes: The target credential file is sent to the intermediate storage system by calling the security gateway interface; The file identifier sent by the intermediate storage system call is received. The file identifier includes the storage path and encryption verification information of the target credential file.

5. The method for processing voucher documents according to claim 1, characterized in that, The step of obtaining a verification token from the target system, generating a notification message based on the file identifier and the verification token, and sending it to the target system includes: Invoke the security gateway to send a signature verification request to the target system; The system receives the verification token sent by the target system through the security gateway. The verification token is used to identify the identity of the target credential file, and the target credential file is allowed to be downloaded from the intermediate storage system based on the verification token. The notification message is generated based on the file identifier and the verification token, and the notification message includes an instruction to instruct the target system to download the target credential file. The notification message is sent to the target system through the security gateway.

6. The method for processing voucher documents according to any one of claims 1 to 5, characterized in that, Receive service configuration information sent by the business system, and generate a target credential file based on the service configuration information, including: Based on the account set field and financial entity field in the business configuration information, query the pre-configured switching configuration table to obtain the online mode field, which indicates whether to go online to the target system or the original system in parallel or separately. If the online mode field indicates that the data is sent to the target system in parallel or individually, the target credential file is generated.

7. The method for processing voucher documents according to claim 6, characterized in that, The switching configuration table supports dynamic updates, which are performed through the following process: Receive configuration data, which includes the account set field, the financial entity field, and the online mode field; Extract the account set field and financial entity field from each of the configuration data as joint query conditions; If there is no configuration record in the switching configuration table that matches the joint query condition, the current configuration data is written into the switching configuration table as new content. When a configuration record matching the joint query condition exists in the switching configuration table, the online mode field in the configuration record is updated according to the configuration data.

8. A voucher document processing apparatus, characterized in that, include: The receiving module is used to receive business configuration information sent by the business system; The processing module is used to generate a target credential file based on the business configuration information; The sending module is used to send the target credential file to the intermediate storage system, and the receiving module is also used to obtain the file identifier fed back by the intermediate storage system; The processing module is also used to obtain a verification token from the target system, generate a notification message based on the file identifier and the verification token, and send it to the target system, so that the target system can obtain and process the target credential file from the intermediate storage system based on the notification message; The receiving module is further configured to receive a response file fed back by the target system, the response file including the processing result of the target system on the target credential file; The processing module is also used to update the file status of the target credential file based on the response file.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that run on the processor, the program or instructions being executed by the processor to implement the steps of the credential document processing method as described in any one of claims 1 to 8.

10. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the steps of the credential file processing method as described in any one of claims 1 to 8.

Images