Reimbursement risk prompt method and apparatus, and device, cluster and medium

Abstract

The present application relates to the field of computers. Provided are a reimbursement risk prompt method and apparatus, and a device, a cluster and a medium. The method comprises: a client sending a risk detection request when the client has detected that a user operates a reimbursement page for a reimbursement application displayed by the client, so as to trigger a detection trigger point, wherein when the roles of users and step nodes corresponding to client operations are different, the positions of detection trigger points arranged on the reimbursement page are also different, and therefore receiving occasions for receiving the risk detection request by a reimbursement management system are also different; the reimbursement management system receiving and managing the risk detection request, which is sent by the client; the reimbursement management system using a risk verification rule to verify reimbursement data of the reimbursement application on the basis of the risk detection request, so as to obtain risk prompt information; and the reimbursement management system sending the risk prompt information to the client, wherein the risk prompt information is used for indicating that there is one or more risks in the reimbursement data.

Description

Reimbursement risk warning method, device, equipment, cluster and medium

[0001] This application claims priority to the Chinese patent application with application number 202311739881.4 filed with the State Intellectual Property Office of China on December 15, 2023, and priority to the Chinese patent application with the invention name “Reimbursement Risk Warning Method, Device, Equipment, Cluster and Medium”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computers, and in particular to a reimbursement risk warning method, apparatus, device, cluster, and medium. Background Art

[0003] Reimbursement refers to the process by which employees receive financial compensation for expenses incurred due to business trips or other work-related needs. After submitting an application to the company and receiving approval, the company records the expenses in detail and submits relevant receipts. These expenses typically include transportation, accommodation, meals, and communication expenses. The company will review and approve employee reimbursement applications based on its policies and regulations and disburse the reimbursement within a specified timeframe.

[0004] In reimbursement scenarios, the entities (also called submitters) who claim reimbursement within enterprises and organizations vary. For example, employees, part-time employees, temporary employees within enterprises, doctors and nurses within hospitals, teachers and students within schools, freelancers, and civil servants all have reimbursement needs. For example, these individuals need to be reimbursed for travel expenses, such as transportation, accommodation, and food, while also requiring reimbursement for office space expenses, such as office supplies, office equipment, rent, and utilities. They also need to be reimbursed for conference expenses, such as venue rental, food, and transportation, incurred by organizing or attending meetings. They also need to be reimbursed for training expenses, such as tuition, accommodation, and transportation, incurred by participating in training courses. They also need to be reimbursed for publicity, promotional expenses, and gifts incurred by marketing activities. They also need to be reimbursed for medical expenses incurred due to work-related injuries or illnesses. They also need to be reimbursed for food and beverage expenses incurred while entertaining clients or partners on business trips. They also need to be reimbursed for fuel, maintenance, and parking fees incurred by purchasing or leasing official vehicles. At this time, the above-mentioned personnel are required to submit a reimbursement application as the submitter.

[0005] When making a reimbursement request, the reimbursement application submitted by the submitter may include one or more of the following reimbursement data: expense details, invoice information, reimbursement reason, payment method, travel itinerary information, payment records, basic information, etc. Among them, the expense details include information such as the time, location, expense item, amount, and purpose of reimbursement. The invoice letter includes the invoice number, invoice date, detailed description of the purchased items or services, amount, etc. The reimbursement reason includes the reason for the expense and necessary background information so that the approver can understand the rationality and necessity of the reimbursement. The payment method includes information such as the method of payment of the expense. Travel itinerary information: If it is a travel expense reimbursement, relevant information such as the time, location, transportation, and accommodation of the business trip is required. Basic information includes the number and department of the reimbursement requester and the approver.

[0006] To protect the interests of companies, hospitals, schools, and government departments, reviewers must verify reimbursement data. For example, they must verify the rationality, accuracy, and standardization of expense items and amounts, and check for duplications or anomalies. They must also verify the authenticity, legality, and completeness of invoices to ensure compliance with relevant policies and regulations. They must also verify the reasons provided by the claimant to determine the rationality and necessity of the expense. They must also verify the payment method and corresponding payment voucher to confirm the authenticity and legality of the expense. They must also query information such as the time, location, transportation, and accommodation of the business trip to determine compliance with relevant policies and regulations. They must also verify that the submitter's personal information is consistent with the information recorded by the company or organization. Reviewers can include supervisors, invoice signatories, financial auditors, and others.

[0007] The entire automated reimbursement process often involves multiple steps. These typically include the following: the submitter submits a reimbursement application, and the approver approves the application. As a company's organizational structure grows and the scope of reimbursements increases, the number of steps involved in reimbursement increases. For example, when a reimbursement request is submitted, there may be multiple steps involved. Approvals may include a supervisor, an invoice signatory, and a financial reviewer. In this case, the supervisor's approval of the reimbursement may involve multiple steps; the invoice signatory may also require multiple steps; and the financial reviewer may also require multiple steps.

[0008] As can be seen from the above description, reimbursement involves various roles, data, and verification processes. Each link must be closely linked to ensure a smooth reimbursement process. However, for large companies, the scale and complexity of the process make reimbursement even more complex. The entire reimbursement process involves submitters, approvers, accountants, and other personnel. These individuals, across various roles, must verify any issues with the reimbursement data. For example, the submitter must verify the reimbursement data to prevent it from being rejected by approvers and accountants after submission. Approvers and accountants must also review the reimbursement data to prevent erroneous reimbursements. Therefore, different roles and different reimbursement processes may have different risk alert requirements, and existing technologies cannot meet the requirements of intelligent risk alerts for different roles. Summary of the Invention

[0009] The present application provides a reimbursement risk warning method, device, equipment, cluster and medium, which can perform risk verification at different times according to different roles and step nodes, obtain risk warning information, and meet the requirements of risk intelligent warning for different roles and step nodes.

[0010] In a first aspect, a reimbursement risk warning method is provided. A client sends a risk detection request to a reimbursement management system, wherein the risk detection request is used to determine a risk warning for the client's operation. Specifically, the client sends a risk detection request upon detecting that a user has triggered a detection trigger point by operating on the reimbursement application page displayed by the client. Because the reimbursement page is different when at least one of the user role and the step node corresponding to the client operation is different, the detection trigger point is also located differently on the reimbursement page. Therefore, the timing at which the reimbursement management system receives the risk detection request is also different. The reimbursement management system receives the risk detection request from the management client. Based on the risk detection request, the reimbursement management system verifies the reimbursement data of the reimbursement application using risk verification rules to obtain risk warning information. The reimbursement management system sends the risk warning information to the client, wherein the risk warning information indicates the presence of one or more risks in the reimbursement data. The client receives the risk warning information from the reimbursement management system and displays it.

[0011] In the above solution, different detection trigger points can be set on the reimbursement page based on different roles and step nodes. Only when the detection trigger point is triggered will a risk detection request be sent to the reimbursement management system. Only when the reimbursement management system receives the risk detection request from the client will it verify the reimbursement data using risk verification rules. Therefore, risk verification can be performed at different times based on different roles and step nodes, meeting the requirements of intelligent risk notification for different roles and step nodes.

[0012] In some possible designs, the client sends a risk warning request to the reimbursement management system, wherein the risk warning request is used to determine the risk warning of the client operation. Specifically, the client sends a risk warning request when it detects that the user operates the reimbursement page of the reimbursement application displayed by the client to trigger the prompt trigger point. Since the reimbursement page is different when the user's role and at least one of the step nodes corresponding to the client operation are different, the position of the prompt trigger point set on the reimbursement page is also different, so the timing of receiving the risk warning request by the reimbursement management system is also different. The reimbursement management system receives the risk warning request sent by the management client and sends the risk warning information to the client. The client receives the risk warning information sent by the reimbursement management system.

[0013] In the above scheme, the detection trigger point and the prompt trigger point are set separately. By setting the detection trigger point and the prompt trigger point, more flexible risk verification and risk prompts can be achieved. For example, when the detection trigger point and the prompt trigger point are set together, instant detection and instant prompts can be achieved, which is suitable for occasions where the real-time requirements for prompts are relatively high. For another example, when the detection trigger point and the prompt trigger point are set separately, when the detection trigger point is triggered for risk verification, no risk prompt will be issued. The risk prompt will only be issued when the prompt trigger point is triggered. Therefore, the risk prompt can be issued at the appropriate time to avoid inappropriate risk prompts interfering with the user.

[0014] In some possible designs, the reimbursement page is generated based on the code of the reimbursement page, the position of the detection trigger point in the reimbursement page, and the position of the prompt trigger point in the reimbursement page. The code of the reimbursement page, the position of the detection trigger point in the reimbursement page, and the position of the prompt trigger point in the reimbursement page are obtained by querying a mapping table based on the role data and the step node data. The mapping table includes the correspondence between the role data, the step node data, the page code, the position of the detection trigger point in the reimbursement page, and the position of the prompt trigger point in the reimbursement page. The role data is used to indicate the role of the user in the reimbursement application, and the step node data is used to indicate the step node corresponding to the client operation.

[0015] In the above solution, by querying the mapping table, the page codes, detection trigger points and prompt trigger points corresponding to different step nodes of different roles can be quickly found, thereby generating different reimbursement pages.

[0016] In some possible designs, the role data includes one or more of submitter and approver.

[0017] When the role data is that of the submitter, the step data includes the Upload Invoice Identification step node, the View Reimbursement Details step node, the Submit Reimbursement step node, and the View Reimbursement List step node. The corresponding reimbursement pages generated include the Upload Invoice Identification page, the Reimbursement Details page, the Submit Reimbursement page, and the Reimbursement List page. The Upload Invoice Identification page is used to identify the invoice to obtain the reimbursement data for this reimbursement application. The Reimbursement Details page is used to display the reimbursement data for this reimbursement application. The Submit Reimbursement page is used to submit the reimbursement data for this reimbursement application. The Reimbursement List is used to record the submitter's multiple reimbursement applications, including this one.

[0018] When the role data is the approver, the step data includes one or more of an approval list step node and an approval detail step node. The corresponding reimbursement pages generated include an approval list page and an approval detail page. The approval list page is used to display the reimbursement applications that require approval by the approver, and the approval detail page is used to display the reimbursement data for a reimbursement application.

[0019] In some possible designs, before the client sends a risk detection request when it detects that the user operates the reimbursement page of the reimbursement application displayed by the client to trigger the detection trigger point, it is necessary to generate a reimbursement page first. The reimbursement page can be generated in the following way: the client sends the role data and the step node data to the reimbursement management system. Correspondingly, the reimbursement management system receives the role data and the step node data sent by the client. The reimbursement management system searches the mapping table according to the role data and the step node data to obtain the code of the reimbursement page, searches the mapping table according to the role data and the step node data to obtain the event of the object of the reimbursement page set by at least one of the detection trigger point and the prompt trigger point, and generates the reimbursement page according to the code of the reimbursement page and the event of the object of the reimbursement page set by at least one of the detection trigger point and the prompt trigger point.

[0020] In the above solution, detection trigger points and prompt trigger points can be set in events of objects on the reimbursement page. When a user operates an object on the reimbursement page and triggers a corresponding event, the corresponding response function will send at least one of a risk detection request and a risk prompt request. This improves the convenience of setting detection trigger points and prompt trigger points.

[0021] In some possible designs, the reimbursement page can be further generated in the following manner: the reimbursement management system obtains the code of the reimbursement page and parses the code to obtain multiple objects. The multiple objects include one or more of a text box, a check box, a radio button, a drop-down button, a button, a text area, an image, a link, a label, a table, a slider, a progress bar, a menu, a pop-up box, a video player, an audio player, a calendar, a carousel, a navigation bar, and a chart. Then, the reimbursement management system finds the object of the reimbursement page set with at least one of the detection trigger point and the prompt trigger point from the multiple objects as the target object, and adds a function of sending at least one of a risk detection request or a risk prompt request to the response function of the event of the target object to obtain a modified target object. The reimbursement management system generates the reimbursement page based on the modified target object.

[0022] In some possible designs, before using the risk verification rules to verify the reimbursement data of the reimbursement application according to the risk detection request and obtaining the risk warning information, it is necessary to configure the configurable items of the rule template to generate the risk verification rules. The risk verification rules are obtained by configuration using the rule template. The configurable items of the rule template include one or more of the main entities, auxiliary entities and output results of the risk verification rules. The main entity is the verification object of the risk verification rule, the auxiliary entity is the verification scope of the risk verification rule, and the output result is the verification result obtained by verification using the risk verification rule. The configurable items of the rule template also include detection trigger points and prompt trigger points.

[0023] In the above solution, risk verification rules can be generated by configuring the rule model, so that more risk verification rules can be generated with fewer templates, providing flexibility in risk verification rule generation to meet the needs of different occasions.

[0024] In some possible designs, the reimbursement management system matches the reimbursement data with at least one of the primary entity and the auxiliary entity based on the risk detection request. If a match occurs, the reimbursement data is verified using the risk verification rule to obtain the output result. If a match does not occur, the reimbursement data is not verified using the risk verification rule. The reimbursement management system generates the risk warning information based on the output result.

[0025] In the above solution, by setting the matching method of the detection trigger point and the risk verification rule, it is possible to perform risk verification on the reimbursement data using the appropriate risk verification rule at the appropriate time.

[0026] In some possible designs, the main entities include one or more of an invoice, a reimbursement form, an expense line, a subsidy line, a submitter, and an approver. The auxiliary entities include one or more of a blacklist, a whitelist, and an expense type. The reimbursement form includes one or more of the purpose of reimbursement, the reviewer's comments, and the name of the reimbursement form attachment. The expense line includes one or more of the expense type, the time when the expense was incurred, the location where the expense was incurred, the expense amount, the expense line description, and the name of the expense line attachment. The subsidy line includes one or more of the subsidy type, the time when the subsidy was incurred, the location where the subsidy was incurred, and the subsidy amount. The blacklist includes one or more first keywords. The whitelist includes one or more second keywords.

[0027] In the above solution, by setting the main entity and auxiliary entity, it is possible to perform risk verification on the reimbursement data for different verification objects and in different verification ranges.

[0028] In some possible designs, when the rule template is a blacklist or whitelist template, the configurable items of the blacklist or whitelist template include the main entity and the auxiliary entity. The reimbursement management system can configure the configurable items of the rule template to generate the risk verification rule in the following manner:

[0029] The reimbursement management system obtains a first primary entity and a first secondary entity of the blacklist and whitelist template input by the user through the client. The first primary entity belongs to the primary entity of the blacklist and whitelist template, the primary entity of the blacklist and whitelist template includes the reimbursement form and the expense line, and the first secondary entity belongs to the secondary entity of the blacklist and whitelist template, the secondary entities of the blacklist and whitelist template include the blacklist and the whitelist.

[0030] The reimbursement management system fills the first main entity and the first auxiliary entity of the blacklist and whitelist template into the rule template to obtain the first risk verification rule.

[0031] In the above solution, by setting the main entity and auxiliary entity of the blacklist and whitelist templates, blacklist verification or whitelist verification can be implemented for the reimbursement form or expense line.

[0032] In some possible designs, the blacklist further includes a blacklist input box and a blacklist switch, and the whitelist further includes a whitelist input box and a whitelist switch. The blacklist input box is used to input keywords for the blacklist, the whitelist input box is used to input keywords for the whitelist, the blacklist switch is used to select whether to use the blacklist, and the whitelist switch is used to select whether to use the whitelist. The reimbursement management system can use risk verification rules to verify reimbursement data and obtain risk warning information in the following manner:

[0033] When the blacklist switch is on and the whitelist switch is off, the first keyword in the blacklist is compared with the reimbursement data using the first risk verification rule. If the reimbursement data contains the first keyword in the blacklist, it is determined that the verification fails and the risk warning information is generated. Or,

[0034] When the blacklist switch is off and the whitelist switch is on, the second keyword in the whitelist is compared with the reimbursement data using the first risk verification rule. If the reimbursement data does not contain the second keyword in the whitelist, it is determined that the verification using the first risk verification rule fails and the risk warning information is generated. Or,

[0035] When the blacklist switch is turned on and the whitelist switch is turned on, the first keyword in the blacklist and the second keyword in the whitelist are respectively compared with the reimbursement data through the first risk verification rule. When the reimbursement data contains the first keyword in the blacklist and the reimbursement data does not contain the second keyword in the whitelist, it is determined that the verification using the first risk verification rule fails and the risk warning information is generated.

[0036] In the above solution, different processing logic can be implemented by setting the blacklist switch and the whitelist switch, thereby making some processing logic of the rule template configurable. In addition, different blacklists and whitelists can be entered through the blacklist input box and the whitelist input box.

[0037] In some possible designs, when the rule template is a consistent repeating template, the configurable items of the consistent repeating template include the main entity. The reimbursement management system configures the configurable items of the rule template to generate the risk verification rule, which may be:

