Invoicing application business information optimization system, method and apparatus

Abstract

This application provides a system, method, and device for optimizing invoice application business information, relating to the field of enterprise financial digital management technology. The system includes: an integration configuration module for establishing an interface connection between the invoicing ISV system and the approval system, and configuring business rules; a rejection processing module for obtaining rejection reasons triggered by the invoicing ISV system through the interface connection, and writing the rejection reasons back to the approval document in the approval system according to the business rules; an information display module for displaying the corresponding business information detail form based on the business rules and the selected business information subtype in the invoice application form; and a line count control module for identifying the business category to which the invoice application form belongs according to the business rules when the invoice application is submitted, validating the number of lines filled in the business information detail corresponding to the business category, and blocking the submission if the validation fails. This method aims to improve the efficiency of existing invoice applications.

Description

Technical Field

[0001] This application relates to the field of enterprise financial digital management technology, and more specifically, to a system, method and device for optimizing invoice application business information. Background Technology

[0002] Currently, in the digital management of enterprise sales invoice applications, especially in the invoicing business processes of large enterprises, the accurate submission of invoice application forms, improved approval efficiency, and compliance assurance are core requirements for financial control. Enterprises have now widely established invoice application approval systems to achieve online processing of invoice applications, which has improved business processing efficiency to some extent.

[0003] However, in actual business operations, the existing technology still has the following shortcomings: First, when the invoicing ISV (Invoicing Service Provider) system triggers the rejection of an invoice application, the rejection reason only displays a general prompt and fails to write the actual rejection reason of the ISV back to the rejection reason field of the approval workflow. The bill of lading person cannot directly know the rejection details and needs to make additional inquiries or consultations, resulting in a longer rectification period. Second, when the approver views the invoice application, specific business information for invoicing needs to be manually switched to a subtype to view. This is particularly cumbersome and inefficient in batch approval scenarios, and it is easy to miss information, leading to incomplete review. Third, for scenarios such as real estate leasing and real estate sales, the State Taxation Administration clearly requires that specific information details can only be filled in one line, but the existing business object writing component does not set a line limit. The bill of lading person may mistakenly fill in multiple lines, causing the invoice application to be rejected by the tax authorities, increasing the enterprise's compliance risk.

[0004] Therefore, how to accurately transmit the reasons for invoice rejection, intelligently display specific business information related to invoice issuance, and control the number of lines in compliance with regulations, so as to improve the efficiency of invoice application processing, reduce compliance risks, and enhance the flexibility of system configuration, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this application is to provide a system, method, and device for optimizing invoice application business information, aiming to solve technical problems in existing invoice application management systems such as inaccurate transmission of rejection reasons, unintuitive display of specific business information, and unlimited number of lines, which violate tax regulations.

[0006] Firstly, an information optimization system for invoice application services is provided, including: The integrated configuration module is used to establish the interface connection between the invoicing ISV system and the approval system, and to configure business rules; The rejection processing module is used to obtain the rejection reason triggered by the invoicing ISV system through the interface connection, and write the rejection reason back to the approval document in the approval system according to the business rules; The information display module is used to display the corresponding business information detail form according to the business rules and the selected business information subtype in the invoice application form when displaying the invoice application form; The line count control module is used to identify the business category to which the invoice application belongs according to the business rules when the invoice application is submitted, and to verify the number of lines to be filled in the business information details corresponding to the business category. If the verification fails, the submission will be blocked.

[0007] Secondly, a method for optimizing invoice application business information is provided, including: In response to user configuration operations, establish an interface connection between the invoicing ISV system and the approval system, and configure business rules; In response to a rejection event triggered by the invoicing ISV system, the rejection reason is obtained through the interface connection, and the rejection reason is written back to the approval document in the approval system according to the business rules; In response to the approval system's operation of displaying the invoice application form, the corresponding business information detail form is displayed according to the business rules and the selected business information subtype in the invoice application form; In response to the submission of an invoice application, the system identifies the business category to which the invoice application belongs based on the business rules, verifies the number of lines to be filled in the business information details corresponding to that business category, and blocks the submission if the verification fails.

[0008] Thirdly, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps described in the first aspect above.

