Invoice generation method and computing device

Abstract

This application discloses an invoice generation method and computing device, relating to the field of enterprise invoicing management technology. The method is applied to a computing device. The method includes: responding to an effective instruction of a sales contract, obtaining first information from the sales contract, the first information including: invoice type, sales entity information, and invoicing milestones, whereby the invoicing milestones define the nodes that trigger invoicing during the execution of the sales contract; determining invoicing rules based on the invoice type, sales entity information, and invoicing milestones, the invoicing rules including invoicing trigger conditions and invoicing trigger amounts; obtaining second information from the sales contract based on the invoicing trigger conditions and invoicing trigger amounts; and generating a first invoicing plan page based on the invoicing milestones, invoicing trigger conditions, and second information, whereby the first invoicing plan page is used to instruct the generation of the invoice corresponding to the sales contract. This automates the process from the sales contract to the invoicing plan page generation, improving the efficiency and accuracy of invoicing management.

Description

Technical Field

[0001] This application relates to the field of enterprise invoicing management technology, and in particular to an invoice generation method and computing device. Background Technology

[0002] Enterprise invoicing management largely relies on industry-standard Enterprise Resource Planning (ERP) solutions. The conventional process uses sales orders as the basis for invoicing, requiring invoicing to be performed after shipment or receipt. However, because the payment agreement maintained by the sales contract is not directly linked to the invoicing process, in scenarios involving advance payments (such as prepayments from customers), before actual goods delivery or service provision has occurred, invoicing cannot be triggered through the sales order. The payment is directly linked to the contract, but the intermediate invoicing step is missing. The matching of the sales contract, sales order, and invoice can only be completed after the order is shipped or received. Furthermore, manual parsing of sales contracts is required, which is not only inefficient and prone to errors, but also results in a simplistic invoicing model that cannot meet the diverse invoicing needs of various business scenarios. Summary of the Invention

[0003] This application provides an invoice generation method and computing device that can improve the timeliness of matching sales contracts, sales orders and invoices in any business scenario, realize automation from sales contract to invoice generation, and meet the invoicing needs of various business scenarios.

[0004] In a first aspect, embodiments of this application provide an invoice generation method, applied to a computing device. The method includes: In response to the sales contract's activation instruction, the system retrieves first information from the sales contract, including: invoice type, sales entity information, and invoice milestones. Invoice milestones define the nodes that trigger invoicing during the sales contract's execution. Based on the invoice type, sales entity information, and invoice milestones, the system determines invoice rules, including invoice trigger conditions and invoice trigger amounts. Based on the invoice trigger conditions and invoice trigger amounts, the system retrieves second information from the sales contract, including the sales contract's invoice amount, invoice period, invoice amount for each period, and expected invoice date. Based on the invoice milestones, invoice trigger conditions, and second information, the system generates a first invoice plan page. The first invoice plan page includes an invoice plan header and invoice plan lines. The invoice plan header includes the sales contract's invoice amount. The invoice plan lines include the invoice period, invoice amount for each period, expected invoice date, invoice milestones, and invoice trigger conditions. The first invoice plan page is used to instruct the generation of the invoice corresponding to the sales contract.

[0005] Thus, by responding to the sales contract's activation instruction, the system retrieves the first information from the sales contract, automatically matches invoicing rules based on this first information, determines the second information based on the invoicing rules, and generates a first invoicing plan page based on the invoicing trigger conditions, invoicing milestones, and the second information. This page instructs the generation of the invoicing plan corresponding to the sales contract. The first invoicing plan page uses its included invoicing plan header to achieve overall identification and control of the invoicing plan, and its included invoicing plan rows to clearly define the specific invoicing content for each period, giving the first invoicing plan page both overall control and detailed execution dimensions. In this way, using the sales contract as the basis for invoicing, the invoicing process can be triggered promptly in any business scenario (including advance payment scenarios), thereby improving the timeliness of matching sales contracts, sales orders, and invoices. Simultaneously, by automatically extracting the first information from the contract, replacing the traditional manual parsing of sales contracts, the efficiency of contract information parsing is improved and errors are reduced. Furthermore, the accurate matching of corresponding invoicing rules based on the first information can flexibly adapt to changing business scenarios, meeting the invoicing needs of different scenarios, ultimately achieving full-process automation from sales contract to invoicing, improving the overall efficiency and accuracy of invoicing.

[0006] In one possible implementation, invoicing rules are determined based on invoicing type, sales entity information, and invoicing milestones, including: determining the target invoicing scenario to which the sales contract belongs based on invoicing type, sales entity information, and invoicing milestones; and determining the invoicing rules from multiple invoicing rules based on the target invoicing scenario.

[0007] In this way, by classifying sales contracts by invoice type, sales customer information, and invoice milestones, and then matching the invoice rules corresponding to the target invoice scenario from multiple preset invoice rules, it is possible to ensure that the determined invoice rules are accurately matched with the invoice requirements of the sales contract, thus guaranteeing the accuracy of invoice rule matching.

[0008] In one possible implementation, after generating the first invoicing plan page based on the invoicing milestone, invoicing triggering conditions, and second information, the method further includes: obtaining the current execution node of the sales contract; and in response to the execution node being a node defined by the invoicing milestone, calling the first interface to generate the invoice corresponding to the sales contract based on the first invoicing plan page.

[0009] This ensures that the timing of invoice generation accurately matches the key milestones of contract performance, avoiding a disconnect between invoicing and performance progress. At the same time, relying on interface calls enables automated triggering of the invoicing process, reducing manual intervention, ensuring consistency between invoicing operations and the first invoicing plan page, and improving the accuracy and efficiency of the invoicing process.

[0010] In one possible implementation, the invoice amount for each invoice corresponding to the sales contract is the same as the invoice amount for each period.

[0011] In this way, the invoice amount for each sales contract can be matched one-to-one with the invoice amount for each period, ensuring accurate matching of invoice amounts.

[0012] In one possible implementation, obtaining second information from the sales contract based on the invoicing trigger condition and the invoicing trigger amount includes: determining a template for the first invoicing plan page based on the invoicing trigger condition and the invoicing trigger amount; obtaining the second information based on the template; and generating the first invoicing plan page based on the invoicing milestone, the invoicing trigger condition, and the second information, including: filling the template with the second information, the invoicing milestone, and the invoicing trigger condition to generate the first invoicing plan page.

[0013] In this way, it can be ensured that the information included in the first invoicing plan page accurately corresponds to the invoicing requirements of the contract, and the template based on the first invoicing plan page can improve the standardization of the format and content of the invoicing plan page, thereby improving the accuracy and standardization of the generation of the first invoicing plan page.

[0014] In one possible implementation, in response to the sales contract's effective instruction, obtaining first information from the sales contract includes: in response to the sales contract's effective instruction, obtaining third information from the sales contract, the third information including entity information and a payment agreement; converting the third information into structured data; and extracting the first information from the structured data.

[0015] Thus, by structuring the third information to organize the scattered third information into a standardized and easily extractable format, the first information can be accurately located and extracted, reducing information extraction errors and improving efficiency.

[0016] In one possible implementation, the method further includes: if no invoice corresponding to the sales contract is generated based on the first invoicing plan page, marking the first invoicing plan page as a first state, the first state indicating that no invoice has been generated based on the invoicing plan page; and if an invoice corresponding to the sales contract is generated based on the first invoicing plan page, marking the first invoicing plan page as a second state, the second state indicating that an invoice has been generated based on the invoicing plan page.

[0017] In this way, the invoicing execution results of the invoicing plan are marked with the first and second states, clearly distinguishing between the two core states of "not invoiced" and "invoiced". This enables visual tracking of the invoicing plan execution status, avoiding duplicate invoicing and missed invoicing, and improving the standardization and traceability of the invoicing process.

[0018] In one possible implementation, the sales contract is the original sales contract; or, the sales contract is an updated version of the initial sales contract, which is the original sales contract, or a sales contract that has been updated one or more times to the original sales contract. The original sales contract can refer to the sales contract that was first signed by the parties and has not undergone any changes.

[0019] This allows for a more comprehensive coverage of sales contract signing scenarios, improving the method's versatility and adaptability.

[0020] In one possible implementation, when the sales contract is an updated version of the initial sales contract, the method further includes: if no invoice is generated based on the second invoicing plan page, setting the second invoicing plan page to be invalid; the second invoicing plan page is an invoicing plan page generated based on invoicing rules matching the initial sales contract; if an invoice has been generated based on the second invoicing plan page, and the first information of the sales contract changes, then generating a red-letter invoice based on the second invoicing plan page; if the first information of the sales contract has not changed and the change to the sales contract meets preset change conditions, then performing preset operations on the target invoice generated based on the second invoicing plan page based on the preset change conditions.

[0021] Thus, in the scenario of updating a sales contract with the target sales contract as the target contract, different operations are performed based on the application status of the second invoicing plan page. For example, if the second invoicing plan page is not applied, it can be directly set to invalid, which can avoid duplicate or incorrect invoicing caused by the disconnect between the old invoicing plan page and the updated contract. If the second invoicing plan page is applied, and the first information changes, a red-ink invoice is generated based on the second invoicing plan page to reverse the target invoice. This can promptly correct the discrepancy between the original invoice and the invoicing information corresponding to the updated contract, ensuring that the invoice content is consistent with the current contract information and complies with tax and business compliance requirements. If the first information remains unchanged and the change meets the preset conditions, the target invoice is processed according to the preset operation. This can flexibly adapt to the contract change requirements that comply with the rules, avoid redundant operations when a red-ink reversal is not required, and improve the standardization and efficiency of invoicing processing in contract change scenarios.

[0022] In one possible implementation, the preset change conditions include that the change to the sales contract does not affect the validity of the target invoice, and the preset operation includes: migrating the data of the target invoice to the first invoicing plan page; or, the preset change conditions include that the invoice amount of the sales contract decreases, and the preset operation includes: migrating the data of the target invoice to the first invoicing plan page and generating a first invoice, which is used to reduce the invoice amount of the target invoice; or, the preset change conditions include that the invoice amount of the contract increases, and the preset operation includes: migrating the data of the target invoice to the first invoicing plan page, and determining whether to generate a second invoice based on an approval operation, whereby the approval operation indicates whether a second invoice needs to be reissued, and generating a second invoice in response to the approval operation indicating that a second invoice needs to be reissued.