[0038] The reimbursement management system obtains a second main entity of the consistency verification template input by the user through the client. The second main entity is a main entity of the consistency verification template, and the main entity of the consistency verification template includes an invoice, and the invoice includes one or more of a special value-added tax invoice, a general value-added tax invoice, an electronic general value-added tax invoice, a special value-added tax invoice, a general fixed-rate invoice, and a general machine-printed invoice.

[0039] The reimbursement management system fills the second main entity of the consistent repeat template into the rule template to obtain the second risk verification rule.

[0040] In the above solution, by configuring different main entities, duplicate verification can be performed on different invoices.

[0041] In some possible designs, the management system configures the configurable items of the rule template to generate the risk verification rules in the following manner: the management system configures the configurable items of the rule template to obtain configuration information, and then generates the risk verification rules using the low-code platform using the configuration information and the rule template.

[0042] In the above solution, risk verification rules are generated through a low-code platform. Therefore, risk verification rules can be generated by simply dragging and dropping the rule model and other configurations. Users do not need to perform programming, which improves the convenience of use and reduces the requirements for users.

[0043] In some possible designs, the risk warning information includes strong control risk warning information and weak control risk warning information, wherein the strong control risk warning information is used to remind the user that the risk warning information must be processed, and the weak control warning information is used to remind the user to pay attention to the risk warning information.

[0044] In the above solution, the risk warning information may include strong control risk warning information and weak control risk warning information. Different risk warning information has different risk control strengths, and users can flexibly select appropriate risk control strengths according to their needs.

[0045] In a second aspect, a method for generating a reimbursement page is provided. A client sends role data and step nodes to a reimbursement management system. The reimbursement management system, in turn, receives the role data and step nodes sent by the client. The role data represents the user's role in the reimbursement application, and the step node data represents the step nodes associated with the client's actions in the reimbursement application process.

[0046] The reimbursement management system searches the mapping table according to the role data and the step node data to obtain the code of the reimbursement page, searches the mapping table according to the role data and the step node data to obtain the event of the object of the reimbursement page set by at least one of the detection trigger point and the prompt trigger point, and generates a reimbursement page according to the code of the reimbursement page and the event of the object of the reimbursement page set by at least one of the detection trigger point and the prompt trigger point.

[0047] The reimbursement management system sends the reimbursement page to the client. Correspondingly, the client receives the reimbursement page sent by the reimbursement management system and displays the reimbursement page.

[0048] In a third aspect, a reimbursement risk warning device is provided, which includes a receiving unit, a verifying unit, and a sending unit.

[0049] The receiving unit is configured to receive a risk detection request sent by a client, wherein the risk detection request is used to determine a risk prompt for the client operation, and when the risk detection request differs in at least one of a user role and a step node corresponding to the client operation, a timing of receiving the risk detection request is also different.

[0050] The verification unit is configured to verify the reimbursement data of the reimbursement application using risk verification rules according to the risk detection request to obtain risk warning information.

[0051] The sending unit is configured to send the risk warning information to the client, wherein the risk warning information is used to indicate that the reimbursement data has one or more risks.

[0052] In a fourth aspect, a reimbursement page generation device is provided, which includes a receiving unit, a generating unit, and a sending unit.

[0053] The receiving unit is used to receive role data and step nodes sent by the client, wherein the role data is used to represent the role of the user in the reimbursement application, and the step node data is used to represent the step nodes of the client's operation in the process of the reimbursement application.

[0054] The generation unit is used to search the mapping table according to the role data and the step node data to obtain the code of the reimbursement page, set at least one of the detection trigger point and the prompt trigger point at the location of the reimbursement page, and generate the reimbursement page according to the code of the reimbursement page and at least one of the detection trigger point and the prompt trigger point at the setting location of the reimbursement page.

[0055] The sending unit is used to send the reimbursement page to the client.

[0056] In a fifth aspect, a computing device is provided, comprising: a processor and a memory, wherein the memory is used to store instructions, and the processor is used to run the instructions in the memory to execute the steps performed by the client or the reimbursement management device in the first aspect or the second aspect.

[0057] In a sixth aspect, a computing cluster is provided, comprising a plurality of computing devices, wherein each computing device comprises a processor and a memory, the memory being used to store instructions, and the processor being used to run the instructions in the memory to execute the steps performed by the client or the reimbursement management device in the first aspect or the second aspect.

[0058] In a seventh aspect, a computer-readable storage medium is provided, comprising instructions, which, when executed by a computing device, execute the steps performed by the client or the reimbursement management device in the first aspect or the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] FIG1 is an architecture diagram of a reimbursement risk reminder system provided by this application;

[0060] FIG2 is a flow chart of a risk verification method provided by the present application;

[0061] FIG3 is a flow chart of a method for generating a reimbursement page provided by the present application;

[0062] FIG4 is a schematic diagram of an invoice identification page uploaded by the present application;

[0063] FIG5 is a schematic diagram of a reimbursement details page provided by this application;

[0064] FIG6 is a schematic diagram of a reimbursement submission page provided by the present application;

[0065] FIG7 is a schematic diagram of a reimbursement list page provided by the present application;

[0066] FIG8 is a schematic diagram of an approval list page provided by this application;

[0067] FIG9 is a schematic diagram of an approval details page provided by this application;

[0068] FIG10 is a schematic diagram of a fee details page provided by this application;

[0069] FIG11 is a schematic diagram of a configuration of a test range in a rule template provided by the present application;

[0070] FIG12 is a schematic diagram of a configuration of a detection trigger point and a prompt trigger point provided by the present application;

[0071] FIG13 is a schematic diagram of the configuration of the main entity and auxiliary entity of a blacklist and whitelist template provided by the present application;

[0072] FIG14 is a schematic diagram of a configuration of output results provided by the present application;

[0073] FIG15 is a schematic diagram of a risk verification rule output by a low-code platform provided in this application;

[0074] FIG16 is a schematic diagram of a mutually exclusive repeat template in a repeat check template provided by the present application;

[0075] FIG17 is a schematic diagram of a consistency repeat template in a repeat check template provided by the present application;

[0076] FIG18 is a schematic diagram of the configuration of an invoice authenticity verification in an invoice verification template provided by the present application;

[0077] FIG19 is a schematic diagram of the configuration of an invoice serial number verification of an invoice verification template provided by the present application;

[0078] FIG20 is a schematic diagram of an invoice header tax number verification of an invoice verification template provided by this application;

[0079] FIG21 is a schematic diagram of the structure of a reimbursement risk reminder system provided by the present application;

[0080] FIG22 is a schematic diagram of the structure of a reimbursement page generation system provided by the present application;

[0081] FIG23 is a schematic diagram of the structure of a computing device provided by the present application. DETAILED DESCRIPTION

[0082] The present application provides a reimbursement risk reminder system that can generate a reimbursement page based on the user's role in the reimbursement process (for example, submitter and approver), the step node of the reimbursement process (for example, filling in reimbursement data, submitting reimbursement data, approving reimbursement data, etc.), and the configured detection trigger points and prompt trigger points. In different reimbursement pages, different detection trigger points and prompt trigger points are set according to the needs of different reimbursement pages. When the user operates the reimbursement process page and triggers the detection trigger point, the reimbursement data of the reimbursement application is risk-checked according to the pre-set risk verification rules to generate risk warning information. When the user operates the reimbursement page and triggers the prompt trigger point, the risk warning information is displayed, thereby realizing a risk warning method that distinguishes user roles and process steps. In addition, trigger points and reminder points can be set as needed to avoid risk verification and risk reminders at inappropriate times.

[0083] To facilitate understanding, we first introduce the architecture of the reimbursement risk reminder system in detail.

[0084] See Figure 1, which is an architecture diagram of a reimbursement risk reminder system provided by this application. As shown in Figure 1, the architecture includes a client 100 and a reimbursement management system 200, wherein a communication connection exists between the client 100 and the reimbursement management system 200, which can be a wired connection or a wireless connection, which is not specifically limited in this application. In addition, the number of clients 100 that establish a communication connection with the reimbursement management system 200 can be one or more, which is not specifically limited in this application.

[0085] The client 100 is used to implement human-computer interaction and can be deployed on a terminal device or computing device. The terminal device includes a personal computer, a smart phone, a wearable device, a handheld processing device, a tablet computer, a mobile notebook, an augmented reality (AR) device, a virtual reality (VR) device, an integrated handheld device, a wearable device, a vehicle-mounted device, an intelligent conference device, an intelligent advertising device, a smart home appliance, etc. The smart home appliance can be a sweeping robot, a mopping robot, etc., which is not specifically limited here.

[0086] In a specific implementation, the above-mentioned client 100 can be implemented in the form of software such as an application (APP) or plug-in running on a hardware device such as a terminal device or computing device controlled by the user, such as a personal computer (PC) client, or a web client accessed based on a browser, or an application (APP) client running on a mobile terminal, or a console of a cloud platform. This application does not make any specific limitations.

[0087] Client 100 can be used to implement a reimbursement risk reminder function. Client 100 can function as both a submitter and an approver, or it can function solely as a submitter or approver, without specific limitations in this application. Approver can be a supervisor, accountant, auditor, or the like.

[0088] Optionally, in addition to being deployed on a hardware device, the client 100 can also be implemented on a cloud platform. For example, the client 100 can be deployed in a virtualized entity such as a virtual machine or container. The reimbursement management system 200 can be deployed on a single computing device, a computing device cluster consisting of multiple computing devices, an edge device, or a terminal device, where the computing device includes a bare metal server (BMS), a virtual machine, a container, or an edge computing device. BMS refers to a general physical server, such as an ARM server or an X86 server; a virtual machine refers to a complete computer system with complete hardware system functions that is simulated by software and runs in a completely isolated environment. Any work that can be done in a physical computer can be done in a virtual machine.

[0089] The reimbursement management system 200 can provide the client 100 with reimbursement risk reminder services, reimbursement risk data viewing services, reimbursement risk data viewing service statistics, and reimbursement management services, etc. Among them, the reimbursement risk reminder service is used to use risk verification rules to verify the reimbursement data and issue reminders when the user submits a reimbursement application through the client. The reimbursement risk data viewing service is used to use risk verification rules to verify the reimbursement data when the user submits a reimbursement application through the client, and send the reimbursement data with risks to the user for review. The reimbursement risk statistics service is used to use risk verification rules to verify the reimbursement data when the user submits a reimbursement application through the client, and count the reimbursement data with risks. The reimbursement management service may include one or more of the above services. In addition, the reimbursement management service may also provide services such as reimbursement data storage and management.

[0090] Optionally, the reimbursement management system 200 can be deployed on the same terminal device as the client 100; or, the reimbursement management system 200 is deployed on a computing device, and the client 100 is deployed on a terminal device; or, the reimbursement management system 200 is deployed on a computing device cluster, and the client 100 is deployed on a terminal device. It should be understood that the above examples are for illustration only, and the specific deployment of the reimbursement management system 200 and the client 100 can be determined based on the actual application scenario.

[0091] Among them, in order to make this application easier to understand, Figure 1 only shows three clients 100 establishing communication connections with the reimbursement management system 200. In fact, the number of clients establishing communication connections with the reimbursement management system 200 is less or more, and the steps for other clients to communicate with the reimbursement management system 200 are the same as those of the client 100, and will not be repeated here.

[0092] The structure of the reimbursement risk reminder system has been introduced in detail above. The following will introduce how the reimbursement risk reminder system shown in Figure 1 implements risk reminders in combination with specific process steps.

[0093] Refer to Figure 2, which is a flow chart of a risk verification method provided by the present application. As shown in Figure 2, the risk verification method of the present application includes the following steps:

[0094] S101: The client sends a risk detection request to the reimbursement management system. Correspondingly, the reimbursement management system receives the risk detection request sent by the client.

[0095] The risk detection request is sent by the client when it detects that the user's operation on the reimbursement page has triggered a detection trigger point.

[0096] The reimbursement page is one or more pages displayed on the client during the reimbursement process. The reimbursement page can be a page generated in Hypertext Markup Language (HTML) code based on the user's role and the step node in the reimbursement process. User roles can include submitter, approver, etc. The submitter is the person who submits the reimbursement application, and the approver is the person who approves the reimbursement application. The step node can be a node in the reimbursement application process.

[0097] Different roles can have different step nodes. The following uses the roles of submitter and approver as examples to illustrate the differences in their step nodes.

[0098] When the role is the submitter, the step nodes may include the upload invoice identification step node, the view reimbursement details step node, the submit reimbursement step node, the view reimbursement list step node, and the like. The upload invoice identification step node is used to upload the invoice image of this reimbursement application, identify part or all of the reimbursement data from the invoice image, or manually enter the reimbursement data. The view reimbursement details step node is used to view the reimbursement data of this reimbursement application, modify the reimbursement data, or add reimbursement data. The submit reimbursement step node is used to submit the reimbursement data of this reimbursement application to the approver. The view reimbursement list step node is used to view the reimbursement data of the reimbursement applications that have been submitted (including this reimbursement application). It can be understood that the above step nodes can be executed in sequence, that is, first enter the upload invoice identification step node, then enter the view reimbursement details step node, then enter the submit reimbursement step node, and then enter the view reimbursement list step node. It is also possible to skip some of the step nodes and enter the next step node. For example, the upload invoice identification step node, the view reimbursement details step node, the submit reimbursement step node, and enter the view reimbursement list step node can be skipped. After the submitter's step node is completed, the reimbursement process for this reimbursement application enters the approver's step node.

[0099] When the role is an approver, the step nodes may include the approval list step node, the approval details step node, the expense details step node, and so on. Among them, the approval list step node is used to display multiple reimbursement applications including the current reimbursement application, the approval details step node is used to display part of the reimbursement data of the current reimbursement application, and the reimbursement details are used to display more specific reimbursement data in the current reimbursement application. It can be understood that the above step nodes can be executed in sequence, that is, first enter the approval list step node, then enter the view approval details step node, and then enter the expense details step node. It is also possible to skip some of the step nodes and enter the next step node. For example, you can skip the approval details step node and enter the view expense details step node.

[0100] In the above example, the step nodes of the approver are executed only after the step nodes of the submitter are completed. However, in actual applications, the step nodes of the submitter and the step nodes of the approver can also be interspersed. For example, a part of the step nodes of the submitter can be executed first, and then a part of the step nodes of the approver can be executed. Then, the remaining step nodes of the submitter can be executed, and finally the remaining step nodes of the approver can be executed.

[0101] Different roles and different step nodes can generate different reimbursement pages. For example, when the role is the submitter, the step nodes are the upload invoice identification step node, the view reimbursement details step node, the submit reimbursement step node, the view reimbursement list step node, etc., and the reimbursement pages correspond to the upload invoice identification page, the reimbursement details page, the submit reimbursement page, the reimbursement list page, etc. When the role is the approver, the step nodes are the approval list step node, the approval details step node, the expense details step node, etc., and accordingly, the reimbursement pages correspond to the approval list page, the approval details page, the expense details page, etc. These reimbursement pages will be introduced in detail below and will not be described in detail here.

[0102] The reimbursement page can be generated using Hypertext Markup Language (HTML) code. Therefore, interpreting the HTML code of the reimbursement page can obtain one or more objects, which may include a text input, a checkbox, a radio button, a drop-down button, a button, a text area, an image, a link, a label, a table, a slider, a progress bar, a menu, a modal, a video player, an audio player, a calendar, a carousel, a navigation bar, a chart, etc. It is understood that the objects included in the HTML code of the reimbursement page are merely specific examples. In actual applications, more or fewer objects may be included, and this is not specifically limited here. It is understood that different reimbursement pages generated according to different roles and different step nodes may include completely different objects, partially identical objects, or completely identical objects.

[0103] An object can include one or more events. An object's events can include click events, mouse hover events, mouse leave events, keyboard press events, keyboard release events, focus events, and focus loss events, among others. Events for different objects can be the same or different. For example, the events for a "list" object and a "text box" object are the same. When the object is a text box, the text box's events can include one or more of the following: click events, edit events, delete events, save events, mouse hover events, mouse leave events, keyboard press events, keyboard release events, focus events, and focus loss events. When the object is a list, the text box's events can include one or more of the following: click events, edit events, delete events, save events, mouse hover events, mouse leave events, keyboard press events, keyboard release events, focus events, and focus loss events. For another example, the events for a "button" object and a "text box" object are different. When the object is a button, the button's events can include one or more of the following: click events, mouse hover events, mouse leave events, keyboard press events, keyboard release events, focus events, and focus loss events, among others. When the object is a text box, the events of the text box may include one or more of click events, edit events, delete events, save events, mouse hover events, mouse leave events, keyboard press events, keyboard release events, focus events, out-of-focus events, and the like.

[0104] The detection trigger point can be set in one or more events of one or more objects in the reimbursement page. For example, to set a detection trigger point in an event of an object on a reimbursement page, it is necessary to add a function of sending a risk detection request to the reimbursement management system in the response function of the event of the object on the reimbursement page. Therefore, when the client detects that the user performs the corresponding operation of the event on the object on the reimbursement page, it will execute the corresponding response function and send a risk detection request to the reimbursement management system. Different reimbursement pages can set detection trigger points in the same event of the same object, can set detection trigger points in different events of the same object, and can set detection trigger points in different events of different objects.