[0009] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0010] This application provides an invoice application business information optimization system, method, and device, comprising: an integration configuration module for establishing an interface connection between the invoice ISV system and the approval system, and configuring business rules; a rejection processing module for obtaining the rejection reason triggered by the invoice ISV system through the interface connection, and writing the rejection reason back to the approval document in the approval system according to the business rules; an information display module for displaying the corresponding business information detail form according to the business rules and the selected business information subtype in the invoice application form when displaying the invoice application form; and a line count control module for identifying the business category to which the invoice application form belongs according to the business rules when the invoice application is submitted, and verifying the number of lines filled in the business information detail corresponding to the business category, and blocking the submission when the verification fails. This solution constructs an integrated invoicing application business information optimization system encompassing "accurate rejection reason writing-intelligent display of specific information-line compliance control." By establishing an interface link between the invoicing ISV system and the approval system, an automatic extraction and writing mechanism for rejection reasons is created. The approval status display logic is optimized to achieve accurate default display of specific business information. Line count restriction rules are designed to meet tax compliance requirements, embedding business object writing components. Therefore, through accurate rejection reason writing, the system automatically associates and synchronizes the ISV's actual rejection reasons with the approval workflow rejection reasons. The billing party can directly know the ISV's actual rejection reasons without additional inquiries or consultations, providing a clear direction for rectification. The rectification cycle for a single rejected document is shortened from an average of 1-2 days to several hours, significantly improving the rectification efficiency of invoicing applications. Through intelligent display of specific business information, the approval status display logic is optimized, allowing the default display of specific business information types selected during form filling. Approver does not need to manually switch subtypes, improving efficiency by over 50% in batch approval scenarios and avoiding incomplete reviews due to missed switching. By implementing a line count restriction mechanism, compliance with national tax regulations is enforced, preventing invoice rejections due to excessive line entries, ensuring compliance, and reducing the manpower and time costs of repeated application submissions. Through interface integration and automated algorithms, the entire process of rejection reason feedback, display logic optimization, and line count verification is automated, making the invoice application process smoother and more efficient. Ultimately, this achieves efficient processing, compliant control, and flexible configuration of invoice application business, improves the user experience for bill of lading personnel and the approval efficiency for approvers, reduces corporate compliance risks, and solves technical problems in existing invoice application management systems such as inaccurate transmission of rejection reasons, unintuitive display of specific business information, and unrestricted line counts violating tax regulations, thereby improving the efficiency of invoice applications. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This application provides a schematic diagram of the structure of an invoice application business information optimization system. Figure 2 A flowchart illustrating a method for optimizing invoice application business information, provided as an embodiment of this application; Figure 3 A schematic diagram of the structure of an invoice application business information optimization device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The words "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The words "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but do not exclude other elements or objects. The words "connected," "coupled," or "connected," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up," "down," "left," "right," etc., are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0014] Currently, in the digital management of enterprise sales invoice applications, especially in the invoicing business processes of large enterprises, the accurate submission of invoice application forms, improved approval efficiency, and compliance assurance are core requirements for financial control. Enterprises have now widely established invoice application approval systems to achieve online processing of invoice applications, which has improved business processing efficiency to some extent.

[0015] However, in actual business operations, the existing technology still has the following shortcomings: First, when the invoicing ISV (Invoicing Service Provider) system triggers the rejection of an invoice application, the rejection reason only displays a general prompt and fails to write the actual rejection reason of the ISV back to the rejection reason field of the approval workflow. The bill of lading person cannot directly know the rejection details and needs to make additional inquiries or consultations, resulting in a longer rectification period. Second, when the approver views the invoice application, specific business information for invoicing needs to be manually switched to view, which is cumbersome and inefficient, especially in batch approval scenarios, and is prone to omissions, leading to incomplete review. Third, for scenarios such as real estate leasing and real estate sales, the State Taxation Administration clearly requires that specific information details can only be filled in one line, but the existing business object writing component does not set a line limit. The bill of lading person may mistakenly fill in multiple lines, causing the invoice application to be rejected by the tax authorities, increasing the enterprise's compliance risk. Fourth, the existing business object multi-select writing component cannot automatically match the corresponding specific business information subtype for invoicing based on custom file values ​​such as "special invoice type". The bill of lading person needs to select manually, which is cumbersome and prone to matching errors.

[0016] Therefore, how to accurately transmit the reasons for invoice rejection, intelligently display specific business information for invoice issuance, control the number of lines in compliance, and automatically match subtypes in order to improve the efficiency of invoice application processing, reduce compliance risks, and enhance the flexibility of system configuration are technical problems that urgently need to be solved in this field.

[0017] The invoice application business information optimization system provided in this application embodiment can be deployed on the electronic device where the approval system is located, and run as a functional extension module of the approval system.

[0018] The invoice application business information optimization method provided in this application embodiment can be applied to electronic devices, terminal devices, invoice application business information optimization devices or equipment, or other devices or equipment that can execute this embodiment, and there are no limitations on this.

[0019] The terminal can be a user equipment (UE) such as a mobile phone, smartphone, laptop computer, digital broadcast receiver, personal digital assistant (PDA), or tablet computer (PAD), handheld device, in-vehicle device, wearable device, computing device, or other processing device connected to a wireless modem, mobile station (MS), or mobile terminal. This terminal has the ability to communicate with one or more core networks via a radio access network (RAN).

