Electricity-counting invoice issuing method and device, and storage medium

Abstract

The invention discloses a digital-to-electricity invoice issuing method and device and a storage medium, and relates to the technical field of tax management, and the method comprises the steps: receiving batch transaction flow data of each business platform system, and generating a corresponding exchange file based on the batch transaction flow data; the exchange file is transmitted to a target tax system, the exchange file is analyzed in the target tax system, and an analysis result is stored in a service intermediate table of the target tax system; and scanning the service intermediate table according to a preset timed task, determining to-be-made electronic invoice information in the service intermediate table, and calling a preset interface to make an invoice based on the to-be-made electronic invoice information. According to the invention, centralized management and control, automatic invoicing and financial management optimization of invoicing flow of a multi-service system are realized, the efficiency and accuracy of invoicing are improved, the financial management cost and the tax risk are reduced, and the high timeliness requirement of financial enterprises for invoicing is met.

Description

Technical Field

[0001] The present application relates to the field of tax management technology, and in particular to a method, device and storage medium for issuing digital invoices. Background Art

[0002] With the widespread adoption of digital invoices, the invoicing process has undergone significant changes. Due to the diverse transaction flows of financial institutions, encompassing a variety of business types, including loans, wealth management, and payments, invoicing processes are often scattered across different business systems. Existing digital invoice systems typically only support integration with a single business system, failing to meet the invoicing needs of financial institutions across multiple business systems. This results in invoicing processes being fragmented across various systems, lacking unified management, and increasing the complexity and cost of financial management.

[0003] At the same time, although the existing digital invoice system supports automatic invoicing, in the financial enterprise scenario, manual intervention is still required to process complex transaction flows, that is, the actual invoicing is still semi-automated and cannot meet the customer's demand for "real-time" invoices. Especially in the financial enterprise scenario, customers have high requirements for the timeliness of invoices, which makes it difficult for existing invoicing technology to meet their actual needs.

[0004] In addition, due to the diversity of transaction flows in financial enterprises and high financial management requirements, it is necessary to ensure the accuracy, completeness and traceability of invoice data. However, invoice data is currently scattered across different systems, and the existing digital invoice system is unable to centrally and uniformly control the invoicing flow, resulting in irregular and non-transparent financial management and increased tax risks.

[0005] Therefore, how to support financial enterprises in automatically and centrally controlling the invoicing flow of multiple business systems is an urgent problem that needs to be solved. Summary of the Invention

[0006] The main purpose of this application is to provide a method, device and storage medium for issuing digital invoices, aiming to solve the technical problem of how to support financial enterprises to automatically and centrally control the invoicing flow of multiple business systems.

[0007] To achieve the above-mentioned purpose, the present application proposes a method for issuing a digital invoice, which includes:

[0008] Receive batch transaction flow data from each business platform system and generate corresponding exchange files based on the batch transaction flow data;

[0009] Transmitting the exchange file to a target tax system, and parsing the exchange file in the target tax system, wherein the parsing result is stored in a business intermediate table of the target tax system;

[0010] The business intermediate table is scanned according to a preset timing task to determine the information of the digital invoice to be issued in the business intermediate table, and a preset interface is called to issue an invoice based on the information of the digital invoice to be issued.

[0011] In one embodiment, the batch transaction flow data is received by a preset data warehouse, and the step of generating a corresponding exchange file based on the batch transaction flow data includes:

[0012] In the preset data warehouse, the batch transaction flow data is subjected to field processing and standardization, and the processed target batch transaction flow data is saved in the data warehouse flow target table;

[0013] Extract the target batch transaction flow data from the data warehouse flow target table, and generate a corresponding exchange file based on the target batch transaction flow data, wherein the exchange file includes a control file, a data file and an extensible markup language file.

[0014] In one embodiment, the step of transmitting the exchange file to the target tax system includes:

[0015] Verify the transfer authority to transfer the exchange file to the target tax system;

[0016] If the transmission permission satisfies a preset first permission requirement and there is an incomplete local file corresponding to the exchange file in the target tax system, clearing the incomplete local file;

[0017] Determining a file path of the exchange file based on a configuration path, a file name, and a file date of the exchange file;

[0018] If it is determined according to the file path that a data file exists in the exchange file, the exchange file is transmitted to the target tax system.

[0019] In one embodiment, the exchange file is transferred by executing the current file transfer task by the target instance, and after the step of cleaning up the target local file in the target tax system, the step further includes:

[0020] Locking the current file transfer task so that the target instance exclusively uses the current file transfer task;

[0021] After the exchange file is transmitted to the target tax system, the current file transmission task is locked and released.

[0022] In one embodiment, the exchange file is transmitted by executing a current file transfer task by the target instance, and the step of parsing the exchange file in the target tax system includes:

[0023] Verifying the parsing authority for parsing the exchanged file in the target tax system;

[0024] In a case where the resolution authority meets the preset second authority requirement, querying the target exchange file in the target state in the transmission record of the target instance according to the IP address of the target instance;

[0025] In the case that the target exchange file exists, the target exchange file is cyclically parsed to obtain a parsing result of the exchange file.

[0026] In one embodiment, the step of performing a cyclic parsing on the target exchange file includes:

[0027] Determine a parsing instance according to a table name in the target exchange file, and determine an absolute path of the target exchange file according to a configuration path, table name, synchronization date, and file type in the target exchange file;

[0028] In a case where it is determined according to the absolute path that the target data file exists in the target exchange file, verifying the consistency of the target control file and the target data file in the target exchange file;

[0029] When the target control file and the target data file meet consistency, the business intermediate table corresponding to the parsing instance is cleaned according to a preset data cleaning task;

[0030] The field names in the target extensible markup language file corresponding to the business intermediate table in the target exchange file are determined, and the fields corresponding to the field names are parsed according to preset delimiters through the parsing instance.

[0031] In one embodiment, the business intermediate table also includes information on digital invoices to be issued on the channel side, and the method for issuing digital invoices also includes:

[0032] The business intermediate table stores the channel side digital invoice information to be issued, which is transmitted by the preset service application through the message queue. The channel side digital invoice information to be issued is generated by any business platform system accessing the corresponding background service group according to the invoicing request, and calling the preset service application based on the background service group.

[0033] In one embodiment, the method for issuing a digital invoice further includes:

[0034] For any business platform system, when the front end of the business platform system receives an operation request, the preset interface is called to return the preset web page interface to the front end of the business platform system according to the identification parameter in the operation request, so that the front end of the business platform system obtains the interaction data generated in the preset web page interface;

[0035] The preset interface is called to perform identity authority verification according to the interaction data, and after the identity authority verification is passed, an invoice is issued based on the identity authority of the interaction data.

[0036] In addition, to achieve the above-mentioned purpose, the present application also proposes an electronic device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the method for issuing digital invoices as described above.

[0037] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the method for issuing digital invoices as described above are implemented.

[0038] One or more technical solutions proposed in this application have at least the following technical effects:

[0039] The present application first receives the batch transaction flow data of each business platform system, and generates a corresponding exchange file based on the batch transaction flow data, so as to receive and integrate the batch transaction flow data of each business platform system, generate an exchange file, and can centrally collect the invoicing flow scattered in different business systems, thereby solving the problem that the invoicing flow of each business platform system of a financial enterprise is scattered and difficult to manage in a unified manner, and lays the foundation for subsequent centralized control; then the exchange file is transmitted to the target tax system, and the exchange file is parsed in the target tax system, wherein the parsing result is saved in the business intermediate table of the target tax system, thereby combining different The invoicing data from the business system is aggregated into the business intermediate table of the target tax system, so that the invoice data is no longer scattered, providing support for the standardization and transparency of financial management and reducing tax risks; then the business intermediate table is scanned according to the preset scheduled task to determine the information of the digital invoice to be issued in the business intermediate table, and the preset interface is called to issue the invoice based on the information of the digital invoice to be issued. Thus, through scheduled scanning and automatic calling of the interface, the information to be invoiced can be discovered in time and invoices can be issued quickly, realizing the automation of the invoicing process, improving the invoicing efficiency and response speed, and meeting the actual needs of financial enterprises with high requirements for the timeliness of invoices.

[0040] In summary, this application avoids the technical problems of the existing technology such as the dispersion of financial enterprises' invoicing flows, the inability to centrally control, inaccurate and incomplete invoice data and non-traceability, and the semi-automated invoicing process that cannot meet real-time needs by adopting the technical means of receiving batch transaction flow data from various business platform systems to generate exchange files, transmitting and parsing the exchange files to the business intermediate table of the target tax system, and calling the interface to issue invoices through scheduled tasks. It realizes the centralized control of invoicing flows of multiple business systems, automated invoicing and financial management optimization, improves the efficiency and accuracy of invoice issuance, reduces financial management costs and tax risks, and meets the high timeliness requirements of financial enterprises for invoice issuance. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0042] Figure 1 A flowchart illustrating the first embodiment of the method for issuing a digital invoice for this application;

[0043] Figure 2 This is a schematic diagram of the API connection process for the method of issuing digital electricity invoices provided in Example 1 of this application;

[0044] Figure 3 A schematic diagram of the batch flow business docking process of the method for issuing digital electricity invoices provided in Example 1 of this application;

[0045] Figure 4 A schematic diagram of the invoicing process of the method for issuing a digital electricity invoice provided in Example 1 of the present application;

[0046] Figure 5 A schematic diagram of the analytical flow of the method for issuing a digital invoice provided in Example 1 of this application;

[0047] Figure 6 A schematic diagram of the channel docking architecture of the method for issuing digital electricity invoices provided in Example 2 of this application;

[0048] Figure 7 A schematic diagram of the webpage docking architecture of the method for issuing digital electricity invoices provided in Example 3 of this application;

[0049] Figure 8 A schematic diagram of the authority control process for the method for issuing digital electricity invoices provided in Example 3 of this application;

[0050] Figure 9 This is a schematic diagram of the device structure of the hardware operating environment involved in the method for issuing digital electronic invoices in the embodiment of the present application. DETAILED DESCRIPTION

[0051] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0052] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0053] The main solution of the embodiment of the present application is: receiving batch transaction flow data of each business platform system, and generating corresponding exchange files based on the batch transaction flow data; transmitting the exchange files to the target tax system, and parsing the exchange files in the target tax system, wherein the parsing results are stored in the business intermediate table of the target tax system; scanning the business intermediate table according to the preset timed task, determining the information of the digital invoice to be issued in the business intermediate table, and calling the preset interface to issue the invoice based on the information of the digital invoice to be issued.

[0054] Due to the diverse transaction flows of financial institutions, encompassing various business types such as loans, wealth management, and payments, invoicing processes are often fragmented across different business systems. Existing digital invoice systems typically only support integration with a single business system, failing to meet the invoicing needs of financial institutions across multiple business systems. This results in invoicing processes being fragmented across different systems and lacking unified management, increasing the complexity and cost of financial management. Furthermore, while existing digital invoice systems support automated invoicing, they still require manual intervention to process complex transaction flows in the financial sector. This means that actual invoicing remains semi-automated, failing to meet customer demands for "real-time" invoices. This is particularly true in the financial sector, where customers place high demands on the timeliness of invoices, making existing invoicing technologies inadequate. Furthermore, due to the diverse transaction flows and stringent financial management requirements of financial institutions, ensuring the accuracy, integrity, and traceability of invoice data is crucial. However, currently, invoice data is fragmented across different systems, making it difficult for existing digital invoice systems to centrally manage invoicing processes. This leads to irregular and opaque financial management and increases tax risks. Therefore, how to support financial institutions in automatically and centrally managing invoicing processes across multiple business systems is a pressing issue.

[0055] The present application provides a solution. By adopting the technical means of receiving batch transaction flow data of various business platform systems to generate exchange files, transmitting and parsing the exchange files to the business intermediate table of the target tax system, and calling the interface to issue invoices through scheduled tasks to scan the intermediate table, the solution avoids the technical problems in the existing technology such as the dispersion of financial enterprises' invoicing flows, the inability to centrally control, inaccurate and incomplete invoice data and non-traceability, and the semi-automated invoicing process that cannot meet real-time needs. It realizes the centralized control of invoicing flows of multiple business systems, automated invoicing and financial management optimization, improves the efficiency and accuracy of invoice issuance, reduces financial management costs and tax risks, and meets the high timeliness requirements of financial enterprises for invoice issuance.

[0056] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of performing the above functions. The following uses electronic devices as an example to illustrate this embodiment and the following embodiments.

[0057] Based on this, the embodiment of the present application provides a method for issuing a digital invoice, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the method for issuing digital invoices in this application.

[0058] In this embodiment, the method for issuing a digital invoice includes steps S10 to S30:

[0059] Step S10: receiving batch transaction flow data from each business platform system, and generating corresponding exchange files based on the batch transaction flow data;

[0060] It should be noted that the systems that financial enterprises rely on to conduct various types of business, such as credit management systems, payment settlement systems, and wealth management sales systems, support daily financial transaction activities. Batch transaction flow data refers to the collection of a large number of transaction records accumulated in the business platform system over a certain period of time. These transaction records reflect in detail the occurrence of financial business, including key elements such as transaction amount, transaction time, information about the two parties to the transaction, and business type. Exchange files refer to data files organized according to specific formats and specifications, which are used to transfer data between different information systems. Exchange files can contain a variety of data content, such as transaction flow information and customer information. In the digital invoice issuance scenario, exchange files are the channel for communication between different systems. This file encapsulates and converts the batch transaction flow data in the business platform system so that it can be correctly identified and received by the target tax system. The exchange file can include a control file with a file suffix of CTL, a data file of DAT, and an extensible markup language (XML) file. The control file stores the control parameters of the data synchronization task, such as the data source, file name, encoding, quantity, etc. The data file can contain various types of data, such as strings, numbers, dates, etc. The extensible markup language file is used to store and transmit structured data. XML files use tags to describe the structure of the flow data, such as table name, field name, field description, length, progress, and field type, making it easy to read and process. The specific structure and content of the file follow the rules pre-agreed by the two systems to ensure accurate transmission and effective exchange of data.