[0023] Thus, when changes to the sales contract do not affect the validity of the target invoice, migrating the target invoice data to the first invoicing plan page avoids redundant operations when no red-ink reversal is needed. This ensures data consistency between already issued valid invoices and the updated invoicing plan page, guaranteeing invoice compliance and improving the efficiency of the invoicing process in contract change scenarios. In scenarios where the sales contract invoice amount decreases, migrating the target invoice data to the first invoicing plan page and generating a first invoice to reduce the target invoice amount accurately corrects the discrepancy between the original invoice amount and the changed contract amount, ensuring the invoice amount matches the current contract requirements. In scenarios where the sales contract invoice amount increases, migrating the target invoice data to the first invoicing plan page and combining this with approval processes to determine whether to generate a positive invoice accurately corrects the discrepancy between the original invoice amount and the changed contract amount. Furthermore, the approval process controls the compliance of the reissue process, improving the standardization and efficiency of invoicing processing in contract change scenarios. Based on this, different processing operations can be adopted for different change scenarios, increasing flexibility.

[0024] In one possible implementation, before obtaining the first information in the sales contract in response to the sales contract's activation instruction, the method further includes: receiving an activation instruction from the user to trigger the sales contract to take effect; or, if the current time is a preset time, triggering the sales contract's activation instruction, where the preset time is the preset activation time of the sales contract.

[0025] Thus, by providing users with the option to manually trigger the activation command, and by providing the option to automatically trigger the activation command based on a preset time point, these two methods of receiving sales contract activation commands adapt to the contract activation needs under different business scenarios, improving the flexibility and accuracy of the sales contract activation triggering logic.

[0026] Secondly, embodiments of this application provide another invoice generation method, which includes: in response to an effective instruction of a sales contract, obtaining first information from the sales contract, the first information including: invoice type, sales entity information, and invoice milestone, the invoice milestone being used to define the node that triggers invoicing during the execution of the sales contract; determining invoicing rules based on the invoice type, sales entity information, and invoice milestone, the invoice rules including invoice triggering conditions and invoice triggering amount; obtaining second information from the sales contract based on the invoice triggering conditions and invoice triggering amount, the second information including the invoice amount of the sales contract, invoice period, invoice amount for each period, and expected invoice date; obtaining the current execution node of the sales contract; and in response to an execution node defined by an invoice milestone, generating an invoice corresponding to the sales contract based on the invoice milestone, invoice triggering conditions, and second information.

[0027] Thus, by responding to the sales contract activation instruction, extracting the first piece of information, and determining the invoicing rules based on this first piece of information, and using the invoicing milestone as the trigger node for invoice generation, invoicing is performed based on the invoicing milestone, the invoicing trigger condition, and the second piece of information, achieving a fully automated invoice generation process for sales contracts. This can improve the timeliness of matching sales contracts, sales orders, and invoices in any business scenario, automating the process from sales contract to invoice generation, and meeting the invoicing needs of diverse business scenarios.

[0028] Thirdly, embodiments of this application provide a computing device, including: a memory and a processor. The memory is used to store program instructions. The processor is used to execute the program instructions, causing the computing device to perform the invoice generation method described above.

[0029] Fourthly, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed on a computing device, cause the computing device to perform the invoice generation method described above.

[0030] Fifthly, a computer program product is provided, the computer program product including computer execution instructions, which, when executed on a computing device, cause the computing device to perform the invoice generation method as described above.

[0031] The technical effects of any of the implementation methods in the third to fifth aspects can be found in the technical effects of different implementation methods in the first and / or second aspects, and will not be repeated here.

[0032] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0033] Figure 1This is a schematic diagram of the structure of a computing device provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of another computing device provided in an embodiment of this application; Figure 3 A flowchart illustrating an invoice generation method provided in this application embodiment; Figure 4 This application provides a schematic diagram for displaying invoicing contract information as an embodiment of the present application. Figure 5 A flowchart illustrating the process of determining invoicing rules, provided for an embodiment of this application; Figure 6 A schematic diagram illustrating an invoicing scenario provided in an embodiment of this application; Figure 7 A visual flowchart illustrating an invoice generation method provided in this application embodiment; Figure 8 A schematic diagram illustrating a process for generating a first invoicing plan page, provided as an embodiment of this application; Figure 9 A schematic diagram illustrating a first invoicing plan page provided for an embodiment of this application; Figure 10 A visual flowchart illustrating another invoice generation method provided in this application embodiment; Figure 11 A visual flowchart illustrating another invoice generation method provided in this application embodiment; Figure 12 A schematic diagram of a first invoicing plan page and a second invoicing plan page provided for embodiments of this application; Figure 13 A schematic diagram illustrating a possible modification and corresponding processing solution provided in an embodiment of this application; Figure 14 A flowchart illustrating another invoice generation method provided in this application embodiment; Figure 15 This is a schematic diagram of another computing device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0035] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0036] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0037] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0038] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0039] The embodiments of this application are mainly applied to the scenario of enterprise invoicing management.

[0040] In enterprise invoicing management, there is a strong reliance on industry-standard ERP solutions. The conventional process uses sales orders as the basis for invoicing, requiring invoicing to be performed after shipment or receipt. However, because the payment agreement maintained by the sales contract is not directly linked to the invoicing process, in scenarios such as advance payments (e.g., customers paying in advance), invoicing cannot be triggered by the sales order before actual goods delivery or service provision has occurred. The payment is directly linked to the contract, but the intermediate invoicing step is missing. The matching of the sales contract, sales order, and invoice can only be completed after the order is shipped or received. Furthermore, manual parsing of sales contracts is required, which is not only inefficient and prone to errors, but also results in a simplistic invoicing model that cannot meet the invoicing plans corresponding to diverse business scenarios.

[0041] This application provides an invoice generation method applied to a computing device. First, in response to a sales contract's activation instruction, first information from the sales contract is obtained. This first information includes: invoice type, sales entity information, and invoice milestones. Invoice milestones define the nodes that trigger invoicing during the execution of the sales contract. Second, based on the invoice type, sales entity information, and invoice milestones, invoice rules are determined. These rules include invoice triggering conditions and invoice triggering amounts. Then, based on the invoice triggering conditions and invoice triggering amounts, second information from the sales contract is obtained. This second information includes the sales contract's invoice amount, invoice period, invoice amount for each period, and expected invoice date. Finally, based on the invoice milestones, invoice triggering conditions, and second information, a first invoice plan page is generated. The first invoice plan page includes an invoice plan header and invoice plan lines. The invoice plan header includes the sales contract's invoice amount; the invoice plan lines include the invoice period, invoice amount for each period, expected invoice date, invoice milestones, and invoice triggering conditions. The first invoice plan page is used to instruct the generation of the invoice corresponding to the sales contract.

[0042] In this embodiment, by responding to the sales contract's activation instruction, first information from the sales contract is obtained. Based on this first information, invoicing rules are automatically matched, and second information is determined based on the invoicing rules. A first invoicing plan page is then generated based on the invoicing trigger conditions, invoicing milestones, and the second information to instruct the generation of the invoice corresponding to the sales contract. The first invoicing plan page uses its included invoicing plan header to achieve overall identification and control of the invoicing plan, and its included invoicing plan rows to clearly define the specific invoicing content for each period, giving the first invoicing plan page both overall control and detailed execution dimensions. Thus, using the sales contract as the basis for invoicing, the invoicing process can be triggered promptly in any business scenario (including advance payment scenarios), thereby improving the timeliness of matching sales contracts, sales orders, and invoices. Simultaneously, by automatically extracting the first information from the contract, replacing the traditional manual parsing of sales contracts, the efficiency of contract information parsing is improved and errors are reduced. Furthermore, based on the first piece of information, the system can accurately match the corresponding invoicing rules, flexibly adapt to changing business scenarios, meet the invoicing needs of different scenarios, and ultimately achieve full-process automation from sales contract to invoicing, thereby improving the overall efficiency and accuracy of invoicing.

[0043] The system architecture of the embodiments of this application will be described below as an example.

[0044] like Figure 1 As shown, this application provides a computing device.

[0045] The computing device, in response to the sales contract's activation instruction, acquires first information from the sales contract, including: invoice type, sales entity information, and invoice milestones. Invoice milestones define the nodes that trigger invoicing during the execution of the sales contract. The computing device is also used to determine invoicing rules based on the invoice type, sales entity information, and invoice milestones. The invoicing rules include invoice triggering conditions and invoice triggering amounts. The computing device is further used to acquire second information from the sales contract based on the invoice triggering conditions and invoice triggering amounts. The second information includes the sales contract's invoice amount, invoice period, invoice amount for each period, and expected invoice date. Furthermore, the computing device is used to generate a first invoicing plan page based on the invoice milestones, invoice triggering conditions, and second information. The first invoicing plan page includes an invoice plan header and invoice plan lines. The invoice plan header includes the sales contract's invoice amount. The invoice plan lines include the invoice period, invoice amount for each period, expected invoice date, invoice milestones, and invoice triggering conditions. The first invoicing plan page is used to instruct the generation of the invoice corresponding to the sales contract.

[0046] In some embodiments, the computing device is deployed with a rule configurator. This rule configurator is understood to be a software module / tool ​​for generating invoicing plan pages corresponding to sales contracts.

[0047] In one implementation, the rule configurator is configured with preset extraction rules for extracting first information from the sales contract. Accordingly, in response to the sales contract's activation command, the computing device extracts the first information from the sales contract based on the extraction rules through the rule configurator.

[0048] In one implementation, the rule configurator is configured with one or more invoicing scenarios. An invoicing scenario indicates the time and content involved in invoice generation. Accordingly, the computing device can use the rule configurator to determine the target invoicing scenario to which the sales contract belongs, based on initial information.