[0020] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0021] Figure 1 This is a schematic diagram illustrating the structure of an invoice application business information optimization system provided in an embodiment of this application. For example... Figure 1 As shown, the system may include: The integrated configuration module is used to establish the interface connection between the invoicing ISV system and the approval system, and to configure business rules; The rejection processing module is used to obtain the rejection reason triggered by the invoicing ISV system through an interface connection, and write the rejection reason back to the approval document in the approval system according to the business rules; The information display module is used to display the corresponding business information details form according to the business rules and the selected business information subtypes in the invoice application form when displaying the invoice application form; The line count control module is used to identify the business category to which the invoice application belongs based on business rules when the invoice application is submitted, and to verify the number of lines to be filled in the business information details corresponding to the business category. If the verification fails, the submission will be blocked.

[0022] For example, the integration configuration module is the foundation for achieving interconnectivity between various systems and the implementation of business rules. Its core functions include interface integration development, visual configuration of business rules, and rule storage and synchronization, ensuring the smooth operation of optimization functions. During the system integration and rule configuration phase, administrators complete the interface integration configuration of the invoicing ISV system, approval system, and custom file system through the system's front-end visual interface. The configuration includes adding, editing, and deleting rules such as rejection reason write-back rules, specific business information display rules (default display logic), line limit rules (for real estate leasing / sales scenarios), and file relationship dependency rules (mapping relationship between special invoice types and subtypes).

[0023] The rejection reason write-back rules include configuring the judgment logic for rejection reasons. Specifically, when the invoicing ISV system automatically rejects a request, it writes back the actual rejection reason pushed by the invoicing ISV system; when the invoicing ISV system manually rejects a request, it writes back a general prompt: "The corresponding invoicing application status is {Invoicing Status}, the document is rejected." It also configures the mapping relationship between rejection reasons and approval document fields to ensure accurate field writing. Specific business information display rules include configuring two optional display strategies: the first strategy is "default display of the first business object type with data," and the second strategy is "default display of all business object types with data and their corresponding data." Administrators can choose the default display strategy based on enterprise approval needs, and approvers can manually switch display modes. Row count limit rules include configuring a list of business types with row count restrictions (e.g., real estate leasing, real estate sales, with corresponding codes), setting the row count limit to 1 row; configuring the verification trigger timing (when submitting the form, when saving) and verification failure prompts (e.g., "Only one row of specific information details for real estate leasing can be filled in, please adjust"). The file relationship dependency rules include configuring the mapping relationship between custom file values ​​and subtypes, such as "Special Ticket Type = Real Estate Operation and Leasing Service Invoice" corresponding to "Subtype = Real Estate Operation and Leasing Invoice Specific Information"; it supports batch import / export of mapping relationships, and supports adding, editing, and deleting mapping rules.

[0024] Optionally, based on an entity's approval document interface and invoice reception interface, a dedicated rejection reason write-back interface can be developed. This interface supports receiving invoicing status (invoicing failed, voided, etc.) and corresponding actual rejection reasons pushed by the invoicing ISV system. Core transmission fields include application number, invoicing status, ISV rejection reason, rejection time, and operator. It supports breakpoint resumption and data integrity verification to ensure accurate transmission of rejection reason data.

[0025] Optionally, a custom interface for linking the file system and the approval system can be developed to realize the associated data transmission of the "special ticket type" file value and the specific business information subtype of the invoice. The linking interface supports real-time query of file mapping relationships. The core transmission fields include special ticket type code, special ticket type name, corresponding subtype code, subtype name, etc., to ensure the real-time automatic matching of subtypes.

[0026] Optionally, a data verification interface for the number of rows entered for specific business information can be developed. For scenarios such as real estate leasing and real estate sales, the number of rows entered can be verified in real time to see if it complies with the restriction rules. The core transmission fields of the data verification interface include business type code, number of rows entered, verification result, prompt information, etc. If the verification fails, feedback will be given to the bill of lading person in real time.

[0027] Optionally, relational databases (such as MySQL) can be used to store various business rules, and the relationship between the rule table and the business type table and the file table can be established to facilitate fast query and matching. A message queue mechanism can be used to realize real-time synchronization of rule data between the configuration module and each business processing module to ensure that rule changes are immediately applied to the subsequent invoice application processing process. A rule change log can be set to record the person who modified the rule, the time of modification, and the content of modification, so as to facilitate traceability and rollback.

