A multi-bank interface-oriented electronic bill batch invoicing processing method, system, device and medium
By using custom batch combinations and dynamic banking business logic verification interfaces, the problem of batch combination and bank interface adaptation in the electronic bill batch invoicing system was solved, realizing intelligent and refined batch management, reducing the risk of bank order rejection, and improving the stability and security of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- INSPUR GENERSOFT CO LTD
- Filing Date
- 2026-05-13
- Publication Date
- 2026-06-16
AI Technical Summary
Existing electronic bill batch invoicing systems cannot customize batch combinations according to the actual needs of enterprises, nor can they verify the differences in business logic between different banks in real time. This leads to frequent manual intervention and low batch management efficiency, and there is also the risk of banks rejecting orders.
It introduces a custom batch combination mechanism across application forms and a dynamic banking business logic verification interface to achieve real-time semantic verification and compliance judgment before invoicing. It supports custom batch combinations and bank interface adaptation, embeds a dynamic rule engine, generates a unique invoicing batch number and writes it back to the application form field.
It improves the autonomy and adaptability of batch management, reduces repetitive operations, lowers the frequency of sending invalid invoice requests, enhances the system's fault tolerance and operational security, and ensures the integrity and traceability of the invoicing process.
Smart Images
Figure CN122222690A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of bulk invoicing technology, and in particular to a method, system, device and medium for bulk electronic invoicing processing with multiple bank interfaces. Background Technology
[0002] The current electronic bill batch issuance field has achieved basic automation, with most market solutions focusing on electronic bill lifecycle management or template-based batch processing. Enterprise treasury ERP systems, as the mainstream tool, can handle the uploading of single-item invoice details, and some systems have also developed adaptation functions for specific bank interfaces. Before the emergence of direct bank-enterprise connections, these systems could basically meet the routine electronic bill issuance needs of enterprises, helping them escape the cumbersome process of relying entirely on manual invoicing and improving invoicing efficiency to some extent.
[0003] However, with the increasing prevalence of direct bank-enterprise invoicing scenarios, the shortcomings of existing technologies have become increasingly apparent. Regarding batch combination, traditional systems are limited by fixed rules, only supporting batch combinations based on a single dimension such as consistent invoicing account. They cannot customize batches across application forms according to the actual needs of enterprises, leading to frequent manual intervention and low batch management efficiency. In terms of bank interface adaptation, the business logic of different banks varies greatly, but existing systems lack a dynamic rule engine, making real-time verification impossible and easily triggering bank rejections. Summary of the Invention
[0004] This application provides a method, system, device, and medium for batch electronic bill issuance processing with multiple bank interfaces, to solve the problems that existing solutions only support batch combinations based on a single dimension such as consistency of the billing account, and that the business logic of different banks varies greatly, while existing systems lack a dynamic rule engine and cannot perform real-time verification.
[0005] Firstly, this application provides a method for batch electronic bill issuance processing with multiple bank interfaces, the method including: Specify or cancel the invoice batch through the preset interface; Read the specified invoice batch and verify whether the invoice batch number already exists; if the invoice batch number exists, trigger the process to cancel the invoice batch. Read the document information of documents without an invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result; when the verification result is successful, trigger the specified invoice batch procedure; through the specified invoice batch procedure, call the bank's business logic verification interface to obtain the return result of the current batch of documents; when the return result is successful, call the document numbering rule to generate an invoice batch number, store it in the settlement details batch number field, and write it back to the invoice application form batch number field; The document information of the current batch of documents is used to call the corresponding verification item program; the specific content of the verification item is read, and the verification item program is used to verify whether it is supported to cancel the invoice batch; when it is supported to cancel the invoice batch, the clearing program is triggered to clear the batch number and update the corresponding invoice application form. When an invoice application form is detected being sent to the bank, the allowed sending verification rule program is triggered. The invoice application form is read and verified to see if it complies with the preset allowed sending verification rule. If it does not comply with the preset allowed sending verification rule, the invoice application form being sent to the bank is automatically blocked.
[0006] In one implementation of this application, the document information includes: document type, settlement statement type, invoice master table amount, and payment details approved amount, wherein the document type includes payment details; Read document information for documents with no invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result; when the verification result is successful, trigger the specified invoice batch procedure, which specifically includes: Read the settlement order type, the amount in the main invoice table, and the approved amount for payment details that do not have an invoice batch number; When a settlement statement is detected to be a non-self-managed invoice, the verification result is determined to be a verification failure, and the specified invoice batch procedure is not allowed to be triggered. When it is detected that the settlement order type is self-managed invoicing and the amount in the main invoice table is inconsistent with the approved amount in the payment details, the verification result is determined to be verification failure, and the specified invoicing batch procedure is not allowed to be triggered. When it is detected that the settlement order type is self-managed invoicing and the amount in the main invoice table is consistent with the approved amount in the payment details, a confirmation box for the specified invoicing batch pops up. When a confirmation instruction is received, the verification result is confirmed as successful, and the specified invoicing batch procedure is triggered.
[0007] In one implementation of this application, the document information includes: document type and settlement document type, wherein the document type includes settlement information; Read document information for documents with no invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result; when the verification result is successful, trigger the specified invoice batch procedure, which also includes: Read the settlement order type corresponding to settlement information for which there is no invoice batch number; When a settlement statement type that is not centrally managed is detected, the verification result is determined to be a verification failure, and the specified invoice batch procedure is not allowed to be triggered. When the settlement statement type is detected as "centralized invoicing", a confirmation box for the specified invoicing batch pops up. When a confirmation instruction is received, the verification result is confirmed as successful, and the specified invoicing batch program is triggered.
[0008] In one implementation of this application, by specifying the invoice batch procedure, the bank's business logic verification interface is called to obtain the return result of the current batch of documents; when the return result indicates successful verification, the document numbering rule is called to generate an invoice batch number, which is stored in the settlement details batch number field and written back to the invoice application batch number field, specifically including: When the specified invoice batch procedure is triggered, all documents that pass the verification in the current batch are encapsulated into standardized messages according to the bank interface specifications; and the pre-registered bank business logic verification interface is called via the HTTPS protocol. When the bank interface returns a successful verification response, the unique transaction identifier and the bank confirmation timestamp in the returned message are extracted as the basis for batch uniqueness. Combined with the enterprise's preset numbering rule engine, the invoice batch number is generated according to the format corresponding to the document numbering rule. The settlement details batch number field in the settlement details table is updated in batches using a transaction, and is synchronously written back to the invoice application batch number field in the associated invoice application table.
[0009] In one implementation of this application, the document information includes document type and status information, and the document type is at least divided into: payment details and settlement information; The document information for the current batch of documents is used to call the corresponding verification item program; the specific content corresponding to the verification item is read, and the verification item program is used to verify whether canceling the invoice batch is supported, specifically including: Read the status information corresponding to the current batch of documents. When the status information corresponds to the preset "cannot be cancelled" status, it is determined that the cancellation of the invoice batch is not supported, and the process termination procedure is called. When the status information does not correspond to the preset "cannot be cancelled" status and the type of the current batch of documents is payment details, the invoice batch number verification program is called to read the invoice batch number corresponding to the payment details. When the invoice batch number verification program detects that the invoice batch number is empty, it is determined that the cancellation of the invoice batch is not supported, and the process termination program is called; when it is not empty, it is determined that the cancellation of the invoice batch is supported. When the status information does not correspond to the preset "cannot be cancelled" status and the current batch of documents is of type "settlement information", the settlement information verification program is called to read the type corresponding to the settlement information. If the settlement information verification program detects that the type is not "unified invoicing", it determines that cancelling the invoicing batch is not supported and calls the end process program. If it is "unified invoicing", the invoice batch number verification program is called to read the invoice batch number. If the invoice batch number verification program detects that the invoice batch number is empty, it determines that cancelling the invoice batch is not supported and calls the end process program. If it is not empty, it determines that cancelling the invoice batch is supported.
[0010] In one implementation of this application, a preset verification rule is provided, specifically including: It is determined that the invoice batch number corresponding to the invoice application form is not empty and is the invoice batch number specified by the system. The invoice batch number and the invoice batch number of the details in the main table of the invoice application form are read. The invoice batch number of the details is determined to be all the preset invoice batch numbers corresponding to the invoice batch number of the main table, and the status information does not have a preset recovery mechanism code. Alternatively, if the invoice batch number corresponding to the invoice application form is empty, and the detailed invoice batch number has both a preset batch identifier code and an empty value, and the status information of the preset batch identifier code is a preset recovery mechanism code.
[0011] Secondly, this application provides a batch invoicing processing system for electronic bills with multiple bank interfaces, the system comprising: The designated module is used to specify or cancel invoice batches through a preset interface. The invoicing module is used to read a specified invoicing batch and verify whether an invoicing batch number already exists; if an invoicing batch number exists, the process of canceling the invoicing batch is triggered. The generation module is used to read document information for documents without an invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result. When the verification result is successful, the specified invoice batch procedure is triggered. Through the specified invoice batch procedure, the bank's business logic verification interface is called to obtain the return result of the current batch of documents. When the return result is successful, the document numbering rules are called to generate an invoice batch number, which is stored in the settlement details batch number field and written back to the invoice application form batch number field. The cancellation module is used to access the document information of the current batch of documents and call the corresponding verification item program. It reads the specific content of the verification item and uses the verification item program to check whether canceling the invoice batch is supported. When canceling the invoice batch is supported, it triggers the clearing program to clear the batch number and update the corresponding invoice application form. The sending module is used to trigger the allow sending verification rule program when it detects that an invoice application form has been sent to the bank. It reads the invoice application form and verifies whether it meets the preset allow sending verification rule. If it does not meet the preset allow sending verification rule, it automatically blocks the invoice application form from being sent to the bank.
[0012] In one implementation of this application, the generation module includes a generation unit. This is used to encapsulate all verified documents in the current batch into standardized messages according to the bank interface specifications when the specified invoicing batch procedure is triggered; and to call the pre-registered bank business logic verification interface via the HTTPS protocol. When the bank interface returns a successful verification response, the unique transaction identifier and the bank confirmation timestamp in the returned message are extracted as the basis for batch uniqueness. Combined with the enterprise's preset numbering rule engine, the invoice batch number is generated according to the format corresponding to the document numbering rule. The settlement details batch number field in the settlement details table is updated in batches using a transaction, and is synchronously written back to the invoice application batch number field in the associated invoice application table.
[0013] Thirdly, this application provides a batch electronic bill issuance processing device for multiple bank interfaces, the device comprising: processor; And a memory containing executable code, which, when executed, causes the processor to perform a batch invoicing processing method for electronic bills with a multi-bank interface, as described above.
[0014] Fourthly, this application provides a non-volatile computer storage medium storing computer instructions thereon, which, when executed, implement a batch invoicing processing method for electronic bills oriented towards a multi-bank interface as described above.
[0015] As can be seen from the above technical solutions, this application has the following advantages: This application introduces a custom batch combination mechanism across application forms, breaking through the limitations of traditional systems that rely solely on static batch division based on a single dimension such as the invoice account. The system can flexibly aggregate payment details or settlement information from different application forms, but of the same type, to form invoicing batches that conform to business logic, according to the actual financial process needs of the enterprise. This mechanism enhances the autonomy and adaptability of batch construction, eliminating the need for manual screening and merging, reducing repetitive operations and human error in batch configuration, and achieving intelligent and refined batch management processes.
[0016] This application embeds a dynamic banking business logic verification interface into the invoicing process, enabling real-time semantic verification and compliance judgment before invoicing, tailored to the interface specifications and verification rules of different banks. When a payment document enters a designated batch process, the system automatically calls the corresponding bank's verification interface, generating the invoicing batch number and writing it back to the application form field only after a successful response is returned. This mechanism effectively avoids the risk of batch rejections due to differences in bank rules, reduces the frequency of invalid invoicing requests, improves the stability and transaction processing success rate of the bank-enterprise direct connection channel, and automates and dynamically adapts to bank interfaces.
[0017] This application establishes a complete closed-loop control mechanism for batch status, supporting intelligent determination of cancellation permissions based on document type and application status when canceling an invoice batch. When cancellation is permitted, the batch number is automatically cleared and associated application field is synchronously updated. Simultaneously, before sending to the bank, the system enforces preset sending verification rules to ensure all documents to be sent meet compliance requirements. This design enhances the system's fault tolerance and operational security, avoiding batch conflicts and abnormal bank responses caused by misoperation or data anomalies, and guaranteeing the integrity, traceability, and system-level consistency of the invoicing process. Attached Figure Description
[0018] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are 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.
[0019] Figure 1 This is a flowchart of a batch invoicing method for electronic bills with multiple bank interfaces provided in an embodiment of this application.
[0020] Figure 2 This is a flowchart of a multi-processing branch electronic invoice batch invoicing process provided in an embodiment of this application.
[0021] Figure 3 This is a schematic diagram of the internal structure of a batch electronic bill issuance processing system for multiple bank interfaces provided in an embodiment of this application.
[0022] Figure 4 This is a schematic diagram of the internal structure of a batch electronic bill issuance processing device for multiple bank interfaces provided in an embodiment of this application. Detailed Implementation
[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0024] Those skilled in the art should understand that the embodiments described below are merely preferred embodiments of this disclosure and do not imply that this disclosure can only be implemented through these preferred embodiments. These preferred embodiments are merely used to explain the technical principles of this disclosure and are not intended to limit the scope of protection of this disclosure. All other embodiments obtained by those skilled in the art based on the preferred embodiments provided in this disclosure without inventive effort should still fall within the scope of protection of this disclosure.
[0025] It should also be noted that 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 process, method, article, or apparatus. Unless otherwise specified, 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.
[0026] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0027] The embodiment provides a method for batch invoicing of electronic bills for multiple bank interfaces, such as... Figure 1 As shown in the embodiments of this application, the method mainly includes the following steps: Step 110: Specify the invoice batch or cancel the invoice batch through the preset interface; read the specified invoice batch and verify whether the invoice batch number already exists; if the invoice batch number exists, trigger the process to cancel the invoice batch.
[0028] Among them, the document types are at least divided into: payment details and settlement information, and the document types in the same batch are the same.
[0029] It should be noted that, through the batch management module in the default interface, users can select "Specify Invoice Batch" or "Cancel Invoice Batch." The interface provides a drop-down list or text input box for entering or selecting a unique invoice batch number. After reading the batch number, the system initiates an SQL query to the settlement center database, with the query condition being batch_id= The system uses a batch number as a reference, linking the `payment_details` and `settlement_info` tables to filter out all document records associated with that batch number. It then iterates through the query results, verifying that the `invoice_batch_no` field in each record is not null. If this field is already assigned a value in any record, the system determines that an invoice batch number already exists. At this point, the system triggers a cancellation process: updating the `invoice_batch_no` field of all associated documents to NULL, and simultaneously recording the operation time, operator, batch number, and operation type as "cancel invoicing" in the `audit_log` table. The system enforces validation during batch creation: when a new document is added to a batch, its `document_type` field (only allowing "payment_detail" or "settlement_info") is checked against the document type already present in the batch. If they do not match, the addition is rejected, ensuring that document types within the same batch are unique and identical.
[0030] Step 120: Read the document information of documents without an invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result; when the verification result is successful, trigger the specified invoice batch procedure; through the specified invoice batch procedure, call the bank's business logic verification interface to obtain the return result of the current batch of documents; when the return result is successful, call the document numbering rule to generate an invoice batch number, store it in the settlement details batch number field, and write it back to the invoice application form batch number field.
[0031] In some embodiments, document information includes: document type, settlement document type, invoice master table amount, and approved payment details amount, where the document type includes payment details. Read document information for documents with no invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result; when the verification result is successful, trigger the specified invoice batch procedure, which specifically includes: Read the settlement order type, the amount in the main invoice table, and the approved amount for payment details that do not have an invoice batch number; When a settlement statement is detected to be a non-self-managed invoice, the verification result is determined to be a verification failure, and the specified invoice batch procedure is not allowed to be triggered. When it is detected that the settlement order type is self-managed invoicing and the amount in the main invoice table is inconsistent with the approved amount in the payment details, the verification result is determined to be verification failure, and the specified invoicing batch procedure is not allowed to be triggered. When it is detected that the settlement order type is self-managed invoicing and the amount in the main invoice table is consistent with the approved amount in the payment details, a confirmation box for the specified invoicing batch pops up. When a confirmation instruction is received, the verification result is confirmed as successful, and the specified invoicing batch procedure is triggered.
[0032] In some embodiments, document information includes: document type and settlement statement type, wherein the document type includes settlement information; Read document information for documents with no invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result; when the verification result is successful, trigger the specified invoice batch procedure, which also includes: Read the settlement order type corresponding to settlement information for which there is no invoice batch number; When a settlement statement type that is not centrally managed is detected, the verification result is determined to be a verification failure, and the specified invoice batch procedure is not allowed to be triggered. When the settlement statement type is detected as "centralized invoicing", a confirmation box for the specified invoicing batch pops up. When a confirmation instruction is received, the verification result is confirmed as successful, and the specified invoicing batch program is triggered.
[0033] In some embodiments, by specifying the invoice batch procedure, the bank's business logic verification interface is called to obtain the return result of the current batch of documents; when the return result indicates successful verification, the document numbering rule is called to generate an invoice batch number, which is stored in the settlement details batch number field and written back to the invoice application form batch number field, specifically including: When the specified invoice batch procedure is triggered, all documents that pass the verification in the current batch are encapsulated into standardized messages according to the bank interface specifications; and the pre-registered bank business logic verification interface is called via the HTTPS protocol. When the bank interface returns a successful verification response, the unique transaction identifier and the bank confirmation timestamp in the returned message are extracted as the basis for batch uniqueness. Combined with the enterprise's preset numbering rule engine, the invoice batch number is generated according to the format corresponding to the document numbering rule. The settlement details batch number field in the settlement details table is updated in batches using a transaction, and is synchronously written back to the invoice application batch number field in the associated invoice application table.
[0034] It should be further explained that the verification rules involved in the bank's business logic verification interface can be specifically as follows: 1. It is necessary to verify whether all bills in the same batch are commercial acceptance bills or bank acceptance bills, and the bill types must be consistent. 2. Verify the issuer account information of all bills and whether the corresponding bank's batch bill issuance interface is activated. 3. Verify whether the selected number of bills issued is within the limit agreed upon with the bank. Verification of bill issuance details: This mainly involves verifying the status of the details. Since the acceptance bills may experience multiple status combinations such as sending failure, sending success, and pending processing when sent to the bank in the system, it is necessary to group all bill issuance details under the same batch for processing, allowing the bank to resend bills that failed to be processed. All bill updates and settlement table updates need to be managed uniformly within the same transaction; if a failure occurs, a complete rollback is required.
[0035] More specifically, in step 120, the system first filters out document records with an empty invoice_batch_no field from the settlement center database, and distinguishes between payment details and settlement information documents based on the document_type field. For payment details documents, the system reads the associated settlement_type, invoice_main_amount, and payment_approved_amount fields; when settlement_type is not "self-managed invoicing", the verification process terminates and returns a verification failure; when settlement_type is "self-managed invoicing" and invoice_main_amount and payment_approved_amount are not equal, it is also determined to be a verification failure; only when settlement_type is "self-managed invoicing" and the two amount fields are completely consistent, the system pops up a confirmation dialog box, waits for the user to enter a confirmation command, and only after receiving confirmation is the verification determined to be successful, triggering the specified invoice batch procedure.
[0036] For settlement information documents, the system only reads the `settlement_type` field. When the value of this field is not "Unified Invoicing," the verification process terminates directly and returns failure. Only when `settlement_type` is "Unified Invoicing" does the system display a confirmation dialog box in the same format, waiting for user confirmation. Upon receiving the confirmation instruction, the verification result is determined to be successful, triggering the specified batch invoicing procedure. The verification logic for the two types of documents is mutually exclusive; the system executes the corresponding verification branch according to the document type, without cross-calling or sharing verification conditions.
[0037] When the designated invoice batch procedure is triggered, the system encapsulates all verified documents within the current batch according to the bank's preset XML or JSON message specifications, including batch ID, document ID list, total amount, timestamp, and operator identifier. It then calls the business verification interface pre-registered by the enterprise in the bank's system via HTTPS, with a request timeout set to 10 seconds and a retry mechanism of two times. If the bank interface returns an HTTP 200 status code and the response body contains the verification_status: "success" field, a unique transaction ID, and the bank's timestamp, the verification is considered successful. The system then calls the local numbering rule engine to generate a unique invoice batch number based on the enterprise's preset format (e.g., INV-YYYYMMDD-XXXX, where XXXX is a four-digit serial number). Subsequently, using database transactions, it batch updates the invoice_batch_no field in the settlement_detail table and synchronously writes it back to the corresponding record's batch_no field in the invoice_application table to ensure data consistency.
[0038] Step 130: For the document information of the current batch of documents, call the corresponding verification item program; read the specific content corresponding to the verification item, and use the verification item program to verify whether it is supported to cancel the invoice batch; when it is supported to cancel the invoice batch, trigger the clearing program to clear the batch number and update the corresponding invoice application form.
[0039] In some embodiments, document information includes document type and status information, and the document type is at least divided into: payment details and settlement information; This step can be specifically described as follows: Read the status information corresponding to the current batch of documents. When the status information corresponds to the preset "cannot be cancelled" status, it is determined that the cancellation of the invoice batch is not supported, and the process termination procedure is called. When the status information does not correspond to the preset "cannot be cancelled" status and the type of the current batch of documents is payment details, the invoice batch number verification program is called to read the invoice batch number corresponding to the payment details. When the invoice batch number verification program detects that the invoice batch number is empty, it is determined that the cancellation of the invoice batch is not supported, and the process termination program is called; when it is not empty, it is determined that the cancellation of the invoice batch is supported. When the status information does not correspond to the preset "cannot be cancelled" status and the current batch of documents is of type "settlement information", the settlement information verification program is called to read the type corresponding to the settlement information. If the settlement information verification program detects that the type is not "unified invoicing", it determines that cancelling the invoicing batch is not supported and calls the end process program. If it is "unified invoicing", the invoice batch number verification program is called to read the invoice batch number. If the invoice batch number verification program detects that the invoice batch number is empty, it determines that cancelling the invoice batch is not supported and calls the end process program. If it is not empty, it determines that cancelling the invoice batch is supported.
[0040] It should be further explained that step 130 achieves precise control over the cancellation of invoice batch operations through a dual verification mechanism of status information and document type. This avoids accidental triggering of clearing operations when documents are in an uncancellable state (such as already recorded or cancelled), reducing the risk of abnormal financial data. For payment detail documents, cancellation is only allowed when the invoice batch number is not empty, ensuring that rollback is only performed on batches with associated invoice numbers, preventing invalid operations on un-invoiced batches. For settlement information documents, cancellation is only allowed when their type is "centralized invoicing" and the invoice batch number is not empty, effectively isolating the cancellation permissions of non-centralized settlement documents and avoiding data interference across business models. By uniformly calling the invoice batch number verification program, duplicate code logic is reduced, improving system maintenance consistency. All cancellation operations are completed within a transaction. After clearing the batch number field, the associated invoice application field is updated synchronously, ensuring data synchronization between the settlement detail table and the invoice application table, preventing accounting inconsistencies caused by asynchronous updates.
[0041] Step 140: When an operation to send an invoice application form to the bank is detected, the operation to allow sending verification rules is triggered, the invoice application form is read, and it is verified whether it conforms to the preset allow sending verification rules; if it does not conform to the preset allow sending verification rules, the operation to send the invoice application form to the bank is automatically blocked.
[0042] In some embodiments, preset verification rules are allowed to be sent, specifically including: It is determined that the invoice batch number corresponding to the invoice application form is not empty and is the invoice batch number specified by the system. The invoice batch number and the invoice batch number of the details in the main table of the invoice application form are read. The invoice batch number of the details is determined to be all the preset invoice batch numbers corresponding to the invoice batch number of the main table, and the status information does not have a preset recovery mechanism code. Alternatively, if the invoice batch number corresponding to the invoice application form is empty, and the detailed invoice batch number has both a preset batch identifier code and an empty value, and the status information of the preset batch identifier code is a preset recovery mechanism code.
[0043] Further specific preset verification rules include: 1. When the batch number of the bill of exchange is not empty and is specified by the system; 2. The batch number of the main form of the acceptance bill is the preset batch identifier (assumed value, for example, PC01), all detailed batch numbers are preset batch identifiers (assumed values), there are no 4B or 4D (preset recovery mechanism codes) under the preset batch identifier, and all orders with the preset batch identifier are selected at this time; 3. The batch number of the main form for accepting bills of exchange is preset batch identifier code 2 (assumed value, for example, PC02). The details of the accepting bills of exchange simultaneously contain preset batch identifier code 1 and preset batch identifier code 2. The details corresponding to preset batch identifier code 1 are in the status 4A / 4B / 4D (preset recovery mechanism code), while the status of preset batch identifier code 2 is not 4B / 4D. All details of preset batch identifier code 2 are selected at this time (this is a scenario where the batch is canceled and re-assigned after partial failure (preset batch identifier code 1), which provides a recovery mechanism for bank processing failures). 4. The main form of the acceptance bill is empty for the batch number, but the details show both a preset batch identifier code and an empty one. The preset batch identifier code is in the state of 4A, 4B, or 4D. (This is a scenario where the batch is returned to be cancelled after partial failure, which provides a recovery mechanism after partial failure and batch cancellation.) 5. The batch number on the main form of the acceptance bill is empty, and the batch number in the bill details is empty (not a batch issuance).
[0044] Based on the above description, this application provides a method for batch electronic bill issuance processing with multiple bank interfaces, specifically as follows: Figure 2 As shown, the processing flow is determined by the request received by the preset interface of the operation type node. Different requests correspond to different processing branches. The processing branches include at least: an update logic branch corresponding to a specified invoice batch, a cancellation logic branch corresponding to a cancelled invoice batch, and a verification logic branch (including the verification logic corresponding to the detection that the invoice application form has been sent to the bank). Among them, the verification logic corresponds to the CheckBatchNo instruction, the update logic corresponds to the UpdateBatchNo instruction, and the cancellation logic corresponds to the CancelUpdateBatchNo instruction.
[0045] When the UpdateBatchNo instruction is triggered, the batch number is first checked to ensure it is not empty (the specified invoice batch is read, and it is checked whether the invoice batch number already exists). If it is not empty, the invoice application batch number, payment details batch number, and settlement information batch number are then updated sequentially, and the update logic is processed accordingly. Specifically: If the settlement statement type corresponding to the payment details is not self-managed invoicing, a prompt will be issued indicating that it is not an invoicing transaction and specifying the invoicing batch is not allowed.
[0046] If the payment details status corresponds to the settlement statement type of self-managed invoicing, but the amount in the main invoice table is inconsistent with the approved amount in the payment details, then specifying the invoicing batch is not allowed.
[0047] The payment details correspond to a settlement statement type of self-managed invoicing, and the amount in the main invoice table matches the approved amount in the payment details. A confirmation dialog box for the specified invoicing batch pops up. After receiving the confirmation information, an invoicing batch number is generated according to the document numbering rules, stored in the settlement details batch number field, and written back to the invoicing application batch number field. (Then the batch number is updated in the payment details, settlement information, and invoicing application. The batch numbers in the payment details and settlement information tables are updated by the settlement platform, and the invoicing application calls the [Specified Invoicing Batch Verification and Update Interface] to update, passing optype as "UpdateBatchNo").
[0048] If the settlement statement type is not a unified invoice, a prompt will be given that specifying the invoice batch is not allowed.
[0049] Call the API provided by the ticket management system to support batch processing.
[0050] If the batch number field on the unified invoice is not empty, then update the batch number. Call the invoice application form interface to update the batch number in the invoice application form.
[0051] When the CancelUpdateBatchNo command is triggered, for settlement details or invoice application forms with invoice batch numbers, if the selected document is a payment detail, if the batch number of the settlement document corresponding to the payment detail is empty, a prompt will be given that the document does not specify an invoice batch and there is no need to cancel the invoice batch; if the batch number of the settlement document corresponding to the payment detail is not empty, the batch number field will be cleared.
[0052] If the selected document is settlement information, and the settlement document type is not centralized invoicing, a prompt will be given that it is a non-invoicing business document and there is no need to cancel the invoicing batch. If the settlement document type is centralized invoicing and the batch number is empty, a prompt will be given that the document does not specify an invoicing batch and there is no need to cancel the invoicing batch. If the settlement document type is centralized invoicing and the batch number is not empty, the batch number will be cleared, and the optype will be "CancelUpdateBatchNo". The status of the relevant tables will be updated, and the cancellation result will be returned.
[0053] When the CheckBatchNo instruction is triggered, specifically, when an invoice application is detected to be sent to the bank, the allowed sending verification rule program is triggered. The invoice application is read, and the existence of the invoice details is verified. If the details exist, the invoice bank directly connected to the invoice is obtained, and it is verified whether it meets the preset allowed sending verification rules (e.g., verifying the consistency of the invoice type and verifying the maximum number of transactions). If it does not meet the preset allowed sending verification rules, the operation of sending the invoice application to the bank is automatically blocked, and the verification result is returned.
[0054] In addition, this application Figure 3 This application provides an embodiment of a batch electronic invoice issuance system for multiple bank interfaces. For example... Figure 3 As shown in the embodiments of this application, the system mainly includes: The designated module 210 is used to specify or cancel invoice batches through a preset interface.
[0055] The invoicing module 220 is used to read a specified invoicing batch and verify whether an invoicing batch number already exists; if an invoicing batch number exists, the process of canceling the invoicing batch is triggered.
[0056] The generation module 230 is used to read document information for documents without an invoice batch number, determine the corresponding invoice verification program, and obtain the verification result. When the verification result is successful, the specified invoice batch program is triggered. Through the specified invoice batch program, the bank's business logic verification interface is called to obtain the return result of the current batch of documents. When the return result is successful, the document numbering rule is called to generate an invoice batch number, which is stored in the settlement details batch number field and written back to the invoice application form batch number field.
[0057] The generation module 230 includes a generation unit. This is used to encapsulate all verified documents in the current batch into standardized messages according to the bank interface specifications when the specified invoicing batch procedure is triggered; and to call the pre-registered bank business logic verification interface via the HTTPS protocol. When the bank interface returns a successful verification response, the unique transaction identifier and the bank confirmation timestamp in the returned message are extracted as the basis for batch uniqueness. Combined with the enterprise's preset numbering rule engine, the invoice batch number is generated according to the format corresponding to the document numbering rule. The settlement details batch number field in the settlement details table is updated in batches using a transaction, and is synchronously written back to the invoice application batch number field in the associated invoice application table.
[0058] Cancel module 240 is used to access the document information of the current batch of documents and call the corresponding verification item program; read the specific content corresponding to the verification item, and use the verification item program to verify whether canceling the invoice batch is supported; when canceling the invoice batch is supported, the clearing program is triggered to clear the batch number and update the corresponding invoice application form.
[0059] The sending module 250 is used to trigger the allow sending verification rule program when it detects that an invoice application form has been sent to the bank. The program reads the invoice application form and verifies whether it conforms to the preset allow sending verification rule. If it does not conform to the preset allow sending verification rule, the program automatically blocks the invoice application form from being sent to the bank.
[0060] The above are method embodiments of this application. Based on the same inventive concept, this application also provides a batch invoicing processing device for electronic bills with multiple bank interfaces. Figure 4 As shown, the device includes: a processor; and a memory storing executable code thereon, which, when executed, causes the processor to perform a batch invoicing processing method for electronic bills oriented towards a multi-bank interface as described in the above embodiment.
[0061] Specifically, the server specifies or cancels an invoice batch through a preset interface; it reads the specified invoice batch and verifies whether an invoice batch number already exists; if an invoice batch number exists, it triggers the cancellation process; it reads the document information of documents without invoice batch numbers, determines the corresponding invoice verification procedure, and obtains the verification result; if the verification result is successful, it triggers the specified invoice batch procedure; through the specified invoice batch procedure, it calls the bank's business logic verification interface to obtain the return result of the current batch of documents; if the return result is successful, it calls the document numbering rules to generate an invoice batch number and stores it in the settlement statement. The batch number field is refined and written back to the batch number field of the invoice application form; the document information of the current batch of documents is used to call the corresponding verification item program; the specific content corresponding to the verification item is read, and the verification item program is used to verify whether canceling the invoice batch is supported; when canceling the invoice batch is supported, the clearing program is triggered to clear the batch number and update the corresponding invoice application form; when the operation of sending the invoice application form to the bank is detected, the allowed sending verification rule program is triggered, the invoice application form is read, and it is verified whether it meets the preset allowed sending verification rule; when it does not meet the preset allowed sending verification rule, the operation of sending the invoice application form to the bank is automatically blocked.
[0062] In addition, this application embodiment also provides a non-volatile computer storage medium storing executable instructions, which, when executed, implement the above-described method for batch electronic bill issuance processing for multiple bank interfaces.
[0063] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for batch invoicing of electronic bills with multiple bank interfaces, characterized in that, The method includes: Specify or cancel the invoice batch through the preset interface; Read the specified invoice batch and verify whether the invoice batch number already exists; if the invoice batch number exists, trigger the process to cancel the invoice batch. Read document information for documents without a valid invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result. When the verification result is successful, trigger the specified invoice batch procedure. Through the specified invoice batch procedure, call the bank's business logic verification interface to obtain the return result of the current batch of documents. When the return result is successful, call the document numbering rules to generate an invoice batch number, store it in the settlement details batch number field, and write it back to the invoice application form batch number field. Read the cancelled invoice batch, and call the corresponding verification item program based on the document information of the current batch of documents; read the specific content corresponding to the verification item, and use the verification item program to verify whether the cancellation of the invoice batch is supported; when the cancellation of the invoice batch is supported, trigger the clearing program to clear the batch number and update the corresponding invoice application form; When an invoice application form is detected being sent to the bank, the allowed sending verification rule program is triggered. The invoice application form is read and verified to see if it complies with the preset allowed sending verification rule. If it does not comply with the preset allowed sending verification rule, the invoice application form being sent to the bank is automatically blocked.
2. The method for batch invoicing of electronic bills with multiple bank interfaces according to claim 1, characterized in that, Document information includes: document type, settlement statement type, invoice master amount, and approved payment details amount. Document type includes payment details. Read document information for documents with no invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result; when the verification result is successful, trigger the specified invoice batch procedure, which specifically includes: Read the settlement order type, the amount in the main invoice table, and the approved amount for payment details that do not have an invoice batch number; When a settlement statement is detected to be a non-self-managed invoice, the verification result is determined to be a verification failure, and the specified invoice batch procedure is not allowed to be triggered. When it is detected that the settlement order type is self-managed invoicing and the amount in the main invoice table is inconsistent with the approved amount in the payment details, the verification result is determined to be verification failure, and the specified invoicing batch procedure is not allowed to be triggered. When it is detected that the settlement order type is self-managed invoicing and the amount in the main invoice table is consistent with the approved amount in the payment details, a confirmation box for the specified invoicing batch pops up. When a confirmation instruction is received, the verification result is confirmed as successful, and the specified invoicing batch procedure is triggered.
3. The method for batch invoicing of electronic bills with multiple bank interfaces according to claim 1, characterized in that, Document information includes: document type and settlement statement type; document type includes settlement information. Read document information for documents with no invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result; when the verification result is successful, trigger the specified invoice batch procedure, which also includes: Read the settlement order type corresponding to settlement information for which there is no invoice batch number; When a settlement statement type that is not centrally managed is detected, the verification result is determined to be a verification failure, and the specified invoice batch procedure is not allowed to be triggered. When the settlement statement type is detected as "centralized invoicing", a confirmation box for the specified invoicing batch pops up. When a confirmation instruction is received, the verification result is confirmed as successful, and the specified invoicing batch program is triggered.
4. The method for batch invoicing of electronic bills with multiple bank interfaces according to claim 1, characterized in that, By specifying the invoice batch procedure, the bank's business logic verification interface is called to obtain the return result of the current batch of documents; when the return result indicates successful verification, the document numbering rules are called to generate an invoice batch number, which is stored in the settlement details batch number field and written back to the invoice application form batch number field. Specifically, this includes: When the specified invoice batch procedure is triggered, all documents that pass the verification in the current batch are encapsulated into standardized messages according to the bank interface specifications; and the pre-registered bank business logic verification interface is called via the HTTPS protocol. When the bank interface returns a successful verification response, the unique transaction identifier and the bank confirmation timestamp in the returned message are extracted as the basis for batch uniqueness. Combined with the enterprise's preset numbering rule engine, the invoice batch number is generated according to the format corresponding to the document numbering rule. The settlement details batch number field in the settlement details table is updated in batches using a transaction, and is synchronously written back to the invoice application batch number field in the associated invoice application table.
5. The method for batch invoicing of electronic bills with multiple bank interfaces according to claim 1, characterized in that, Document information includes document type and status information, and document types are at least divided into: payment details and settlement information; The document information of the current batch of documents calls the corresponding verification item program; Read the specific content corresponding to the verification item, and use the verification item program to verify whether canceling the invoice batch is supported. Specifically, this includes: Read the status information corresponding to the current batch of documents. When the status information corresponds to the preset "cannot be cancelled" status, it is determined that the cancellation of the invoice batch is not supported, and the process termination procedure is called. When the status information does not correspond to the preset "cannot be cancelled" status and the type of the current batch of documents is payment details, the invoice batch number verification program is called to read the invoice batch number corresponding to the payment details. When the invoice batch number verification program detects that the invoice batch number is empty, it is determined that the cancellation of the invoice batch is not supported, and the process termination program is called; when it is not empty, it is determined that the cancellation of the invoice batch is supported. When the status information does not correspond to the preset "cannot be cancelled" status and the current batch of documents is of type "settlement information", the settlement information verification program is called to read the type corresponding to the settlement information. If the settlement information verification program detects that the type is not "unified invoicing", it determines that cancelling the invoicing batch is not supported and calls the end process program. If it is "unified invoicing", the invoice batch number verification program is called to read the invoice batch number. If the invoice batch number verification program detects that the invoice batch number is empty, it determines that cancelling the invoice batch is not supported and calls the end process program. If it is not empty, it determines that cancelling the invoice batch is supported.
6. The method for batch invoicing of electronic bills with multiple bank interfaces according to claim 1, characterized in that, Preset verification rules for allowed transmission, specifically including: It is determined that the invoice batch number corresponding to the invoice application form is not empty and is the invoice batch number specified by the system. The invoice batch number and the invoice batch number of the details in the main table of the invoice application form are read. The invoice batch number of the details is determined to be all the preset invoice batch numbers corresponding to the invoice batch number of the main table, and the status information does not have a preset recovery mechanism code. Alternatively, if the invoice batch number corresponding to the invoice application form is empty, and the detailed invoice batch number has both a preset batch identifier code and an empty value, and the status information of the preset batch identifier code is a preset recovery mechanism code.
7. A batch invoicing system for electronic bills with multiple bank interfaces, characterized in that, The system includes: The designated module is used to specify or cancel invoice batches through a preset interface. The invoicing module is used to read a specified invoicing batch and verify whether an invoicing batch number already exists; if an invoicing batch number exists, the process of canceling the invoicing batch is triggered. The generation module is used to read document information for documents without an invoice batch number, determine the corresponding invoice verification procedure, and obtain the verification result. When the verification result is successful, the specified invoice batch procedure is triggered. Through the specified invoice batch procedure, the bank's business logic verification interface is called to obtain the return result of the current batch of documents. When the return result is successful, the document numbering rules are called to generate an invoice batch number, which is stored in the settlement details batch number field and written back to the invoice application form batch number field. The cancellation module is used to access the document information of the current batch of documents and call the corresponding verification item program. It reads the specific content of the verification item and uses the verification item program to check whether canceling the invoice batch is supported. When canceling the invoice batch is supported, it triggers the clearing program to clear the batch number and update the corresponding invoice application form. The sending module is used to trigger the allow sending verification rule program when it detects that an invoice application form has been sent to the bank. It reads the invoice application form and verifies whether it meets the preset allow sending verification rule. If it does not meet the preset allow sending verification rule, it automatically blocks the invoice application form from being sent to the bank.
8. The electronic bill batch invoicing processing system for multiple bank interfaces according to claim 7, characterized in that, The generation module includes generation units. This is used to encapsulate all verified documents in the current batch into standardized messages according to the bank interface specifications when the specified invoicing batch procedure is triggered; and to call the pre-registered bank business logic verification interface via the HTTPS protocol. When the bank interface returns a successful verification response, the unique transaction identifier and the bank confirmation timestamp in the returned message are extracted as the basis for batch uniqueness. Combined with the enterprise's preset numbering rule engine, the invoice batch number is generated according to the format corresponding to the document numbering rule. The settlement details batch number field in the settlement details table is updated in batches using a transaction, and is synchronously written back to the invoice application batch number field in the associated invoice application table.
9. A batch invoicing processing device for electronic bills with multiple bank interfaces, characterized in that, The device includes: processor; And a memory having executable code stored thereon, which, when executed, causes the processor to perform a batch invoicing processing method for electronic bills with a multi-bank interface as described in any one of claims 1-6.
10. A non-volatile computer storage medium, characterized in that, It stores computer instructions, which, when executed, implement a batch invoicing method for electronic bills with multiple bank interfaces as described in any one of claims 1-5.