[0049] In one implementation, the rule configurator also configures the correspondence between invoicing scenarios and invoicing rules. Accordingly, the computing device determines the invoicing rule from a set of preset invoicing rules based on the correspondence and the target invoicing scenario through the rule configurator.

[0050] In one implementation, the rule configurator is configured with a template for the invoicing plan page. Accordingly, the computing device determines the template for the first invoicing plan page based on the invoicing rules. Second information is obtained based on the template of the first invoicing plan page. The computing device then uses the rule configurator to populate the invoicing milestones, invoicing trigger conditions, and second information into the template of the first invoicing plan page, thereby generating the first invoicing plan page.

[0051] In some embodiments, the computing device is further configured to obtain the current execution node of the sales contract and, in response to the execution node being a node defined as an invoicing milestone, generate an invoice corresponding to the sales contract based on the first invoicing plan page.

[0052] In some embodiments, the computing device is equipped with an invoicing module for generating invoices based on an invoicing plan page. The computing device generates invoices based on the invoicing plan page by invoicing the invoicing module. The invoicing module includes a first interface. In one implementation of the computing device generating invoices based on the first invoicing plan page, the computing device calls the first interface to generate invoices based on the first invoicing plan page.

[0053] In some embodiments, the computing device further comprises an approval module for approving generated invoices. The computing device approves the generated invoices by invoking the approval module. The approval module includes a second interface. In one implementation, the computing device further invokes the second interface to approve the generated invoices.

[0054] In this embodiment, the computing device can be a server. The server can be a single physical server or logical server, or it can be composed of two or more physical servers or logical servers that share different responsibilities, working together to achieve various server functions such as data processing and service provision.

[0055] In terms of hardware form, servers can be blade servers, high-density servers, rack servers, or tower servers, which are suitable for different application scenarios such as high-density cluster deployment in data centers and small enterprise server rooms.

[0056] like Figure 2 As shown, the hardware of a computing device includes a processor, a basic input / output system (BIOS) chip, a baseboard management controller (BMC), and memory, while the software mainly includes BIOS firmware, an out-of-band management module, and an operating system (OS).

[0057] The processor may include a central processing unit (CPU). In this embodiment, the various functions of the aforementioned computing device may be implemented by a processor (such as a CPU). For example, the processor generates an invoicing plan page corresponding to the sales contract by running a rule configurator.

[0058] The program code for the out-of-band management module can be stored in dedicated flash memory (such as the flash memory area built into the BMC chip, the flash memory area in the BIOS chip, etc.).

[0059] Memory, also known as internal memory or main memory, is installed in memory slots on the motherboard of a computing device and is connected to the CPU via the memory bus. It is mainly used for temporary storage of data and instructions, providing high-speed data read and write support for the processor.

[0060] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0061] For ease of understanding, the invoice generation method provided in this application embodiment will be described exemplarily below with reference to the above-described computing device and accompanying drawings.

[0062] like Figure 3 As shown, this application embodiment provides an invoice generation method. For example, it includes the following steps: S301-S304, which can be executed by a processor of a computing device, such as a CPU.

[0063] S301, in response to the sales contract effective instruction, obtain the first information in the sales contract.

[0064] The first information is obtained based on the third information. The third information is explained below as an example: For example, a sales contract includes third-party information (or, more commonly, invoicing contract information). This third-party information includes basic information and a payment agreement.

[0065] Among them, basic information includes main information.

[0066] The subject includes the seller (or, may also be referred to as the sales entity, performance provider, or invoicing entity), and may also include the purchaser (or, may also be referred to as the customer, sales customer, performance recipient, or settlement entity). Entity information includes the seller's information in the sales contract (or, may also be referred to as sales entity information). For example, the seller's information includes: a sales entity identifier, where the sales entity identifier includes the sales entity name (…). (Technology Limited Company) and / or sales entity code (such as Unified Social Credit Code: 91410100) Optionally, the seller's information may also include one or more of the following: the seller's registered address, seller's header, tax identification number, or the seller's representative office (including the representative office identifier and details). Optionally, the entity information may also include the buyer's information (or, as may be called, sales customer information). For example, the buyer's information includes: a customer identifier, where the customer identifier includes the customer name (e.g., ...). Group Limited Company) and / or customer code (such as Unified Social Credit Code: 91410100) Optionally, the purchaser's information may also include one or more of the following: customer coding relationships (including customer coding relationship identifiers and customer coding details), customer registered address, customer header or tax number, etc.

[0067] Optionally, the basic information may also include one or more of the following: contract identification information or contract expiration information.

[0068] Contract identification information is used to identify the sales contract. For example, contract identification information includes: contract number. -20250 0 -00 Optionally, the contract identification information may also include the contract version number (e.g., V1.0 (initial version) / V1.1 (first revised version, generated due to adjustments in purchase volume)), and / or, the contract type identifier. The contract type identifier defines the attribution of the sales contract, indicating the geographical location of the sales contract (e.g., domestic or overseas), and / or the business type scenario of the sales contract (e.g., equipment sales or service provision), for example, the contract type identifier for sales contract 1 is a domestic equipment sales contract or an overseas service contract.

[0069] Contract validity information indicates one or more of the following: the effective date, performance date, and expiration date of a sales contract. For example, Sales Contract 1: Signing Date: September 1, 2025; Effective Date: September 5, 2025 (requires both parties to affix their seals to become effective, and is later than the signing date); Performance Period: September 5, 2025 - December 31, 2025 (including equipment delivery, installation, commissioning, and acceptance); Expiration Date: June 30, 2026 (the 6-month warranty period ends after performance, and the contract becomes completely invalid).

[0070] The payment agreement includes invoice types and invoice milestones. Invoice type indicates the type of invoice stipulated in the sales contract, such as "tax invoice" or "commercial invoice." When the payment agreement defines invoices for different periods, the invoice type can be the invoice type for each period. Invoice milestones define the points in the sales contract execution process that trigger invoicing. For example, invoicing milestones may define triggers such as receipt of prepayment, equipment delivery, equipment acceptance, or completion of service fulfillment.

[0071] Optionally, the payment agreement may also include one or more of the following: payment period, payment amount for each period, invoice period, invoice amount for each period, invoice type, expected invoice date, start date, and expected delivery date. Invoice types may include "special invoice" or "general invoice," etc.

[0072] For example, for a sales contract, one or more invoices can be generated, depending on the terms of the payment agreement. For instance, Payment Period 1: Within 10 working days of the sales contract taking effect, the buyer pays 30% of the total contract amount. This can be understood as a prepayment. This corresponds to Invoicing Period 1: If the invoicing milestone defines the trigger for invoicing as the receipt of the prepayment, an invoice will be generated after the prepayment is received; the invoice type is: tax invoice; the invoice amount is 30% of the total amount; and the invoice type is "special VAT invoice". Payment Period 2: Within 15 working days of the buyer issuing the "Acceptance Certificate", 60% of the total contract amount will be paid. This can be understood as an acceptance payment. This corresponds to Invoicing Period 2: If the invoicing milestone defines the trigger for invoicing as the receipt of the acceptance payment, an invoice will be generated after the acceptance payment is received; the invoice type is: tax invoice; the invoice amount is 60% of the total amount; and the invoice type is "special VAT invoice". Payment Period 3: Within 10 working days after the warranty period ends, 10% of the total contract amount will be paid. This amount can be considered a warranty deposit. This corresponds to Invoicing Period 3: If the invoicing milestone is triggered by the receipt of the warranty deposit, an invoice will be generated after the warranty deposit is received; the invoice type is: tax invoice; the invoice amount is 10% of the total amount; and the invoice type is "special VAT invoice".

[0073] Optionally, third-party information may also include contract terms and / or contract details.

[0074] Contract terms specify one or more of the following: sales scenario, performance standards, acceptance requirements, liability for breach of contract, and dispute resolution. The sales scenario refers to the cooperation model of the sales contract (e.g., direct sales or channel sales). Acceptance requirements, for example, include: within 15 working days of equipment arrival, the purchaser shall complete appearance, quantity, and functional tests and issue an "Acceptance Certificate"; failure to raise objections within the time limit shall be deemed acceptance.

[0075] The contract details list records a detailed list of specific transaction items (such as equipment or services). For example, the equipment sold is: server host; specifications and model: Unit: Unit; Quantity: 10; Unit Price (excluding tax): 18,000 yuan; Amount (excluding tax): 180,000 yuan; Tax Rate: 13%; Amount including tax: 203,400 yuan; Remarks: Includes installation guidance. Another example: The service provided is: Server maintenance service; Specifications: 1 year on-site maintenance; Unit: Item; Quantity: 1; Unit Price (excluding tax): 30,000 yuan; Amount (excluding tax): 30,000 yuan; Tax Rate: 6%; Amount including tax: 31,800 yuan; Remarks: Covers 10 servers.

[0076] like Figure 4 As shown, the computing device displays the aforementioned invoicing contract information through a display interface. Optionally, the computing device may also display remarks through the display interface.

[0077] For example, the sales contract is the original sales contract. An original sales contract can refer to a sales contract signed for the first time by both parties without any changes (such as adjustments to the amount, changes in the parties involved, or modifications to the terms). Examples include a "Domestic Equipment Procurement Contract" or an "Overseas Service Cooperation Contract" signed for the first time between a company and a customer.

[0078] Another example is a sales contract that is an updated version of an initial sales contract. The initial sales contract is the original sales contract, or a sales contract that has been updated one or more times from the original sales contract. A sales contract updated from the original sales contract can be understood as a new version of the contract generated after changes to the original sales contract due to business needs (such as adjustments to the amount, changes in the subject, modifications to the performance milestones, etc.). For example, if the original sales contract is for equipment worth 1 million yuan, and it is adjusted to "1.2 million yuan" due to additional purchase, the adjusted "1.2 million yuan contract" is the "updated sales contract".

[0079] An enforcement directive is used to instruct a sales contract to be enforceable. Understandably, an enforcement directive is triggered when the seller and buyer agree that the sales contract will take effect.

[0080] As an example, the computing device receives a user-input activation command that triggers the sales contract to take effect.