[0028] The line count control module is used during the invoice application submission and data flow stages. When the bill of lading holder submits an invoice application in the system, he / she fills in fields such as special invoice types and specific business information for invoicing. The system automatically verifies the number of lines filled in for specific business information (for real estate-related scenarios). After the verification is passed, it is submitted to the approval flow, and the application data is synchronized to the invoicing ISV system.

[0029] The rejection processing module is used during the rejection reason processing and write-back stage. If the invoicing ISV system triggers a rejection, the system extracts the actual rejection reason from the invoicing ISV system through the interface, determines the rejection type (automatic rejection type / manual rejection type) according to preset rules, and automatically writes the corresponding rejection reason back to the rejection reason field of the approval flow, and pushes it synchronously to the bill of lading holder.

[0030] The information display module is used to display the corresponding business information details form when displaying an invoice application form, based on any strategy in the business rules and the selected business information subtype in the invoice application form.

[0031] The system provided in this application includes: an integration configuration module for establishing an interface connection between the invoicing ISV system and the approval system, and configuring business rules; a rejection processing module for obtaining the rejection reason triggered by the invoicing ISV system through the interface connection, and writing the rejection reason back to the approval document in the approval system according to the business rules; an information display module for displaying the corresponding business information detail form according to the business rules and the selected business information subtype in the invoicing application form when displaying the invoicing application form; and a line count control module for identifying the business category to which the invoicing application form belongs according to the business rules when the invoicing application is submitted, and verifying the number of lines filled in the business information detail corresponding to the business category, and blocking the submission when the verification fails. This solution constructs an integrated invoicing application business information optimization system encompassing "accurate rejection reason writing-intelligent display of specific information-line compliance control." By establishing an interface link between the invoicing ISV system and the approval system, an automatic extraction and writing mechanism for rejection reasons is created. The approval status display logic is optimized to achieve accurate default display of specific business information. Line count restriction rules are designed to meet tax compliance requirements, embedding business object writing components. Therefore, through accurate rejection reason writing, the system automatically associates and synchronizes the ISV's actual rejection reasons with the approval workflow rejection reasons. The billing party can directly know the ISV's actual rejection reasons without additional inquiries or consultations, providing a clear direction for rectification. The rectification cycle for a single rejected document is shortened from an average of 1-2 days to several hours, significantly improving the rectification efficiency of invoicing applications. Through intelligent display of specific business information, the approval status display logic is optimized, allowing the default display of specific business information types selected during form filling. Approver does not need to manually switch subtypes, improving efficiency by over 50% in batch approval scenarios and avoiding incomplete reviews due to missed switching. By implementing a line count restriction mechanism, compliance with national tax regulations is enforced, preventing invoice rejections due to excessive line entries, ensuring compliance, and reducing the manpower and time costs of repeated application submissions. Through interface integration and automated algorithms, the entire process of rejection reason feedback, display logic optimization, and line count verification is automated, making the invoice application process smoother and more efficient. Ultimately, this achieves efficient processing, compliant control, and flexible configuration of invoice application business, improves the user experience for bill of lading personnel and the approval efficiency for approvers, reduces corporate compliance risks, and solves technical problems in existing invoice application management systems such as inaccurate transmission of rejection reasons, unintuitive display of specific business information, and unrestricted line counts violating tax regulations.

[0032] In one example, the rejection processing module includes: a reason receiving unit, used to receive rejection data pushed by the invoicing ISV system, the rejection data including at least the application form identifier and the rejection reason; and a write-back execution unit, used to write the rejection reason into the rejection reason field of the corresponding approval document in the approval system.

[0033] For example, the rejection processing module is responsible for automatically extracting the rejection reasons, determining the type, and writing back the approval flow from the invoicing ISV system. The rejection processing module includes a reason receiving unit and a write-back execution unit. The reason receiving unit is used to receive the rejection data pushed by the invoicing ISV system. The rejection data includes at least the application form identifier and the rejection reason. The write-back execution unit is used to write the rejection reason into the rejection reason field of the corresponding approval document in the approval system, thereby ensuring that the bill of lading holder can intuitively obtain the rejection details.

[0034] Specifically, the rejection reason receiving mechanism involves the system using an integrated dedicated rejection reason write-back interface to monitor invoicing status change events in the invoicing ISV system in real time. When a rejection status such as "invoicing failed" or "voided" is detected, the rejection reason receiving process is automatically triggered to extract the original data pushed by the invoicing ISV system, including the application number, invoicing status code, actual rejection reason, rejection operation type (automatic rejection type / manual rejection type), rejection time, etc. The received data is format-validated to ensure that the fields are complete and the format is correct. If the validation fails, a retry mechanism is triggered. If the retry still fails after a preset number of times (e.g., 3 times), an exception log is recorded and the administrator is notified.