[0061] In addition, it should be noted that the batch transaction flow data transmitted by each business platform system can be directly pushed to the VAT invoice system (i.e. the target tax system) by calling the API interface. The interface adopts a modular design. Figure 2 The system primarily consists of the following components: a gateway layer responsible for receiving external application requests; a docking component utilizing a Spring Boot-based web architecture responsible for logically processing transaction flows; and an Oracle database for data persistence. Subsequently, invoicing personnel push successful transaction flows to the VAT invoice system based on this interface to issue VAT invoices.

[0062] It is understandable that due to the diversity of business systems of financial enterprises, a large number of transaction flow records will be generated in each business platform system. These batch transaction flow data are scattered in different systems, making it difficult to uniformly manage and issue invoices. Therefore, step S10 can avoid the problem of scattered invoicing flows in multiple business systems and the inability to centrally control them. This allows the transaction flow data scattered in various business platform systems to be collected and exchange files to be generated, providing a data basis for subsequent centralized processing and invoicing, thereby realizing data integration and unified management.

[0063] In a feasible implementation, the batch transaction flow data is received by a preset data warehouse, and the step of generating a corresponding exchange file based on the batch transaction flow data in step S10 may include steps S11 to S12:

[0064] Step S11, in the preset data warehouse, performing field processing and standardization on the batch transaction flow data, and saving the processed target batch transaction flow data to the data warehouse flow target table;

[0065] It should be noted that a pre-set data warehouse refers to a system or platform designed for data storage, integration, and management. In financial enterprises, this data warehouse is used to collect and store data from different business platform systems, including various types of business data such as batch transaction flow data. Through operations such as data extraction, transformation, and loading (ETL), the raw data is cleaned, converted, and integrated into a format suitable for analysis and application. The target batch transaction flow data refers to the batch transaction flow data that has been processed and standardized through the fields in the pre-set data warehouse. This data has been organized according to unified data formats and specifications, eliminating any inconsistencies and errors that may exist in the raw data. The data warehouse flow target table is a specific table structure in the pre-set data warehouse used to store the target batch transaction flow data. It is a specially designed data storage structure whose fields and formats match the requirements of downstream business applications such as invoicing.

[0066] It is understandable that, since the data formats and specifications of various business platform systems of financial enterprises are often not unified, there are differences in field content, data types, etc. in batch transaction flow data. Directly using this data for invoice issuance may lead to data errors or incompatibility issues. Therefore, performing step S11 can avoid the problem that the data formats of various business platform systems are not unified and cannot be directly used for invoice issuance. Thus, by standardizing the batch transaction flow data, including field processing and standardized operations, the accuracy and consistency of the data are ensured, and the processed target batch transaction flow data is saved to the data warehouse flow target table, providing a high-quality data source for subsequent exchange file generation, thereby improving data availability and the accuracy of invoice issuance.

[0067] For example, in the preset data warehouse, the data warehouse system will perform a series of field processing and standardization operations on the batch transaction flow data. For example, for the date fields in the transaction flow data from different business systems, their formats are uniformly converted to the standard format of "yyyy-MM-dd HH:mm:ss"; for numeric fields, the numerical precision and units are unified, such as the amount field is uniformly retained with two decimal places and in yuan; for string fields, the encoding format is unified to UTF-8, and data cleaning is performed to remove unnecessary spaces, special characters, etc. At the same time, some missing values ​​will also be filled in, such as for some empty fields, reasonable default values ​​are filled in according to business rules. After completing these processes, the processed target batch transaction flow data will be stored according to the table structure of the preset data warehouse flow target table.

[0068] Step S12: extract the target batch transaction flow data from the data warehouse flow target table, and generate a corresponding exchange file based on the target batch transaction flow data, wherein the exchange file includes a control file, a data file and an extensible markup language file.

[0069] It is understandable that even standardized data needs to be transmitted to the target tax system in a specific, structured manner so that the tax system can correctly identify and interpret the data. Therefore, performing step S12 can avoid the problem of non-standard data transmission format and the inability of the target tax system to effectively receive and process the data. This allows the target batch transaction flow data to be extracted and an exchange file containing a control file, data file, and XML file to be generated according to the requirements of the target tax system. This exchange file generation method ensures the integrity and accuracy of the data during transmission, allowing the target tax system to smoothly receive and interpret the data, preparing for further invoice issuance operations, and improving the reliability of data transmission and the efficiency of invoice issuance.

[0070] For example, the target batch transaction flow data is extracted from the data warehouse flow target table, and then an exchange file is generated based on this data. Generate a control file (.ctl), which stores the control parameters of the data synchronization task, such as data source information (including database connection string, table name, etc.), file name (such as "invoice_data_20241010.ctl"), encoding format (such as UTF-8), number of data records, etc. Generate a data file (.dat), which contains the specific content of the transaction flow data. These data are arranged in a specific format, such as one transaction record per line, and each field is separated by a separator (such as "|"). The field content can contain various types of data, such as characters. The system generates an Extensible Markup Language (.xml) file, which uses tags to describe the structure of the transaction data, such as the table name "transaction_details," the field name "amount," the field description "transaction amount," the length "10," the progress "required," and the field type "decimal," making the data structure easy to read and process. These three files together form the exchange file. This exchange file, which includes multiple file types, ensures that the data is fully and accurately received and parsed by the target tax system during transmission, providing reliable data support for subsequent invoice issuance operations.

[0071] For example, referring to Figure 3 , batch transaction flow data from multiple business platform system databases is loaded into the flow interface table in the data warehouse, and corresponding processing is performed to obtain the flow target table. Then, data is extracted to generate an SFTP exchange file, which is then transmitted to the data loading component in the VAT system (i.e., the target tax system) for subsequent parsing and storage. In particular, in the event of abnormal scenarios such as SFTP timeouts during data extraction (out of the warehouse) resulting in file download failures, the backend management component can be used to re-download and parse the file and save the flow to the VAT database. This can enhance system stability, data integrity, and flexibility.

[0072] In this embodiment, by performing field processing and standardization on batch transaction flow data in a preset data warehouse, and then saving the processed data to the data warehouse flow target table, and then extracting these data to generate an exchange file containing a control file, a data file and an extensible markup language file, the technical means further avoids the uneven quality of exchange files due to inconsistent and non-standard data formats, and the inability of the target tax system to effectively identify and parse data, thereby ensuring the accuracy and consistency of the exchange file data, and improving the reliability of data transmission and the accuracy of invoice issuance.

[0073] Step S20: transmitting the exchange file to a target tax system, and parsing the exchange file in the target tax system, wherein the parsing result is stored in a business intermediate table of the target tax system;