[0081] In another example, if the current time is a preset time, a sales contract activation instruction is triggered, where the preset time is the preset effective time of the sales contract.

[0082] In this application embodiment, by providing two methods for receiving sales contract effectiveness instructions—one for users to manually trigger the effectiveness instruction and the other for automatic triggering of the effectiveness instruction based on a preset time point—the contract effectiveness requirements under different business scenarios are adapted, thereby improving the flexibility and accuracy of the sales contract effectiveness triggering logic.

[0083] The following is an illustrative description of the first information: The primary information includes: invoice type, seller information, and invoice milestones. This primary information can indicate the type of sales contract. Understandably, different pieces of primary information can distinguish between different types of sales contracts.

[0084] Optionally, the first information may also include one or more of the following: sales scenario, sales customer information, ownership of the sales contract, business scenario type of the sales contract, and the customer's industry. The customer's industry (also referred to as the customer's sector) indicates the customer's industry characteristics, such as telecom operators, government departments, or other enterprises. For example, the customer's industry information includes the customer's industry identifier and details of the customer's industry.

[0085] In one implementation of retrieving first information from a sales contract in response to an effective instruction of the sales contract, the first information is extracted from third information by a rule configurator based on extraction rules, and the extraction rules are set to extract the first information from the third information.

[0086] In one implementation method for retrieving primary information from a sales contract in response to its effective command, secondary information is also retrieved. This secondary information is then converted into structured data, from which the primary information is extracted. This transforms scattered unstructured information within the sales contract (such as entity information, payment agreements, and contract details) into a standardized, rapidly accessible data format. This allows for precise location and extraction of the primary information directly from the standardized structured data, reducing extraction time, ensuring consistency between the primary information and the core contract data, minimizing extraction errors, and improving overall process efficiency.

[0087] For example, the invoice type is extracted from the payment agreement and used as the invoice type in the first information.

[0088] For example, invoicing milestones can be extracted from the payment agreement, such as the aforementioned milestones after the prepayment is received, after the acceptance payment is received, and after the warranty deposit is received, as well as milestones such as "equipment delivery completed", "service acceptance passed", and "project progress reached 50%", and these can be used as invoicing milestones in the first piece of information.

[0089] For example, sales entity information is extracted from the main information and used as the sales entity information in the first information. Optionally, if the main information includes sales customer information, the sales customer information is extracted from the main information and used as the sales customer information in the first information. Yet another option is, if the main information includes purchaser information, the customer's industry is determined based on the purchaser information in the main information and used as the customer's industry in the first information. Furthermore, based on the purchaser information and the customer's industry in the main information, further customer sub-industries can be determined. For example, the customer sub-industry information includes a sub-industry identifier and sub-industry details.

[0090] For example, in the case where the structured data includes contract terms and the contract terms include a sales scenario, the sales scenario is extracted from the contract terms and used as the sales scenario in the first information.

[0091] For example, if the structured data includes contract identification information and the contract identification information includes contract type identification, the ownership relationship of the sales contract and / or the business scenario type of the sales contract are extracted from the contract identification information and used as the ownership relationship of the sales contract and / or the business scenario type of the sales contract in the first information.

[0092] Specifically, in response to the sales contract's effective instruction, the rule configurator extracts first information from the structured data based on the first extraction rule.

[0093] S302, based on invoice type, sales entity information and invoice milestones, determines invoice rules, which include invoice trigger conditions and invoice trigger amounts.

[0094] Invoicing rules are used to determine the invoicing plan. For example, invoicing rules include invoicing trigger conditions and invoicing trigger amounts. Invoicing trigger conditions are the conditions that trigger invoicing, used to translate the performance nodes for triggering invoicing stipulated in the sales contract into specific and verifiable execution standards, clarifying what conditions must be met to initiate the invoicing process.

[0095] In one implementation, the invoicing trigger condition can be determined based on the invoicing milestone.

[0096] For example, invoicing milestones that meet the criteria of being unique, clearly defined without further subdivision, and requiring no additional business execution information for judgment can be directly used as independent criteria to trigger invoicing. For instance, if the invoicing milestone is defined as issuing an invoice after the sales contract takes effect, then the invoicing trigger condition is directly the sales contract status taking effect.

[0097] In another implementation, the invoicing trigger condition can be determined based on invoicing milestones and execution details.

[0098] Due to the complexity of sales contracts, there are often various performance scenarios in actual performance, such as phased execution, batch delivery, phased acceptance, service provision in cycles, and payment collection in installments. Therefore, the triggering nodes defined by the invoicing milestone are usually macro-level nodes, and the invoicing triggering conditions need to be further refined by combining them with the execution details.

[0099] For example, execution details could be the service cycle. Specifically, the invoicing milestone might be service completion, but if technical services are provided in phases according to service cycles (monthly maintenance, quarterly implementation), the invoicing trigger condition is refined to the completion of the corresponding service cycle and customer confirmation. Each completed service cycle triggers the invoicing for that cycle. In this case, the first piece of information must include the business scenario type. If the business scenario type is a service, the invoicing trigger condition must be determined by combining the service cycle and the invoicing milestone.

[0100] For example, execution details could include payments received in installments (advance payments, progress payments, final payments). Specifically, the invoicing milestone might be the receipt of funds, but the contract stipulates payments received in installments (advance payments, progress payments, final payments). In this case, the invoicing trigger condition is refined to the full receipt of the corresponding number of payments stipulated in the contract. Once each agreed payment is received, the invoicing for that payment is triggered. In this scenario, the first piece of information should include the business scenario type, the customer's industry, or a specific sub-industry. Understandably, a fixed performance model for a specific industry or business scenario might involve payments received in installments, which by default requires separate payments and separate invoicing. For example, if the customer's industry is a telecom operator, and the business scenario type is large equipment sales or project implementation services, these industries and scenarios inherently possess the characteristics of payments received in installments. In this case, the invoicing trigger condition needs to be determined jointly by the payments received in installments and the invoicing milestone.

[0101] For example, execution details could include consolidated invoicing. Specifically, an invoicing milestone is defined as the completion of equipment delivery and service fulfillment triggering invoicing. If the sales contract is a mixed contract encompassing both equipment sales and service provision, the invoicing triggering conditions need to be refined based on the execution details of consolidated invoicing. If equipment delivery and service fulfillment are completed on the same date, the invoicing triggering condition is refined to the same date for both. Upon reaching this milestone, the contract amounts for the equipment and service are combined and invoiced accordingly. In this case, the first piece of information must include the business scenario type, the customer's industry, or the customer's sub-industry. The invoicing triggering conditions must be determined jointly by consolidated invoicing and invoicing milestones.

[0102] The invoice trigger amount is a calculation rule for the amount of each invoice issued corresponding to the invoice trigger condition, rather than a fixed specific amount. It specifies how the amount of the invoice to be issued should be determined when the invoice trigger condition is met, and its value is determined based on the invoice trigger amount.

[0103] For example, if the invoice issuance is triggered by the receipt of a prepayment, and the contract stipulates that the prepayment is 30% of the total contract amount, then the rule for the invoice issuance trigger amount is: total contract amount × 30%.

[0104] For example, if the invoicing trigger condition is the completion of quarterly maintenance services, and the contract stipulates that the quarterly maintenance fee is 50,000 yuan, then the rule for the invoicing trigger amount is: the maintenance service fee for the single quarter.

[0105] For example, the invoicing trigger condition is the equipment delivery date, and the contract includes both equipment sales and service provision. In this case, the rule for the invoicing trigger amount is: equipment amount + service agreement amount. When the trigger points for equipment delivery and service performance coincide, the system will automatically sum the amounts of the two types of items according to this rule, and use this sum as the calculation rule for the combined invoicing amount.

[0106] Because the content of different sales contracts varies greatly, the timing of invoicing also varies greatly. Therefore, by setting invoicing rules, the invoicing process can follow the contract performance progress, supporting automated invoicing, reducing manual intervention, and avoiding the problems of invoicing in advance or in delay.

[0107] like Figure 5 As shown, a specific implementation of the above step S302 is provided, which may include the following steps S3021-S3022.

[0108] S3021 determines the target invoicing scenario to which the sales contract belongs based on the invoicing type, sales entity information, and invoicing milestones.

[0109] The invoicing scenario is used to indicate the time points and content involved in the invoice generation. For example... Figure 6As shown, the computing device can display the invoicing scenario through a display interface, allowing users to access and interact with the invoicing scenario. For example, the invoicing scenario may specifically include one or more of the following types of information: The first type of information can be used to indicate the content involved in generating an invoice. For example, it includes the invoice type (e.g., tax invoice) and sales entity information (e.g., sales name). Representative office of the sales entity (if including representative office signage): Representative Office Details: ).