[0035] In one example, the rejection processing module also includes: a type determination unit, used to determine the rejection operation type based on the rejection data; the rejection operation type includes automatic rejection type and manual rejection type; and a write-back execution unit, used to write back the actual rejection reason pushed by the invoicing ISV system to the rejection reason field when the rejection type is determined to be automatic; and to write back the preset standard prompt information to the rejection reason field when the rejection type is determined to be manual.

[0036] For example, based on a pre-set rejection type judgment algorithm and the "Rejection Operation Type" field or feature information pushed by the invoicing ISV system, the type judgment unit distinguishes between automatic rejection types and manual rejection types. When it is determined to be an automatic rejection type, the actual rejection reason pushed by the invoicing ISV system is written back to the rejection reason field by the write-back execution unit; when it is determined to be a manual rejection type, the preset standard prompt information is written back to the rejection reason field by the write-back execution unit.

[0037] Optionally, based on the final actual rejection reason and application number obtained from the judgment, the system calls the pre-developed approval document interface to locate the corresponding approval document; the final actual rejection reason is written into the "Rejection Reason" field of the approval document through the interface, and the document status is updated to "Rejected" at the same time; after the write-back is completed, the system automatically sends a message notification (such as an in-system message or email) to the billing party, informing them that the invoice application has been rejected and the specific reason for rejection; the write-back log is recorded, including the application number, write-back reason, write-back time, write-back result, etc., for subsequent verification.

[0038] For example, the invoicing ISV system automatically rejects an invoicing application because "the real estate address cannot be empty." The pushed data shows "rejection operation type" as "auto" and "actual rejection reason" as "the real estate address cannot be empty!". The system determines this as an automatic rejection and ultimately writes the reason back as "the real estate address cannot be empty!", which is then synchronized to the rejection reason field of the approval document. The bill of lading holder can then directly see that a real estate address needs to be added when viewing the document.

[0039] Alternatively, if a staff member manually rejects an invoice application in the invoicing ISV system without specifying a reason for rejection, the "Rejection Operation Type" in the pushed data will be "manual," and the "Actual Rejection Reason" will be empty. The system will then determine that it was a manual rejection and ultimately write back the reason as "The corresponding invoice application status is invoicing failed, document rejected." This ensures that the written feedback is standardized.

[0040] Alternatively, manual input of rejection reasons can be used instead of automatic write-back, which has the advantages of low development difficulty and fast initial deployment.

[0041] In one example, the information display module supports at least one of the following display strategies: First display strategy, displaying the detailed form corresponding to the first business information subtype selected when filling out the form and containing filled data; Second display strategy, aggregating and displaying the detailed forms corresponding to all business information subtypes containing filled data in the form of tabs.

[0042] For example, the information display module supports at least one of the following display strategies: a first display strategy and a second display strategy. The first display strategy is used to display the detailed form corresponding to the first business information subtype selected when filling out the form and for which there is filled data. The second display strategy is used to aggregate and display the detailed forms corresponding to all business information subtypes for which there is filled data in the form of tabs.

[0043] Optionally, the display type matching mechanism includes: when the bill of lading holder submits an invoice application, the system records the specific business information subtype selected by the bill of lading holder and its corresponding data, storing it in the business object data table. Associated fields include the application number, the selected subtype code, the subtype name, and the data entered. When the approver opens the approval document, the system automatically queries the business object data corresponding to the application number and extracts the specific business information subtype selected by the bill of lading holder. Based on the preset display strategy (first display strategy / second display strategy), the system matches the corresponding display type. If no specific business information subtype is found, the parent business object information is displayed by default with the message "No specific business information available." Here, "business information subtype" refers to "specific business information subtype," which is the category corresponding to the detailed information that needs to be filled in for a specific business scenario (such as real estate leasing, real estate sales, construction services, etc.).

[0044] Optionally, the first display strategy refers to displaying the first business object type with data by default. The system queries all invoice-specific business information subtypes and data corresponding to the invoice application form, sorts them by the order of subtype selection, and filters out the first subtype with entered data; it automatically renders the form fields and entered data corresponding to this subtype, hides other subtypes with no data or those sorted later; and provides a "Switch Subtype" button, allowing approvers to manually view other subtype information.

[0045] The second display strategy refers to displaying all business object types with data by default. The system aggregates all invoice-specific business information subtypes with data corresponding to the invoice application form and displays them uniformly in tab or list format; each subtype is an independent tab, and the tab name is the subtype name. Clicking the tab allows you to view the corresponding entered data; subtypes without data are not displayed to ensure a clean interface; approvers can customize the tab sorting order.