[0074] It should be noted that the target tax system is an information system responsible for handling tax-related business operations, primarily responsible for invoice issuance, tax filing, and tax payment. Within financial enterprises, the target tax system processes incoming transaction flow data and generates corresponding digital invoices in accordance with tax laws and the enterprise's tax management requirements. This system maintains data exchange with the tax authorities' information systems to ensure corporate tax compliance. It includes functional modules such as invoice management, tax data statistical analysis, and tax filing, making it a crucial tool for tax management within financial enterprises. The business intermediate table is a temporary data storage structure within the target tax system that temporarily stores pending business data parsed from exchange files. This provides a unified data source for subsequent invoice issuance operations and facilitates centralized management and querying of invoice information. The structure of the business intermediate table is typically designed to align with the business requirements of invoice issuance, including key fields such as invoice header, amount, and transaction type. This ensures data integrity and accuracy, enabling rapid response to invoice issuance tasks.

[0075] It is understandable that since the existing digital invoice system cannot directly connect to the multiple business systems of financial enterprises, there are obstacles to the transmission and processing of invoice data. Therefore, performing step S20 can avoid the problem that invoice data cannot be effectively transmitted and processed between multiple business systems and tax systems, thereby realizing the transmission of the exchange file to the target tax system, parsing the exchange file in the target tax system, extracting the transaction flow information therein, and saving the parsing results in the business intermediate table as an intermediate transition table for data storage, ensuring that the invoice data can be correctly processed and stored in the tax system, and providing accurate data support for invoice issuance.

[0076] In a feasible implementation, the step of transmitting the exchange file to the target tax system in step S20 may include steps S21 to S24:

[0077] Step S21, verifying the transmission authority for transmitting the exchanged file to the target tax system;

[0078] It should be noted that transfer permissions refer to the authorization rules that allow exchange files to be transferred from one system to the target tax system. They usually include provisions on the transfer user, transfer time, transfer file type, etc., to ensure the security and compliance of file transfer.

[0079] It is understandable that if the transmission permissions are not verified during the file transfer process, unauthorized file transfer may occur, causing data security and privacy issues. Therefore, performing step S21 can avoid security and data privacy risks during the file transfer process, thereby ensuring that only exchange files with legal transmission permissions can be transmitted to the target tax system, effectively ensuring the security of file transfer and data compliance.

[0080] For example, before transferring exchange files, the system first verifies the identity of the user initiating the transfer. This can be done through username and password verification, digital certificate verification, or dynamic token verification. For example, the transfer program uses a pre-stored digital certificate to send an authentication request to the target tax system. After receiving the request, the target tax system verifies the validity of the digital certificate, including checking whether the certificate is issued by a trusted certificate authority, whether it is within the validity period, whether it has been revoked, etc. At the same time, the system will also verify whether the user has the authority to transfer exchange files. This is usually achieved by checking the user's role and permission configuration in the system. For example, only roles with "invoicing file transfer" permissions can initiate a transfer. Subsequent file transfer operations are allowed only when the user identity authentication is passed and the permission check meets the preset first permission requirements.

[0081] Step S22: if the transmission permission satisfies a preset first permission requirement and there is an incomplete local file corresponding to the exchange file in the target tax system, clearing the incomplete local file;

[0082] It's important to note that incomplete local files refer to files stored in the target tax system. These files may be exchange files received in previous transfer tasks. Before executing a new file transfer task, clearing these target local files frees up storage space for new exchange files and avoids data redundancy.

[0083] In addition, it should be noted that when the transmission authority does not meet the preset first authority requirements, the current exchange file transmission task is terminated; when the transmission authority meets the preset first authority requirements and there is no incomplete local file corresponding to the exchange file in the target tax system, the subsequent step S23 is directly executed.

[0084] It is understandable that since the target tax system may have previously interrupted the task of transferring the exchange file from the source system to the target tax system, there are some incomplete local files that have not been transferred. If they are not cleaned up, it may cause data redundancy, waste of storage space and data processing confusion. Therefore, performing step S22 can avoid the problems of data redundancy, storage space waste and data processing confusion caused by duplicate files in the target tax system, thereby clearing out duplicate and incomplete local files before transmitting legitimate files, ensuring that the files stored in the target tax system are the latest and non-duplicate, and improving the system's storage efficiency and data processing accuracy.

[0085] Step S23, determining the file path of the exchange file based on the configuration path, file name and file date of the exchange file;

[0086] It should be noted that the configuration path refers to the pre-configured path information in the exchange file transfer task, including the storage path of the source file and the storage path of the target file, etc., which is used to guide the file transfer process; the file path refers to the specific location of the exchange file in the file system. By combining information such as the configuration path, file name and file date, the file path can be accurately determined to facilitate file reading, transfer and other operations.

[0087] It is understandable that if the file path of the exchange file is not accurately determined and the existence of the data file is not judged, the file may not be found or the wrong file may be transmitted during the file transfer process. Therefore, performing step S23 can avoid transmission errors caused by incorrect file path or missing data file during the file transfer process, thereby accurately determining the file path through the configuration path, file name and file date of the exchange file, so as to subsequently judge whether the data file exists, ensuring that the transferred file is correct and available, and improving the accuracy and reliability of file transfer.

[0088] Exemplarily, when the transfer permission check is passed, the system queries the target tax system for historical exchange files that are identical to the current exchange files. This can be done by comparing information such as the file name, creation date, file size, and content checksum (such as MD5 value) to determine whether they are the same files. For example, the system searches for historical exchange files that match the name and date of the current exchange file in the designated storage directory of the target tax system. Once matching files are found, the system marks these files as files to be cleaned up and records a cleanup log, including information such as the file path, file name, and cleanup time. The system then cleans up these target local files according to preset cleanup strategies, such as direct deletion, moving to a backup directory, or compressed archiving. After the cleanup is completed, the system updates the file index of the target tax system to ensure that subsequent file reading and processing operations will not be affected by the cleaned files, thereby freeing up storage space for new exchange files and avoiding data redundancy.

[0089] Step S24: When it is determined according to the file path that there is a data file in the exchange file, the exchange file is transmitted to the target tax system.

[0090] It can be understood that since the data file is only transmitted after the existence is confirmed, step S24 is performed, which avoids the problem of invalid or incomplete files being transmitted during the file transmission process, thereby ensuring that the exchange file transmitted to the target tax system is complete and valid, ensuring that the target tax system can receive the correct file and perform subsequent processing, and improving the quality of file transmission and the stability of system operation.

[0091] In this implementation, by further adopting technical means such as transmission permission verification, target local file cleaning, file path determination, and data file existence judgment, problems such as unauthorized file transfer, data redundancy, storage space waste, data processing confusion, and transmission of erroneous files are avoided, thereby ensuring the security, compliance, accuracy, and reliability of file transfer, and improving storage efficiency and system operation stability.

[0092] In a feasible implementation, the exchange file is transmitted by the target instance executing the current file transfer task. The step of parsing the exchange file in the target tax system in step S20 may include steps S25 to S27:

[0093] Step S25, verifying the parsing authority for parsing the exchanged file in the target tax system;