[0110] Optionally, the first type of information may also include one or more of the following: customer identification (such as customer code). Customer coding relationship (e.g., including customer coding relationship identifier:) Customer Code Details: ), customer registration address (e.g. ), the customer's industry (if including the customer's industry identifier: Customer industry details: ), customer segmentation by sub-industry (e.g., including sub-industry identifiers: Detailed breakdown of sub-sectors: ), sales scenario (such as including sales scenario identifier: Sales scenario details: One or more of the following: business scenario type (e.g., including applicable business type (e.g., equal to or including) and business type details (e.g., service or equipment)); and invoice type (e.g., "special invoice" or "general invoice").

[0111] Optionally, the first type of information may also include whether the sales contract amount including tax is 0 (e.g., no), whether the sales contract invoice amount is 0 (e.g., no), and whether the rules for triggering fraudulent transactions are met (e.g., ...). Invoice approval method (such as) ), rules for handling changes to sales contracts (such as The validity of the invoicing scenario (e.g., valid). The trigger rule for value manipulation refers to the rule that automatically updates relevant values ​​in the invoicing plan (e.g., the expected invoicing date in the plan line) when the sales contract changes. For example, invoicing approval methods can include one of the following: automatic system approval (e.g., automatic approval by the system based on preset rules (e.g., amount threshold, scenario compliance), manual approval (e.g., requiring manual review by finance, legal, etc.), or mixed approval (e.g., some stages are automatically reviewed, some stages are manually reviewed). The sales contract change processing rule indicates the processing specifications for the generated invoicing plan and invoices already issued / pending when the sales contract changes. The validity of the invoicing scenario indicates whether the invoicing scenario is valid or invalid.

[0112] The second type of information can be used to indicate the time points involved in invoice generation. For example, it includes invoicing milestones. Invoicing milestones include matching logic (such as include or equal to) and milestone details (such as order details). The matching logic for invoicing milestones indicates that the preset node defined by the invoicing milestone equals a specific execution node in the sales contract. For example, if the execution node of the sales contract is "equipment acceptance qualified," the preset node defined by the invoicing milestone corresponds to the complete achievement of the "equipment acceptance qualified" node. Alternatively, the matching logic for invoicing milestones indicates that the preset node defined by the invoicing milestone includes a specific execution node in the sales contract. For example, if the sales contract execution node includes multiple sub-nodes such as "equipment arrival," "installation completion," and "preliminary acceptance," the preset node defined by the invoicing milestone can correspond to the achievement of one of these sub-nodes.

[0113] Optionally, the second type of information may also include one or more of the following: conditions for automatically creating invoices (such as...). ), the start date of the planned operation (e.g. ), planned maturity date (e.g. ), the planned delivery date is as follows ), the planned invoice issuance date is as follows ), the planned actual delivery date is as follows For example, the condition for automatically creating an invoice can be that the current execution node of the sales contract is a preset node defined by the invoicing milestone. A planning line represents a single invoicing unit broken down based on the execution node of the sales contract. The planned line's estimated delivery date represents the theoretical delivery time of the equipment or service pre-planned based on the sales contract agreement or business expectations. The planned line's estimated invoicing date represents the theoretical invoicing time pre-set for this line. The planned line's actual delivery date represents the actual time when the equipment or service in this line is delivered.

[0114] Optional, continue as follows Figure 6 As shown, the invoicing scenario can also include an invoicing scenario identifier, such as the invoicing scenario number (and: CN). / or the name of the invoice issuance scenario.

[0115] Optional, continue as follows Figure 6 As shown, a serial number (e.g., 1) and a system number are set for each invoicing scenario to facilitate the management of each invoicing scenario.

[0116] Understandably, by using the aforementioned first and / or second types of information and other multi-dimensional information, a unique invoicing scenario is identified as the target invoicing scenario. Sales contracts are categorized into scenarios using the invoicing type and sales entity information from the first type of information, and the invoicing milestones from the second type of information as core filtering dimensions. Furthermore, anchoring can be done using key information such as sales scenario, business scenario type, and invoice type to exclude invoicing scenarios that are completely inconsistent with the core attributes of the sales contract. For example, if the first information of the sales contract clearly states that the sales scenario is "domestic," the business scenario type is "equipment sales," the invoicing type is "tax invoice," and the invoice type is "special invoice," then scenarios such as "overseas services," "commercial invoice issuance," and "general invoice application" can be directly filtered out, narrowing the candidate range. And / or, further precise filtering can be achieved based on the subdivided dimensions in the first type of information, such as sales customer information, the customer's industry, and sub-industries, to further refine the initially filtered scenarios. For example, if the initially screened scenarios include two categories: "domestic equipment sales to operator customers" and "domestic equipment sales to government customers," and considering the dimension that the customer's industry is operator in the first information of the sales contract, scenarios corresponding to government customers can be excluded, further focusing the matching scope. Simultaneously, by combining additional conditions in the first type of information, such as "whether the sales contract's tax-inclusive amount is 0" and "invoice approval method," scenarios that do not meet the contract amount attributes or approval requirements can be excluded, ensuring that the scenarios are consistent with the contract execution requirements. And / or, the second type of information can be used as the final locking dimension. Information related to time and triggering logic, such as the conditions for automatically creating invoices and the rules for planned line time nodes, can be used to uniquely confirm the remaining scenarios. For example, if the remaining scenarios all satisfy the attributes of "domestic equipment sales, operator, tax invoice, special invoice," but one scenario's invoicing milestone is "after the prepayment is received," and the other is "after equipment acceptance," and considering that the invoicing milestone extracted from the first information of the sales contract is "after the prepayment is received," and the "conditions for automatically creating invoices" in the second type of information completely match this invoicing milestone, then this scenario can be ultimately locked as the unique target invoicing scenario.

[0117] In this embodiment of the application, the scenario filtering is completed step by step through the multi-dimensional matching logic preset by the rule configurator, and finally the unique locking of the target invoicing scenario is achieved, which provides a foundation for subsequent accurate matching of invoicing rules and generation of invoicing plans that meet the contract requirements.

[0118] like Figure 7 As shown, in one possible implementation, the target invoicing scenario is determined by the rule configurator based on first information (such as invoice type, sales entity information, invoicing milestone, sales scenario, sales customer information, ownership of sales contract, business scenario type of sales contract, and industry of customer).