[0046] Optionally, optimize the rendering logic of the approval interface to ensure that the data format of specific business information displayed by default is clear and the fields are aligned; support collapsing / expanding for long text fields; highlight key fields (such as real estate address and building project name) to improve the approver's attention; and support data export and printing to facilitate approval record keeping.

[0047] Alternatively, a fixed display strategy can be used instead of configurable display logic, which has the advantages of being simple to implement and having low development costs.

[0048] The system provided in this application embodiment supports at least one of the following display strategies in its information display module: a first display strategy, displaying the detailed form corresponding to the first business information subtype selected during form filling and containing filled data; and a second display strategy, aggregating and displaying the detailed forms corresponding to all business information subtypes containing filled data in a tab format. Therefore, the information display module can optimize the display logic of specific business information in the approval-state invoicing process, enabling the default display of the type selected during form filling. Through display type matching, data aggregation, and interface rendering, approval efficiency is greatly improved.

[0049] In one example, the row count control module includes: a type identification unit, used to identify whether the business category of the invoice application form belongs to the preset list of business categories with a limited row count; a quantity verification unit, used to count the number of rows filled in the corresponding business information details when it belongs to the list of business categories with a limited row count, and compare the number of rows filled in with the preset threshold; and a submission control unit, used to intercept the submission and output a prompt message when the number of rows filled in exceeds the preset threshold.

[0050] For example, the line count control module is responsible for imposing mandatory restrictions on the number of lines filled in for specific information in real estate leasing and real estate sales scenarios. Specifically, this includes business type identification, line count verification and submission interception to ensure that invoice applications comply with tax regulations.

[0051] The business type identification mechanism includes: when the bill of lading holder fills out the invoice application, they select a major business category (such as real estate leasing, real estate sales, construction services, etc.); the system matches the selected major business category code against a pre-defined list of business categories with limited line counts; if the match is successful (i.e., it belongs to a scenario requiring line count restrictions), the line count restriction verification function is automatically activated; if the match is unsuccessful, multiple lines are allowed to be filled freely according to normal logic. It also supports the use of tax codes and goods / service names to assist in identifying business types, ensuring accurate identification.

[0052] The line count verification and submission interception logic includes: when the bill of lading holder saves or submits the invoice application, the system triggers the line count verification process; if the verification result fails, the system automatically intercepts the submission process, pops up a prompt message on the interface, and informs the bill of lading holder that the number of lines to be filled needs to be adjusted; at the same time, it locates the specific information filling area and highlights the entries that exceed the line count limit; it supports the bill of lading holder to delete the extra lines with one click, improving the convenience of operation.

[0053] Alternatively, offline training can be used to fill in the required information instead of the system's line limit. The advantage is that no system development is required and the initial cost is low.

[0054] In one example, the preset list of business categories with the limited number of rows includes real estate leasing and real estate sales, with a preset threshold of one row.

[0055] For example, the preset list of business categories with limited number of rows includes real estate leasing business, real estate sales business, and other business categories that require limited number of rows, with a preset threshold of one row.

[0056] In one example, the system also includes a type matching module. This module monitors changes in the values ​​of custom file fields in the form-filling interface according to business rules, retrieves the corresponding business information subtypes based on the file mapping relationship, and automatically fills them in. The type matching module includes: a monitoring unit for real-time monitoring of changes in the values ​​of custom file fields in the approval system's form-filling interface; a query unit for querying preset file mapping relationships based on value changes to retrieve the corresponding business information subtypes; and a filling unit for automatically filling the retrieved business information subtypes into the business object component and loading the corresponding business information detail form.

[0057] For example, the system also includes a type matching module; the type matching module is used to automatically match the corresponding business information subtype and display it by default according to the specific business information subtype selected when filling out the invoice application form during the intelligent display stage of approval; at the same time, it displays the line limit verification result to assist the approver in quick review.

[0058] Specifically, the file value change monitoring mechanism includes: the system monitors changes to key file fields such as "special invoice type" in real time on the invoice application form interface; when the bill of lading holder selects or modifies the value of the "special invoice type" field, the business information subtype matching process is automatically triggered to obtain the currently selected file value (such as "real estate operation and leasing service invoice") and the corresponding code; if the bill of lading holder clears the field, the matched subtype information is automatically cleared.

[0059] The automatic matching logic for business information subtypes includes: based on the values ​​of the changed file fields obtained from monitoring, the system queries the preset file relationship dependency rule table to match the corresponding specific business information subtypes for invoicing; if a unique matching subtype is found, the subtype is automatically populated into the business object multi-select component, and the corresponding specific information form is loaded; if multiple matching subtypes are found, a list of subtypes is displayed for the bill of lading holder to select; if no matching subtype is found, the business object multi-select component remains empty, prompting the bill of lading holder to select manually.