[0105] In summary, there is a corresponding relationship between role data, step node data, reimbursement page, detection trigger point, and prompt trigger point. For example, Table 1 is a specific embodiment of a mapping table of role data, step node data, reimbursement page, detection trigger point, and prompt trigger point, which can reflect the corresponding relationship between role data, step node data, reimbursement page, detection trigger point, and prompt trigger point.

[0106] Table 1 Mapping table of role data, step node data, reimbursement page, detection trigger point, and prompt trigger point

[0107] It can be understood that Table 1 is only an example of a specific mapping table. In actual applications, it can include more or less role data and step node data. Therefore, it can include more or fewer reimbursement pages. The data of the detection trigger points and prompt trigger points in each reimbursement page can be more or less. The detection trigger points and prompt trigger points can also be set in the events of other objects, which are not specifically limited here. It can be seen from Table 1 that different detection trigger points and prompt trigger points can be set on different reimbursement pages. Some reimbursement pages may only have prompt trigger points, and some reimbursement pages may have both detection trigger points and prompt trigger points. Even if two reimbursement pages have detection trigger points and prompt trigger points, the events of the objects set for the detection trigger points and prompt trigger points set on the two reimbursement pages may be different.

[0108] The risk detection request can be a trigger signal. That is, when the reimbursement management system receives the risk detection request, it will verify the reimbursement data using risk verification rules. Optionally, the risk detection request can include some or all of the reimbursement data. Alternatively, the client can first send a risk detection request to the reimbursement management system as a trigger signal for verification using risk verification rules, and then send some or all of the reimbursement data to the reimbursement management system via other messages.

[0109] S102: The reimbursement management system obtains reimbursement data.

[0110] The reimbursement data may be data in the reimbursement application submitted by the submitter, such as invoices, reimbursement forms, expense lines, subsidy lines, submitters, approvers, and the like.

[0111] Invoices can be stored in the form of images, or, after image recognition, invoice information such as invoice header tax number, invoice header, invoice code, invoice number, invoice date, purchaser information, seller information, product or service information, tax rate, tax amount, price-tax total, remarks, and invoice authentication code can be stored in the form of an array or structure.

[0112] An expense report includes the information of the reimburser, the reimbursement date, the expense report number, the reimbursement item, the amount, the invoice and accompanying documents, the reason for the reimbursement, the reimbursement approval, the reimbursement method, the reimbursement account number, remarks, the total reimbursement amount, etc. An expense report can be stored in text, array, or structure formats.

[0113] Expense lines and subsidy lines are key data related to expenses and subsidies in reimbursement applications. Expense lines can include expense type, expense incurred time, expense incurred location, expense amount, expense line description, reimbursement purpose, and more.

[0114] The subsidy line may include subsidy type, subsidy occurrence time, subsidy occurrence location, subsidy amount, subsidy line description, etc. Here, the expense line and subsidy line may be stored in text format, array, structure, etc.

[0115] It is understandable that the above reimbursement data is only used as an example. In actual application, more or less reimbursement data may be included, and no specific limitation is made here.

[0116] Reimbursement data can be entered on the reimbursement page. The following will provide a detailed introduction to the following two methods.

[0117] In the first method, all reimbursement data can be entered on the reimbursement page corresponding to one of the step nodes. For example, if the reimbursement data only includes invoices and expense lines, the invoices and expense lines can be entered on the Upload Invoice Identification step page, and no reimbursement data is entered on other reimbursement pages.

[0118] In the second method, reimbursement data can be entered partially on the reimbursement page corresponding to one step node, and partially on the reimbursement page corresponding to another step node, and so on. For example, when the reimbursement data includes invoices, expense lines, and subsidy lines, the invoices and expense lines can be entered on the Upload Invoice Identification step page, while the subsidy lines can be entered on the Reimbursement Details page.

[0119] It can be understood that the above two methods are only used as a specific example. In actual applications, more methods can be used. For example, the reimbursement data can be entered on the reimbursement page corresponding to one step node, and the reimbursement data can be modified on the reimbursement page corresponding to another step node, and so on.

[0120] In a specific embodiment, reimbursement data can be entered into an object on the reimbursement page, such as a text box, checkbox, drop-down button, etc. For example, the expense line's expense type, expense incurred time, expense incurred location, expense amount, expense line description, reimbursement purpose, etc. can be entered via a text box or list, or an invoice image can be entered via an image. It is understood that the object used to enter reimbursement data and the object used to set the detection trigger point can be the same object or different objects. For example, an expense line can be entered via a text box, and a detection trigger point can be set in a response function corresponding to the save event of the text box where the expense line is entered. Then, when the client detects that the user has entered the expense line in the text box and saved the expense line, the detection trigger point can be triggered. If the expense line also matches the risk verification rules, the risk verification rules can be used to verify the expense line. For another example, an expense line can be entered via a text box, and a trigger point can be set in a response function corresponding to the click event of a "Submit Application" button. Then, when the client detects that the user has clicked the "Submit Application" button, the detection trigger point can be triggered. If the expense line also matches the risk verification rules, the risk verification rules can be used to verify the expense line.

[0121] Reimbursement data and risk detection requests can be generated on the reimbursement page of the same step node of the same role (hereinafter referred to as the same reimbursement page), or the reimbursement data can be generated in the reimbursement page corresponding to the previous step node of the same role or a different role, and the risk detection request can be generated in the reimbursement page corresponding to the subsequent step node of the same role or a different role (hereinafter referred to as different reimbursement pages). When the reimbursement data and the risk detection request are generated on the same reimbursement page, the reimbursement data can be carried in the risk detection request and sent, or the risk detection request can be sent and then the reimbursement data. When the reimbursement data and the risk detection request are generated on different reimbursement pages, the reimbursement data can be sent to the reimbursement management system first, and then the risk detection request can be sent to the reimbursement management system.

[0122] S103: The reimbursement management system verifies the reimbursement data using risk verification rules matched with the reimbursement data to obtain risk warning information.

[0123] Upon receiving a risk detection request, the reimbursement management system triggers the use of risk verification rules to verify the risk detection request. First, the reimbursement management system obtains the first risk verification rule stored in the reimbursement management system and matches the first risk verification rule with the reimbursement data. If the match is successful, the reimbursement data is verified using the first risk verification rule to obtain an output result. If the match is unsuccessful, the reimbursement data is not verified using the first risk verification rule. The reimbursement management system then obtains the second risk verification rule stored in the reimbursement management system and repeats the process, and so on, until the last risk verification rule stored in the reimbursement management system is completed. Finally, the reimbursement management system generates risk warning information based on the output results of the matched risk verification rules. The risk warning information is used to indicate which risk verification rules are risky.

[0124] Risk verification rules are used to verify the legality and rationality of reimbursement data. These rules can include verification of reimbursement limits, reimbursement time, reimbursement form, invoice authenticity, invoice serial number, invoice header tax number, reimbursement reason, reimbursement data matching, social expense verification, mutually exclusive duplication, consistent duplication, blacklist, and whitelist verification. Risk verification rules primarily consist of four components: primary entities, secondary entities, processing logic, and output results. Primary entities are the verification targets, such as invoices, reimbursement forms, expense lines, subsidy lines, submitters, and approvers. Secondary entities are the verification scope, including blacklists, whitelists, expense types, and invoice verification ranges. Expense types can include business expenses, office supplies, training expenses, and travel expenses. Processing logic encompasses the specific processing logic for the verification, such as comparing the verification range with the reimbursement data and matching keywords with the reimbursement data. The output result is the output result of verification passing or verification different outdated. Because some risk verification rules do not have risks when the verification passes, and some risk verification rules do not have risks when the verification fails, the output result needs to be configured.

[0125] Risk verification rules can be generated by configuring rule templates. Different risk verification rules can be obtained by using different configurations of rule templates. Among them, the rule template is a template obtained by abstracting the risk verification rules. Since different risk verification rules may have the same or partially the same processing logic, the same or partially the same processing logic can be abstracted to obtain a rule template. Then, by configuring different main entities, auxiliary entities, output results, and even part of the processing logic, different risk verification rules can be obtained. Of course, different rule templates can configure different parts. For example, some rule templates can configure the main entity and auxiliary entities, some rule templates can configure the main entity and output results, and some rule templates can only configure the main entity, etc., which are not specifically limited here.

[0126] When performing a risk verification rule validation, the reimbursement data is compared with the primary entity and auxiliary entities of the risk verification rule. If the reimbursement data matches the primary entity and auxiliary entities of the risk verification rule, then the risk verification rule and the reimbursement data match. The reimbursement data can then be processed using the risk verification rule's processing logic to determine whether the reimbursement data is risky and generate an output indicating whether the reimbursement data is risky. More specifically, during the validation, a determination can be made as to whether the reimbursement data falls within the validation range indicated by the auxiliary entities in the risk verification rule. If not, the reimbursement data is deemed to not match the risk warning rule, and the next risk verification rule is retrieved or the risk verification ends. If within the validation range, a determination is then made as to whether the reimbursement data includes the primary entity in the risk verification rule. If not, the reimbursement data is deemed to not match the risk warning rule, and the next risk verification rule is retrieved or the risk verification ends. If the primary entity is included, the reimbursement data is processed using the risk verification rule's processing logic to determine whether the reimbursement data is risky and generate an output indicating whether the reimbursement data is risky. It can be understood that the above verification process is only a specific example. In actual applications, it is also possible to first determine whether the reimbursement data includes the main entity of the risk verification rule, and then determine whether the reimbursement data is within the verification range indicated by the auxiliary entity of the risk verification rule. Finally, the processing logic of the risk verification rule is used to process the reimbursement data to obtain the input result.

[0127] Since the risk verification rules are generated by configuring the rule templates through the low-code platform, the reimbursement data can be obtained through the rule engine of the low-code platform. Then, the obtained reimbursement data is matched with the risk verification rules. In the case of a match, the processing logic of the risk verification rules is used to process and obtain the output results. The reimbursement management system generates risk warning information based on the output results and stores it in the reimbursement management system. The rule engine mainly verifies the reimbursement data through risk verification rules through conditional judgment, regular expressions, value range judgment, etc. It can be understood that one or more of conditional judgment, regular expressions, and value range judgment can be used in combination in the risk verification rules.

[0128] The following example illustrates the process of verifying reimbursement data using one of the risk verification rules. Assume that the reimbursement data includes expense line 1, which includes expense type 1, reimbursement purpose 1, and so on. Expense type 1 is a social entertainment expense, and reimbursement purpose 1 is "Communicating with clients for industry consultation." The primary entity of the risk verification rule includes the reimbursement purpose of the expense line, and the secondary entity includes the expense type "social entertainment expense." The processing logic matches the content of the primary entity with the keyword "gold" in the blacklist. If the content of the primary entity matches the keyword in the blacklist, the output result is "failed verification," indicating a risk. If the content of the primary entity does not match the keyword in the blacklist, the output result is "passed verification," indicating no risk. Therefore, the reimbursement management system can first match the primary entity of the risk verification rule with the reimbursement data. Since the primary entity of the risk verification rule is the reimbursement purpose of the expense line, and the reimbursement data also includes the reimbursement purpose of the expense line, the two are matched. The reimbursement management system then determines whether the reimbursement data falls within the validation range indicated by the auxiliary entity in the risk validation rule. Since the expense type in the reimbursement data is entertainment expenses, and the validation range for the auxiliary entity in the risk validation rule is also entertainment expenses, the two are a match. Therefore, the reimbursement management system determines that the reimbursement data matches the risk validation rule and uses the risk validation rule's processing logic to verify whether the blacklisted keyword "gold" exists in the expense line's reimbursement purpose. Because the reimbursement purpose, "Communicating with clients for industry consultation," does not contain the blacklisted keyword "gold," the validation passes, indicating no risk.

[0129] It can be understood that the above example only illustrates the implementation process of a risk verification rule. In the application, more risk verification rules will be stored in the reimbursement management system. The execution process of different risk verification rules may be slightly different, which will not be explained in detail here.

[0130] S104: The client sends a risk warning request to the reimbursement management system. Correspondingly, the reimbursement management system receives the risk warning request sent by the client.

[0131] The risk warning request is sent by the client when it detects that the user's operation on the reimbursement page has triggered a warning trigger point. The warning trigger point can be set in one or more events of one or more objects in the reimbursement page. For example, to set a warning trigger point in an event of an object on a reimbursement page, it is necessary to add a function of sending a risk warning request to the reimbursement management system in the response function of the event of the object on the reimbursement page. Therefore, when the client detects that the user performs the corresponding operation of the event on the object on the reimbursement page, it will execute the corresponding response function to send a risk warning request to the reimbursement management system. It can be understood that for different reimbursement pages, the warning trigger point can be set in the same event of the same object, the warning trigger point can be set in different events of the same object, and the warning trigger point can be set in different events of different objects.

[0132] The setting of the prompt trigger point can be related to the detection trigger point, or it can be unrelated. The following will describe these two situations in detail.

[0133] In the first approach, the prompt trigger and the detection trigger are related. For example, the prompt trigger and the detection trigger can be set in the same event of the same object on the same reimbursement page. In this case, the response function of the object's event includes the functions of sending risk detection requests and risk warning requests. Therefore, the risk detection request and risk warning request can be sent simultaneously.

[0134] In the second way, the setting of the prompt trigger point and the detection trigger point are unrelated. For example, the prompt trigger point and the detection trigger point can be set in the events of different objects on the same reimbursement page or different reimbursement pages. More specifically, take the example of setting the detection trigger point in the event of the first object on the same reimbursement page and setting the prompt trigger point in the event of the second object on the same reimbursement page. Therefore, when the client detects the user operation and triggers the event of the first object on the reimbursement page, it will trigger the response function of the event of the first object accordingly, and the response function of the event of the first object includes the function of sending a risk detection request. When the client detects the user operation and triggers the event of the second object on the reimbursement page, it will trigger the response function of the event of the second object accordingly, and the response function of the event of the second object includes the function of sending a risk warning request.

[0135] It can be understood that the settings of detection trigger points and prompt trigger points in the same reimbursement page may have only related settings or unrelated settings, or may have both related settings and unrelated settings at the same time, which is not specifically limited here.

[0136] S105: The reimbursement management system sends risk warning information to the client. Correspondingly, the client receives the risk warning information sent by the reimbursement management system.

[0137] The risk warning information may include the output results obtained by using the risk verification rules. In addition, the risk warning information may also include the legal provisions corresponding to the risk verification rules, modification suggestions, reasons for failure of verification, etc.

[0138] The risk warning information is sent when the reimbursement management system receives a risk warning request. Here, the risk warning request can be a trigger signal, that is, when the reimbursement management system receives the risk warning request, it will know that it needs to use the corresponding risk verification rules to verify the previously received risk detection request stored in the reimbursement management system and return the risk warning information obtained to the client. For example, the first risk detection request is triggered and sent on the invoice identification page, and the reimbursement data is verified according to the first risk detection request to obtain the first risk warning information. The second risk detection request is triggered and sent on the reimbursement details page, and the reimbursement data is verified according to the second risk detection request to obtain the second risk warning information. If the reimbursement data with risks has not been corrected, then when the reimbursement management system receives the risk warning request triggered and sent by the client in the reimbursement submission page, it will send the first risk warning information and the second risk warning information to the client.

[0139] If the risk detection request and risk warning request are related, they are sent simultaneously. Upon receiving the risk detection request, the reimbursement management system processes the reimbursement data using risk validation rules to generate risk warning information. This information is then returned to the client, prompting the user to make changes. This provides real-time risk warnings.

[0140] If the risk detection request and the risk warning request are unrelated, the reimbursement management system will verify the reimbursement data using risk verification rules after receiving the risk detection request. If a risk exists, it will generate and store risk warning information within the reimbursement management system. The reimbursement management system will only return the risk warning information to the client for display after receiving the risk warning request. This allows risk verification and risk warning to be separated, making it suitable for situations where real-time risk warning display is not necessary, and preventing users from being distracted by risk warning information.

[0141] It's understandable that risk detection requests and risk warning requests can be triggered repeatedly. For example, suppose the client detects that a user has entered an expense line on the invoice upload page, triggering the expense line detection trigger point. This triggers a risk detection request. The reimbursement management system verifies the reimbursement data using risk validation rules based on the risk detection request, generates risk warning information, and then sends the risk warning information to the client. After viewing the risk warning information, the user modifies the expense line, triggering the expense line detection trigger point again, and the client sends another risk detection request to the reimbursement management system.

[0142] Before the client detects user actions on the reimbursement page and triggers the detection trigger point or prompt trigger point, it must first generate the reimbursement page containing the detection trigger point and prompt trigger point. The following describes the generation process of the reimbursement page containing the detection trigger point and prompt trigger point, combining specific process steps.

[0143] See Figure 3, which is a flow chart of a method for generating a reimbursement page provided by the present application. As shown in Figure 3, a method for generating a reimbursement page provided by the present application may include the following steps:

[0144] S201: The client sends a page request to the reimbursement management system. Correspondingly, the reimbursement management system receives the page request sent by the client.

[0145] Page requests can include role data, step node data, etc. The following will introduce them in detail.

[0146] Role data is used to represent the user's role in the reimbursement application, for example, submitter, approver, etc. Approver includes supervisors, accountants, financial personnel, etc.

[0147] Step node data is used to represent the step nodes in the reimbursement application process, for example, the upload invoice identification step node, the view reimbursement details step node, the submit reimbursement step node, the view reimbursement list step node, the approval list step node, the approval details step node, the expense details step node, and so on.

[0148] When the user's role is that of a submitter, the step node can be any one of the following: upload invoice identification step node, view reimbursement details step node, submit reimbursement step node, view reimbursement list step node, etc., but cannot be any one of the following: approval list step node, approval details step node, expense details step node, etc.; when the user's role is that of an approver, the step node can be any one of the following: upload invoice identification step node, view reimbursement details step node, submit reimbursement step node, view reimbursement list step node, etc., but cannot be any one of the following: upload invoice identification step node, view reimbursement details step node, submit reimbursement step node, view reimbursement list step node, etc.

[0149] Different roles and different step nodes may trigger different timings for sending page requests:

[0150] When the user's role is submitter and the step node is the invoice identification step node, the page request can be triggered when the user logs in to the client;

[0151] When the user's role is submitter and the step node is any of the following: view reimbursement details step node, submit reimbursement step node, or view reimbursement list step node, the page request can be triggered when the previous step node ends and the next step node begins.

[0152] When the user's role is approver and the step node is an approval list step node, the page request can be triggered when the user logs in to the client;

[0153] When the user's role is an approver and the step node is any of the approval details step node and the expense details step node, the page request can be triggered when the previous step node ends and the next step node is entered.

[0154] S202: The reimbursement management system obtains the detection trigger point and the prompt trigger point of the reimbursement page according to the role data, the step node data and the mapping table.

[0155] The detection trigger points and prompt trigger points can be obtained by searching a mapping table corresponding to the role data and step node data, the corresponding role data, step node data, reimbursement page, detection trigger points, and prompt trigger points. Once the role data and step node data are determined, the corresponding reimbursement page can be determined based on the mapping table. This also allows the user to determine which objects and events on the reimbursement page should be set for the detection trigger points and prompt trigger points based on the mapping table. The detection trigger points and prompt trigger points in the mapping table can be determined by the user when configuring the rule template to generate the risk verification rule. For example, when configuring rule template 1 to generate risk verification rule 1, the user selects to set detection trigger points for the click event of the Save & Add button and the click event of the Save button, and to set a prompt trigger point for the click event of the Save button. If the search determines that the Save & Add button and the Save button exist on the upload invoice identification page, the detection trigger points for the click event of the Save & Add button and the click event of the Save button are added to the detection trigger point field of the corresponding row on the upload invoice identification page, and the prompt trigger point for the click event of the Save button is added to the prompt trigger point field. When generating risk verification rule 2 by configuring rule template 2, it is selected to set detection trigger points in the click event of the Save as Draft button and the click event of the Submit button, and to set a prompt trigger point in the click event of the Submit button. Then, by searching to determine whether the Save as Draft button and the Submit button exist in the object of the Reimbursement Details page, the detection trigger points of the click event of the Save as Draft button and the click event of the Submit button are added to the detection trigger point field of the corresponding row of the Reimbursement Details page, and the prompt trigger point of the click event of the Submit button is added to the prompt trigger field.

[0156] S203: The reimbursement management system generates a reimbursement page according to the acquired detection trigger point and prompt trigger point.

[0157] The generated reimbursement page can be any one of the invoice upload identification page, reimbursement details page, reimbursement submission page, reimbursement list page, approval list page, approval details page, expense details page, etc.

[0158] The reimbursement management system obtains the reimbursement page that matches the role data and step node data from the mapping table based on the role data and step node data. Then, the reimbursement management system obtains the code of the matching reimbursement page, interprets the code of the reimbursement page to obtain the object contained in the code of the reimbursement page. Among them, the code of the reimbursement page is pre-set by the user in the reimbursement management system. The reimbursement management system then obtains the detection trigger points and prompt trigger points that match the role data and step node data from the mapping table based on the role data and step node data, and sets them in which objects and events of the reimbursement page, and finds the corresponding objects in the objects included in the code of the reimbursement page, and adds one or more functions of sending risk detection requests and risk prompt requests in the response function of the event of the corresponding object. These steps will be explained in detail below with reference to specific examples.

[0159] The reimbursement management system obtains the code of the reimbursement page that matches the role data and the step node data according to the role data and the step node data, for example, HTML code. For ease of description, the following description will be made using HTML code as an example.

[0160] When the role data is Submitter and the step node data is Upload Invoice Identification step node, you can get the HTML code of the Upload Invoice Identification page;

[0161] When the role data is the submitter and the step node data is the step node for viewing reimbursement details, the HTML code of the reimbursement details page can be obtained;

[0162] When the role data is the submitter and the step node data is the reimbursement submission step node, the HTML code of the reimbursement submission page can be obtained;

[0163] When the role data is the submitter and the step node data is the step node for viewing the reimbursement list, the HTML code of the reimbursement list page can be obtained;

[0164] When the role data is approver and the step node data is approval list step node, you can get the HTML code of the approval list page;

[0165] When the role data is approver and the step node data is approval detail step node, you can get the HTML code of the approval detail page;

[0166] When the role data is approver and the step node data is the expense details step node, the HTML code of the expense details page can be obtained.

[0167] It is understood that the HTML code of each page can be pre-set in the reimbursement management system. The reimbursement management system can retrieve the HTML code of the corresponding page based on the role data and step node data.

[0168] The reimbursement management system interprets the code of the reimbursement page to obtain the objects contained in the code. The reimbursement management system uses an HTML parser to parse the HTML code of the reimbursement page into a Document Object Model (DOM) tree for the reimbursement page. The DOM tree of the reimbursement page organizes the objects on the reimbursement page in a tree-like data structure. Therefore, by traversing the DOM tree, objects on the reimbursement page can be obtained.

[0169] The reimbursement management system searches for objects in the reimbursement page that match the objects recorded in the detection trigger point column and the prompt trigger point column of the mapping table. The reimbursement management system matches the first object in the DOM tree with the object recorded in the detection trigger point column of the reimbursement page in the mapping table. If the match is successful, the function of sending a risk detection request is added to the response function of the corresponding event of the object. If the match is unsuccessful, the first object is matched with the object recorded in the prompt trigger point column of the reimbursement page in the mapping table. If the match is successful, the function of sending a risk prompt request is added to the response function of the corresponding event of the object. Then, the second object in the DOM tree is matched, and so on, until the matching of the last object in the DOM tree is completed.

[0170] S204: The reimbursement management system sends the reimbursement page to the client. Correspondingly, the reimbursement page receives the reimbursement page sent by the reimbursement management system.

[0171] S205: The client renders and displays the reimbursement page.

[0172] In some possible embodiments, the client parses the HTML file of the reimbursement page, constructs a document object model (DOM) tree, and parses the cascading style sheet (CSS) file to construct a CSS object model (CSSOM) tree. At this point, the DOM tree contains various events for each object on the reimbursement page and the response functions for each event when it is triggered. Some of the events for some of the objects in the DOM tree have been set with one or more of a detection trigger point and a prompt trigger point, and the response functions for the corresponding events of these objects are also correspondingly set with one or more of a risk detection request and a risk warning request. Therefore, after the client generates a render tree based on the DOM tree and the CSSOM tree and draws the render tree on the screen, the displayed reimbursement page can then send a risk detection request to the reimbursement management system when a detection trigger point is triggered, and send a risk warning request to the reimbursement management system when a prompt trigger point is triggered.

[0173] In the above example, the object in the DOM tree is used as the submit button, the object submit button in the detection trigger point field in the mapping table is matched, and the submit button in the DOM tree and the submit button in the detection trigger point field are matched. In actual applications, the matching method can be more flexible. For example, the detection trigger point field in the mapping table can be set to click on the expense line. Then, when the object in the DOM tree is the text box of the expense line, it can be considered that the match is successful, and the function of sending to the risk detection request is added in the click event of the text box. When the object in the DOM tree is a list of expense lines, it can also be considered that the match is successful, and the function of sending to the risk detection request is added in the click event of the list, and so on.

[0174] The following will use the example of social entertainment expense verification generated by configuring the blacklist and whitelist templates to explain in detail how to insert detection trigger points and prompt trigger points in the HTML code of the reimbursement page.

[0175] When the user matches the black and white list templates to configure the generated social entertainment expense verification, the detection trigger points selected by the submitter are clicking on the expense line, editing the reimbursement reason, saving the draft, and submitting the application; the detection trigger points for the approver are filling in the remarks, submitting the approval, and clicking on the expense line; the prompt trigger points for the submitter are clicking on the expense line, editing the reimbursement reason, and submitting the application; the prompt trigger points for the approver are filling in the remarks and clicking on the expense line.

[0176] When the role data in the page request sent by the client endpoint is "submitter" and the step node is the "upload invoice identification step node," the reimbursement management system obtains the HTML code for the upload invoice identification page and parses it into a DOM tree for the upload invoice identification page using an HTML parser. Objects in this DOM tree include a drop-down button for the expense line, a Save and Add button, a Save button, and an image of the invoice. The client checks the objects in the DOM tree to see if they match the detection trigger point and prompt trigger point configured for the social entertainment expense verification configuration. This detection finds that the drop-down button for the expense line in the DOM tree matches the detection trigger point and prompt trigger point for clicking on the expense line in the social entertainment expense verification configuration. Therefore, a response function can be added to the click event for the drop-down button for the expense line on the upload invoice identification page. This response function also includes the functionality to send a risk detection request and a risk warning request to the reimbursement management system. The risk detection request and risk warning request can be sent synchronously or asynchronously.

[0177] When the client sends a page request with the role data set "Submitter" and the step node set to "View Reimbursement Details," the reimbursement management system retrieves the HTML code for the reimbursement details page and uses an HTML parser to parse it into a DOM tree for the reimbursement details page. Objects in this DOM tree include a list of expense lines, a list of subsidy lines, a Save as Draft button, a Submit button, and so on. The client checks the objects in the DOM tree to see if they match the detection trigger points and prompt trigger points configured for the social entertainment expense verification. After detection, it was found that the list of expense lines in the object of the DOM tree is an object that matches the detection trigger point and prompt trigger point of the click expense line of the social entertainment expense verification configuration. Therefore, a response function can be added to the click event of the expense line list in the reimbursement details page, and the function of sending a risk detection request to the reimbursement management system and sending a risk prompt request to the reimbursement management system can be added to the response function; the drop-down button of the reimbursement reason in the object of the DOM tree is an object that matches the detection trigger point and prompt trigger point of the reimbursement reason editing in the social entertainment expense verification configuration. Therefore, a response function can be added to the keyboard press event of the drop-down button of the reimbursement reason in the reimbursement details page, and the function of sending a risk detection request to the reimbursement management system can be added to the response function. The function of sending a risk detection request and a risk warning request to the reimbursement management system is added; the Save as Draft button in the object of the DOM tree is an object that matches the detection trigger point of the Save Draft configuration of the social entertainment expenses verification. Therefore, a response function can be added to the click event of the Save as Draft button in the reimbursement details page, and the function of sending a risk detection request to the reimbursement management system is added to the response function; the Save as Submit Application button in the object of the DOM tree is an object that matches the detection trigger point of the Submit Application configuration of the social entertainment expenses verification. Therefore, a response function can be added to the click event of the Submit button in the reimbursement details page, and the function of sending a risk detection request to the reimbursement management system and a risk warning request to the reimbursement management system is added to the response function.

[0178] When the role data in the page request sent by the client endpoint is the submitter, and the step node is the reimbursement submission step node, the reimbursement management system obtains the HTML code of the reimbursement submission page and parses the HTML code of the reimbursement page into a DOM tree for the reimbursement submission page through the HTML parser. Objects in this DOM tree include buttons such as Cancel and OK. However, none of the objects in this DOM tree match detection trigger points or prompt trigger points, such as clicking an expense line, editing a reimbursement reason, saving a draft, and submitting an application. Therefore, there is no need to add response functions for the objects in this DOM tree.

[0179] When the role data in the page request sent by the client node is the submitter, and the step node is the step node for viewing the reimbursement list, the reimbursement management system obtains the HTML code of the reimbursement list page, and parses the HTML code of the reimbursement list page into a DOM tree of the reimbursement list page through the HTML parser. The objects in the DOM tree include a list of expense lines, a print button, a delete expense button, and the like. The client detects whether there are objects in the DOM tree that match the detection trigger point and the prompt trigger point of the social entertainment expense verification configuration. After detection, it is found that the list of expense lines in the objects of the DOM tree is an object that matches the detection trigger point and the prompt trigger point of the click expense line of the social entertainment expense verification configuration. Therefore, a response function can be added to the click event of the list of expense lines in the reimbursement list page, and the function of sending a risk detection request to the reimbursement management system and sending a risk prompt request to the reimbursement management system can be added to the response function.

[0180] When the role data in the page request sent by the client endpoint is the approver and the step node is the approval list step node, the reimbursement management system obtains the HTML code of the approval list page, thereby obtaining the objects of the approval list page including the expense lines and notes. Therefore, the detection trigger point and prompt trigger point for clicking the expense line and the detection trigger point for filling in the notes can be added to the expense lines and notes in the expense details page respectively.

[0181] When the role data in the page request sent by the client node is the approver and the step node is the approval details step node, the reimbursement management system obtains the HTML code of the approval details page and parses the HTML code of the approval details page into a DOM tree of the approval details page through the HTML parser. The objects in the DOM tree include a list of expense lines and page buttons. The client detects whether there are objects in the DOM tree that match the detection trigger points and prompt trigger points of the social entertainment expense verification configuration. After detection, it is found that the list of expense lines in the objects of the DOM tree is an object that matches the detection trigger points and prompt trigger points of the click expense lines configured for the social entertainment expense verification configuration. Therefore, a response function can be added to the click event of the list of expense lines in the approval details page, and the function of sending risk detection requests and risk prompt requests to the reimbursement management system can be added to the response function.

[0182] When the role data in the page request sent by the client node is the approver and the step node is the expense details step node, the reimbursement management system obtains the HTML code of the expense details page and parses the HTML code of the approval details page into a DOM tree of the approval details page through the HTML parser. The objects in the DOM tree include the drop-down button of the expense line and the image of the invoice, etc. The client detects whether there is an object in the DOM tree that matches the detection trigger point and prompt trigger point of the social entertainment expense verification configuration. After detection, it is found that the drop-down button of the expense line in the object of the DOM tree is an object that matches the detection trigger point and prompt trigger point of the click expense line of the social entertainment expense verification configuration. Therefore, a response function can be added to the click event of the drop-down button of the expense line in the expense details page, and the function of sending a risk detection request to the reimbursement management system and sending a risk prompt request to the reimbursement management system can be added to the response function.

[0183] The above is only an illustration of the risk verification rules for entertainment expenses verification. In actual applications, it may often include multiple risk verification rules. For each risk verification rule, the above method can be used to set the detection trigger node and the prompt trigger node, which will not be described in detail here.

[0184] The following will illustrate the entire reimbursement application execution process with reference to Figures 4 to 10. This execution process includes the roles of the submitter and the approver.

[0185] When the user's role is the submitter, the submitter's reimbursement process includes the following step nodes: upload invoice identification step node, view reimbursement details step node, submit reimbursement step node, view reimbursement list step node, etc.

[0186] At the upload invoice identification step, the client 100 may display an upload invoice identification page as shown in FIG4 . The upload invoice identification page includes a reimbursement application field 310 , an invoice display field 320 , an expense identification field 330 , and a risk warning field 340 .

[0187] The reimbursement application column 310 can display reimbursement applications that have not been submitted to the approver, for example, Reimbursement Application 1, Reimbursement Application 2, and Reimbursement Application 3. When the client 100 detects that the user has clicked on a corresponding reimbursement application, it switches to the corresponding reimbursement application. For example, when the client 100 detects that the user has clicked on Reimbursement Application 2, it enters the reimbursement application for that time.

[0188] Invoice display section 320 displays the uploaded invoice image in Reimbursement Application 2. Additionally, the invoice display section may include a Save button, a Download button, and a Print button. The Save button is used to save the invoice image. The Download button is used to download the invoice image to a local disk. The Print button is used to print the invoice image to a printer or to other document types, such as PDF.

[0189] The expense identification column 330 can be used to display the reimbursement data obtained after identifying the invoice display column, such as the expense line, which can include the expense type, expense incurred time, expense incurred location, expense amount, etc. The expense type, expense incurred time, expense incurred location, and expense amount can be displayed through visual controls, such as text boxes, drop-down buttons, etc. The information in the expense identification column 330 can be filled in after identifying the invoice image through image recognition technology, or it can be filled in manually by the submitter, or it can be obtained by manually modifying the information filled in the expense identification column 330 after image recognition if there is an error. The user can obtain multiple expenses by repeating the above operations, and the expense types can be the same or different.