[0119] In one possible implementation, determining the target invoicing scenario to which the sales contract belongs based on the first information includes: matching the invoicing type in the first information with the invoicing type in the invoicing scenario to obtain a first matching result; matching the sales entity information in the first information (such as the sales entity name, the sales entity's representative office, etc.) with the sales entity information in the invoicing scenario to obtain a second matching result; and matching the invoicing milestones in the first information with the invoicing milestones in the invoicing scenario to obtain a third matching result. Among multiple invoicing scenarios, the invoicing scenario in which the first, second, and third matching results all indicate a successful match is identified and designated as the target invoicing scenario.

[0120] By precisely matching multi-dimensional information such as invoice type, sales entity information, and invoice milestones, the target invoice scenario is determined. Sales contracts are then categorized in a standardized manner from an invoice perspective, ensuring that contracts for the same invoice scenario belong to the same category. Even in business scenarios with numerous sales contracts, the target invoice scenario for each sales contract can be efficiently determined. This enables classified management of invoice dimensions for different sales contracts, laying a foundation for the subsequent unified adaptation of standardized invoice rules to similar contracts and the large-scale implementation of the invoice process.

[0121] For example, if the invoice type in the first piece of information is the same as the invoice type in the invoice scenario, the first matching result indicates a successful match; otherwise, the first matching result indicates a failed match. Other matching results can be obtained in the same way, and will not be elaborated upon here.

[0122] In another possible implementation, determining the target invoicing scenario to which the sales contract belongs, based on the first information, further includes: matching the sales scenario in the first information with the sales scenario in the invoicing scenario to obtain a fourth matching result; and / or matching the sales customer information (customer code, customer code relationship, customer registration address, etc.) in the first information with the sales customer information in the invoicing scenario to obtain a fifth matching result; and / or matching the customer's industry in the first information with the customer's industry in the invoicing scenario to obtain a sixth matching result; and / or matching the customer's sub-industry segment in the first information with the customer's sub-industry segment in the invoicing scenario to obtain a seventh matching result; and / or matching the business scenario type in the first information with the business scenario type in the invoicing scenario to obtain an eighth matching result.

[0123] Based on more dimensions of information matching, the more information dimensions are selected, the more refined the division and matching of invoicing scenarios becomes, and the more accurate the positioning of the target invoicing scenario becomes, ultimately resulting in a target invoicing scenario with a higher degree of matching with the sales contract.

[0124] If the invoicing scenario includes the above-mentioned invoicing type, sales scenario, sales entity information, sales customer information, customer industry, customer sub-industry, business scenario type, and invoicing milestone, and the first matching result, second matching result, third matching result, fourth matching result, fifth matching result, sixth matching result, seventh matching result, and eighth matching result all indicate a successful match, then the invoicing scenario is determined as the target invoicing scenario.

[0125] The following examples illustrate the "first correspondence between first information and invoicing scenario" using different invoicing scenarios (e.g., invoicing scenario 1) and different first information (e.g., first information 1): For example, the information in invoicing scenario 1 includes: sales scenario: domestic; business scenario type: equipment sales; sales entity information: the seller is... Technology Co., Ltd. (Registered in China, Unified Social Credit Code 91410100) Sales customer information: The buyer is Limited Liability Company (Operator-type, Registered Location) The customer's industry is: Telecom Operator; Invoice type: Tax Invoice; Invoice milestone: Equipment acceptance passed (corresponding to an invoice amount of 60% of the total contract amount), etc. If the first piece of information 1 includes: Invoice type: Tax Invoice; Sales scenario: Domestic; Business scenario type: Equipment sales; Sales entity information: Seller is... Technology Co., Ltd. (Registered in China, Unified Social Credit Code 91410100) Sales customer information: The buyer is Limited Liability Company (Operator-type, Registered Location) Customer's industry: Telecom operator; Invoice type: Tax invoice; Invoice milestone: Equipment acceptance passed (corresponding invoice amount is 60% of the total contract amount). Therefore, invoice scenario 1 can be the target invoice scenario.

[0126] S3022, based on the target invoicing scenario, determines the invoicing rule from multiple invoicing rules.

[0127] In an implementation method that determines the invoicing rule from multiple invoicing rules based on a target invoicing scenario, the rule configurator determines the invoicing rule corresponding to the target invoicing scenario from multiple preset invoicing rules based on the correspondence between the invoicing scenario and the invoicing rules.

[0128] For example, the correspondence between invoicing scenarios and invoicing rules can be user-defined and pre-stored in the computing device. Understandably, the information included in the invoicing scenario is used to distinguish different sales contracts, thereby determining the invoicing rules corresponding to each sales contract.

[0129] For example, different invoicing scenarios can correspond to different invoicing rules. Scenario A indicates domestic direct sales of equipment, with the invoicing milestone indicating a 30% invoicing rate after receiving advance payment; its corresponding invoicing rule 1 could be: 30% initial invoicing rate, triggered by advance payment receipt. Similarly, scenario B indicates overseas service channels, with the invoicing milestone indicating service commencement; its corresponding invoicing rule 2 could be: 40% initial invoicing rate, triggered by service commencement, and so on. Alternatively, different invoicing scenarios can correspond to the same invoicing rule. For example, scenario C indicates domestic direct sales of equipment, with the sales contract invoicing amount not zero; scenario D indicates domestic consumable procurement, with the sales contract invoicing amount not zero. Both can correspond to invoicing rule 3, which could be: full invoicing, triggered by goods delivery, etc.

[0130] In this embodiment, based on the pre-configured binding relationship (such as correspondence) between invoicing scenarios and invoicing rules configured by the rule configurator, the rule corresponding to the target invoicing scenario is accurately located from multiple preset invoicing rules, realizing the automatic matching of invoicing rules and sales contracts, reducing the intervention error of manual rule screening, improving the efficiency of rule matching, and ensuring that the matched invoicing rules are highly compatible with the target invoicing scenario, thereby improving the accuracy of the subsequent generation of invoicing plans that meet the invoicing requirements of the sales contract.

[0131] Continue as Figure 7 As shown, invoicing rules are generated based on the target invoicing scenario.

[0132] S303, based on the invoicing trigger conditions and the invoicing trigger amount, obtain the second information in the sales contract.

[0133] The second piece of information includes the invoice amount of the sales contract, the invoice period, the invoice amount for each period, and the expected invoice date.

[0134] Optionally, the second information may also include the start date and / or the expected delivery date.

[0135] For example, the invoice amount, invoice period, invoice amount for each period, and expected invoice date are extracted from the payment agreement in the structured data and used as second information. Optionally, if the second information includes the start date and / or expected delivery date, and the payment agreement also includes the start date and / or expected delivery date, the start date and / or expected delivery date are extracted from the payment agreement.

[0136] like Figure 8 As shown, a specific implementation of the above step S303 is provided, which may include the following steps S3031-S3032.

[0137] S3031, Based on the invoice triggering conditions and the invoice triggering amount, determine the template for the first invoice plan page.

[0138] There is a correspondence between invoicing rules and templates. For example, different invoicing rules correspond to different templates. The template corresponding to the invoicing rule is used as the template for the first invoicing plan page, which is used to generate the first invoicing plan page.

[0139] For example, the template's fields include invoice amount, invoice period, invoice amount for each period, expected invoice date, invoice milestone, and invoice trigger condition. Optionally, the template may also include a start date and / or expected delivery date.

[0140] S3032, based on the template, obtain the second information.

[0141] In one possible implementation, obtaining the second information based on a template includes: extracting information corresponding to the bytes of the template from the structured information based on the template's fields, and using this information as the second information. This allows for efficient and accurate extraction of the second information.

[0142] Since the invoicing rules define how to issue invoices (e.g., "when to issue, how much to issue, and how many installments"), the second information is the specific data supporting the implementation of the invoicing plan. Therefore, extracting the second information through the invoicing rules ensures accurate matching between the data and the invoicing rules, avoiding a disconnect between the invoicing plan and contractual agreements or business scenarios. For example, the invoicing trigger condition in the invoicing rules is "after the prepayment is received," and the invoicing amount is "30% of the total contract amount" (the first installment). The second information extracted based on this rule includes: invoicing amount (30% of the total contract amount), invoicing amount for each installment (30% of the total amount), invoicing milestone (prepayment received), invoicing trigger condition (prepayment receipt record is verifiable), start date (contract effective date), and expected invoicing date (within 10 working days after the start date). The invoicing rules clearly state "prepayment must be received before the first installment invoice is issued," so the second information is data related to "prepayment" and "first installment amount."

[0143] S304, based on the invoicing milestone, invoicing triggering conditions, and second information, generate the first invoicing plan page.

[0144] An invoicing plan is an executable program that instructs the execution plan for generating invoices for sales contracts. The invoicing plan page is a system-side visual interactive page that carries out the entire lifecycle management of the invoicing plan, and serves as the medium for users to interact with the executable invoicing plan program.

[0145] like Figure 9 As shown, the computing device can also display a first invoicing plan page via a display interface. For example, the first invoicing plan page includes an invoicing plan header and invoicing plan lines. The invoicing plan header includes the invoicing amount of the sales contract, which may include the amount due for invoicing, the amount already invoiced, and the amount not yet invoiced. Optionally, the invoicing plan header may also include a plan identifier and / or plan status (e.g., valid) for the first invoicing plan page. The plan identifier identifies the first invoicing plan page and may include a plan number (e.g., number 1) and / or a plan version (e.g., version V1). The plan number serves as a business primary key and is used to associate with subsequent processes. The plan status indicates whether the first invoicing plan is valid. The invoicing plan lines include the invoicing period (e.g., invoicing period 1), the invoicing amount for each period, the expected invoicing date, invoicing milestones, and invoicing trigger conditions. The expected invoicing date indicates the scheduled invoicing date. Optionally, the invoicing plan lines may also include a start date and / or an expected delivery date. The start date indicates the initial date that triggers the invoicing process. The estimated delivery date indicates the date on which the scheduled goods (equipment or services) will be delivered.

[0146] Continue as Figure 8 As shown, a specific implementation of the above step S304 is provided, which may specifically include the following step S3041.

[0147] S3041, fill the template with the second information, invoicing milestones and invoicing trigger conditions to generate the first invoicing plan page.

[0148] For example, the second information, invoicing milestones, and invoicing trigger conditions are filled into the template according to the corresponding items in the template. In this embodiment of the application, it can be ensured that the information included in the first invoicing plan page accurately corresponds to the contract invoicing requirements, and the template based on the first invoicing plan page can improve the standardization of the format and content of the invoicing plan page, and improve the accuracy and standardization of the generation of the first invoicing plan page.

[0149] In one implementation, the method further includes: the computing device generating a plan identifier based on the first invoicing plan page. Thus, the first invoicing plan page is identified by the plan identifier, facilitating operation and maintenance management.

[0150] In one implementation, the method further includes: receiving a user-triggered setting operation on the plan status of the first invoicing plan page, and in response to the setting operation, setting the plan status of the first invoicing plan page. This allows users to manually operate and flexibly control the plan status of the first invoicing plan page, adapting to the needs of adjusting the invoicing plan status in business scenarios, and ensuring the human controllability and business adaptability of the invoice generation process.

[0151] In one implementation, the invoicing period is determined based on the order of the nodes that trigger invoicing as defined by the invoicing milestones. Since the invoicing milestones define the nodes that trigger invoicing during the execution of the sales contract, if the node defined by the invoicing milestones is the receipt of the prepayment, then an invoice is generated after the prepayment is received, and this invoicing period can correspond to invoicing period 1. If the node defined by the invoicing milestones is the receipt of the acceptance payment, then an invoice is generated after the acceptance payment is received, and this invoicing period can correspond to invoicing period 2.

[0152] Optional, such as Figure 9 As shown, the invoicing plan line may also include one or more of the following: invoicing currency (e.g., RMB), invoicing percentage (e.g., 20%), customer relationship management (CRM) invoicing milestones, triggering materials, and remarks. The invoicing percentage refers to the proportion of the invoiced amount in the sales contract invoicing amount. CRM invoicing milestones indicate the nodes in the entire invoicing process. Triggering materials indicate the basis for triggering invoicing.

[0153] Optional, such as Figure 9 As shown, sequence numbers are set for different invoice planning lines, such as sequence number 1.

[0154] like Figure 10As shown, after a contract (such as a sales contract) takes effect, an invoicing plan page (such as the first invoicing plan page) is generated based on the rule configurator.

[0155] In some embodiments, continue as follows Figure 10 As shown, after generating the invoicing plan page (such as the first invoicing plan page), an approval operation is performed on the invoicing plan page (such as the first invoicing plan page) based on the sales contract (i.e., the invoicing plan page is approved). The approval operation here is used to instruct the information included in the invoicing plan page to be checked based on the sales contract, so as to ensure the accuracy of the invoicing plan page.

[0156] In some embodiments, the method may further include: obtaining the current execution node of the sales contract; and generating an invoice corresponding to the sales contract based on the first invoicing plan page in response to the execution node being a node defined as an invoicing milestone.

[0157] Understandably, when execution reaches the node defined by the invoicing milestone, if the invoicing trigger condition indicates invoicing in installments (such as invoicing after each payment is received, or invoicing after each batch of equipment is delivered), the sales contract needs to be invoiced at multiple execution nodes triggered by the invoicing trigger condition. Each node that triggers invoicing corresponds to a different invoicing period, such as invoicing period 1 and invoicing period 2, and each invoicing period has a corresponding invoicing amount.

[0158] In one implementation, the invoice amount for each invoice corresponding to a sales contract is the same as the invoice amount for each period. This ensures a one-to-one correspondence between the invoice amount for each invoice and the invoice amount for each period, guaranteeing accurate matching of invoice amounts.

[0159] For example, different invoice types have different invoice templates. The invoice template includes fields for amount and other information. The amount for each invoice period is entered into the amount field of the invoice template. Information corresponding to the other information fields is obtained from third-party information sources and entered into those fields. For example, other information fields may include: seller name, unified social credit code (tax number), registered address, contact number, bank name and account number; purchaser name, unified social credit code (tax number), registered address, contact number, bank name and account number, transaction details, etc.

[0160] Continue as Figure 7 As shown, based on the target invoicing scenario, the automatic triggering rules corresponding to the sales contract are determined. For example, the execution node is the preset node defined by the invoicing milestone. The automatic triggering rules define the planned line delivery date, the planned line invoicing date, and the planned line actual delivery date.

[0161] Continue as Figure 10As shown, after the approval of the invoice plan page (such as the first invoice plan page), if the approval is successful, the invoice plan page (such as the first invoice plan page) is applied based on the invoice triggering conditions, that is, the invoice is generated based on the invoice plan page.

[0162] In one implementation of generating an invoice corresponding to a sales contract based on the first invoicing plan page, the first interface is called to generate an invoice corresponding to the sales contract based on the first invoicing plan page.

[0163] Optionally, before calling the first interface, the computing device generates an invoice application form based on the first invoicing plan page, and calls the first interface based on the invoice application form to generate an invoice based on the invoice application form. For example, if the first invoicing plan page indicates that multiple invoicings are required, that is, multiple invoicing periods, then each time the invoicing trigger condition is met, an invoice application form corresponding to the current invoicing period is generated based on the first invoicing plan page. The first interface is then called based on the invoice application form corresponding to the current invoicing period to generate the invoice corresponding to the current invoicing period.

[0164] Continue as Figure 10 As shown, after triggering the generation of an invoice based on the invoicing plan page (such as the first invoicing plan page), an application is made to generate an invoice based on the invoicing plan page (such as the first invoicing plan page) to generate an invoice.

[0165] In some embodiments, after generating an invoice, the computing device also invokes a second interface to approve the generated invoice. This enables automatic approval of generated invoices, improving approval efficiency and accuracy.

[0166] In other embodiments, after generating the invoice, the computing device also displays the invoice through a display interface and, in response to the user's approval action, sets the invoice as a valid invoice. Thus, by setting up a user-based approval process, the accuracy of the generated invoices is ensured.

[0167] Continue as Figure 10 As shown, after an invoice is generated, it is approved (i.e., the invoice is approved). If the sales contract changes, the invoicing plan page (such as the first invoicing plan page) is adjusted to generate a new invoicing plan page, and the new invoicing plan page is then approved.

[0168] In some embodiments, the method further includes: if no invoice corresponding to the sales contract is generated based on the first invoicing plan page, marking the first invoicing plan page as a first state, the first state indicating that no invoice has been generated based on the invoicing plan page; and if an invoice corresponding to the sales contract is generated based on the first invoicing plan page, marking the first invoicing plan page as a second state, the second state indicating that an invoice has been generated based on the invoicing plan page.

[0169] The invoicing plan's execution results are marked with a first state and a second state, clearly distinguishing between the two core states of "not yet invoiced" and "invoiced." This enables visual tracking of the invoicing plan's execution status, preventing duplicate or missed invoicing and improving the standardization and traceability of the invoicing process.

[0170] like Figure 11 As shown, based on the sales contract, a sales order is generated upon contract execution, and goods are shipped according to the sales order. Optionally, an invoice can be generated based on the sales order after the goods are shipped. Alternatively, based on the sales contract, an invoicing scenario and an invoicing plan page are determined. When the invoicing trigger condition is triggered (such as sales shipment or other nodes stipulated in the sales contract), an invoice is generated based on the first invoicing plan page. Payment is received after the invoice is generated.

[0171] In some embodiments, when the sales contract is an updated version of the initial sales contract, the method further includes: deactivating the second invoicing plan page if no invoice has been generated based on the second invoicing plan page. The second invoicing plan page is an invoicing plan page generated based on an invoicing rules page that matches the initial sales contract. If an invoice has already been generated based on the second invoicing plan page, and the first information of the sales contract changes, a red-ink invoice is generated based on the second invoicing plan page, such as generating a red-ink invoice with the same amount as the target invoice. If the first information of the sales contract has not changed and the change to the sales contract meets preset change conditions, a preset operation is performed on the target invoice generated based on the second invoicing plan page based on the preset change conditions.

[0172] Understandably, the target invoice is based on the invoice already generated on the first invoicing plan page.

[0173] For example, when the second invoicing plan page is marked as "first state," the computing device determines that no invoice has been generated based on the second invoicing plan page. When the second invoicing calculation page is marked as "second state," the computing device determines that an invoice has been generated based on the second invoicing plan page.

[0174] Understandably, "invoices generated based on the second invoicing plan page" can be interpreted as the second invoicing plan page triggering invoice generation. This can be further divided into two scenarios: one, the second invoicing plan page has begun generating some invoices but not all invoices; and two, the second invoicing plan page has generated all invoices. In other words, if invoices have been generated based on the second invoicing plan page, it means that one or more invoices may have been generated, and the total amount of these invoices may be less than the invoice amount in the sales contract. If all invoices have been generated based on the second invoicing plan page, it means that all invoices have been generated, and the total amount of these generated invoices equals the invoice amount in the sales contract.

[0175] In this embodiment, in the scenario of updating a sales contract that is the initial sales contract, different operations are performed based on the application status of the second invoicing plan page. For example, if the second invoicing plan page is not applied, it can be directly set to invalid, which can avoid duplicate or incorrect invoicing caused by the disconnect between the old invoicing plan page and the updated contract. If the second invoicing plan page is applied, and the first information changes, a red-ink invoice is generated based on the second invoicing plan page to reverse the target invoice. This can promptly correct the discrepancy between the original invoice and the invoicing information corresponding to the updated contract, ensuring that the invoice content is consistent with the current contract information and complies with tax and business compliance requirements. If the first information remains unchanged and the change meets preset conditions, the target invoice is processed according to preset operations. This allows for flexible adaptation to contract change requirements that comply with rules while retaining compliant invoices that have already been generated, avoiding redundant operations when a red-ink reversal is not required. In this way, the standardization and efficiency of invoicing processing in contract change scenarios are improved.

[0176] For example, if the sales contract is an updated version of the initial sales contract, the second invoicing plan page can represent the invoicing plan page corresponding to the old version of the sales contract, and the first invoicing plan page can represent the invoicing plan page corresponding to the new version of the sales contract. Therefore, if... Figure 12 As shown, if the first information of the sales contract changes, some or all of the information on the first invoicing plan page will change compared to the second invoicing plan page.

[0177] For example, in the above embodiment, the invoice type corresponding to the sales contract is a commercial invoice.

[0178] For example, the preset change conditions include that the change to the sales contract does not affect the validity of the target invoice, and the preset operation includes migrating the target invoice data to the first invoicing plan page. Thus, when the change to the sales contract does not affect the validity of the target invoice, migrating the target invoice data to the first invoicing plan page avoids redundant operations when there is no need for a red-ink reversal, ensuring data consistency between already issued valid invoices and the updated invoicing plan page. This guarantees invoice compliance and improves the efficiency of the invoicing process in contract change scenarios.

[0179] In the example above, if the invoice amount on the first invoicing plan page differs from the amount in the target invoice, an invoice will continue to be generated based on the first invoicing plan page. This is because after inheriting the data from the target invoice on the first invoicing plan page, the invoice amount differs from the invoice amount on the first invoicing plan page. Therefore, it is necessary to continue generating an invoice based on the first invoicing plan page to reduce the invoice amount of the target invoice, or to issue a supplementary invoice.

[0180] In another example, the preset change conditions include a decrease in the invoice amount of the sales contract. The preset operations include migrating the data of the target invoice to the first invoicing plan page and continuing to generate invoices based on the first invoicing plan page. In this example, the first invoice (also known as a credit invoice) continues to be generated based on the first invoicing plan page, and the first invoice is used to reduce the invoice amount of the target invoice.

[0181] Thus, in scenarios where the sales contract invoice amount decreases, by migrating the target invoice data to the first invoicing plan page and generating a first invoice to offset the target invoice amount, the deviation between the original invoice amount and the changed contract amount can be accurately corrected, ensuring that the invoice amount is consistent with the current contract requirements.

[0182] In another example, the preset change conditions include an increase in the invoice amount of the contract. The preset operations include: migrating the data of the target invoice to the first invoicing plan page, and continuing to generate invoices based on the first invoicing plan page. In this example, continuing to generate invoices based on the first invoicing plan page includes: determining whether to generate a second invoice based on an approval operation, whereby the approval operation indicates whether a second invoice needs to be issued, and generating a second invoice (also known as a positive invoice) in response to the approval operation indicating that a second invoice needs to be issued. For example, the second invoice represents an invoice generated by the seller to record the amount received for the sale of goods or services and the corresponding output tax.

[0183] Thus, in scenarios where the sales contract invoice amount increases, migrating the target invoice data to the first invoicing plan page and combining the approval process to decide whether to generate a formal invoice can not only accurately correct the discrepancy between the original invoice amount and the changed contract amount, but also control the compliance of the reissue process through the approval process, thereby improving the standardization and efficiency of invoicing processing in contract change scenarios.

[0184] In some embodiments, if the reason for the change of a sales contract is cancellation, the sales contract is set to invalid, and the target invoice is reversed. Thus, when a sales contract is changed to cancellation, setting the sales contract to invalid and reversing the target invoice promptly terminates the business association of the invalid contract, eliminates invoice records without corresponding actual transactions, and ensures that the invoicing data is consistent with the contract status.

[0185] like Figure 13 The diagram illustrates different processing schemes based on the changes made to a sales contract. If the old sales contract has not yet been invoiced, and the change pertains to the first piece of information, the processing scheme is as follows: invalidate the old sales contract, invalidate the invoicing plan page corresponding to the old sales contract, invalidate the information extracted from the old sales contract, and regenerate the invoicing plan page corresponding to the new sales contract. If the sales contract is cancelled, the processing scheme is as follows: invalidate the old sales contract, invalidate the invoicing plan page corresponding to the old sales contract, invalidate the information extracted from the old sales contract, and invalidate the regenerated invoicing plan page corresponding to the new sales contract. If some or all invoices have been generated for the old sales contract, and the invoiced amount of the new sales contract has not changed compared to the old sales contract, the processing scheme is as follows: invalidate the old sales contract, migrate the generated invoice data to the invoicing plan page corresponding to the new sales contract, and regenerate the invoicing plan page corresponding to the new sales contract. If the invoice amount of the new version of the sales contract is larger than that of the old version, the corresponding solution is to: invalidate the old version of the sales contract, migrate the data of the generated invoices to the invoicing plan page corresponding to the new version of the sales contract, regenerate the invoicing plan page corresponding to the new version of the sales contract, and automatically issue a supplementary positive invoice. If the invoice amount of the new version of the sales contract is smaller than that of the old version, the corresponding solution is to: invalidate the old version of the sales contract, migrate the data of the generated invoices to the invoicing plan page corresponding to the new version of the sales contract, regenerate the invoicing plan page corresponding to the new version of the sales contract, and automatically issue a supplementary credit invoice.

[0186] Continue as Figure 7 As shown, based on the target invoicing scenario, the contract modification rules under the target invoicing scenario are determined, and the contract modification rules define one or more of the above-mentioned processing schemes.

[0187] like Figure 14As shown, this application embodiment provides another invoice generation method, which includes, for example, the following steps: S1401-S1404, which can be executed by the processor of a computing device, such as a CPU.

[0188] S1401, in response to the sales contract effective instruction, obtain the first information in the sales contract.

[0189] S1402, based on the invoice triggering conditions and the invoice triggering amount, obtain the second information in the sales contract.

[0190] S1403, obtain the current execution node of the sales contract.

[0191] S1404, in response to the node defined by the execution node as the invoicing milestone, generates the invoice corresponding to the sales contract based on the invoicing milestone, the invoicing triggering condition, and the second information.

[0192] In this embodiment, after the invoice generation trigger node is triggered, invoicing is directly performed based on the invoicing milestone, invoicing trigger conditions, and second information, realizing a fully automated invoice generation process for sales contracts, which is more efficient. It can improve the timeliness of matching sales contracts, sales orders, and invoices in any business scenario, achieving automation from sales contract to invoice generation, and meeting the invoicing needs of diverse business scenarios.

[0193] In one implementation, in response to an execution node defined as an invoicing milestone, an invoice corresponding to the sales contract is generated based on the invoicing milestone, invoicing trigger conditions, and second information. This includes: in response to an execution node defined as an invoicing milestone, filling the template of the first invoicing plan page with the second information, invoicing milestone, and invoicing trigger conditions, thus generating the first invoicing plan page. The invoice corresponding to the sales contract is then generated based on the first invoicing plan page. In this way, when an invoicing milestone node is triggered, the invoicing plan page is automatically and standardizedly generated based on the second information, invoicing milestone, and invoicing trigger conditions, and then the invoice is generated accordingly. This achieves automated connection between invoicing plan page generation and invoice generation, improving the execution efficiency of the invoicing process and ensuring accurate matching between the information on the invoicing plan page and the invoicing rules.

[0194] The foregoing primarily describes the solutions provided by the embodiments of this application from a methodological perspective. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0195] like Figure 15 As shown, this application embodiment provides another computing device 500. The computing device 500 includes a processor 510 and a memory 520 for storing processor-executable instructions. When the processor 510 is configured to execute instructions, the computing device 500 implements the invoice generation method described above.