[0060] Subtype population and form loading include: After the system automatically matches the subtypes and populates them into the multi-select component of the business object, it automatically loads the corresponding invoicing-specific business information form based on the subtype code, including form fields, field validation rules, and filling examples; if the bill of lading holder has any objection to the automatically matched subtypes, they can manually modify the selection, and the system will synchronously update the corresponding filling form after modification; a subtype matching log is recorded, including the application number, file value, matched subtype, and whether it was manually modified, for easy subsequent verification.

[0061] Optionally, a preset fixed mapping relationship can be used instead of dynamic file dependency matching. The advantages are that it is simple to implement and has a fast response speed. However, when adding special ticket types or subtypes, the system code needs to be modified in time to update the mapping relationship.

[0062] The system provided in this application embodiment further includes a type matching module. This module monitors changes in the values ​​of custom file fields in the form-filling interface according to business rules, obtains the corresponding business information subtypes based on the file mapping relationship, and automatically fills them in. The type matching module includes: a monitoring unit for real-time monitoring of changes in the values ​​of custom file fields in the form-filling interface of the approval system; a query unit for querying preset file mapping relationships based on value changes to obtain the business information subtypes corresponding to the current values; and a filling unit for automatically filling the obtained business information subtypes into the business object component and loading the corresponding business information detail form. Therefore, through the automatic subtype matching function based on file relationship dependencies, automatic association and matching of special invoice types and subtypes are achieved, reducing manual operations by bill of lading personnel and lowering the matching error rate. It supports visual rule configuration, improves system scalability, enhances configuration flexibility, and can quickly adapt to newly added invoicing business types for enterprises.

[0063] In one example, the integrated configuration module provides a visual configuration interface for configuring at least one of the following rules: rejection reason write-back rules, business information display rules, line count limit rules, and file mapping relationship rules; and the integrated configuration module also includes a synchronization unit for synchronizing configuration changes to each processing module in real time.

[0064] For example, the integrated configuration module provides a visual configuration interface for configuring at least one of the following rules: rejection reason write-back rules, business information display rules, line count limit rules, and file mapping relationship rules; and the integrated configuration module also includes a synchronization unit for synchronizing configuration changes to each processing module in real time. The rejection reason write-back rules, business information display rules, line count limit rules, and file mapping relationship rules are described in the above embodiments and will not be repeated here.

[0065] Optionally, during the exception handling and logging phase, the system monitors in real time any abnormalities in the interface data flow, rejection reason writing back, and line count verification, triggering corresponding alarm prompts; it also records detailed operation logs for the entire invoice application process, including form information, verification results, rejection reasons, and approval records, facilitating subsequent traceability and verification.

[0066] Figure 2 A flowchart illustrating a method for optimizing invoice application business information provided in this application is shown below. Figure 2 As shown, the method includes: Step S201: In response to the user's configuration operation, establish an interface connection between the invoicing ISV system and the approval system, and configure business rules.

[0067] Step S202: In response to the rejection event triggered by the invoicing ISV system, obtain the rejection reason through the interface connection, and write the rejection reason back to the approval document in the approval system according to the business rules.

[0068] Step S203: In response to the operation of displaying the invoice application form in the approval system, display the corresponding business information detail form according to the business rules and the selected business information subtype in the invoice application form.

[0069] Step S204: In response to the invoice application submission operation, identify the business category to which the invoice application belongs according to the business rules, and verify the number of lines to be filled in the business information details corresponding to the business category. If the verification fails, the submission is blocked.

[0070] The invoice application business information optimization method provided in the above embodiments of this application can be implemented through the above embodiments. Therefore, the specific working process and beneficial effects of the invoice application business information optimization method provided in the embodiments of this application will not be repeated here.

[0071] Corresponding to the above method, embodiments of this application also provide an invoice application business information optimization device, such as... Figure 3 As shown, the device includes: Configuration module 41 is used to respond to user configuration operations, establish an interface connection between the invoicing ISV system and the approval system, and configure business rules; The write-back module 42 is used to respond to the rejection event triggered by the invoicing ISV system, obtain the rejection reason through the interface connection, and write the rejection reason back to the approval document in the approval system according to the business rules; Display module 43 is used to respond to the operation of displaying the invoice application form in the approval system. Based on the business rules and the selected business information subtype in the invoice application form, it displays the corresponding business information detail form. The verification module 44 is used to respond to the invoice application submission operation, identify the business category to which the invoice application belongs according to the business rules, and verify the number of lines filled in the business information details corresponding to the business category. If the verification fails, the submission is blocked.