[0190] The risk warning column 340 is used to display risk warning information obtained after the reimbursement data is verified using risk verification rules.

[0191] The upload invoice recognition page also includes a Save and Add button and a Save button in the lower right corner. When the client 100 detects that the user has clicked the Save and Add button, it saves the current invoice image and expense line and adds a new expense line, but does not proceed to the next step. When the client 100 detects that the user has clicked the Save button, it saves the current invoice image and expense line and proceeds to the next step.

[0192] The following describes how the upload invoice identification page of the client 100 interacts with the reimbursement management system 200. The interaction between them mainly includes two modes: risk detection request interaction and risk warning request interaction.

[0193] The first method is risk detection request interaction. When the client 100 detects that the user triggers the detection trigger point during the operation of the uploaded invoice identification page, it will send a risk detection request to the reimbursement management system 200. After the reimbursement management system 200 receives the risk detection request sent by the reimbursement management system 200, it will use the risk verification rules to verify the reimbursement data. If the verification passes, a verification pass message is returned to the client 100. If the verification fails, a risk warning message is generated and saved. Here, the detection trigger points that can be set on the uploaded invoice identification page may include: editing the expense line, deleting the expense line, saving the expense line, clicking the Save and Add button, clicking the Save button, and so on.

[0194] The second method involves risk warning request interaction. When the client 100 detects that a user has triggered a warning trigger point while operating the uploaded invoice identification page, it sends a risk warning request to the reimbursement management system 200. The warning trigger points that can be set on the uploaded invoice identification page may be a subset of the detection trigger points that can be set on the uploaded invoice identification page. These trigger points may include editing an expense line, deleting an expense line, saving an expense line, clicking the Save and Add button, clicking the Save button, and so on. After receiving the risk warning request, the reimbursement management system 200 sends the risk warning information to the client 100. The client 100 displays the risk warning information in the risk warning column 340 on the uploaded invoice identification page. The risk warning column 340 can indicate the presence of risks using risk icons and prominent titles. It also indicates the number of risk warnings and the number of risks that have been reviewed, for example, "Two risk warnings exist, one has been reviewed, and one has not been reviewed." The risk warning column 340 includes a risk warning light and a text box. Risk warning lights can include those for "Invoice header error" and "Expenses exceed standard." The risk warning light can have two or more states, for example, lit and off. The lit state indicates that the user has not reviewed the risk, while the off state indicates that the user has reviewed the risk. For example, the unreviewed "Invoice Heading Error" risk warning light in the figure remains lit (indicated by white in the figure), while the reviewed "Expenses Exceed Standard" risk warning light is off (indicated by gray in the figure). The text box is used to enter comments (e.g., explanation of the relevant reasons, etc.). If the client 100 detects that the user clicks the "Invoice Heading Error" risk warning light, the user can select a comment for the invoice heading error using the drop-down button or enter a comment in the text box using the keyboard. If the client 100 detects that the user clicks the "Expenses Exceed Standard" risk warning light, the user can select a comment for the expense exceeding the standard using the drop-down button or enter a comment in the text box. Risk warning information can be divided into strong control prompts and weak control prompts. Strong control prompts remind the user that the risk must be addressed, while weak control prompts remind the user to pay attention to the risk. For example, an invoice header error can be a weak control prompt, while an expense exceeding the standard can be a strong control prompt. Because the expense exceeding the standard is a strong control prompt, the client 100 will not allow the user to proceed to the next step until it detects that the user must select a reason from the optional menu of the drop-down button in the risk warning column 340, or manually enter a reason in the input field of the text box "Please fill in the relevant reason", such as a large number of department employees, etc.

[0195] In order to allow users to have a clearer understanding of the overall situation, the risk warning column of the client 100 can also display the total number of risk warning information, the number of reviewed risk warning information and the number of unreviewed risk warning information. For example, there are two risk warning information here, one has been reviewed and one has not been reviewed.

[0196] At the View Reimbursement Details step, client 100 may display the reimbursement details page shown in Figure 5. This reimbursement details page includes a personal information column 410, a basic information column 420, an expense information column 430, and a subsidy information column 440. The personal information column 410 primarily displays the submitter's personal information and indicates the expense type of the reimbursement request through a prominent icon and title. The personal information displayed in the personal information column 410 may include the submitter: Zhang San, employee number 00001, reimbursement compliance level A, company: ** Technology Co., Ltd., and department: Administration.

[0197] Basic information section 420 displays basic information about the current reimbursement request, such as the business application, the reason for the reimbursement, the payment method, and the currency. The business application can be linked to a previously submitted office supply purchase request, the reason for the reimbursement can be insufficient stationery supplies, and the payment method can be bank card transfer. The currency can be RMB.

[0198] The expense information column 430 is used to display the reimbursement data (for example, display the information of the expense line) that was input through image recognition or manual input in the previous step node, and the reimbursement data can be modified (for example, the information of the expense line is modified), or reimbursement data can be added. The expense information column 430 can display an expense list, and the expense list includes multiple expense lines, each expense line includes a serial number field, an expense type field, an expense occurrence time field, an expense occurrence location field, an expense amount field, a description information field, and an operation field. Among them, the expense type field, the expense occurrence time field, the expense occurrence location field, and the expense amount field are filled with the information of the expense line that was input through image recognition or manual input in the previous step. The description information field can be filled in or not. When the risk warning information is a strong control warning information, this field must be filled in. If the risk warning information is a weak control warning information, this field can be filled in or not. The action field can include an Edit button and a Delete button. When the Edit button is triggered, the client 100 allows the user to modify one or more of the following: expense type, expense time, expense location, expense amount, and description information for that row in the list. When the Delete button is triggered, the client 100 deletes the entire row. The Subsidy Information field is used to add reimbursement data, such as subsidy information.

[0199] Subsidy information column 440 may include a subsidy list, which displays subsidy lines. Subsidy lines include fields such as a serial number, subsidy type, subsidy occurrence time, subsidy location, subsidy amount, and an operation. The subsidy type, subsidy occurrence time, subsidy location, and subsidy amount fields can be manually entered or automatically calculated based on personal information, basic information, and expense information. Users can add one or more subsidies through this subsidy list.

[0200] The risk warning window 450 is used to display the risk warning information obtained after the reimbursement data of the current page or the previous page is verified using the risk verification rules. The detailed introduction of the risk warning window 450 can be found above.

[0201] The reimbursement details page also includes a Save as Draft button and a Submit button. When the client 100 detects that the user has clicked the Save as Draft button, it saves the current basic information, expense information, subsidy information, and the information entered in the text box, but does not proceed to the next step. When the client 100 detects that the user has clicked the Submit button, it saves the current basic information, expense information, subsidy information, and the information entered in the text box, and proceeds to the next step.

[0202] The following describes how the reimbursement details page of the client 100 interacts with the reimbursement management system 200. The interaction between them mainly includes two modes: risk detection request interaction and risk warning request interaction.

[0203] The first way is risk detection request interaction. When the client 100 detects that the user operates the reimbursement details page and triggers the verification trigger point, the client 100 will also send a risk detection request to the reimbursement management system 200. Among them, the verification trigger points that can be set on the reimbursement details page may include modifying the information of the expense line in the expense list, deleting the information of the expense line, adding the subsidy information in the correction list, deleting the subsidy information in the correction list, clicking the save button, clicking the confirm button, and so on. Similarly, after the reimbursement management system 200 receives the risk detection request sent by the client 100, it will also use the risk verification rules to verify the modified reimbursement data and the newly added reimbursement data. If the verification passes, the verification pass message is returned to the client 100. If the verification fails, the risk warning information is saved.

[0204] The second way is risk warning request interaction. When the client 100 detects that the user triggers the prompt trigger point during the operation of the above-mentioned reimbursement details page, a risk warning request is sent to the reimbursement management system 200. Among them, the prompt trigger point that can be set on the reimbursement details page can be a subset of the detection trigger point that can be set on the reimbursement details page. The prompt trigger point that can be set on the reimbursement details page can be to modify the information of the expense line in the expense list, delete the information of the expense line, add the subsidy information in the correction list, delete the subsidy information in the correction list, click the save button, click the confirm button, etc. After receiving the risk warning request, the reimbursement management system 200 will send the risk warning information to the client 100.

[0205] The client 100 displays a risk warning window to remind the user of the risks involved in the reimbursement application.

[0206] The risk warning window 450 may indicate the existence of risks through a risk icon and a clear title, and may also indicate the number of existing risks and the number of risks that have been reviewed. For example, it may display "There are two risk warnings, one has been reviewed, and one has not been reviewed." The risk warning floating window includes a risk warning light and a text box.

[0207] Risk warning lights can include risk warning lights for "invoice header error" and "costs exceeding the standard." Risk warning lights can have two or more states, for example, a lit state and an off state. The lit state indicates that the user has not reviewed the risk, and the off state indicates that the user has reviewed the risk. For example, the risk warning light for "invoice header error" in the figure, which has not been reviewed, remains lit (indicated by white in the figure), and the risk warning light for "costs exceeding the standard" that has been reviewed is off (indicated by gray in the figure).

[0208] The text box is used to enter notes (e.g., explanation of relevant reasons, etc.). If the client 100 detects that the user has clicked the "Invoice Heading Error" risk warning light, the user can select a note for the invoice heading error using the drop-down button or enter a note in the text box using the keyboard. If the client 100 detects that the user has clicked the "Expenses Exceed Standard" risk warning light, the user can select a note for the invoice heading error using the drop-down button or enter a note in the text box.

[0209] In order to allow users to more clearly understand the overall risk situation of this reimbursement application, the risk warning window can use risk icons and obvious titles to indicate the existence of risks, and the number of existing risks and the number of risks that have been reviewed can be prompted. For example, it can be displayed as "There are two risks here, 1 has been reviewed, and 1 has not been reviewed", etc.

[0210] It is understandable that the above two interaction modes are merely specific examples. In actual applications, the interactions between the client and the reimbursement management system may be more than the above interactions, for example, may include query request interactions, etc.

[0211] At the reimbursement submission step, the client 100 may display a reimbursement submission page as shown in FIG6 . The reimbursement submission page includes a frozen reimbursement details page 510 and a risk warning window 520 .

[0212] The frozen reimbursement details page 510 is frozen by the client 100 when the user clicks on the reimbursement details page to proceed to the reimbursement submission step. While frozen, no controls on the reimbursement submission page are accessible to the user. However, the risk warning window 520 remains accessible. This design allows the user to focus their attention on the risk warning window 520, allowing them to focus on the risks inherent in the reimbursement application.

[0213] The risk warning window 520 may indicate the existence of risks through a risk icon and a clear title, and may also indicate the number of existing risks and the number of risks that have been reviewed. For example, it may display "There are two risk warnings, one has been reviewed, and one has not been reviewed." The risk warning floating window 520 includes a risk warning light and a text box.

[0214] Risk warning lights can include risk warning lights for "invoice header error" and "costs exceeding the standard." Risk warning lights can have two or more states, for example, a lit state and an off state. The lit state indicates that the user has not reviewed the risk, and the off state indicates that the user has reviewed the risk. For example, the risk warning light for "invoice header error" in the figure, which has not been reviewed, remains lit (indicated by white in the figure), and the risk warning light for "costs exceeding the standard" that has been reviewed is off (indicated by gray in the figure).

[0215] The text box is used to enter notes (e.g., explanation of relevant reasons, etc.). If the client 100 detects that the user has clicked the "Invoice Heading Error" risk warning light, the user can select a note for the invoice heading error using the drop-down button or enter a note in the text box using the keyboard. If the client 100 detects that the user has clicked the "Expenses Exceed Standard" risk warning light, the user can select a note for the invoice heading error using the drop-down button or enter a note in the text box.

[0216] In addition, the risk warning window also includes a cancel button and an OK button. When the client 100 detects that the user clicks the cancel button of the risk warning floating window 520, it will return to the reimbursement details page of the previous step. When the client 100 detects that the user clicks the OK button of the risk warning floating window 520, it will complete the submission and enter the next step. It can be understood that the client 100 can be set to disable the OK button if it is detected that the user has not processed the strong control prompt information (for example, review and remarks), and enable the OK button if it is detected that the user has processed the strong control prompt information.

[0217] At the step node of viewing the reimbursement list, the client 100 may display the reimbursement list page as shown in FIG7 . The reimbursement list page may display a reimbursement list, which may include multiple reimbursement lines, each of which is a reimbursement application that has been submitted (including the reimbursement application submitted by the submitter this time and the reimbursement application submitted previously). Each reimbursement line in the reimbursement list includes fields such as serial number, expense type, expense occurrence time, expense occurrence location, expense amount, status, and operation. Here, the status bar may be used to display the status of the submitted reimbursement application, for example, completed, awaiting supervisor review, awaiting financial review, etc.

[0218] Here, the interaction between the reimbursement list page and the reimbursement management system mainly includes the risk warning request interaction. When the client 100 detects that the user triggers the warning trigger point during the operation of the above-mentioned reimbursement list page, it will send a risk warning request to the reimbursement management system 200. After the reimbursement management system 200 receives the risk warning request sent by the reimbursement management system 200, it will send the risk warning information to the client 100. The client 100 briefly displays the risk warning box. The risk warning box shows that 1 item has been reviewed and 1 item has not been reviewed. Here, the warning trigger points that can be set on the reimbursement list page may include: clicking on the reimbursement line, clicking on the expense type field, etc.

[0219] The prompt trigger points of each of the above pages are explained by taking the risk warning information obtained from the reimbursement management system 200 as an example. In actual application, if the risk warning information has been obtained when uploading the invoice identification page and the risk warning information has not changed, after entering the reimbursement details page, the reimbursement submission page and the reimbursement list page, the risk warning information saved by the client can also be directly displayed.

[0220] The above is explained using the example of 4 step nodes under the submitter role and each step node corresponding to a page. In actual applications, more or fewer step nodes and corresponding pages can be set. For example, the above 4 step nodes can be merged into 3 step nodes or even 1 step node. Correspondingly, the 4 pages can be combined into 3 pages or 2 pages, or even 1 page, etc. Similarly, a step node can be split into 2 step nodes, 3 step nodes or even more step nodes. Correspondingly, a page can be split into 2 pages, 3 pages or even more pages. No specific limitation is made here.

[0221] When the user's role is an approver, the approver's reimbursement process includes the following step nodes: approval list step node, approval details step node, expense details step node, etc.

[0222] During the approval list step, client 100 may display the approval list page shown in Figure 8 . The approval list page displays the approval list, which includes the serial number, expense type, reimbursement recipient, expense amount, reimbursement reason, status, notes, and so on. Each row in the approval list represents a reimbursement request submitted to the approver. For example, the first row in the approval list is the reimbursement request shown in Figures 4 through 7 .

[0223] Here, the interaction between the reimbursement list page and the reimbursement management system mainly includes the risk warning request interaction. When the client 100 detects that the user operates the risk warning button in the note field of the first row in the approval table, the warning trigger point will be triggered. The client 100 will send a risk warning request for the reimbursement application to the reimbursement management system 200. After receiving the risk warning request, the reimbursement management system 200 will send the risk warning information of the reimbursement application to the client 100. The client 100 will display the risk warning window on the approval list page. When the client 100 detects that the user clicks or double-clicks one of the rows in the approval table, it will enter the approval details step.

[0224] In the approval details step, the client 100 may display the approval details page as shown in Figure 9. The approval details page includes a reimbursement person information column 710, an approval progress column 720, a basic information column 730, an expense information column 740, and the like.

[0225] The reimbursement information column 710 may include the reimbursement person's name, employee number, reimbursement compliance level, company, department, etc. For example, the reimbursement person mentioned above may be: Zhang San, employee number 00001, reimbursement compliance level A, company: ** Technology Co., Ltd., department: Administration Department, etc.

[0226] Approval progress bar 720 can include a bar for displaying the approval progress of the reimbursement application. As shown in FIG7 , the approval progress bar includes multiple nodes, such as Employee Submission, Supervisor Approval, Finance Approval, and Finance Payment. Initially, the Employee Submission node, Supervisor Approval node, Finance Approval node, and Finance Payment node are all unchecked. The lines between the Employee Submission node and the Supervisor Approval node, the Supervisor Approval node and the Finance Approval node, and the Finance Approval node and the Finance Payment node are all dashed. When the process moves from Employee Submission to Supervisor Approval, the Employee Submission node is checked, and the line between Employee Submission and Supervisor Approval changes from a dashed line to a solid line. When Supervisor Approval moves to Finance Approval, but the Finance Approval process has not yet been completed, the line between Supervisor Approval and Finance Approval changes from a dashed line to a solid line. However, the Finance Approval node is not checked, and the line between the Finance Approval node and the Finance Payment node remains dashed. When this reimbursement application is completed, the employee submission node, supervisor approval node, finance approval node, and finance payment node are all checked, and the line segments from the employee submission node to the supervisor approval node, the supervisor approval node to the finance approval node, and the finance approval node to the finance payment node are all solid lines.