[0196] Figure 15 The computing device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0197] The computing device 500 is manifested in the form of a general-purpose computing device. The components of the computing device 500 may include, but are not limited to: one or more processors 510, memory 520, communication bus 540 connecting different system components (including memory 520 and processor 510), and communication interface 530.

[0198] The communication bus 540 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0199] Computing device 500 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computing device, including volatile and non-volatile media, removable and non-removable media.

[0200] Memory 520 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The computing device may further include other removable / non-removable, volatile / non-volatile computer system storage media. Although Figure 15As not shown, a disk drive may be provided for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and a removable non-volatile optical disk (e.g., a compact disc read-only memory; hereinafter referred to as CD). ROM (Read-Only Memory Disc); Digital Video Disc Read Only Memory (hereinafter referred to as DVD) An optical disc drive that reads and writes to ROM or other optical media. In these cases, each drive can be connected to the communication bus 540 through one or more data media interfaces. The memory 520 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0201] A program / utility having a set (at least one) of program modules can be stored in memory 520. Such program modules include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The program modules typically perform the functions and / or methods described in the embodiments of this application.

[0202] The computing device 500 can also communicate with one or more external devices (e.g., keyboard, pointing device, display, etc.), and with one or more devices that enable a user to interact with the computing device, and / or with any device that enables the computing device to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). This communication can be performed through the communication interface 530. Furthermore, the computing device 500 can also communicate through a network adapter (… Figure 15 (Not shown) communicates with one or more networks (e.g., Local Area Network (LAN), Wide Area Network (WAN), and / or public networks, such as the Internet). The aforementioned network adapter can communicate with other modules of the computing device via the communication bus 540. It should be understood that, although... Figure 15 As not shown, the computing device 500 may be used with other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Arrays of Independent Drives (RAID) systems, tape drives, and data backup storage systems.

[0203] The processor 510 executes various functional applications and data processing by running programs stored in the memory 520, such as implementing the methods described above in the embodiments of this application.

[0204] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the computing device 500. In other embodiments of this application, the computing device 500 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0205] It is understood that the aforementioned computing devices, etc., include hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, in conjunction with the exemplary units and algorithm steps described in conjunction with the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware-driven or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0206] This application embodiment can divide the above-mentioned computing device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0207] This application also provides a storage medium storing computer program instructions. When the computer program instructions are executed by a computing device, the computing device performs the method described above.