[0094] It should be noted that parsing permissions refer to the authorization settings in the target tax system that allow specific users, roles or system instances to perform parsing operations on exchange files. This permission defines who can parse, under what conditions, and the scope of the parsing, etc., and is an important mechanism to ensure data security and system stability.

[0095] It is understandable that since unauthorized parsing operations may lead to data leakage or incorrect parsing, affecting the security and accuracy of the data, performing step S25 can avoid data security and accuracy issues caused by unauthorized parsing operations, thereby ensuring that only authorized entities can parse the exchange file, ensuring data security and reliability of parsing.

[0096] Exemplarily, the system maintains a permission configuration database, which stores the parsing permission information corresponding to different users, roles or system instances. When it is necessary to parse an exchange file, the system obtains the identity information of the user or instance currently requesting parsing, such as user ID, role name or instance ID, etc. The system then queries the corresponding parsing permission in the permission configuration database based on this identity information. At the same time, the system will also verify whether the type, source, etc. of the exchange file requested for parsing are within the scope of the user or instance's permissions. For example, some users may only be able to parse exchange files of specific business types (such as loan business). If all permission checks are passed, that is, the preset second permission requirements are met, the system allows the exchange file to be parsed; otherwise, the parsing request is rejected and the relevant permission rejection log is recorded for subsequent security audits and problem troubleshooting.

[0097] Step S26, when the parsing authority meets the preset second authority requirement, querying the target exchange file in the target state in the transmission record of the target instance according to the IP address of the target instance;

[0098] It should be noted that the target instance refers to the system instance or service instance that undertakes specific task execution during the file transfer and parsing process. Each instance usually has a unique IP address for identification and positioning, so as to facilitate operations such as task allocation, status monitoring and data management; the target exchange file refers to the exchange file in the target tax system that meets specific conditions (such as successful transmission, pending parsing, and other target states) and needs to be parsed. It is the object of the current parsing task and contains information such as transaction flow data that needs to be extracted and processed for subsequent business operations such as invoice issuance.

[0099] It is understandable that since there may be a large number of exchange files in the target tax system, directly searching for the files that need to be parsed is inefficient and prone to errors. Therefore, performing step S26 can avoid the problem of not being able to accurately and efficiently locate the target exchange file that needs to be parsed among the numerous exchange files, thereby accurately locating the target exchange file through the IP address and transmission record of the target instance, thereby improving the parsing efficiency and accuracy.

[0100] Exemplarily, the system first obtains the IP address of the target instance, and then searches the transfer record database or log file of the instance. For example, the system constructs an SQL query statement with the filtering conditions being the target instance IP address and the record with the file status of "transferred to be parsed". By executing this query, the system can obtain all exchange file records that meet these conditions. Then, the system further filters out specific target exchange files based on business rules (such as file priority, file name pattern, etc.). These target exchange files are the files that currently need to be parsed. The system will list them in the parsing task queue and prepare for subsequent cyclic parsing operations to extract the data for business processing such as invoicing.

[0101] Step S27: If the target exchange file exists, the target exchange file is cyclically parsed to obtain a parsing result of the exchange file.

[0102] It is understandable that since the exchange file may contain a large number of data records, a one-time parsing may face performance pressure and the risk of incomplete parsing. Therefore, performing step S27 can avoid the problem of not being able to efficiently and completely parse large-scale exchange file data, thereby processing the data records in the exchange file one by one through cyclic parsing, ensuring the integrity of the parsing and the stability of the system.

[0103] In this implementation, by adopting technical means such as parsing permission verification, target instance IP address query and circular parsing, unauthorized parsing operations, inaccurate parsing files and incomplete parsing are further avoided, ensuring the security, accuracy and integrity of the parsing process, and improving parsing efficiency and system stability.

[0104] Step S30, scanning the business intermediate table according to the preset timed task, determining the information of the digital invoice to be issued in the business intermediate table, and calling the preset interface to issue the invoice based on the information of the digital invoice to be issued.

[0105] It should be noted that a preset scheduled task is a pre-configured task program in a computer system or software that automatically executes at specified intervals. In the digital invoice issuance process, a preset scheduled task is responsible for regularly scanning the business intermediate table to check for pending transaction flow information. This task can be flexibly configured based on the financial institution's business volume and invoicing needs, such as scanning every hour or at a specific time each day. Pending digital invoice information refers to invoice information corresponding to transaction flows stored in the business intermediate table for which invoice issuance has yet to be completed. This information contains key elements required for digital invoice issuance, such as the purchaser's name, taxpayer identification number, seller information, transaction amount, business type, and invoice date. Pending digital invoice information directly supports the invoice issuance process. By identifying and processing this information, the system invokes the corresponding invoicing interface to generate digital invoices that comply with tax laws. A preset interface refers to a pre-developed and configured interface program used to facilitate data exchange and function calls between different systems or software modules. When the preset scheduled task determines the information of the digital invoice to be issued, the system will call the preset interface to communicate with the invoice issuance system or the invoice management system of the tax authority, send the invoice request and receive the invoice result. Among them, the preset interface follows specific communication protocols and data format specifications to ensure that data can be accurately transmitted and processed between different systems.

[0106] It is understandable that due to the high timeliness requirements of financial enterprises for invoices, the existing invoicing process often requires manual intervention and cannot meet the needs of real-time invoicing. Therefore, performing step S30 can avoid the problem that the semi-automated invoicing process cannot respond to the invoice issuance needs in a timely manner. By automatically scanning the business intermediate table through the preset timed task, the information of the digital invoice to be issued is determined, and the preset interface is called to issue the invoice, the automation and efficiency of invoice issuance are realized, and the customer's invoice needs can be quickly responded to, thereby improving invoicing efficiency and service quality.

[0107] For example, the business intermediate table is scanned according to the preset timed task to determine the invoice information to be issued in the business intermediate table according to the invoicing mark. Figure 4 Based on the system flag (e.g., GJS, KZX, or other) and the active invoicing flag in the / add request, the automatic invoicing table is combined to execute the active invoicing scheduled task. The preset interface is called to issue the invoice based on the pending digital invoice information. The VAT system provides users with multiple VAT invoicing application methods, including manual invoicing, transaction flow summary, split invoicing, manual amortization invoicing, and red-ink confirmation form application. Furthermore, the successfully issued electronic invoice file is automatically sent to the target mailbox specified in the exchange file.

[0108] This embodiment provides a method for issuing digital invoices. By adopting the technical means of receiving batch transaction flow data from various business platform systems to generate an exchange file, transmitting and parsing the exchange file to the business intermediate table of the target tax system, and calling the interface to issue invoices through a scheduled task scanning the intermediate table, it avoids the technical problems in the existing technology of financial enterprises' decentralized invoicing flow, the inability to centrally control, inaccurate and incomplete invoice data and non-traceability, and the semi-automated invoicing process that cannot meet real-time needs. It realizes centralized control of invoicing flows of multiple business systems, automated invoicing and financial management optimization, improves the efficiency and accuracy of invoice issuance, reduces financial management costs and tax risks, and meets the high timeliness requirements of financial enterprises for invoice issuance.