[0227] The basic information column 730 is used to display the basic information of the reimbursement application submitted by the submitter, such as the business application form, reimbursement reason, payment method and payment currency, etc. Please refer to the above introduction for details.

[0228] The expense information column 740 is used to display the reimbursement data (for example, the information of the expense line is displayed). For example, the expense information column can display an expense list, which includes a serial number field, an expense type field, an expense occurrence time field, an expense occurrence location field, an expense amount field, a description information field, and an operation field. When the client 100 detects that the user clicks or double-clicks one of the rows of expense information, it enters the expense details step. When the client 100 detects that the user operates the risk warning button in the approval details page, the prompt trigger point is triggered. The client 100 will send a risk reminder request for the reimbursement application to the reimbursement management system 200. After receiving the risk reminder request, the reimbursement management system 200 will send the risk warning information of the reimbursement application to the client 100. The client 100 will display the risk warning window on the approval details page.

[0229] The risk warning window 750 is used to display the risk warning information of the current reimbursement application. The introduction of the risk warning window 750 can be found above.

[0230] In the expense details step, the client 100 may display the expense details page as shown in Figure 10. The expense details page includes an expense item column 810, a subsidy item column 820, an attachment list column 830, a risk warning column 840, an expense line column 850, and an invoice display column 860.

[0231] The expense item column 810 is used to display one or more expenses of the reimbursement application, such as office supplies, etc. When the client detects that the user clicks on an expense item, the detailed expense line and invoice image of the expense item will be displayed in the expense line column 850 and the invoice display column 860.

[0232] The subsidy item column 820 is used to display one or more subsidies of the reimbursement application. When the client detects that the user clicks on an expense item, the detailed subsidy line of the subsidy item will be displayed in the expense line column 850 accordingly.

[0233] The attachment list column 830 may be used to display one or more attachments of the reimbursement application.

[0234] The expense line column 850 is used to display one or more expense lines, for example, expense type, expense incurred time, expense incurred location, expense incurred amount, etc. Please refer to the above introduction for details.

[0235] The invoice display column 860 is used to display the invoice image of this reimbursement application.

[0236] The interaction between the expense details page and the reimbursement management system primarily involves risk warning request interaction. When client 100 detects that a user's actions on the expense details page have triggered a warning trigger, it sends a risk warning request to reimbursement management system 200. Upon receiving the risk warning request, reimbursement management system 200 sends the risk warning information to client 100. Client 100 then displays the risk warning information in the risk warning column. For an introduction to the risk warning column, please refer to the previous section.

[0237] The above is explained using the example of 3 step nodes under the approver role and each step node corresponding to a page. In actual applications, more or fewer step nodes and corresponding pages can be set. For example, the above 3 step nodes can be merged into 2 step nodes or even 1 step node. Correspondingly, 3 pages can be combined into 2 pages or even 1 page, and so on. Similarly, a step node can be split into 2 step nodes, 3 step nodes or even more step nodes. Correspondingly, a page can be split into 2 pages, 3 pages or even more pages. There is no specific limitation here.

[0238] It is understandable that the above description only uses the reimbursement process with only one approver as an example. In actual applications, there may be two, three or even more levels of approvers. The roles of these approvers may be different, and each approver may correspond to one or more step nodes. The description will not be expanded here.

[0239] The client 100 and the reimbursement management system 200 can interact via a synchronous communication interface or an asynchronous communication interface. Since the client has a relatively high requirement for real-time performance when interacting with the reimbursement management system 200 via the reimbursement pages shown in Figures 4 to 7, a synchronous communication interface can be used to communicate with the reimbursement management system 200. Synchronous communication interfaces may include hypertext transfer protocol interfaces, synchronous application programming interfaces, synchronous database interfaces, synchronous file operation interfaces, and the like. When the client interacts with the reimbursement management system 200 via the reimbursement pages shown in Figures 8 to 10, the requirement for real-time performance is not high, so an asynchronous communication interface can be used to communicate with the reimbursement management system 200. Asynchronous communication interfaces may include asynchronous message queue interfaces, asynchronous callback interfaces, asynchronous task interfaces, asynchronous notification interfaces, asynchronous file upload interfaces, asynchronous data processing interfaces, asynchronous request interfaces, asynchronous calculation interfaces, asynchronous query interfaces, and asynchronous push interfaces, and the like.

[0240] The uploaded invoice identification page, reimbursement details page, reimbursement submission page, reimbursement list page, approval list, approval details list, and expense details list mentioned in Figures 4 to 10 can all be web pages displayed on a desktop computer, laptop computer, etc., or can be pages displayed on a mobile terminal, such as a mobile phone, etc. In addition, the web pages displayed on the desktop computer, laptop computer, etc. and the pages displayed on the mobile terminal can be provided simultaneously. To make user use more comfortable, the web pages displayed on the desktop computer, laptop computer, etc. and the pages displayed on the mobile terminal can be kept consistent.

[0241] In the above solution, risk warnings are issued by different roles and step nodes, so that users can obtain layer-by-layer thoughtful risk warnings, promptly discover and correct problems in the reimbursement data, and avoid subsequent rejection by the approver due to non-compliance.

[0242] Before using the risk verification rules, users (eg, administrators) can generate risk verification rules by configuring rule templates. The following will describe in detail the implementation process of generating risk verification rules by configuring rule templates in conjunction with FIG11 and FIG12.

[0243] Risk verification rules are generated by configuring a rule template through the following steps: selecting a rule template, configuring the rule template, and generating risk verification rules. The rule template selection step is used to select an appropriate rule template from multiple rule templates. The rule template configuration step is used to configure the selected template. The risk verification rule generation step is used to generate low-code risk verification rules based on the configured rule template.

[0244] During the rule template selection step, the client detects that the user has selected one of multiple rule templates. These rule templates can include blacklist and whitelist templates, duplicate verification templates, and bill verification templates, among others. As mentioned above, rule templates are abstractions of different risk verification rules. Therefore, different configurations of the same rule template can generate different risk verification rules, effectively reducing the number of rule templates required to be stored in the reimbursement management system.

[0245] Blacklist and whitelist templates can be used to generate risk verification rules for things like entertainment expense verification and name verification. Entertainment expense verification checks whether invoices, reimbursement forms, expense lines, and subsidy lines contain item keywords. Name verification checks whether invoices, reimbursement forms, expense lines, and subsidy lines contain person name keywords.

[0246] Duplicate verification templates can be used to generate risk verification rules for invoice duplicate verification and expense line duplicate verification. Invoice duplicate verification is used to verify whether invoices are used for duplicate reimbursement applications. Expense line duplicate verification is used to verify whether expense lines are used for duplicate reimbursement applications.

[0247] The bill verification template is used to generate risk verification rules for invoice authenticity, invoice serial number verification, invoice header tax number verification, and more. Invoice authenticity verification verifies the authenticity of invoices. Invoice serial number verification verifies whether multiple invoices have consecutive numbers. Invoice header tax number verification verifies the legitimacy of the invoice header tax number.

[0248] It is understandable that the above rule templates are only specific examples. In actual applications, more or fewer rule templates may be included, and the client 100 may also increase or decrease rule templates as needed.

[0249] In the step of configuring the rule template, you can configure part or all of the detection range, detection trigger point, prompt trigger point, main entity, auxiliary entity, processing logic, and output result of the rule template. The processing logic of the risk verification rules generated by the same rule template is the same or similar, but the main entity, auxiliary entity, part of the processing logic, and one or more of the output results are different. Therefore, different risk verification rules can be implemented through different configurations, thereby achieving the purpose of generating more risk verification rules with fewer rule templates. The following will illustrate this with two specific examples.

[0250] Taking risk verification rules such as social entertainment expense verification and name verification as an example, these two risk verification rules share the same primary entities: invoices, reimbursement forms, expense lines, and subsidy lines. Their processing logic is the same: both verify whether the verified object contains keywords. Their output is also the same: either the keyword is included or not. However, the auxiliary entities used for verification differ; for example, the content of the blacklist and whitelist differs. Therefore, by configuring different auxiliary entities, such as blacklists and whitelists, different risk verification rules can be configured.

[0251] Taking invoice duplication verification and expense line duplication verification as examples, the processing logic of these two risk verification rules is the same: both determine whether two checked objects are duplicates; the output is also the same: duplicate or non-duplicate. However, the primary and secondary entities are different. By configuring different primary and secondary entities in the duplication template, you can create different risk verification rules. Here, the primary entity for invoice duplication verification is the invoice, and the secondary entity is the invoice verification scope. The primary entity for expense line duplication verification is the expense line, and the secondary entity is the expense type.

[0252] It is understood that different rule templates may have different configurable sections. For example, for a blacklist or whitelist template, configurable sections include detection trigger points, prompt trigger points, primary entities, and auxiliary entities. For an invoice verification template, configurable sections include detection trigger points, prompt trigger points, and auxiliary entities. In actual applications, users can set different configurable sections as needed.

[0253] In the step of generating risk verification rules, the reimbursement management system 200 can use the low-code platform to generate low-code risk verification rules based on the user's configuration of the rule template. Among them, the low-code platform is a software development platform that can simplify and accelerate the generation process of risk verification rules, enabling users to create and deliver risk verification rules with less manual coding and less technical expertise. To this end, the low-code platform generally provides a set of visual tools and components that enable users to create risk verification rules by dragging and dropping and configuring. The low-code platform also provides a series of pre-built components and modules that users can use directly without having to write code from scratch. In addition, the low-code platform also provides automated code generation, integration and deployment functions to make the process of generating risk verification rules more efficient and faster.

[0254] The following will take the configuration of the black and white list template to generate the risk verification rule for social entertainment expenses verification as an example to explain in detail how to generate risk verification rules by performing zero configuration on the rule template.

[0255] The configurable items of the blacklist and whitelist template include the verification range, trigger point, main entity, auxiliary entity, and output result. The following will be combined with the drawings and specific embodiments to illustrate how to configure the verification range, trigger point, main entity, auxiliary entity, and output result of the blacklist and whitelist template.

[0256] In order to configure the verification range of the black and white template, the client 100 may display a verification range configuration page as shown in FIG11 . The verification range configuration page may include a rule selection field 910 and a verification range field 920 .

[0257] The rule selection bar 910 may include a search box 911 and a template list 912. The search box 911 is used to search for rule templates stored in the reimbursement management system 200, and the template list 912 is used to display rule templates stored in the reimbursement management system 200 or rule templates selected through the search box 911. In the embodiment shown in Figure 9, the rule templates displayed in the template list 912 include black and white list templates, bill verification templates, and duplicate verification templates. When the client detects which rule template the user clicks, the configurable items of the verification range of the rule template will be displayed in the verification range bar 920 accordingly. For example, after the client 100 detects that the user has selected the black and white list template, a company selection bar and an expense type selection bar can be displayed in the verification range bar 920.

[0258] The company selection column includes a list of head offices, which includes a first-level checkbox and a second-level checkbox. The first-level checkbox is the head office, and the second-level checkboxes include multiple checkboxes such as Subsidiary 1, Subsidiary 2, Subsidiary 3, and Subsidiary 4. When the first-level checkbox Head Office is selected, multiple checkboxes such as Subsidiary 1, Subsidiary 2, Subsidiary 3, and Subsidiary 4 will be selected at the same time. When any one or more of the second-level checkboxes are selected, the corresponding subsidiary will be selected. The user can combine the company ranges for verification as needed. For example, they can select Company 1, Company 2, or Company 1, Company 2, and Company 4, and so on. If the client 100 detects which subsidiaries the user has selected, it will perform verification within the scope of these subsidiaries. If it detects that the user has selected the head office, it will perform verification within the scope of all subsidiaries.

[0259] The expense type selection column includes a list of expense types, which includes a first-level checkbox and a second-level checkbox. The first-level checkbox represents the expense type, and the second-level checkboxes include multiple checkboxes for office supplies, business expenses, travel expenses, and training expenses. When the first-level checkbox for an expense type is selected, multiple checkboxes for the second-level checkboxes, such as office supplies, business expenses, travel expenses, and training expenses, are also selected. When any one or more of the second-level checkboxes are selected, the corresponding expense is selected. The user can combine the expense types to be verified as needed. For example, they can select business expenses, travel expenses, office supplies, travel expenses, training expenses, and so on. The client 100 detects which expense types the user has selected and performs verification within the scope of these expense types. For example, if the client 100 detects that the user has selected business expenses, it performs verification within the scope of business expenses. Business expenses include entertainment expenses, etc.

[0260] It should be understood that the above verification range configuration is merely a specific example. In actual applications, the configurable verification range may be fewer or more, and may include other ranges besides the company range and expense type range. Furthermore, the configurable items for the company range and expense type range may be fewer or more, or even other configurable items, and are not specifically limited here.

[0261] In order to configure the trigger points of the black and white template, the client 100 may display a trigger point configuration page as shown in FIG12 . The trigger point configuration page may include: a detection trigger point selection bar 1010 and a prompt trigger point selection bar 1020 .

[0262] The detection trigger point selection bar 1010 includes the detection trigger points of the submitter and the detection trigger points of the approver. The detection trigger points of the submitter include multiple check boxes such as clicking the expense line, clicking the subsidy line, editing the reimbursement reason, saving the draft, and submitting the application. The detection trigger points of the approver include check boxes such as filling in the remarks and submitting the approval. The detection trigger points of the submitter can be applied to the step nodes of the reimbursement process shown in Figures 4 to 7 as detection trigger points. The detection trigger points of the approver can be applied to the step nodes of the reimbursement process shown in Figures 8 to 10 as detection trigger points.

[0263] The prompt trigger point selection bar 1020 includes prompt trigger points for the submitter and detection trigger points for the approver. The prompt trigger points for the submitter include clicking on the expense line, clicking on the subsidy line, editing the reimbursement reason, saving the draft, and submitting the application, etc. The prompt trigger points for the approver include filling in the remarks and submitting the approval, etc. The prompt trigger points include the prompt trigger points for the submitter and the prompt trigger points for the approver. The prompt trigger points for the submitter can be applied to the step nodes of the reimbursement process shown in Figures 4 to 7 as prompt trigger points. The prompt trigger points for the approver can be applied to the step nodes of the reimbursement process shown in Figures 8 to 10 as prompt trigger points.

[0264] The detection trigger points of the submitter, the detection trigger points of the approver, the prompt trigger points of the submitter, and the prompt trigger points of the approver in the above examples are only specific examples. In actual applications, the detection trigger points of the submitter can also include expense line editing, expense line saving, expense line deletion, subsidy line editing, subsidy line saving, subsidy line deletion, reimbursement form submission, reimbursement reason editing, reimbursement form attachment, saving draft, and viewing draft, etc. The detection trigger points of the approver can also include approval filling, entering the page, etc. The prompt trigger points of the submitter can also include expense line saving, expense line deletion, subsidy line saving, subsidy line deletion, reimbursement form submission, reimbursement reason editing, reimbursement form attachment, saving draft, and viewing draft, etc. The prompt trigger points of the approver can also include approval filling, entering the page, etc.

[0265] The user can freely combine the detection trigger points and prompt trigger points as needed. When the client 100 detects which detection trigger points and prompt trigger points the user has set, it will issue a risk detection request and a risk prompt request at the corresponding detection trigger points and prompt trigger points. In the example shown in Figure 12, the user selected expense line editing, reimbursement reason editing, and saving the draft as the detection trigger points for the submitter, selected notes filling and approval submission as the detection trigger points for the approver, selected expense line editing, reimbursement reason editing as the prompt trigger points for the submitter, and selected notes filling as the prompt trigger point for the approver. In actual application, the user can select the submitter's detection trigger point, the approver's detection trigger point, the submitter's prompt trigger point, and the approver's prompt trigger point as needed, and no specific limitation is made here.

[0266] In order to configure the verification range of the blacklist and whitelist templates, the client 100 may display an entity configuration page as shown in FIG 13 . The entity configuration page may include a main entity configuration column 1110 and an auxiliary entity column 1120 .

[0267] The main entity configuration column 1110 is used to configure the detection object (ie, main entity) of the blacklist and whitelist template. The main entity configuration column 1110 includes one or more fields, each field may include one or more elements, and each element is a main entity.

[0268] 11 as an example, the main entity configuration column 1110 includes a reimbursement form field and an expense line field. Here, the reimbursement form field and the expense line field are only used as specific examples.

[0269] Reimbursement form fields include the purpose of the reimbursement, reviewer comments, and the name of the reimbursement form attachment. Furthermore, in addition to the purpose of the reimbursement, reviewer comments, and the name of the reimbursement form attachment, the reimbursement form fields may also include the name of the beneficiary region, the name of the cost center, and so on. It should be understood that the above example is merely a specific example. In actual applications, the reimbursement form fields may include more or fewer elements, and this is not specifically limited here.