[0208] This application also provides a computer program product, which includes a computer program that, when at least one processor executes the computer program, causes the at least one processor to perform the methods described above in this application.

[0209] The computing device, storage medium, or computer program product provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0210] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0211] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0212] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0213] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating invoices, characterized in that, Applied to a computing device, the method includes: In response to the sales contract's effective instruction, the first information in the sales contract is obtained, including: invoice type, sales entity information, and invoice milestone, wherein the invoice milestone is used to define the node that triggers invoicing during the execution of the sales contract; Based on the invoice type, the sales entity information, and the invoice milestone, invoice rules are determined, including invoice triggering conditions and invoice triggering amounts. Based on the invoicing trigger condition and the invoicing trigger amount, the second information in the sales contract is obtained. The second information includes the invoicing amount of the sales contract, the invoicing period, the invoicing amount of each period, and the expected invoicing date. Based on the invoicing milestone, the invoicing triggering condition, and the second information, a first invoicing plan page is generated; the first invoicing plan page includes an invoicing plan header and an invoicing plan line; the invoicing plan header includes the invoicing amount of the sales contract; the invoicing plan line includes the invoicing period, the invoicing amount of each period, the expected invoicing date, the invoicing milestone, and the invoicing triggering condition; the first invoicing plan page is used to instruct the generation of the invoice corresponding to the sales contract.

2. The method according to claim 1, characterized in that, The process of determining invoicing rules based on the invoicing type, the sales entity information, and the invoicing milestones includes: Based on the invoice type, the sales entity information, and the invoice milestone, the target invoice scenario to which the sales contract belongs is determined; Based on the target invoicing scenario, the invoicing rule is determined from multiple invoicing rules.

3. The method according to claim 1 or 2, characterized in that, After generating the first invoicing plan page based on the invoicing milestone, the invoicing triggering condition, and the second information, the method further includes: Obtain the current execution node of the sales contract; In response to the execution node being a node defined by the invoicing milestone, the first interface is invoked to generate an invoice corresponding to the sales contract based on the first invoicing plan page.

4. The method according to any one of claims 1-3, characterized in that, The step of obtaining the second information in the sales contract based on the invoicing trigger condition and the invoicing trigger amount includes: Based on the invoicing trigger conditions and the invoicing trigger amount, determine the template for the first invoicing plan page; Based on the template, obtain the second information; The process of generating a first invoicing plan page based on the invoicing milestone, the invoicing triggering condition, and the second information includes: The second information, the invoicing milestone, and the invoicing triggering condition are filled into the template to generate the first invoicing plan page.

5. The method according to any one of claims 1-4, characterized in that, The step of obtaining the first information in the sales contract in response to the sales contract's effective instruction includes: In response to the sales contract's effective command, obtain third information from the sales contract, the third information including entity information and payment agreement; Convert the third information into structured data; Extract the first information from the structured data.

6. The method according to any one of claims 1-5, characterized in that, In the case that the sales contract is an updated version of the initial sales contract, the method further includes: If an invoice is not generated based on the second invoicing plan page, the second invoicing plan page is set to invalid. The second invoicing plan page is an invoicing plan page generated based on invoicing rules that match the initial sales contract. If an invoice has already been generated based on the second invoicing plan page, and the first information of the sales contract changes, a red-letter invoice is generated based on the second invoicing plan page; if the first information of the sales contract has not changed and the change of the sales contract meets the preset change conditions, then a preset operation is performed on the target invoice generated based on the second invoicing plan page based on the preset change conditions.

7. The method according to claim 6, characterized in that, The preset change conditions include that changes to the sales contract do not affect the validity of the target invoice, and the preset operation includes: migrating the data of the target invoice to the first invoicing plan page; or, The preset change conditions include a decrease in the invoice amount of the sales contract, and the preset operation includes: migrating the data of the target invoice to the first invoicing plan page and generating a first invoice, which is used to reduce the invoice amount of the target invoice; or, The preset change conditions include an increase in the invoice amount of the contract. The preset operation includes: migrating the data of the target invoice to the first invoicing plan page, and determining whether to generate a second invoice based on the approval operation. The approval operation is used to indicate whether a second invoice needs to be reissued, and generating the second invoice in response to the approval operation indicating that a second invoice needs to be reissued.

8. The method according to any one of claims 1-7, characterized in that, Before obtaining the first information in the sales contract in response to the sales contract's effective instruction, the method further includes: Receive a user-input instruction to trigger the sales contract to take effect; or, If the current time is a preset time, the sales contract is triggered to take effect, where the preset time is the preset effective time of the sales contract.

9. A method for generating invoices, characterized in that, include: In response to the sales contract's effective instruction, the first information in the sales contract is obtained, including: invoice type, sales entity information, and invoice milestone, wherein the invoice milestone is used to define the node that triggers invoicing during the execution of the sales contract; Based on the invoice type, the sales entity information, and the invoice milestone, invoice rules are determined, including invoice triggering conditions and invoice triggering amounts. Based on the invoicing trigger condition and the invoicing trigger amount, the second information in the sales contract is obtained. The second information includes the invoicing amount of the sales contract, the invoicing period, the invoicing amount of each period, and the expected invoicing date. Obtain the current execution node of the sales contract; In response to the execution node being a node defined by the invoicing milestone, an invoice corresponding to the sales contract is generated based on the invoicing milestone, the invoicing triggering condition, and the second information.

10. A computing device, characterized in that, It includes a processor and a memory; the processor is coupled to the memory; The memory is used to store instructions; The processor is configured to execute instructions stored in the memory to cause the computing device to perform the method as described in any one of claims 1-9.

Images