[0109] In a feasible implementation manner, the exchange file is transmitted by the target instance executing the current file transfer task. After step S22, steps S201 to S202 may be included:

[0110] Step S201, locking the current file transfer task so that the target instance exclusively uses the current file transfer task;

[0111] It should be noted that the current file transfer task refers to the task including steps S21 to S24, of transferring the exchange file to the target tax system.

[0112] It is understandable that in a multi-instance environment, multiple instances may try to execute the same file transfer task at the same time, resulting in data inconsistency, repeated transmission and other problems. Therefore, performing step S201 can avoid data confusion and repeated operation problems caused by multiple instances concurrently executing the same file transfer task, ensuring that the same file transfer task is only executed by one instance at the same time, ensuring the atomicity of file transfer and data integrity.

[0113] For example, in a file transfer system, when a target instance acquires a file transfer task, the system marks the task status as "Resolving" in the task management database and records information such as the target instance executing the task's IP address and start time. Simultaneously, the system creates a lock object associated with the task. This lock object can be a database record, a file lock, or a flag in memory. For example, if a database lock is used, the system inserts a lock record into the task table containing fields such as the task ID, lock status, lock time, and the executing instance's IP address. When other instances attempt to acquire the task, they first check the lock status in the task table. If they find the task is locked and the lock status is "Resolving," they are informed that the task is being executed by another instance and are forced to abandon the task or enter a waiting queue. Furthermore, the system can implement a heartbeat mechanism where the target instance periodically sends heartbeat signals to indicate that the task is still executing normally. If other instances detect that a task has been locked for an extended period without receiving heartbeat updates, they may determine that the target instance has failed. In this case, they can attempt to unlock the task and reallocate it to another instance, improving system availability and fault tolerance.

[0114] Step S202: After the exchange file is transmitted to the target tax system, the current file transmission task is locked and released.

[0115] It is understandable that if the lock is not released in time after the file transfer task is completed, other instances will not be able to execute subsequent file transfer tasks, resulting in idle system resources and task backlogs. Therefore, performing step S202 can avoid the problems of idle system resources and task execution delays that may be caused by the locking mechanism, and realize the timely release of the lock after the file transfer task is completed, so as to open the restriction on the remaining instances occupying the current file transfer task, so that other instances can continue to execute subsequent file transfer tasks, thereby improving the system's concurrent processing capabilities and resource utilization.

[0116] This implementation, through the use of a task locking and releasing mechanism, avoids duplicate file transfer tasks and resource contention in a multi-instance environment, ensuring the atomicity of file transfers and improving the system's concurrent processing capabilities and resource utilization. Specifically, locking the current file transfer task prevents other instances from executing the same task simultaneously, ensuring task atomicity and data consistency. Releasing the lock promptly after the file transfer is complete allows other instances to continue executing subsequent tasks, improving the system's overall efficiency and resource utilization.

[0117] In a feasible implementation manner, the exchange file is transferred by executing the current file transfer task through the target instance, and the step of cyclically parsing the target exchange file in step S27 may include steps S271 to S274:

[0118] Step S271, determining a parsing instance according to the table name in the target exchange file, and determining the absolute path of the target exchange file according to the configuration path, table name, synchronization date and file type in the target exchange file;

[0119] It should be noted that the parsing instance refers to the program or service instance responsible for parsing the exchange file, which is usually selected according to the type and content of the exchange file; the configuration path refers to the configuration information of the exchange file storage location, which is used to help the system quickly locate the file; the table name refers to the database table name corresponding to the data in the exchange file, which is used to determine the storage location of the data; the synchronization date refers to the timestamp of the data transmission, which is used to identify the timeliness of the data; the file type refers to the format of the exchange file, such as text, XML, etc., which is used to determine the parsing method; the absolute path refers to the complete path of the exchange file in the file system, which is used to accurately access the file; the target data file refers to the DAT file containing the actual data in the exchange file.

[0120] It can be understood that since it is necessary to accurately find the corresponding parsing instance and data file when parsing the exchange file, otherwise it may cause parsing errors or be unable to parse, so step S271 is performed to solve the problem of how to accurately determine the location of the parsing instance and data file, avoid parsing errors and waste of resources, and thus achieve accurate finding of the parsing instance and data file through the information in the exchange file to ensure the smooth progress of the parsing process.

[0121] Exemplarily, the system maintains a parsing instance configuration table, which records the parsing instance information corresponding to different table names. When the target exchange file needs to be parsed, the table name is first obtained from the file header or configuration segment. Based on this table name, the system queries the parsing instance configuration table to find the corresponding parsing instance. At the same time, the system uses the configuration path (such as " / data / incoming / "), table name (such as "transaction_data"), synchronization date (such as "20241010") and file type (such as ".dat") provided in the exchange file, and combines them into an absolute path according to the preset path rules, such as " / data / incoming / 20241010 / transaction_data.dat".

[0122] Step S272: When it is determined according to the absolute path that the target data file exists in the target exchange file, verify the consistency between the target control file and the target data file in the target exchange file;

[0123] It should be noted that the target control file refers to the CTL file containing control parameters in the exchange file.

[0124] It is understandable that since the control file and the data file need to be consistent, otherwise data parsing errors or incomplete data may occur, performing step S272 can avoid problems that may be caused by inconsistencies between the control file and the data file, such as data parsing errors, thereby ensuring the accuracy and completeness of the data by verifying consistency and improving the reliability of the parsing.

[0125] Exemplarily, the system checks whether the target data file under the absolute path exists by calling the file system API. If it exists, continue with subsequent processing; if it does not exist, record the error log and perform corresponding error handling, wherein the subsequent processing includes: the system reads the control parameters in the target control file (such as the ".ctl" file), including the number of data records, data checksum (such as CRC checksum value), field definition, etc. At the same time, the system reads the actual number of data records in the target data file (such as the ".dat" file) and calculates the data checksum. The system compares whether the number of records in the control file is consistent with the actual number of records in the data file, and whether the checksum in the control file matches the calculated checksum of the data file. If the number of records and checksums of the two are consistent, the verification is passed, and the system records a successful verification log; otherwise, the verification fails, the system records detailed inconsistency information, and performs corresponding error handling, such as notifying the administrator or retransmitting the file.

[0126] Step S273: When the target control file and the target data file meet consistency, clean up the business intermediate table corresponding to the parsing instance according to a preset data cleanup task;

[0127] It is understandable that since the business intermediate table may contain outdated or irrelevant data, which affects the parsing efficiency and data accuracy, performing step S273 can avoid the problems of data redundancy and obsolescence in the business intermediate table, and then optimize the business intermediate table through data cleaning tasks, thereby improving the parsing efficiency and data accuracy.

[0128] Step S274: determining the field names in the target extensible markup language file corresponding to the business intermediate table in the target exchange file, and parsing the fields corresponding to the field names according to the preset delimiters through the parsing instance.

[0129] It should be noted that the field name refers to the name of each data item in the data file, which is used to identify the data content.