[0072] The functions of each functional unit of the invoice application business information optimization device provided in the above embodiments of this application can be implemented through the above methods and steps. Therefore, the specific working process and beneficial effects of each unit in the invoice application business information optimization device provided in the embodiments of this application will not be repeated here.

[0073] This application also provides an electronic device, such as... Figure 4As shown, it includes a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540.

[0074] Memory 530 is used to store computer programs; The processor 510 performs the above steps when executing the program stored in the memory 530.

[0075] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0076] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0077] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0078] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0079] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 2 The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0080] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the invoice application business information optimization method described in any of the above embodiments.

[0081] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the invoice application business information optimization method described in any of the above embodiments.

[0082] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0083] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0084] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0085] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0086] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0087] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims in this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. A system for optimizing invoice application business information, characterized in that, include: The integrated configuration module is used to establish the interface connection between the invoicing ISV system and the approval system, and to configure business rules; The rejection processing module is used to obtain the rejection reason triggered by the invoicing ISV system through the interface connection, and write the rejection reason back to the approval document in the approval system according to the business rules; The information display module is used to display the corresponding business information detail form according to the business rules and the selected business information subtype in the invoice application form when displaying the invoice application form; The line count control module is used to identify the business category to which the invoice application belongs according to the business rules when the invoice application is submitted, and to verify the number of lines to be filled in the business information details corresponding to the business category. If the verification fails, the submission will be blocked.

2. The system as described in claim 1, characterized in that, The rejection processing module includes: The reason receiving unit is used to receive rejection data pushed by the invoicing ISV system. The rejection data includes at least the application form identifier and the reason for rejection. The write-back execution unit is used to write the rejection reason into the rejection reason field of the corresponding approval document in the approval system.

3. The system as described in claim 2, characterized in that, The rejection processing module also includes: A type determination unit is used to determine the rejection operation type based on the rejection data; the rejection operation type includes automatic rejection type and manual rejection type; The write-back execution unit is used to write back the actual rejection reason pushed by the invoicing ISV system to the rejection reason field when the rejection type is determined to be automatic; and to write back the preset standard prompt information to the rejection reason field when the rejection type is determined to be manual.

4. The system as described in claim 1, characterized in that, The information display module supports at least one of the following display strategies: The first display strategy is to display the detailed form corresponding to the first business information subtype selected when filling out the form and for which there is data to be entered. The second display strategy is to aggregate and display detailed forms corresponding to all business information subtypes with entered data in the form of tabs.

5. The system as described in claim 1, characterized in that, The row number control module includes: The type identification unit is used to identify whether the business category of the invoice application form belongs to a preset list of business categories with a limited number of rows. The quantity verification unit is used to count the number of lines filled in the corresponding business information details when the business belongs to the restricted line count business category list, and compare the number of lines filled in with a preset threshold. The submission control unit is used to intercept the submission and output a prompt message when the number of lines filled exceeds the preset threshold.

6. The system as described in claim 5, characterized in that, The preset list of business categories with limited number of rows includes real estate leasing and real estate sales, and the preset threshold is one row.

7. The system as described in claim 1, characterized in that, The system also includes a type matching module; The type matching module is used to monitor changes in the values ​​of custom file fields in the form filling interface according to business rules, obtain the business information subtypes corresponding to the changed values ​​according to the file mapping relationship, and automatically fill them in. The type matching module includes: The monitoring unit is used to monitor the changes in the values ​​of custom file fields in the form filling interface of the approval system in real time. The query unit is used to query a preset file mapping relationship based on the value change and obtain the business information subtype corresponding to the current value; The fill unit is used to automatically fill the obtained business information subtypes into the business object component and load the corresponding business information detail form.

8. The system according to any one of claims 1-7, characterized in that, The integrated configuration module provides a visual configuration interface for configuring at least one of the following rules: Rules for writing back the reason for rejection, rules for displaying business information, rules for limiting the number of lines, and rules for mapping file relationships; Furthermore, the integrated configuration module also includes a synchronization unit, which is used to synchronize configuration changes to each processing module in real time.

9. A method for optimizing invoice application business information, characterized in that, The method includes: In response to user configuration operations, establish an interface connection between the invoicing ISV system and the approval system, and configure business rules; In response to a rejection event triggered by the invoicing ISV system, the rejection reason is obtained through the interface connection, and the rejection reason is written back to the approval document in the approval system according to the business rules; In response to the approval system's operation of displaying the invoice application form, the corresponding business information detail form is displayed according to the business rules and the selected business information subtype in the invoice application form; In response to the submission of an invoice application, the system identifies the business category to which the invoice application belongs based on the business rules, verifies the number of lines to be filled in the business information details corresponding to that business category, and blocks the submission if the verification fails.

10. An electronic device, characterized in that, The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of claim 9.

Images