[0270] The expense line field includes the expense line description, expense line attachment name, and so on. Furthermore, in addition to the expense line description and expense line attachment name, the expense line field may also include the invoice number, invoice code, and excess description. It should be understood that the above example is merely a specific example. In actual applications, the expense line field may include more or fewer elements, and this is not specifically limited here.

[0271] The user can combine the main entities to be verified as needed, for example, the user can select the expense line description and the reimbursement purpose, or the expense line description, the reimbursement purpose, and the reviewer's comments, etc. The client 100 detects which main entities the user has selected and verifies the selected main entities. For example, the client 100 detects that the user has selected the expense line description and the reimbursement purpose and verifies the expense line description and the reimbursement purpose.

[0272] In addition to the aforementioned reimbursement form fields and expense line fields, in actual applications, more fields may be included, and the number of elements included in a field may be fewer or more. For example, a subsidy line field and a bill field may be included. Subsidy line fields include subsidy line description, subsidy expense attachment name, destination city, departure city, etc. Bill fields include goods or taxable services, service name, specification model, remarks, invoice code, invoice code, train or train ticket number, electronic ticket number, etc.

[0273] The auxiliary entity column 1120 is used to configure the blacklist and whitelist in the auxiliary entity. The auxiliary entity column 1120 may include a blacklist group and a whitelist group, wherein:

[0274] The blacklist group includes a blacklist input box 1121, a blacklist display box 1122, a blacklist add button, and a blacklist switch. Blacklist input box 1121 is used to enter blacklist keywords. Blacklist display box 1122 displays entered blacklist keywords. The blacklist add button is used to add blacklist keywords. The blacklist switch is used to configure whether to enable the blacklist. The controls in the blacklist group described above are merely examples. In actual applications, the blacklist group may have fewer or more controls, or may include other controls, which are not specifically limited here.

[0275] The whitelist group includes a whitelist input box 1123, a whitelist display box 1124, a whitelist add button, and a whitelist switch. Whitelist input box 1123 is used to enter whitelist keywords. Whitelist display box 1124 displays already entered whitelist keywords. The whitelist add button is used to add keywords to the whitelist. The whitelist switch is used to configure whether the whitelist is enabled. The controls in the whitelist group described above are merely examples. In actual applications, the whitelist group may have fewer or more controls, or may include other controls, which are not specifically limited here.

[0276] Due to the settings of the blacklist switch and the whitelist switch, users can freely choose to use a blacklist, a whitelist, or both. Users can also freely add, remove, and modify keywords in the blacklist and whitelist through the blacklist input box 1121 and the whitelist input box 1123. In addition, users can freely increase the number of blacklists and whitelists. In other words, there can be more than one blacklist and whitelist, and users can freely choose which blacklist or whitelist to use. When the client detects which blacklist the user is using, it matches the keywords in that blacklist; when it detects which whitelist the user is using, it matches the keywords in that whitelist.

[0277] By setting the blacklist switch and the whitelist switch, it is also possible to configure some processing logic. For example, if the blacklist is enabled and the whitelist is not enabled, then the processing logic of the black and white list template is that when the main entity includes one or more keywords in the blacklist, it is determined that the verification fails, and otherwise the verification passes; if the blacklist is not enabled and the whitelist is enabled, then the processing logic of the black and white list template is that when the main entity includes one or more keywords in the whitelist, it is determined that the verification passes, and otherwise it is determined that the verification fails; if the blacklist is enabled and the whitelist is enabled, then the processing logic of the black and white list template is that when the main entity includes one or more keywords in the blacklist and does not include one or more keywords in the whitelist, it is determined that the verification fails, and otherwise it is determined that the verification passes.

[0278] In order to configure the output result of the black and white template, the client 100 may display an output result configuration page as shown in Figure 14. The output result configuration page may include a prompt trigger point bar 1210 displayed on the left and an output configuration bar 1220 displayed on the right.

[0279] The prompt trigger point column 1210 can display all prompt trigger points (including the prompt trigger points of the submitter and the prompt trigger points of the approver), or it can only display the prompt trigger points selected in the trigger point selection page shown in Figure 12. For example, the prompt trigger points of the submitter including expense line editing, subsidy line editing, reimbursement reason editing and saving draft, as well as the prompt trigger points of the approver filling in remarks and approval submission can be displayed. It can also only display the prompt trigger points of the submitter including the selected expense line editing and reimbursement reason editing, as well as the prompt trigger points of the approved approver filling in remarks, etc. When displaying all prompt trigger points, the selected prompt trigger points in the trigger point selection page shown in Figure 12 can be displayed in an enabled manner, and the unselected prompt trigger points in the trigger point selection page shown in Figure 12 can be displayed in a disabled manner.

[0280] The output configuration bar 1220 includes a prompt type drop-down button 1221, a prompt name output box 1222, a prompt message input box 1223, a verification failed input box 1224, and a verification passed input box 1225. When the client 100 detects that a user has clicked a prompt trigger point for a clicked expense line in the prompt trigger point bar 1210, the output configuration editor for the clicked expense line prompt trigger point will be displayed in the output configuration bar 1220. In one specific embodiment, the prompt type for the clicked expense line can be a "strong control risk prompt message" entered in the prompt type drop-down button 1221, the prompt name can be "socializing verification" entered in the prompt name output box 1222, and the prompt message entered in the prompt message input box 1223 can include, for example, relevant regulations, reasons for verification failure, and ways to seek help. The verification failed input box 1224 can be used to enter the output result if the verification fails, and the verification passed input box 1225 can be used to enter the output result if the verification passes.

[0281] It is understandable that the above output result configuration page is only used as a specific example. In actual applications, the configurable items of the output results may be fewer or more, and other configurable items may also be set, which are not specifically limited here.

[0282] Once the above verification scope, trigger points, main entities, auxiliary entities, and output results are configured, the low-code risk verification rules shown in Figure 15 will be automatically generated. The generated risk verification rules are:

[0283] Match {expense line. Reimbursement purpose, blacklist and whitelist. Blacklist} equals matching result. Match, and, Match {expense line. Reimbursement purpose, blacklist and whitelist. Whitelist} equals matching result. Unmatched is connected through the first and relationship,

[0284] Match {expense line.Expense line description, blacklist and whitelist.Blacklist} equals matching result.Match, and, Match {expense line.Expense line description, blacklist and whitelist.Whitelist} equals matching result.Unmatched is connected through the second AND relationship,

[0285] The first and the second and the relationship are connected by an or relationship.

[0286] Employee.Employee's Company belongs to Company List.Headquarters, Expense Line.Expense Type belongs to Expense Type.Business Expense and the Or relationship are connected through a third-party And relationship.

[0287] If the above conditions are met, the verification result is failed; otherwise, the verification result is passed.

[0288] Therefore, the meaning of the risk verification rules shown in Figure 15 is: if the company to which the employee applying for reimbursement belongs belongs to the head office, the expense type is within the detection range of business expenses, the reimbursement purpose of the expense line matches the blacklist and does not match the whitelist, then the verification result is failed, otherwise, the verification result is passed; or, if the company to which the employee applying for reimbursement belongs belongs to the head office, the expense type is within the detection range of business expenses, the expense line description of the expense line matches the blacklist and does not match the whitelist, then the verification result is failed, otherwise, the verification result is passed.

[0289] The following will also introduce the configuration methods of the duplicate verification template and the bill verification template respectively in conjunction with Figures 16 to 20. By selecting different configuration methods, multiple different risk verification rules can be generated.

[0290] When the client 100 detects that the user has selected a duplicate check template in the page shown in FIG12 , the mutually exclusive duplicate template and the consistent duplicate template included in the duplicate check template may be displayed.

[0291] Mutually exclusive duplicate templates refer to expense types within the configuration. Duplicates occur when overlapped expense occurrence times are detected for the same submitter. For example, the same submitter cannot submit both an out-of-town travel allowance and a business trip allowance on the same day.

[0292] When the client 100 detects that the user has selected a mutually exclusive repeat template, the mutually exclusive repeat configuration page shown in Figure 16 will be displayed. The mutually exclusive repeat configuration page includes a repeat template column 1410 and a verification range column 1420. Here, the repeat template column 1410 can display two radio buttons corresponding to the mutually exclusive repeat template and the consistent repeat template, respectively. The user can switch between templates by clicking different radio buttons. The verification range column 1420 can include a time range column 1430 and an expense type 1440. The time range column 1430 can include multiple radio buttons such as within one month, within three months, within six months, and within one year to determine the time range for performing the mutually exclusive repeat check. The expense type 1440 can include multiple check boxes such as office supplies, business expenses, travel expenses, and training expenses to determine the range of expense types for performing the mutually exclusive repeat check. In this mutually exclusive repeat template, auxiliary entities, such as the verification range (including the time range and expense type), can be configured. By setting the verification range, mutually exclusive repeat checks can be performed on main entities of different expense types within different time ranges.

[0293] The meaning of a consistent duplicate template is that if the configured main entities are consistent, it is considered a duplicate. For example, if the submitter, the time when the expense occurred, the location where the expense occurred, the amount of the expense occurred, etc. are all the same, it is considered a duplicate reimbursement.

[0294] When the client 100 detects that the user has selected a consistent repeat template, the consistent repeat configuration page shown in Figure 17 will be displayed. The consistent repeat configuration page includes a repeat template field 1510 and a configuration field 1520. The repeat template field 1510 may display two radio buttons, one for each of mutually exclusive repeat templates and one for consistent repeat templates. The user can switch between templates by clicking different radio buttons. The configuration field 1520 includes a verification range field 1530 and a main entity 1540. The verification range field 1530 may include a time range and a document range. The time range may include radio buttons such as within one month, within three months, within six months, and within one year, which are used to determine the time range for consistency verification. The document range may include the same document for the individual, different documents for the individual, and so on. The same document for the individual refers to the same reimbursement application for the same reimbursement claimant, while different documents for the individual refer to multiple reimbursement applications for the same reimbursement claimant. The main entity includes the reimbursement form fields and the invoice field. The reimbursement form fields include the reimbursement form type, payment currency, reimbursement form amount, invoice status, reimbursement unit price, and the location of the expense / subsidy line. Invoice fields can include special VAT invoices, general VAT invoices, electronic general VAT invoices, special VAT invoices, general fixed-rate invoices, and general machine-printed invoices, among others. Furthermore, primary entities can include expense type, expense incurred time, expense incurred location, expense amount, and more. Within this consistency repetition template, you can configure both secondary entities and primary entities. By setting the verification scope and primary entity, you can perform consistency repetition verification on different primary entities within different timeframes and document scopes.

[0295] It can be understood that the above-mentioned configurable items of mutually exclusive repeating templates and consistent repeating templates are merely specific examples. In actual applications, the configurable items of mutually exclusive repeating templates and consistent repeating templates may be fewer or more, and the configurable items of mutually exclusive repeating templates and consistent repeating templates may also have other configurable items, which are not specifically limited here.

[0296] When the client 100 detects that the user has selected a bill verification template in the page shown in FIG18 , the bill verification template may display the invoice authenticity verification, invoice serial number verification, and invoice header tax number verification included in the invoice verification template.

[0297] Invoice authenticity verification is used to verify the authenticity of invoices. When the client 100 detects that the user has selected invoice authenticity verification, the invoice authenticity configuration page shown in Figure 18 will be displayed. The invoice authenticity configuration page includes an invoice template column 1610 and a main entity column 1620. The invoice template column 1610 can display three radio buttons, corresponding to invoice authenticity verification, invoice serial number verification, and invoice header tax number verification, among others. Users can switch between templates by clicking different radio buttons. The main entity column 1620 includes multiple check boxes, such as special value-added tax invoice, ordinary value-added tax invoice, electronic ordinary value-added tax invoice, special value-added tax invoice, general fixed-rate invoice, general machine-printed invoice, taxi machine-printed invoice, highway machine-printed invoice, passenger limit invoice, airline passenger itinerary, train ticket, electronic ordinary invoice (blockchain), medical fee receipt, and general electronic invoice. In this invoice authenticity verification, you can configure main entities. By setting the main entities, you can verify the authenticity of invoices for different main entities.

[0298] Invoice serial number verification is used to verify whether invoice numbers are consecutive. Because invoice numbers are usually scattered during use, counterfeit invoices usually have the same or consecutive numbers. Therefore, it can be set to detect whether the difference between the invoice numbers is less than a set value, for example, 2, 3, etc. Here, the set value can be set based on experience, and the recommended value is 2. If the difference between the invoice numbers is less than or equal to the set value, the invoice verification is considered to have failed. If the difference between the invoice numbers is greater than the set value, the invoice verification is considered to have passed. When the client 100 detects that the user has selected invoice serial number verification, the page shown in Figure 19 will be displayed. This page includes an invoice template column 1710, a main entity column 1720, and a verification range. The invoice template column 1710 can display three radio buttons corresponding to invoice authenticity verification, invoice serial number verification, and invoice header tax number verification, etc. The user can switch between templates by clicking different radio buttons. The main entity column 1720 includes multiple checkboxes, such as special VAT invoices, general VAT invoices, electronic general VAT invoices, special VAT invoices, general fixed-rate invoices, general machine-printed invoices, taxi machine-printed invoices, highway machine-printed invoices, passenger limit invoices, airline passenger itineraries, train tickets, electronic general invoices (blockchain), medical fee receipts, and general electronic invoices. The verification range can include the absolute value of the consecutive number determined to be a consecutive number and the value range of the invoice to be verified. In this invoice consecutive number verification, auxiliary entities and main entities can be configured, for example, the auxiliary entity for the verification range (including the absolute value and value range of the consecutive number). By setting the verification range and main entity, it is possible to verify whether invoices from different main entities with numbers within different value ranges are consecutive invoices. In addition, it is possible to set the absolute value range of the consecutive number within which the difference between the invoice numbers is considered to be a consecutive invoice.

[0299] Invoice header tax number verification verifies whether the invoice header tax number complies with the corresponding rules. Invoice header tax numbers are generated according to certain rules. For example, the length of an invoice header tax number is generally 15 or 18 digits, and the format of the invoice header tax number is generally a combination of numbers and letters. When the client 100 detects that the user has selected invoice header tax number verification, the invoice header tax number configuration page shown in Figure 20 will be displayed. The invoice header tax number configuration page includes an invoice template field 1810 and a main entity field 1820. The invoice template field 1810 can display three radio buttons, corresponding to invoice authenticity verification, invoice serial number verification, and invoice header tax number verification. Users can switch between templates by clicking different radio buttons. The main entity field 1820 includes multiple checkboxes, such as special VAT invoice, general VAT invoice, electronic general VAT invoice, special VAT invoice, general fixed-rate invoice, general machine-printed invoice, taxi machine-printed invoice, highway machine-printed invoice, passenger limit invoice, airline passenger itinerary, train ticket, electronic general invoice (blockchain), medical fee receipt, and general electronic invoice. In the invoice serial number verification, you can configure the main entity. By configuring the main entity, you can check whether different invoice header tax numbers meet the invoice header tax number generation rules.

[0300] It can be understood that the above-mentioned configurable items for invoice authenticity verification, invoice serial number verification and invoice header tax number verification are merely specific examples. In actual applications, the configurable items for invoice authenticity verification, invoice serial number verification and invoice header tax number verification may be fewer or more, and the configurable items for invoice authenticity verification, invoice serial number verification and invoice header tax number verification may also have other configurable items, which are not specifically limited here.

[0301] The blacklist and whitelist templates, duplicate verification templates and bill verification templates in the above embodiments are only used as specific examples. In actual applications, the number of rule templates can be less or more, and the configurable items of each rule template, such as the main entity, auxiliary entity and output results, etc., can also be less or more. The settings of the configurable content of each configurable item can be set according to actual needs and are not specifically limited here.

[0302] The above text introduces in detail the reimbursement risk warning method provided by this application in combination with Figures 1 to 20. Next, the reimbursement risk warning system and computing device provided by this application are further introduced in combination with Figures 21 and 22 respectively.

[0303] See Figure 21, which is a schematic diagram of the structure of a reimbursement risk warning system provided by the present application. As shown in Figure 21, the reimbursement risk warning system of the present application includes: a client 100 and a reimbursement management system 200. The following will focus on the reimbursement management system 200 for a detailed introduction.

[0304] The reimbursement management system 200 includes a receiving unit 211, a verification unit 212, and a sending unit 213, wherein:

[0305] The receiving unit 211 is configured to receive a risk detection request sent by a client, wherein the risk detection request is used to determine a risk prompt for the client operation, and the timing of receiving the risk detection request varies when at least one of the user role and the step node corresponding to the client operation is different;

[0306] The verification unit 212 is configured to verify the reimbursement data of the reimbursement application using risk verification rules according to the risk detection request to obtain risk warning information;

[0307] The sending unit 213 sends the risk warning information to the client, wherein the risk warning information is used to indicate that the reimbursement data has one or more risks.