[0130] It can be understood that since it is necessary to accurately parse the fields in the extensible markup language file in order to correctly store and process the data, step S274 is performed to solve the problem of how to accurately parse the field names and corresponding fields, thereby accurately parsing the fields through preset delimiters, ensuring the correctness of the data and the efficiency of parsing.

[0131] Exemplarily, the system determines the field names in the corresponding target extensible markup language file (such as an ".xml" file) based on the structural definition of the business intermediate table. For example, the business intermediate table has a field "transaction_amount", and the corresponding field name in the XML file may be "amount". The system finds the nodes corresponding to these field names by parsing the structure of the XML file. When parsing a data file, the parsing instance splits each row of data records according to a preset delimiter (such as a comma ","), and matches the split field values ​​with the field names defined in the XML file. For example, a row of records in a data file may be "1,2024-10-10,1000.00", the delimiter is a comma, and the corresponding field names are "id", "date", and "amount". The parsing instance assigns these field values ​​to the corresponding field names respectively to form structured data records, which are stored in the business intermediate table.

[0132] For example, as an example, the parsing process can refer to Figure 5 .

[0133] In this implementation, by adopting technical means such as parsing instance determination, absolute path generation and judgment, file consistency verification, data cleaning and field parsing, problems such as data file positioning errors, parsing errors, data inconsistency and redundancy are avoided, ensuring data accuracy and integrity, improving parsing efficiency and optimizing storage.

[0134] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction and will not be repeated hereafter. On this basis, the business intermediate table also includes the information of the digital invoice to be issued on the channel side, and the method for issuing the digital invoice also includes step A01:

[0135] Step A01, save the channel side digital invoice information to be issued transmitted by the preset service application through the message queue in the business intermediate table, wherein the channel side digital invoice information to be issued is generated by any business platform system accessing the corresponding background service group according to the invoicing request, and calling the preset service application based on the background service group.

[0136] It should be noted that the preset service application refers to a service program pre-configured by a financial enterprise that can be used to process invoicing requests. The application can receive invoicing requests from different business platform systems, perform necessary processing and conversion, and then send the channel side's digital invoice information to be issued to the business intermediate table through the message queue; the channel side's digital invoice information refers to the information on digital invoices to be issued from various business channels of the financial enterprise (such as online loan platforms, offline financial management centers, etc.). This information contains detailed data required for invoicing, such as transaction amount, customer information, business type, etc., reflecting the transaction records generated by customers through different channels, and is the direct basis for invoicing; the backend service group refers to a group of backend service programs or modules that support the operation of the business platform system. It is responsible for processing various business logic and data operation requests of the business platform. When the business platform receives an invoicing request, it will send the request to the backend service group for processing. The backend service group then calls the preset service application to generate the channel side's digital invoice information to be issued.

[0137] It is understandable that due to the diversity of business platform systems of financial enterprises, the sources of information on digital invoices to be issued on the channel side are wide and scattered. Storing this information directly in the business intermediate table can avoid repeated data processing and the complexity of multi-source integration. Therefore, performing step A01 can avoid the problems of difficult integration of multi-channel invoicing information and low processing efficiency, thereby realizing the centralized storage and management of information on digital invoices to be issued from different channels, improving data processing efficiency and the timeliness of invoicing.

[0138] For example, referring to Figure 6 When the business platform system (such as the corporate online banking web terminal, mobile banking mobile terminal, etc.) receives the customer's invoicing request, it will first send the request to the background service group through the Nginx cluster and security gateway cluster in the DMZ network segment. The background service group is usually composed of multiple microservices, responsible for processing various business logics, such as transaction verification, invoice information generation, etc. After receiving the invoicing request, the background service group will call the value-added tax invoice platform service group, that is, the preset service application, which is specifically responsible for processing invoice-related business logic. The preset service application generates the digital invoice information to be issued on the channel side. This information includes key fields such as the invoice header, taxpayer identification number, transaction amount, and invoicing date. The preset service application sends this information to the Leqi Tax Bureau, that is, the preset tax system, through a message queue (such as RabbitMQ, Kafka, etc.). Among them, the value-added tax invoice platform service group is connected to the Oracle database.

[0139] In this embodiment, by adopting message queues and preset service applications, compatibility issues, inconsistent data transmission, and excessive system coupling caused by direct connection of multiple business platform systems to the tax system are avoided, and centralized management and efficient transmission of digital invoice information to be issued on the channel side are achieved, thereby improving the efficiency of invoice issuance and data consistency.

[0140] Based on the first and / or second embodiments of the present application, in the third embodiment of the present application, the same or similar contents as those of the first and second embodiments can be referred to above and will not be described in detail. On this basis, the method for issuing digital invoices further includes steps B01 to B02:

[0141] Step B01: For any business platform system, when the front end of the business platform system receives an operation request, calling the preset interface to return a preset web page interface to the front end of the business platform system according to the identification parameter in the operation request, so that the front end of the business platform system obtains the interaction data generated in the preset web page interface;

[0142] It should be noted that an operation request refers to a request initiated by a user on the front-end interface of the business platform system, which usually includes the type of operation the user wants to perform (such as invoicing application) and related parameter information; identification parameters refer to parameters used to uniquely identify the user identity or operation context in the operation request, such as user ID, session ID, etc., which are used for subsequent identity authentication and operation records; the preset web page interface refers to a web page interface provided to users for entering and confirming information related to invoice issuance, which usually includes interactive elements such as forms and buttons to guide users to complete the invoicing operation; interactive data refers to data entered or selected by the user on the preset web page interface, such as invoice header, amount, invoice type, etc., which will be used for invoice generation and recording.

[0143] It is understandable that due to the risks of illegal calls and redundant system development in the traditional interface docking model, and the diverse business platform systems of financial enterprises with different user interfaces and operating procedures, directly implementing complex invoicing functions on the front end will lead to repeated development and inconsistent user experience. Therefore, step B01 is performed to provide users with a consistent invoicing operation entrance through a preset interface and a unified preset web page interface, achieving dual isolation of business logic and interactive interface, and effectively preventing illegal call risks through the request signature verification mechanism. In addition, it also reduces development and maintenance costs and improves user experience.

[0144] For example, referring to Figure 7When a user initiates an operation request on the front-end of a business system (such as the Operation Center or Zhaoyingtong), the business system sends a page call request containing parameters such as the customer ID to the digital component (i.e., the pre-configured tax system). The digital component returns a separate web interface, which the business system loads and presents in the front-end container. Users interact with the tax system directly within the embedded web page, completing core operations such as applying for VAT digital invoices, tracing application records, and querying issued invoices.

[0145] Step B02: calling the preset interface to verify identity authority according to the interaction data, and after the identity authority verification is passed, issuing an invoice based on the identity authority of the interaction data.

[0146] It should be noted that, referring to Figure 8 Users can control the transaction records they can access through their organization, limiting the scope of access to transaction resources when issuing invoices. Administrators can assign roles, which authorize or disable certain menus, which contain various function buttons, thereby enabling user function permission control.