[0308] The receiving unit 211, the verification unit 212, and the sending unit 213 can all be implemented by software or hardware. For example, the implementation of the verification unit 212 will be described below using the verification unit 212 as an example. Similarly, the implementation of the receiving unit 211 and the sending unit 213 can refer to the implementation of the verification unit 212.

[0309] As an example of a software functional unit, the verification unit 212 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the verification unit 212 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0310] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0311] As an example of a hardware functional unit, the verification unit 212 may include at least one computing device, such as a server. Alternatively, the module A may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0312] The multiple computing devices included in verification unit 212 can be distributed in the same region or in different regions. The multiple computing devices included in verification unit 212 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in verification unit 212 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0313] It is worth noting that the verification unit 212 can be used to execute any step in the reimbursement risk warning method shown in Figure 2. Similarly, the receiving unit 211 and the sending unit 213 can be used to execute any step in the reimbursement risk warning method shown in Figure 2. The steps that the receiving unit 211, the verification unit 212 and the sending unit 213 are responsible for implementing can be specified as needed.

[0314] In another embodiment, referring to FIG. 22 , the reimbursement management system 200 includes a receiving unit 221 , a generating unit 222 , and a sending unit 223 , wherein:

[0315] The receiving unit 221 is used to receive role data and step nodes sent by the client, wherein the role data is used to represent the role of the user in the reimbursement application, and the step node data is used to represent the step nodes of the client's operation in the process of the reimbursement application.

[0316] The generation unit 222 is used to search the mapping table according to the role data and the step node data to obtain the code of the reimbursement page, search the mapping table according to the role data and the step node data to obtain the event of the object of the reimbursement page set by at least one of the detection trigger point and the prompt trigger point, and generate a reimbursement page according to the code of the reimbursement page and the event of the object of the reimbursement page set by at least one of the detection trigger point and the prompt trigger point.

[0317] The sending unit 223 is used to send the reimbursement page to the client.

[0318] It is worth noting that the generation unit 222 can be used to execute any step in the reimbursement page generation method shown in Figure 3. Similarly, the receiving unit 221 and the sending unit 223 can be used to execute any step in the reimbursement risk warning method shown in Figure 2. The steps that the receiving unit 221, the generation unit 222 and the sending unit 223 are responsible for implementing can be specified as needed.

[0319] Referring to Figure 23, Figure 23 is a schematic diagram of the structure of a computing device provided in this application. The computing device 300 may be the data query system described above. Furthermore, the computing device 300 includes a processor 301, a storage unit 302, a storage medium 303, and a communication interface 304. The processor 301, storage unit 302, storage medium 303, and communication interface 304 communicate via a bus 305, and may also communicate via other means such as wireless transmission.

[0320] Processor 301 is composed of multiple general-purpose processors, such as CPUs. The hardware chip is an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD is a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a data processing unit (DPU), a system on chip (SoC), or any combination thereof. Processor 301 executes various types of digital storage instructions, such as software or firmware programs stored in storage unit 302, which enables computing device 300 to provide a wide variety of services.

[0321] In a specific implementation, as an embodiment, the processor 301 includes one or more CPUs, such as CPU0 and CPU1 shown in FIG23 .

[0322] In a specific implementation, as an embodiment, computing device 300 also includes multiple processors, such as processor 301 and processor 306 shown in FIG23 . Each of these processors can be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). A processor here refers to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0323] The storage unit 302 is used to store program code and is controlled by the processor 301 to execute the processing steps of the reimbursement risk warning method and the reimbursement page generation method in any of the embodiments of Figures 1 to 20. The program code includes one or more software units. The one or more software units are the receiving unit, the verification unit, and the sending unit in the embodiment of Figure 21, wherein the receiving unit is used to receive one or more of the risk detection request, risk warning request, role data, and step node data sent by the client, and can be specifically used to implement S101, S104 and its optional steps in the embodiment of Figure 2, as well as S201, S205 and its optional steps in the embodiment of Figure 3. The verification unit is used to implement the risk verification rules for reimbursement data, and is specifically used to implement S103 in the embodiment of Figure 2. The sending unit is used to send risk warning information and reimbursement page to the client, and is specifically used to implement S105 in the embodiment of Figure 2 and S204 in the embodiment of Figure 3.

[0324] The storage unit 302 includes a read-only memory and a random access memory, and provides instructions and data to the processor 301. The storage unit 302 also includes a non-volatile random access memory. The storage unit 302 is a volatile memory or a non-volatile memory, or includes both volatile and non-volatile memories. Among them, the non-volatile memory is a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory is a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are used, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronized dynamic random access memory (SLDRAM), and direct RAM bus dynamic random access memory (DR DRAM). A hard disk, a universal serial bus (USB), a flash memory, a secure digital memory card (SD card), a memory stick, etc., and a hard disk can be a hard disk drive (HDD), a solid state drive (SSD), a mechanical hard disk (HDD), etc., which is not specifically limited in this application.

[0325] The storage medium 303 is a carrier for storing data, such as a hard disk, a universal serial bus (USB), a flash memory, a secure digital memory card (SD card), a memory stick, etc. The hard disk can be a hard disk drive (HDD), a solid state disk (SSD), a mechanical hard disk (HDD), etc., and this application does not make specific limitations.

[0326] The communication interface 304 is a wired interface (such as an Ethernet interface), an internal interface (such as a high-speed serial computer expansion bus (Peripheral Component Interconnect express, PCIe) bus interface), a wired interface (such as an Ethernet interface) or a wireless interface (such as a cellular network interface or a wireless local area network interface) for communicating with other servers or units.

[0327] Bus 305 is a Peripheral Component Interconnect Express (PCIe) bus, an extended industry standard architecture (EISA) bus, a unified bus (UBus or UB), a compute express link (CXL), or a cache coherent interconnect for accelerators (CCIX). Bus 305 is divided into an address bus, a data bus, and a control bus.

[0328] In addition to the data bus, the bus 305 also includes a power bus, a control bus, a status signal bus, etc. However, for the sake of clarity, various buses are labeled as the bus 305 in the figure.

[0329] It should be noted that FIG23 is only one possible implementation of the present application. In actual applications, the computing device 300 may also include more or fewer components, which is not limited here. For matters not shown or described in the embodiments of the present application, please refer to the relevant descriptions in the embodiments of FIG1 to FIG20 above, and will not be repeated here.

[0330] The present application also provides a computing device cluster, which may be the business management system described above, and includes at least one computing device 300. The storage unit 302 in one or more computing devices 300 in the computing device cluster may store the same or different instructions for executing the business management method.

[0331] The present application also provides a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be executed on a computing device or stored in any available medium. When the computer program product is executed on at least one computing device, the at least one computing device executes the service management method.

[0332] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a high-density digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the service management method.

[0333] The above embodiments can be implemented in whole or in part through software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. A computer program product includes multiple computer instructions. When the computer program instructions are loaded or executed on a computer, the processes or functions according to the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0334] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent repairs or replacements within the technical scope disclosed in the present invention, and such repairs or replacements should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A reimbursement risk warning method, characterized in that: include: Receiving a risk detection request sent by a client, wherein the risk detection request is used to determine a risk prompt for the client operation, and when the risk detection request is different in at least one of a user role and a step node corresponding to the client operation, the timing of receiving the risk detection request is also different; Verify the reimbursement data of the reimbursement application using risk verification rules according to the risk detection request to obtain risk warning information; The risk warning information is sent to the client, wherein the risk warning information is used to indicate that the reimbursement data has one or more risks.

2. The method according to claim 1, characterized in that The risk verification rule is configured using a rule template. The configurable items of the rule template include one or more of a main entity, an auxiliary entity, and an output result of the risk verification rule. The main entity is a verification object of the risk verification rule, the auxiliary entity is a verification scope of the risk verification rule, and the output result is a verification result obtained by verifying the risk verification rule; According to the risk detection request, the reimbursement data of the reimbursement application is verified using risk verification rules to obtain risk warning information, including: Matching the reimbursement data with at least one of the primary entity and the secondary entity according to the risk detection request, and in case of a match, verifying the reimbursement data using the risk verification rule to obtain the output result; The risk warning information is generated according to the output result.

3. The method according to claim 2, characterized in that Sending the risk warning information to the client includes: receiving a risk warning request sent by the client, wherein the risk warning request is used to display a risk warning of the client operation, and when the risk warning request is different in at least one of a user role and a step node corresponding to the client operation, the timing of receiving the risk warning request is also different; The risk warning information is sent to the client based on the risk warning request.

4. The method according to claim 3, characterized in that The risk detection request is sent when a detection trigger point of the reimbursement page of the reimbursement application displayed on the client is triggered, the reimbursement page is generated according to the page code by querying a mapping table based on the role data and the step node data, the position of the detection trigger point in the reimbursement page is obtained by querying the mapping table based on the role data and the step node data, the mapping table includes the corresponding relationship between the role data, the step node data, the page code and the position of the detection trigger point in the reimbursement page, the role data is used to indicate the role of the user in the reimbursement application, the step node data is used to indicate the step node corresponding to the client operation, and the detection trigger point is a trigger point set on the reimbursement page for triggering the client to send the risk detection request; The risk warning request is sent when the prompt trigger point set in the reimbursement page of the reimbursement application displayed on the client is triggered. The position of the prompt trigger point in the reimbursement page is obtained by querying the mapping table based on the role data and the step node data. The mapping table also includes the correspondence between the role data, the step node data and the prompt trigger point. The prompt trigger point is a trigger point set on the client for triggering the client to send a risk warning request.

5. The method according to claim 4, characterized in that Before receiving the risk detection request sent by the client, the method further includes: Receiving the role data and the step node data sent by the client; Search the mapping table according to the role data and the step node data to obtain the code of the reimbursement page; Searching the mapping table according to the role data and the step node data to obtain an event of the object of the reimbursement page set by at least one of a detection trigger point and a prompt trigger point; A reimbursement page is generated according to the code of the reimbursement page and the event of the object of the reimbursement page set by at least one of a detection trigger point and a prompt trigger point.

6. The method according to claim 5, characterized in that The role data includes one or more of submitter and approver. When the role data is the submitter, the step data includes an upload invoice identification step node, a view reimbursement details step node, a submit reimbursement step node, and a view reimbursement list step node, and the corresponding generated reimbursement pages include an upload invoice identification page, a reimbursement details page, a submit reimbursement page, and a reimbursement list page. The upload invoice identification page is used to identify the invoice to obtain the reimbursement data for this reimbursement application, the reimbursement details page is used to display the reimbursement data for this reimbursement application, the submit reimbursement page is used to submit the reimbursement data for this reimbursement application, and the reimbursement list is used for multiple reimbursement applications of the submitter including this reimbursement application; When the role data is the approver, the step data includes one or more of the approval list step nodes and the approval details step nodes, and the corresponding generated reimbursement page includes an approval list page and an approval details page. The approval list page is used to display the reimbursement applications that need to be approved by the approver, and the approval details page is used to display the reimbursement data of one of the reimbursement applications.

7. The method according to claim 5 or 6, characterized in that: Generating a reimbursement page according to the code of the reimbursement page and an event of an object of the reimbursement page set by at least one of a detection trigger point and a prompt trigger point, comprising: Obtain the code of the reimbursement page, and parse the code to obtain multiple objects, wherein the multiple objects include one or more of a text box, a check box, a radio button, a drop-down button, a button, a text area, an image, a link, a label, a table, a slider, a progress bar, a menu, a pop-up box, a video player, an audio player, a calendar, a carousel, a navigation bar, and a chart, Finding an object of the reimbursement page set by at least one of the detection trigger point and the prompt trigger point from the multiple objects as a target object; Adding at least one of a function of sending a risk detection request or a risk warning request in a response function of an event of the target object, to obtain a modified target object; The reimbursement page is generated according to the modified target object.

8. The method according to any one of claims 2 to 7, characterized in that: Before verifying the reimbursement data of the reimbursement application using a risk verification rule according to the risk detection request to obtain risk warning information, the method further includes: The configurable items of the rule template are configured to generate the risk verification rule.

9. The method according to claim 8, characterized in that The main entities include one or more of invoices, reimbursement forms, expense lines, subsidy lines, submitters and approvers; the auxiliary entities include one or more of blacklists, whitelists, and expense types; the reimbursement forms include one or more of reimbursement purpose, reviewer comments, and reimbursement form attachment names; the expense lines include one or more of expense type, expense incurred time, expense incurred location, expense amount, expense line description, and expense line attachment names; the subsidy lines include one or more of subsidy type, subsidy incurred time, subsidy incurred location, and subsidy amount; the blacklist includes one or more first keywords, and the whitelist includes one or more second keywords.

10. The method according to claim 9, characterized in that In the case where the rule template is a blacklist or whitelist template, the configurable items of the blacklist or whitelist template include the main entity and the auxiliary entity, and configuring the configurable items of the rule template to generate the risk verification rule includes: Acquire a first main entity and a first auxiliary entity of the black and white list template input by the user through the client, wherein the first main entity belongs to the main entity of the black and white list template, the main entity of the black and white list template includes the reimbursement form and the expense, and the first auxiliary entity belongs to the auxiliary entity of the black and white list template, and the auxiliary entity of the black and white list template includes the blacklist and the whitelist; The first main entity and the first auxiliary entity of the blacklist and whitelist template are filled into the rule template to obtain the first risk verification rule.

11. The method according to claim 10, characterized in that The blacklist further includes a blacklist input box and a blacklist switch, and the whitelist further includes a whitelist input box and a whitelist switch, wherein the blacklist input box is used to input keywords of the blacklist, the whitelist input box is used to input keywords of the whitelist, the blacklist switch is used to select whether to use the blacklist, and the whitelist switch is used to select whether to use the whitelist. The reimbursement data is verified using risk verification rules according to the risk detection request, and the risk warning information obtained includes: When the blacklist switch is turned on and the whitelist switch is turned off, the first keyword in the blacklist is compared with the reimbursement data according to the first risk verification rule, and when the reimbursement data contains the first keyword in the blacklist, it is determined that the verification fails and the risk warning information is generated; or When the blacklist switch is turned off and the whitelist switch is turned on, the second keyword in the whitelist is compared with the reimbursement data using the first risk verification rule, and when the reimbursement data does not contain the second keyword in the whitelist, it is determined that the verification using the first risk verification rule fails and the risk warning information is generated; or, When the blacklist switch is turned on and the whitelist switch is turned on, the first keyword in the blacklist and the second keyword in the whitelist are respectively compared with the reimbursement data through the first risk verification rule. When the reimbursement data contains the first keyword in the blacklist and the second keyword in the whitelist is not contained in the reimbursement data, it is determined that the verification using the first risk verification rule fails and the risk warning information is generated.

12. The method according to any one of claims 2 to 11, characterized in that In the case where the rule template is a consistent repeating template, the configurable items of the consistent repeating template include the main entity, and configuring the configurable items of the rule template to generate the risk verification rule includes: Obtaining a second main entity of the consistency duplication verification template input by the user through the client, wherein the second main entity belongs to the main entity of the consistency duplication template, and the main entity of the consistency duplication template includes an invoice, and the invoice includes one or more of a special value-added tax invoice, a general value-added tax invoice, a general value-added tax electronic invoice, a special value-added tax electronic invoice, a general fixed-amount invoice, and a general machine-printed invoice; Fill the second main entity of the consistent repeat template into the rule template to obtain the second risk verification rule.

13. The method according to any one of claims 2 to 12, characterized in that: Configuring the configurable items of the rule template to generate the risk verification rule includes: Configuring the configurable items of the rule template to obtain configuration information; The risk verification rules are generated by combining the configuration information and the rule template through a low-code platform.

14. The method according to any one of claims 1 to 13, characterized in that: The risk warning information includes strong control risk warning information and weak control risk warning information, wherein the strong control risk warning information is used to remind the user that the risk warning information must be processed, and the weak control warning information is used to remind the user to pay attention to and check the risk warning information.

15. A reimbursement risk warning device, characterized in that: include: A receiving unit, a checking unit and a sending unit; The receiving unit is used to receive a risk detection request sent by a client, wherein the risk detection request is used to determine a risk prompt of the client operation, and when the risk detection request is different in at least one of a user role and a step node corresponding to the client operation, the timing of receiving the risk detection request is also different; The verification unit is used to verify the reimbursement data of the reimbursement application using the risk verification rule according to the risk detection request to obtain risk warning information; The sending unit is used to send the risk warning information to the client, wherein the risk warning information is used to indicate that the reimbursement data has one or more risks.

16. A computing device, characterized in that include: A processor and a memory, wherein the memory is used to store instructions, and the processor is used to run the instructions in the memory to perform the method according to any one of claims 1 to 14.

17. A computing cluster, characterized in that: The method comprises a plurality of computing devices, wherein each computing device comprises a processor and a memory, wherein the memory is used to store instructions, and the processor is used to run the instructions in the memory to execute the method according to any one of claims 1 to 14.

18. A computer-readable storage medium, characterized in that: The method comprises instructions, which, when executed by a computing device, perform the method according to any one of claims 1 to 14.

Images