[0147] It is understandable that since invoice issuance involves sensitive information, it is necessary to ensure that the user performing the operation has a legitimate identity and authority to prevent unauthorized operations. Therefore, performing step B02 can avoid identity theft and unauthorized operations during the invoice issuance process, and realize the verification of user identity and authority through the preset interface to ensure that only legitimate users can perform invoice issuance operations, thereby improving the security and compliance of the system.

[0148] For example, during the identity verification stage, the system links the customer file through the customer number / account number and dynamically limits the types of invoices that can be applied for; in the flow processing stage of the invoice issuance process, it supports multi-dimensional filtering by business system identification, time range, etc., which can eliminate cross-system interference; in the invoice execution stage of the invoice issuance process, it provides three standardized modes: single transaction, summary (single transaction), and summary merger.

[0149] In this embodiment, when an operation request is received at the front end of the business platform system, a preset interface is called to return a preset web page interface according to the identification parameters to obtain interaction data, and identity authority verification and invoice issuance are performed based on these data. This avoids the problem of each business platform repeatedly developing invoicing interfaces and identity authentication modules, and achieves a unified invoicing portal, simplifies the development process, and improves the security of invoice issuance.

[0150] The present application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the electronic method in the above-mentioned embodiment one.

[0151] like Figure 9 As shown, the electronic device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory 1002 or programs loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems may be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape or a hard disk; and a communication device 1009. The communication device 1009 may allow the electronic device to communicate with other devices wirelessly or wired to exchange data.

[0152] In particular, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. The computer program can be downloaded and installed from a network via a communication device, or installed from the storage device 1003, or installed from the read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in this application are performed.

[0153] The electronic device provided in this application, utilizing the method for issuing digital electronic invoices in the aforementioned embodiment, can solve the technical problem of supporting financial enterprises in automatically and centrally managing the invoicing flow of multiple business systems. Compared to the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the method for issuing digital electronic invoices in the aforementioned embodiment, and the other technical features of the electronic device are the same as those disclosed in the aforementioned embodiment, and are not further described here.

[0154] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer program) stored thereon, and the computer-readable program instructions are used to execute the method for issuing digital invoices in the above-mentioned embodiment.

[0155] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof.

[0156] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by an electronic device, the electronic device: receives batch transaction flow data of each business platform system, and generates corresponding exchange files based on the batch transaction flow data; transmits the exchange files to the target tax system, and parses the exchange files in the target tax system, wherein the parsing results are saved in the business intermediate table of the target tax system; scans the business intermediate table according to the preset timed task, determines the information of the digital invoice to be issued in the business intermediate table, and calls the preset interface to issue invoices based on the information of the digital invoice to be issued.

[0157] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned method for issuing digital invoices. This computer-readable storage medium can address the technical problem of supporting financial enterprises in automatically and centrally managing the invoicing flow of multiple business systems. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the method for issuing digital invoices provided in the aforementioned embodiments, and are not further elaborated here.

Claims

1. A method for issuing digital invoices, characterized in that: The method for issuing the digital invoice includes: Receive batch transaction flow data from each business platform system and generate corresponding exchange files based on the batch transaction flow data; Transmitting the exchange file to a target tax system, and parsing the exchange file in the target tax system, wherein the parsing result is stored in a business intermediate table of the target tax system; The business intermediate table is scanned according to a preset timing task to determine the information of the digital invoice to be issued in the business intermediate table, and a preset interface is called to issue an invoice based on the information of the digital invoice to be issued.

2. The method for issuing digital invoices according to claim 1, characterized in that: The batch transaction flow data is received by a preset data warehouse, and the step of generating a corresponding exchange file based on the batch transaction flow data includes: In the preset data warehouse, the batch transaction flow data is subjected to field processing and standardization, and the processed target batch transaction flow data is saved in the data warehouse flow target table; Extract the target batch transaction flow data from the data warehouse flow target table, and generate a corresponding exchange file based on the target batch transaction flow data, wherein the exchange file includes a control file, a data file and an extensible markup language file.

3. The method for issuing digital invoices according to claim 1, characterized in that: The step of transmitting the exchange file to the target tax system includes: Verify the transfer authority to transfer the exchange file to the target tax system; If the transmission permission satisfies a preset first permission requirement and there is an incomplete local file corresponding to the exchange file in the target tax system, clearing the incomplete local file; Determining a file path of the exchange file based on a configuration path, a file name, and a file date of the exchange file; If it is determined according to the file path that a data file exists in the exchange file, the exchange file is transmitted to the target tax system.

4. The method for issuing digital invoices according to claim 3, characterized in that: The exchange file is transmitted by executing the current file transmission task by the target instance, and after the step of cleaning up the target local file in the target tax system, the step further includes: Locking the current file transfer task so that the target instance exclusively uses the current file transfer task; After the exchange file is transmitted to the target tax system, the current file transmission task is locked and released.

5. The method for issuing digital invoices according to claim 1, wherein: The exchange file is transmitted by executing the current file transmission task by the target instance, and the step of parsing the exchange file in the target tax system includes: Verifying the parsing authority for parsing the exchanged file in the target tax system; In a case where the resolution authority meets the preset second authority requirement, querying the target exchange file in the target state in the transmission record of the target instance according to the IP address of the target instance; In the case that the target exchange file exists, the target exchange file is cyclically parsed to obtain a parsing result of the exchange file.

6. The method for issuing digital invoices according to claim 5, characterized in that: The step of cyclically parsing the target exchange file comprises: Determine a parsing instance according to a table name in the target exchange file, and determine an absolute path of the target exchange file according to a configuration path, table name, synchronization date, and file type in the target exchange file; In a case where it is determined according to the absolute path that the target data file exists in the target exchange file, verifying the consistency of the target control file and the target data file in the target exchange file; When the target control file and the target data file meet consistency, the business intermediate table corresponding to the parsing instance is cleaned according to a preset data cleaning task; The field names in the target extensible markup language file corresponding to the business intermediate table in the target exchange file are determined, and the fields corresponding to the field names are parsed according to preset delimiters through the parsing instance.

7. The method for issuing digital invoices according to claim 1, wherein: The business intermediate table also includes information on digital invoices to be issued by the channel side, and the method for issuing the digital invoice also includes: The business intermediate table stores the channel side digital invoice information to be issued, which is transmitted by the preset service application through the message queue. The channel side digital invoice information to be issued is generated by any business platform system accessing the corresponding background service group according to the invoicing request, and calling the preset service application based on the background service group.

8. The method for issuing digital invoices according to claim 1, wherein: The method for issuing the digital invoice also includes: For any business platform system, when the front end of the business platform system receives an operation request, the preset interface is called to return the preset web page interface to the front end of the business platform system according to the identification parameter in the operation request, so that the front end of the business platform system obtains the interaction data generated in the preset web page interface; The preset interface is called to perform identity authority verification according to the interaction data, and after the identity authority verification is passed, an invoice is issued based on the identity authority of the interaction data.

9. An electronic device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the method for issuing a digital invoice according to any one of claims 1 to 8.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the method for issuing a digital invoice as described in any one of claims 1 to 8 are implemented.

Images