Method of revenue recognition and computing device

Abstract

The embodiment of the application discloses a revenue confirmation method and a computing device, and relates to the technical field of enterprise financial management. The method comprises the following steps: acquiring first information of a target sales contract, the target sales contract being a sales contract for at least one product, and the first information comprising a product type, a transaction type and a contract type of the at least one product. Based on the first information, a target analysis rule matched with the first information is determined from a plurality of analysis rules, the analysis rule being used for defining revenue confirmation content of the sales contract. Based on the target analysis rule, an analysis conclusion of the target sales contract is determined, the analysis conclusion of the target sales contract being used for indicating the revenue confirmation content corresponding to the at least one product in the target sales contract. Based on the analysis conclusion of the target sales contract, revenue confirmation is performed. In this way, the automation processing efficiency and the accuracy of the revenue confirmation are improved, the adaptability of the revenue confirmation process of the enterprise is enhanced, and the work flow and the manpower input demand of the enterprise are simplified.

Description

Technical Field

[0001] This application relates to the field of enterprise financial management technology, and in particular to a revenue recognition method and calculation device. Background Technology

[0002] In modern enterprises, revenue recognition scenarios vary, and specific revenue recognition methods differ depending on business complexity. Currently, most enterprises still rely on manual revenue recognition. This not only limits their ability to handle diverse scenarios and makes them prone to inconsistencies due to human error, but also leads to low efficiency and a heavy manpower burden. Therefore, there is an urgent need for a method that can accurately and efficiently recognize revenue across multiple scenarios, while simultaneously simplifying enterprise workflows and reducing manpower requirements. Summary of the Invention

[0003] This application provides a revenue recognition method and computing device that can improve the efficiency and accuracy of automated revenue recognition, enhance the adaptability of the enterprise's revenue recognition process, and simplify the enterprise's workflow and manpower input requirements.

[0004] In a first aspect, embodiments of this application provide a revenue recognition method, the method comprising: obtaining first information of a target sales contract, wherein the target sales contract is a sales contract for at least one product, and the first information includes the product type, transaction type, and contract type of the at least one product; based on the first information, determining a target parsing rule matching the first information from a plurality of parsing rules, the parsing rule being used to define the revenue recognition content of the sales contract; based on the target parsing rule, determining a parsing conclusion of the target sales contract, the parsing conclusion of the target sales contract being used to indicate the revenue recognition content corresponding to at least one product in the target sales contract; and based on the parsing conclusion of the target sales contract, performing revenue recognition.

[0005] Thus, by first obtaining the initial information from the target sales contract, and then accurately matching the target parsing rules based on this initial information—since the target parsing rules define the revenue recognition content of the sales contract—it is possible to determine the parsing conclusion for the corresponding product and recognize revenue based on this conclusion. This not only achieves precise adaptation of revenue recognition logic in different sales scenarios such as single-product and multi-product sales, enhancing the adaptability of the enterprise's revenue recognition process, but also avoids the risk of mismatch between timing and methods caused by manual judgment, improving the efficiency and accuracy of automated revenue recognition. Furthermore, since manual revenue recognition is not required, it simplifies the enterprise's workflow and reduces manpower requirements, optimizing the workflow and resource allocation of the finance department.

[0006] In one possible implementation, the parsing rule includes multiple first fields, which are fields used to match first information; based on the first information, a target parsing rule that matches the first information is determined from the multiple parsing rules, including: for each of the multiple parsing rules, matching the multiple first fields in the parsing rule with the first information; if the multiple first fields in the parsing rule match the first information successfully, the parsing rule is taken as the target parsing rule.

[0007] In this way, by directly matching the first field and the first information of the parsing rule, the target parsing rule is determined, which simplifies and improves the accuracy of the parsing rule matching process and enhances the efficiency and adaptability of the target parsing rule determination.

[0008] In one possible implementation, the parsing rule includes multiple second fields, each corresponding to a different parsing conclusion. These second fields include one or more identifiers such as country identifier, customer identifier, framework contract identifier, project identifier to which the target sales contract belongs, and product compliance identifier. Based on the target parsing rule, the parsing conclusion for the target sales contract is determined, including: obtaining second information about the target sales contract, which includes one or more identifiers such as country identifier, customer identifier, framework contract identifier, project identifier to which the target sales contract belongs, and product compliance identifier; matching the multiple second fields with the second information in descending order of priority based on the priority of the multiple second fields included in the target parsing rule, until a target second field matching the second information is determined from the multiple second fields; and the parsing conclusion corresponding to the target second field is determined as the parsing conclusion for the target sales contract.

[0009] In this way, by obtaining secondary information from one or more dimensions of the target sales contract, such as country identifier, customer identifier, framework contract identifier, project identifier, and product compliance identifier, and by matching multiple secondary fields in the target parsing rules from high to low priority until a parsing conclusion that successfully matches the secondary information is determined, the accuracy and compliance of revenue recognition under different complex scenarios can be achieved.

[0010] In one possible implementation, the method further includes: if no target second field matching the second information is determined among multiple second fields, the default parsing conclusion is determined as the parsing conclusion of the target sales contract.

[0011] Thus, if no matching is found in multiple second fields, enabling the default parsing conclusion (such as the parsing conclusion corresponding to the general level) can avoid the revenue recognition process being interrupted due to the lack of matching rules, thereby improving the completeness and operational reliability of the revenue recognition method.

[0012] In one possible implementation, before determining the target parsing rule matching the first information from multiple parsing rules based on the first information, the method further includes: obtaining the contract status of the target sales contract, the contract status indicating whether the target sales contract is effective; in response to the contract status being effective, determining whether there is a parsing conclusion for the target sales contract; and determining the target parsing rule matching the first information from multiple parsing rules based on the first information, including: in the case where there is no parsing conclusion for the target sales contract, determining the target parsing rule matching the first information from multiple parsing rules based on the first information.

[0013] Thus, when there is no parsing conclusion for the target sales contract, matching the target parsing rule from multiple parsing rules based on the first information can fill in the missing parsing conclusion and ensure the applicability of the target parsing rule.

[0014] In one possible implementation, before determining the target parsing rule matching the first information from multiple parsing rules based on the first information, the method further includes: creating a parsing rule structure for each of the preset multiple product types according to the configuration operation; the parsing rule structure is used to define the first field and the second field of the parsing rule corresponding to the product type and the priority of each second field; and determining at least one parsing rule corresponding to each product type based on the parsing rule structure for each product type to obtain multiple parsing rules.

[0015] Thus, by pre-configuring the parsing rule structure and determining the parsing rules based on the parsing rule structure, it is possible to adapt to the revenue recognition logic required by IFRS 15, thereby achieving automated revenue recognition.

[0016] In one possible implementation, different second fields include different numbers of identifiers; the more identifiers a second field includes, the higher its priority.

[0017] In this way, the priority of multiple second fields can be preset based on the number of identifiers included in the second field, thus meeting the needs of revenue recognition.

[0018] In one possible implementation, before creating the parsing rule structure for each of the preset product types according to the configuration operation, the method further includes: determining the multiple product types based on the target company's sales business.

[0019] In this way, by identifying multiple product types based on the target company's sales business, it is possible to achieve a precise match between product type classification and the company's actual sales scenarios, thereby improving the adaptability of revenue recognition.

[0020] In one possible implementation, after determining the target parsing rule that matches the first information from multiple parsing rules based on the first information, the method further includes: displaying a first interface, the first interface including a confirmation intervention identifier, the confirmation intervention identifier being used by the user to confirm whether to intervene in the modification of the target parsing rule; and in response to an operation on the confirmation intervention identifier, displaying the target parsing rule, for the user to confirm whether the target parsing rule needs to be modified.

[0021] Thus, by determining the target parsing rules and displaying the first interface with a confirmation intervention mark, users can view and modify the target parsing rules, realize automatic matching of manual verification and error correction of target parsing rules, and adapt to the personalized needs of complex and special contracts.

[0022] In one possible implementation, after revenue recognition based on the analysis results of the target sales contract, the method further includes: in response to a preset instruction of the target sales contract, reversing the revenue already recognized by the target sales contract, wherein the preset instruction includes a content change instruction or an execution status change instruction of the target sales contract.

[0023] Thus, by responding to changes in the content or execution status of the target sales contract after revenue recognition, and backflushing the recognized revenue, the problem of mismatch between revenue data and actual transaction scenarios after contract changes can be avoided, and the needs of change management throughout the entire contract lifecycle can be met.

[0024] Secondly, embodiments of this application provide another revenue recognition method, comprising: displaying a first interface, the first interface including a confirmation intervention identifier, the confirmation intervention identifier being used by the user to confirm whether to intervene in the modification of a target parsing rule, wherein the target parsing rule is a parsing rule that matches a target sales contract among multiple parsing rules, and the parsing rule is used to define the revenue recognition content of the sales contract; responding to the operation on the confirmation intervention identifier, displaying the target parsing rule, for the user to confirm whether the target parsing rule needs to be modified; responding to the user's modification operation on the target parsing rule, obtaining the modified target parsing rule; and performing revenue recognition based on the modified target parsing rule.

[0025] Thus, through the first interface displayed by the computing device, users can view and modify the target parsing rules, realize automatic matching of manual verification and error correction of the target parsing rules, and adapt to the personalized needs of complex and special contracts.

[0026] Thirdly, embodiments of this application provide a computing device, including a processor and a memory; the processor is coupled to the memory; the memory is used to store instructions; the processor is used to execute the instructions stored in the memory, so that the computing device performs the revenue recognition method as described above.

[0027] 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 revenue recognition method described above.

[0028] 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 revenue recognition method as described above.

[0029] 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.

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

[0031] Figure 1 This 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 a configuration parsing rule provided in an embodiment of this application; Figure 4 A schematic diagram of a parsing rule structure provided in an embodiment of this application; Figure 5 A schematic diagram illustrating a parsing rule provided in an embodiment of this application; Figure 6 A schematic diagram illustrating a list of analytical conclusions provided in an embodiment of this application; Figure 7 A flowchart illustrating a revenue recognition method provided in an embodiment of this application; Figure 8 A visual schematic diagram illustrating a revenue recognition method provided in an embodiment of this application; Figure 9 A visual schematic diagram illustrating another revenue recognition method provided in an embodiment of this application; Figure 10 This is a schematic diagram of another computing device provided in an embodiment of this application. Detailed Implementation

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

[0033] 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.

[0034] 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.

[0035] 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.

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

[0037] This application's embodiments are primarily applied to revenue recognition scenarios for enterprises. Revenue recognition is a crucial source of core data in a company's financial statements, directly impacting profit calculation and financial position reflection. It is a key indicator for measuring a company's operating results and provides important decision-making basis for investors and managers. Revenue recognition must strictly comply with accounting standards, such as International Financial Reporting Standard 15 (IFRS 15). For example, this application's embodiments can be applied to revenue recognition scenarios for enterprises based on IFRS 15.

[0038] In modern enterprises, revenue recognition scenarios vary, and specific revenue recognition methods differ depending on the complexity of the business. Currently, most enterprises still rely on manual revenue recognition. This not only limits their ability to handle diverse scenarios and makes them prone to inconsistent results due to human error, but also leads to low efficiency and a heavy manpower burden.

[0039] This application provides a revenue recognition method. First, first information about a target sales contract is obtained. The target sales contract is a sales contract for at least one product. The first information includes the product type, transaction type, and contract type of the at least one product. Second, based on the first information, a target parsing rule matching the first information is determined from multiple parsing rules. This parsing rule defines the revenue recognition content of the sales contract. Then, based on the target parsing rule, a parsing conclusion for the target sales contract is determined. This parsing conclusion indicates the revenue recognition content corresponding to at least one product in the target sales contract. Finally, revenue is recognized based on the parsing conclusion of the target sales contract.

[0040] In this embodiment, by first obtaining the first information from the target sales contract and then accurately matching the target parsing rules based on that first information, the parsing rules, which define the revenue recognition content of the sales contract, can determine the parsing conclusion for the corresponding product. Revenue recognition is then performed based on this conclusion. This not only achieves precise adaptation of revenue recognition logic in different sales scenarios such as single-product and multi-product sales, enhancing the adaptability of the enterprise's revenue recognition process, but also avoids the risk of mismatch between timing and method caused by manual judgment, improving the efficiency and accuracy of automated revenue recognition. Furthermore, since manual revenue recognition is not required, it simplifies the enterprise's workflow and reduces manpower requirements, optimizing the workflow and resource allocation of the finance department.

[0041] The system architecture of the embodiments of this application will be described exemplarily below.

[0042] This application provides a computing device.

[0043] The computing device is used to acquire first information about a target sales contract, which is a sales contract for at least one product. The first information includes the product type, transaction type, and contract type of the at least one product. The computing device is also used to determine, based on the first information, a target parsing rule matching the first information from multiple parsing rules. This parsing rule defines the revenue recognition content of the sales contract. The computing device is further used to determine the parsing conclusion of the target sales contract based on the target parsing rule. The parsing conclusion of the target sales contract indicates the revenue recognition content corresponding to the at least one product in the target sales contract. Furthermore, the computing device is also used to perform revenue recognition based on the parsing conclusion of the target sales contract.

[0044] In some embodiments, such as Figure 1 As shown, the computing device is equipped with a revenue analysis system, which enables the aforementioned functions.

[0045] In one implementation, such as Figure 1 As shown, the revenue parsing system includes a rule configurator. For example, this rule configurator is a software module / tool ​​for determining target parsing rules. Specifically, the computing device can use the rule configurator in the revenue parsing system to determine a target parsing rule that matches the first information from multiple parsing rules, based on the first information.

[0046] In some embodiments, such as Figure 1 As shown, the computing device is equipped with a customer relationship management (CRM) system. The computing device determines whether a sales contract is valid by checking its contract status within the CRM system. Once a valid sales contract is confirmed, the computing device integrates it into the revenue analysis system, enabling the revenue analysis system to perform the aforementioned functions based on the valid sales contract.

[0047] 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.

[0048] 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.

[0049] 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).

[0050] The processor may include a central processing unit (CPU). A CPU includes one or more CPU cores, each containing an arithmetic unit, a control unit, and a register set. It supports instruction sets such as integer and floating-point arithmetic, and all data processing operations are executed by the CPU cores. In the embodiments of this application, the processor (such as a CPU) may specifically implement the various functions of the aforementioned computing device. Specifically, the processor (such as a CPU) runs the aforementioned revenue analysis system and / or CRM system to implement the various functions of the aforementioned computing device.

[0051] Memory, also known as internal memory or main memory, is installed in memory slots on the motherboard of a computing device and connected to the CPU via the memory bus. It is primarily used for temporary storage of data and instructions, providing high-speed data read and write support for the processor. For example, the program code and processed data (such as initial information, parsing rules, etc.) of the aforementioned revenue analysis system and / or CRM system are temporarily stored in memory for the processor to read and execute. Memory provides high-speed data storage services for the operation of the aforementioned revenue analysis system and / or CRM system.

[0052] 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.

[0053] For ease of understanding, the revenue recognition method provided in the embodiments of this application will be described exemplarily below with reference to the above-described computing device and accompanying drawings.

[0054] This application will describe the revenue recognition method in two parts.

[0055] Part One: Combination Figures 3-6 This section introduces the specific implementation method of configuring and parsing rules.

[0056] Part Two: Combination Figures 7-9 This section introduces the specific implementation methods of revenue recognition.

[0057] Part One, such as Figure 3 As shown, this application embodiment provides a specific implementation method for configuring parsing rules. For example, it includes the following steps S301-S302, which can be executed by the processor of a computing device, such as a CPU.

[0058] S301, based on the configuration operation, creates a parsing rule structure for each of the preset product types.

[0059] The configuration operation is used to configure the parsing rule structure corresponding to different product types. Product type indicates the domain to which the traded product belongs. For example, products include one or more of the following: equipment, software (such as self-developed software and / or purchased software), software annual fees, or services. It is understood that the products in this application embodiment not only cover hardware devices with physical form, but also software products, service products, and software annual fees without physical form. For example, equipment includes servers, switches, or terminals; software includes management software, office software, or database software; software annual fees include cloud service annual subscription fees or software annual upgrade and maintenance fees; and services include server operation and maintenance services, server media (such as physical storage media or virtual media) security storage services, or technical consulting services. For example, multiple product types may include multiple types of equipment, software, software annual fee, and service types.

[0060] The parsing rule structure is used to define the fields of the parsing rules corresponding to the product type. The fields of the parsing rule include a first field and a second field. The parsing rules are determined based on the parsing rule structure. The specific content of the parsing rules will be described in subsequent step S302, and will not be elaborated here.

[0061] The parsing rule structure includes type information, entity information, and entity attribute information. Entity attribute information is the data item corresponding to the entity information. Type information is used to define the hierarchical affiliation of entity attribute information (such as the overall contract level, contract detail level, or parsing result output level; in this embodiment, the contract is a sales contract). Entity information is used to define the carrier of the field information (such as entity attribute information) required by the parsing rule.

[0062] For example, the type information includes header rule input, row rule input, and row rule output. Header rule input is used to define field information at the overall contract level, row rule input is used to define field information at the contract detail level, and row rule output is used to define field information at the parsing result output level.

[0063] For example, entity information includes the contract information table, parsing rules, and contract transaction details table. Optionally, entity information may also include one or more of the following: country, customer, other information (also referred to as "other"), and product analysis report (certificate of analysis, COA). The contract information table and parsing rules are the associated entity information inputs for the header rules. The contract transaction details table, country, customer, other, and product COA are the associated entity information inputs for the row rules. Furthermore, the parsing rules also output associated entity information for the row rules.

[0064] The contract information table serves as the storage medium for fundamental contract information, recording globally common data about the contract. The contract information table includes a contract identifier and scenario attributes. The contract identifier includes the contract number. Optionally, the contract identifier may also include a framework contract identifier, the project identifier to which the contract belongs, and one or more contract versions. A framework contract is a contract entered into by both parties who have reached an agreement on the subject matter of the transaction and determined its main contents; for example, a framework contract identifier may include a framework contract number. The project identifier to which the contract belongs indicates the business objective associated with the contract; for example, a project identifier may include a project number. Scenario attributes include transaction type and contract type. The transaction type indicates the execution mode of the transaction, such as "channel sales" or "direct sales." The contract type indicates the legal attributes of the sales contract, such as "framework contract" or "non-framework contract." Optionally, scenario attributes may also include contract status, whether it includes equipment, and whether it is a simple purchase order (PO). The contract status indicates whether the sales contract is effective. If the sales contract is activated, the contract status indicates an effective status (which can be marked as "Activated"). Activation here means that the sales contract is explicitly recognized by both parties as having legal binding force and performance effect. If the sales contract is not activated, the contract status indicates an invalid status. "Includes Equipment" indicates whether the contract includes equipment products. "Simple PO" indicates whether the purchase order is simple.

[0065] The parsing rules in entity information are conceptually the same as those determined based on the parsing rule structure, but their descriptive dimensions differ. Parsing rules in entity information are described from the data carrier dimension, and are a component of the parsing rule structure. Parsing rules determined based on the parsing rule structure are described from the content dimension of the parsing rules themselves.

[0066] The contract transaction details table is a storage medium for detailed contract information, used to record specific information about each type of product in the contract, such as product type, product COA, quantity, and amount. Optionally, the contract transaction details table may also include product descriptions, whether software loading and delivery are required, etc., with the product description describing the product's content.

[0067] The nation-state serves as a storage medium for geographical data, used to record standardized information related to the nation.

[0068] Customers are the storage carriers for customer-related data, used to record standardized information related to customers.

[0069] Other information is used to store general information or auxiliary information for special scenarios that cannot be attributed to the aforementioned entity information. Specifically, it includes one or more of the following: general remarks, default identifiers (such as general), and manually popped-up parsing identifiers. Other information can be used to adapt to general rules that do not correspond to specific entities (such as a fallback matching rule for all product types) and manual intervention triggering requirements in special scenarios (such as an identifier field when complex contracts require manual review).

[0070] The Product Certificate of Account (COA) serves as a storage medium for product compliance identifiers, used to record these identifiers. Product compliance identifiers are information used to indicate that a product complies with one or more of the industry standards, company internal regulations, or IFRS 15 revenue recognition criteria; for example, they may include the Product COA code.

[0071] Entity attribute information includes the entity attribute information associated with each entity information, specifically including one or more of the following: entity attribute information associated with the contract information table, entity attribute information associated with the parsing rules, entity attribute information associated with the contract transaction details table, entity attribute information associated with the country, entity attribute information associated with the customer, entity attribute information associated with other information, and entity attribute information associated with the product COA.

[0072] The entity attribute information associated with the contract information table includes contract number, transaction type, and contract type. Optionally, it may also include one or more of the following: contract status, framework contract identifier, project identifier, contract version, whether it includes equipment, and whether it is a simple purchase order (PO).

[0073] The entity attribute information associated with the parsing rules includes the revenue recognition time point, revenue recognition method, and the trigger level of the parsing conclusion. The revenue recognition time point refers to the specific point in time when the revenue corresponding to the contract is included in the financial statements, such as the "acceptance time point" or "delivery time point" for equipment; the "authorization effective time point" for software; and the "service completion time point" for service types / annual software fees. The revenue recognition method refers to how the company recognizes the revenue amount after reaching the revenue recognition time point, such as the "one-time recognition method" for equipment / software; and the "straight-line method" or "recognition method based on performance progress" for service types / annual software fees. The type information associated with the revenue recognition time point and revenue recognition method is the row rule output. The trigger level of the parsing conclusion indicates the business granularity or triggering time of the parsing conclusion generation. The type information associated with the trigger level of the parsing conclusion is the header rule input. In essence, the trigger level of the parsing conclusion is a pre-configuration item for the parsing rule, specifying how parsing is initiated and at what granularity the conclusion is generated. The revenue recognition time point and revenue recognition method are post-output items of the parsing rule, clarifying when revenue is recorded and how it is calculated. Regarding the analysis conclusion, please refer to the subsequent step S302 for details, which will not be repeated here. Optionally, the entity attribute information associated with the analysis rule may also include whether manual analysis was performed. Whether manual analysis was performed indicates whether manual intervention is required in the process of determining the analysis conclusion.

[0074] The entity attribute information associated with the contract transaction details table includes product type, product COA, quantity, and amount. Optionally, the entity attribute information associated with the contract transaction details table may also include product description, whether software loading and delivery are required, etc.

[0075] The entity attribute information associated with a country includes country identifiers, such as country name and / or country code.

[0076] The entity attribute information associated with a customer includes customer identifiers, such as customer codes. Optionally, customer identifiers may also include customer type, etc.

[0077] Other associated entity attribute information includes one or more of the following: general remarks, default identifiers (such as General), and manually popped-up parsing identifiers.

[0078] The entity attribute information associated with a product COA includes product compliance identifiers, such as the product COA code.

[0079] Optionally, the parsing rule structure may also include one or more of the following: entity attribute type information, entity attribute source information, or whether it is required.

[0080] Entity attribute type information is used to represent the value format and configuration type of entity attribute information, and is used to standardize the input, storage, or matching logic of entity attribute information. For example, entity attribute type information may include one or more of the following: drop-down selection lookup configuration items, control boxes, database tables, and text boxes.

[0081] The lookup configuration item is applicable to standardized enumeration values. For example, the entity attribute information applicable to the lookup configuration item includes: contract status (preset "Activated", "Invalid", etc.), transaction type (preset "channel sales", "direct sales", etc.), contract type (preset "framework contract", "non-framework contract", "PO under framework", etc.), revenue recognition time point, revenue recognition method, trigger level of parsing conclusion, product type, and default identifier, one or more of these.

[0082] Dropdown lists are suitable for binary or limited selection values. For example, the entity attribute information that dropdown lists are suitable for includes: whether manual parsing is required, whether it contains equipment, whether it is a simple PO, whether manual pop-up parsing is required, and whether software loading and delivery are required.

[0083] Database tables are used for values ​​that need to be retrieved from a unified data source. For example, database tables may use entity attribute information including: country name, country code, customer code, customer type, product COA code, and framework contract number.

[0084] Text boxes are suitable for custom information that requires manual input. For example, text boxes may be used for entity attribute information such as: contract number, project number, contract version, quantity, amount, product description, and general remarks.

[0085] Entity attribute source information indicates the source or channel through which entity attribute information is obtained. For example, entity attribute source information might include: country name data from the database table `crc_ioc_country_districiapha_2_code`; customer code data from the database table `crc_customer_parner_vicode`; enumerated values ​​for lookup configuration items from the system's preset business rule dictionary (e.g., "AcceptAmount" and "Straightline" for revenue recognition methods); text box content from user-entered custom descriptions (e.g., detailed descriptions of general remarks); and dropdown options from the system's preset binary / finite option set (e.g., "Y / N" for manual parsing).

[0086] The "Required" field indicates whether entity attribute information is mandatory or cannot be configured during the parsing rule structure configuration process. For example, the contract number, transaction type, contract type, revenue recognition time, revenue recognition method, parsing conclusion trigger level, product type, product COA, quantity, and amount among the entity attribute information mentioned above are mandatory. The remaining entity attribute information can be configured as mandatory or optional based on actual needs.

[0087] The parsing rule structure for different product types will vary in terms of entity information and entity attribute information based on their business characteristics, performance models, and IFRS 15 requirements. For example, the configuration of product type, whether it includes equipment, revenue recognition time, revenue recognition method, and the trigger level for parsing conclusions will differ. Optionally, information such as contract type will also differ.

[0088] For example, for a product type of "equipment", the entity information associated with the corresponding parsing rule structure can be the following: contract number; contract status (e.g., "Activated"); transaction type (e.g., "channel sales" or "direct sales"); contract type (e.g., "framework contract", "non-framework contract" or "PO under framework"); whether it includes equipment (value is "Y"); the trigger level of the parsing conclusion (e.g., "contract + equipment sales configuration", indicating that the business granularity of generating the parsing conclusion and the parsing start rule are based on the entire sales contract and configured according to the scenario of "equipment product sales"); revenue recognition time point (e.g., "delivery time", "acceptance time"); revenue recognition method (e.g., one-time recognition method); product type (fixed to equipment type "Equipment", which is the starting field for equipment rule routing); product COA (identifier of equipment sub-products, distinguishing different models / specifications of equipment under the same equipment type); quantity (basic data for equipment revenue allocation); amount (measurement basis for equipment revenue recognition); product COA code (standardized compliance identifier for equipment products).

[0089] For example, for a product type of software, the entity information associated with the corresponding parsing rule structure can be the following: contract number; contract status; transaction type; contract type (e.g., "framework contract", "non-framework contract", or "PO under framework"); whether it includes equipment (value is "N"); trigger level of the parsing conclusion (e.g., "contract + software license sales configuration", indicating that the business granularity of generating the parsing conclusion and the parsing start rule are based on the entire sales contract as the basic scope and configured according to the scenario of "software product sales"); revenue recognition time point (e.g., the time when the software license officially takes effect, "Effective Authorization"); revenue recognition method (e.g., one-time recognition method); product type (fixed to software type "License"); product COA (unique identifier for software sub-products, distinguishing different license versions / scopes under the same software type); quantity (the basis for calculating the number of software licenses); amount (the measurement basis for software revenue recognition); product COA code (standardized compliance identifier for software products).

[0090] For example, for a product type of "Software Annual Fee," the entity information associated with the corresponding parsing rule structure can be the following: Contract Number; Contract Status; Transaction Type; Contract Type (e.g., "Framework Contract" or "Non-Framework Contract"); Whether it includes equipment (value is "N"); Trigger Level of Parsing Conclusion (e.g., "Contract + Software Annual Fee Sales Configuration," indicating that the business granularity and parsing initiation rules for generating parsing conclusions are based on the entire sales contract and configured according to the scenario of "Software Annual Fee Product Sales"); Revenue Recognition Time Point (e.g., Periodic Performance Recognition); Revenue Recognition Method (e.g., Straight-Line Method); Product Type (fixed to "Software Annual Fee"); Product COA (unique identifier for sub-products of the Software Annual Fee category, distinguishing different service levels / scopes under the same annual fee type); Quantity (basis for calculating annual fee service volume); Amount (measurement basis for software annual fee revenue recognition); Product COA Code (standardized compliance identifier for software annual fee products).

[0091] For example, for a product type of service, the entity information associated with the corresponding parsing rule structure can be the following: contract number; contract status; transaction type; contract type (e.g., "framework contract", "non-framework contract", or "PO under framework"); whether it includes equipment (value is "N"); the trigger level of the parsing conclusion (e.g., "contract + service sales configuration", indicating that the business granularity of generating the parsing conclusion and the parsing start rule are based on the entire sales contract as the basic scope and configured according to the scenario of "service product sales"); revenue recognition time point (e.g., service completion time); revenue recognition method (e.g., straight-line method, or recognition method based on performance progress, etc.); product type (fixed to service type "Service"); product COA (unique identifier for service sub-products, distinguishing different service content / levels under the same service type); quantity (basic basis for service volume accounting); amount (measurement basis for service revenue recognition); product COA code (standardized compliance identifier for service products).

[0092] In some embodiments, the parsing rule structure differs in the "mandatory" configuration for different product types. For example, for device types, "Framework Contract Number Identifier" is set as mandatory to meet the matching requirements of framework agreements and purchase orders in bulk procurement scenarios. For software types, "Software Loading and Delivery Required" is set as mandatory to adapt to the rule distinctions between different authorization and delivery modes such as online automatic authorization and offline deployment loading. For service types, "Framework Contract Number Identifier" is set as optional but mandatory to adapt to the association between framework agreements and service orders in long-term bulk service procurement scenarios, ensuring the consistency of service performance rules and settlement logic. For software annual fee types, "Quantity (Annual Fee Service Volume)" is set as mandatory, serving as the core basis for straight-line revenue allocation and ensuring the accuracy of revenue calculation for multi-level and multi-year annual fee services. In this way, by flexibly setting the rule configuration for different product types, the accuracy of adapting to different business characteristics and performance scenarios is improved.

[0093] like Figure 4 As shown, the computing device provides a first interactive interface through which the parsing rule structure is configured and displayed. Specifically, for type information (e.g., identified as type), entity information (e.g., identified as entity), entity attribute information (e.g., identified as entity attribute), entity attribute type information (e.g., identified as entity attribute type), entity attribute source information (e.g., identified as entity attribute source), and whether it is required, the information corresponding to number 1 is respectively: "Header Rule Input", "Parsing Rule", "Triggering Level of Parsing Conclusion", "Drop-down Lookup Configuration Item", "XCRC_ 1. "Yes". The information corresponding to number 2 is: "Header Rule Input", "Parsing Rule", "Manual Parsing?", "Dropdown", "Y / N", "No". The information corresponding to number 3 is: "Row Rule Input", "Country", "Country Name", "Database Table", "CRC". 1. "No". The information corresponding to number 4 is as follows: "Row Rule Input", "Other Information", "General", "Text Box", "General", "No". The information corresponding to number 5 is as follows: "Row Rule Input", "Customer", "Customer Code", "Database Table", "CRC". 2”, “No”. The information corresponding to number 6 is as follows: “Row Rule Input”, “Contract Information Table”, “Framework Contract”, “Text Box”, “ ”, “No”. The information corresponding to number 7 is as follows: “Row Rule Output”, “Parsing Rule”, “Revenue Recognition Time Point”, “Lookup Configuration Item”, “XCRC_ 2”, “Yes”. The information corresponding to serial number 8 is as follows: “Row rule output”, “Parsing rule”, “Revenue recognition method”, “lookup configuration item”, “XCRC_ 3”, “Yes”.

[0094] In some embodiments, the parsing rule structure is also used to define the priorities of multiple preset fields. Correspondingly, optionally, the parsing rule structure may also include priority information, which indicates the priority hierarchy of the multiple preset fields. The preset fields are one or more of the following: country identifier (e.g., country name, country code), customer identifier (e.g., customer code), framework contract identifier (e.g., framework contract number), project identifier to which the contract belongs (e.g., project number), or product compliance identifier (e.g., product COA). For example, the multiple preset fields include preset field 1, preset field 2, and preset field 3, wherein preset field 1 includes country name, customer code, framework contract number, and project number; preset field 2 includes country name, customer code, and framework contract number; and preset field 3 includes country name. The priorities of these multiple preset fields can be preset by the user.

[0095] In this embodiment of the application, since IFRS 15 requires revenue to be recognized on a per-performance-obligation basis, the above-mentioned entity attribute information is the core screening condition for refining performance obligations. Therefore, different preset fields can be set with different priority levels.

[0096] For example, different second fields may include different numbers of identifiers. The more identifiers a second field includes, the higher its priority. For instance, using the aforementioned preset fields 1, 2, and 3, preset field 1 has a higher priority than preset field 2, and preset field 2 has a higher priority than preset field 3. This allows for more specific and targeted restrictions on priority order. Another example is where different identifiers included in the second field have different priorities; the higher the priority of the identifiers included in the second field, the higher the priority of the second field. For instance, continuing with the aforementioned preset fields 1, 2, and 3, if the project number has the highest priority, then preset field 1 has the highest priority.

[0097] Continue as Figure 4 As shown in the example, the user-configured priority information is as follows: Priority 1 includes "Country Name" and "Framework Contract"; Priority 2 includes "Country Name" and "Customer Code"; Priority 3 includes "Framework Contract Number"; Priority 4 includes "Country Name".

[0098] In one implementation, priority information is also used to indicate a general level with a priority lower than multiple preset fields. Understandably, the general level is the "bottom-level" of the priority information; it is the preset lowest priority matching rule, used to ensure that all contracts (regardless of whether they have higher priority matching fields) can uniquely match the parsing rule.

[0099] Continue as Figure 4 As shown, the general level is identified by the "general" label. Its priority is the lowest among multiple priority levels, corresponding to priority 5.

[0100] In this embodiment, by pre-configuring parsing rule structures for various product types, multiple different parsing rule structures can be obtained. These may include parsing rule structures for device types (e.g., Mode 1), software types (e.g., Mode 2), software annual fee types (e.g., Mode 3), and service types (e.g., Mode 4), etc. It should be noted that multiple different parsing rule structures can be created for each product type according to the user's actual needs.

[0101] In one implementation that creates a parsing rule structure for each product type based on configuration operations, a first configuration interface is displayed, which includes a preset configuration template. Based on the configuration template, a parsing rule structure for each product type is created according to the configuration operations.

[0102] The configuration template includes product type configuration items, type configuration items, entity configuration items, and entity attribute configuration items. The product type configuration item configures the product type to which the parsing rule structure belongs; the type configuration item configures type information; the entity configuration item configures entity information; and the entity attribute configuration item configures entity attribute information. Optionally, the configuration template may also include one or more of the following: entity attribute type configuration item, entity attribute source configuration item, or mandatory / unmandable configuration item. The entity attribute type configuration item configures entity attribute type information; the entity attribute source configuration item configures entity attribute source information; and the mandatory / unmandable configuration item specifies whether a field is required.

[0103] Specifically, users select the information to be configured (i.e., configuration operations) from multiple configuration items in the configuration template to complete the creation of parsing rule structures for different product types. For example, users select "Device Type," "Software Type," "Software Annual Fee Type," or "Service Type" in the product type configuration item. Continuing... Figure 4 As shown, the identifier for the type configuration item is "Type", the identifier for the entity configuration item is "Entity", the identifier for the entity attribute configuration item is "Entity Attribute", the identifier for the entity attribute type configuration item is "Entity Attribute Type", the identifier for the entity attribute source configuration item is "Entity Attribute Source", and the identifier for the mandatory / unmandable configuration item is "Mandatory / Unmandable". Users (e.g., based on business hierarchy requirements of product type) select "Header Rule Input", "Row Rule Input", or "Row Rule Output" as the type information in the type configuration item. For example, in the type configuration item corresponding to serial number 1, the user selects "Header Rule Input", selects the "Parsing Rule" from the entity information associated with "Header Rule Input" in the entity configuration item, selects the "Triggering Level of Parsing Conclusion" associated with "Parsing Rule" from the entity attribute configuration item, selects the "lookup configuration item" associated with "Triggering Level of Parsing Conclusion" from the entity attribute type configuration item, and selects the "XCRC_" associated with "Triggering Level of Parsing Conclusion" from the entity attribute source configuration item. 1. Select "Yes" from the "Required" configuration options to match "Trigger level of parsing conclusion". This completes the configuration of the header rule input in the parsing rule structure. The row rule input and row rule output can be configured in a similar way.

[0104] Optionally, the configuration template also includes a priority information configuration item, which is used to configure priority information. Continuing... Figure 4As shown, priority information is identified by "priority" and "level". Users configure "country name + framework contract" in priority 1. Priority information for other levels can be configured in a similar manner. In this embodiment, through user configuration operations, the creation of parsing rule structures for each product type is completed, meeting users' actual needs and flexibly adapting to the business characteristics and performance logic of different product types such as equipment, software, services, and software annual fees, achieving standardized and scenario-based precise matching of rule configurations.

[0105] In one implementation, the method further includes: determining multiple product types based on the target company's sales operations. Sales operations refer to transactions between a seller and a customer involving one or more independently accountable revenue-generating products such as equipment, software, services, and annual software fees, completed through the signing of sales contracts. For example, if the target company's sales operations include equipment, software, annual software fees, and services, then multiple product types are determined, including equipment, software, annual software fees, and services. For instance, these multiple product types can be determined based on the contract transaction details in the target company's sales contracts. Thus, after determining the multiple product types, step S301 described above can be performed.

[0106] In some embodiments, multiple parsing rule structures (such as mode 1, mode 2, mode 3, mode 4, etc.) are displayed to the user in a list format so that the user can view or modify them.

[0107] S302, based on the parsing rule structure for each product type, determine at least one parsing rule corresponding to each product type to obtain multiple parsing rules.

[0108] The parsing rules are used to define the revenue recognition details of a sales contract. Revenue recognition details include the revenue recognition timing and methods described above. The parsing rules include basic information, rule matching information, and the revenue recognition details.

[0109] like Figure 5 As shown, the basic information includes the trigger level of the parsing conclusion (e.g., contract-equipment sales configuration). Optionally, continue as follows... Figure 5 As shown, the basic information also includes whether manual parsing is required.

[0110] In one implementation, the triggering level and / or whether manual parsing is used for the parsing conclusion in the basic information is determined based on the header rule input in the corresponding parsing rule structure, specifically based on the entity information of the parsing rule associated with the header rule input.

[0111] Optional, continue as follows Figure 5As shown, the basic information may also include one or more of the following: parsing rule identifier (e.g., parsing rule name: Device-Channel Sales-Framework Contract), parsing rule structure identifier (e.g., corresponding parsing structure: Mode 1), parsing rule product type (e.g., type: device), parsing rule version number (e.g., version: 20230427001), and remarks.

[0112] The rule matching information includes first entity information, first entity attribute information, operation information, and entity attribute value. First entity information refers to the entity information associated with the row rule input, and first entity attribute information is the entity attribute information associated with the first entity information. Entity attribute value represents the preset value of the first entity attribute information in the rule matching information. Operation information indicates the matching method between the entity attribute value in the rule matching information and the actual value of the entity attribute information in the sales contract. Operation information includes "equal to," "includes," etc. For example, if the operation information is "equal to," it means that a successful match occurs when the entity attribute value equals the actual value corresponding to that entity attribute information in the sales contract. If the operation information is "includes," it means that a successful match occurs when the entity attribute value includes the actual value corresponding to that entity attribute information in the sales contract.

[0113] In one implementation, the first entity information and the first entity attribute information in the rule matching information are determined based on the entity information and entity attribute information in their corresponding parsing specification structure. Specifically, they can be determined by the entity information and entity attribute information associated with the row rule input in the parsing specification structure. The entity attribute values ​​and / or operation information are pre-configured by the user.

[0114] Optionally, the rule matching information may also include associations with other entity information. These associations are pre-configured by the user.

[0115] Continue as Figure 5 As shown, for entity information (e.g., identified as an entity), entity attribute information (e.g., identified as an entity attribute), operation information (e.g., identified as an operation), entity attribute values, and relationships with other entity information (e.g., relationships with other entities), the information corresponding to number 1 is: "Contract Information Table", "Contract Status", "Equal to", "Activated", and "And". The information corresponding to number 2 is: "Contract Information Table", "Transaction Type", "Equal to", "Channel Sales", and "And". The information corresponding to number 3 is: "Contract Information Table", "Contract Type", "Equal to", "Framework Contract", and "And". The information corresponding to number 4 is: "Contract Transaction Details Table", "Product Type", "Equal to", "Equipment", and "And".

[0116] Revenue recognition details are determined based on the second entity attribute information. The second entity attribute information refers to the entity attribute information associated with the row rule output in the parsing rule structure corresponding to the parsing rule.

[0117] Optionally, the parsing rules also include priority information. This priority information is determined through the priority information in the corresponding parsing rule structure. Continuing... Figure 5 As shown, the priority information is the same as the above. Figure 4 The priority information is the same as in the previous section, so it will not be repeated here.

[0118] For example, each priority level corresponds to a unique combination of revenue recognition timing and revenue recognition method. In other words, different combinations of preset fields correspond to unique combinations of revenue recognition timing and revenue recognition methods. For example, continuing... Figure 5 As shown, this illustrates the correspondence between multiple preset fields (such as country name, customer code, framework contract number, project code, and product COA code) and revenue recognition details, identified by "Revenue Recognition Details": The preset fields corresponding to number 1 are: country name (… ) and framework contract number ( This matches the scenario of "specific country + bulk equipment procurement under framework contract", with revenue recognition point "acceptance point 1" and revenue recognition method "one-time recognition method 1". The multiple preset fields corresponding to serial number 2 are: country name ( ) and customer code ( This matches the scenario of "specific country + designated core customer equipment procurement", with revenue recognition point "acceptance point 2" and revenue recognition method "one-time recognition method 2". The multiple preset fields corresponding to serial number 3 are: framework contract number ( This matches the scenario of "no specific country restrictions + equipment procurement under a framework contract," with revenue recognition point "acceptance point 3" and revenue recognition method "one-time recognition method 3." The preset field corresponding to serial number 4 is: country name ( The first item matches the scenario of "equipment procurement in a specific country + non-framework contract", with revenue recognition point at "delivery point 4" and revenue recognition method at "one-time recognition method 4". Item 5 has no corresponding actual value for any of the above information, and it matches the scenario of "general equipment procurement without restrictions on specific countries, customers, or framework contracts", with revenue recognition point at "acceptance point 5" and revenue recognition method at "one-time recognition method 5", serving as a fallback solution for all scenarios.

[0119] In this embodiment, the product type, transaction type, or contract type in the parsing rule are the first fields included in the parsing rule. Multiple first fields are used to match the first information in the sales contract. The first information includes the product type, transaction type, and contract type. It should be noted that the first information is the actual value of the product type, transaction type, and contract type. For example, in the sales contract, the actual value of the product type is "Equipment," "License," "Service," or "Software Annual Fee," the actual value of the transaction type is "Channel Sales" or "Direct Sales," and the actual value of the contract type is "Framework Contract," "PO under Framework," "Non-Framework Contract," or "Standard Sales Contract." Specifically, the values ​​of multiple first fields (i.e., the entity attribute values ​​associated with the first field) are matched with the first information. It can be understood that the first field is the core pre-selection condition for matching the parsing rule with the sales contract. By locking in the three basic scenario dimensions of product type, transaction type, and contract type, the parsing rule corresponding to the sales contract can be accurately matched, thus improving matching efficiency.

[0120] One or more of the entity attribute information in the parsing rules, such as country identifier (e.g., country name, country code), customer identifier (e.g., customer code), framework contract identifier (e.g., framework contract number), project identifier (e.g., project number), and product compliance identifier (e.g., product COA code), constitute the second field of the parsing rules. This second field is the aforementioned preset field, used to match the second information in the sales contract. The second information includes one or more of the country identifier, customer identifier, framework contract identifier, project identifier, and product compliance identifier. It should be noted that the second information refers to the actual values ​​of the country identifier, customer identifier, framework contract identifier, project identifier, and product compliance identifier in the sales contract. For example, the actual value of the country identifier is "China" or "CN (China code)", the actual value of the customer identifier is "C001", the actual value of the framework contract identifier is "F2023001", the actual value of the project identifier is "P20230501", and the actual value of the product compliance identifier is "9221500". Different second fields correspond to different revenue recognition content, that is, different parsing conclusions. It can be understood that the second field is a subdivided scenario matching field based on the first field. As mentioned earlier, different preset fields (second fields) correspond to different priority levels. Through the second field, on the one hand, the second information in the sales contract is matched, and on the other hand, the parsing conclusion is matched to achieve a precise match between the sales contract and the parsing conclusion.

[0121] In this embodiment, by setting the parsing rules to the aforementioned basic information, rule matching information, and revenue recognition content, it is possible to adapt to the core logic of identifying performance obligations from the perspective of the entire contract as required by IFRS 15, thus clarifying the boundaries of performance obligations for the entire contract. Furthermore, priority information can be used to achieve precise matching of revenue recognition logic under different business scenarios (such as cross-border contracts and hybrid performance contracts), thereby improving the accuracy and adaptability of determining revenue recognition methods and timing.

[0122] In an implementation method that determines at least one parsing rule corresponding to each product type based on a parsing rule structure to obtain multiple parsing rules, a second configuration interface is displayed. The second configuration interface includes a parsing rule structure, and at least one parsing rule is configured according to a second configuration operation and the parsing rule structure. Specifically, the second configuration operation is used to configure the entity attribute values ​​associated with each entity attribute information, and the matching method between the entity attribute values ​​and the actual values ​​of the corresponding fields in the sales contract.

[0123] For example, this matching method is identified by the operation information mentioned above. If the entity attribute value needs to be equal to the actual value of the corresponding field in the sales contract, and the entity attribute value is confirmed to match the actual value of the corresponding field in the sales contract, the operation information is indicated as "equal to". If the entity attribute value includes the actual value of the corresponding field in the sales contract, and the entity attribute value is confirmed to match the actual value of the corresponding field in the sales contract, the operation information is indicated as "includes".

[0124] In this way, users can intuitively configure the core information of the parsing rules through this interface.

[0125] The analytical conclusions are presented below: The analytical conclusion includes the revenue recognition time and method, i.e., the content of revenue recognition. In other words, the purpose of the analytical rules is to generate analytical conclusions, and the analytical conclusions are the output of the analytical rules. By setting matching rules and priority information for the first and second fields, the analytical rules precisely match the corresponding information in the sales contract, outputting analytical conclusions that conform to the business scenario of the sales contract and the requirements of IFRS 15 standards.

[0126] Optionally, the parsing conclusion may also include one or more of the following: parsing rule identifier, trigger level of the parsing conclusion, product COA, product description, parsing exception description, country identifier, customer identifier, general identifier, and whether manual parsing was performed. The parsing rule identifier, trigger level of the parsing conclusion, product COA, product description, country identifier, customer identifier, general identifier, and whether manual parsing was performed are all obtained from the parsing rules. The parsing exception description is an exception record information generated in real time during the process of generating the parsing conclusion from the sales contract, used to mark problems that occur in the parsing process. Examples include incomplete rule matching, invalid field values ​​(such as non-existent country name, empty customer code), multiple rule priority conflicts, and missing core configurations. By setting parsing exception descriptions, maintenance personnel can quickly troubleshoot parsing faults, ensuring the traceability of parsing conclusions and the targeted nature of problem rectification.

[0127] The following further explains the triggering hierarchy of the parsing conclusion. The triggering hierarchy of the parsing conclusion consists of a basic scope dimension and a sub-scenario dimension. The basic scope dimension defines the boundary of the smallest business unit for generating the parsing conclusion. For example, the "contract" dimension clearly states that the parsing conclusion is generated based on a single contract, without confusing the parsing logic across contracts. The sub-scenario dimension defines the specific scenario or sub-object to which the parsing conclusion is adapted within the boundary of the basic scope, such as "product code", "software license sales configuration", "software annual fee sales configuration", etc. The specific parsing scenario is locked by matching the corresponding fields in the contract (such as core information such as product code, product type, transaction type, etc.). Specifically, when the corresponding field in the sales contract matches the entity attribute value corresponding to that field in the parsing rule, the generation of the parsing conclusion is triggered.

[0128] For example, the trigger level for parsing conclusions is as follows: "Contract + Product Code" indicates that the entire contract is used as a basis, with business granularity subdivided by product code. Services / products with different product codes under the same contract need to generate independent parsing conclusions separately. The trigger time for generating parsing conclusions is when the product COA code in the contract transaction details table of the sales contract matches the preset product COA code entity attribute value in the parsing rules. Alternatively, "Contract + Product Code" indicates that the entire contract is used as a basis, with business granularity locked according to the "Equipment Sales" specific scenario configuration. The trigger time for generating parsing conclusions is when "Contract Status = Activated", "Transaction Type = Channel Sales", and "Contract Type = Framework Contract" in the contract information table of the sales contract match "Product Type = Equipment" in the contract transaction details table, respectively, with the corresponding entity attribute values ​​in the parsing rules. The triggering level for the parsing conclusion is as follows: For the "Contract + Software License Sales" configuration, the entire contract is used as the basis, and the business granularity is determined according to the "Software License Sales" scenario. The parsing conclusion is triggered when fields such as "Product Type = License" and "Whether Software Loading and Delivery is Required" in the sales contract match the preset entity attribute values ​​in the parsing rules. Similarly, for the "Contract + Software Annual Fee Sales" configuration, the entire contract is used as the basis, and the business granularity is defined according to the "Software Annual Fee Sales" scenario. The parsing conclusion is triggered when fields such as "Product Type = Software Annual Fee" and "Transaction Type = Channel Sales" in the sales contract match the corresponding entity attribute values ​​in the parsing rules.

[0129] like Figure 6 As shown, a list of parsing conclusions corresponding to various product types is displayed. For example, for the device type, the parsing rule name is: Device - Channel Sales - Standard Sales Contract; the triggering level for the parsing conclusion is: Contract + Device Sales Configuration; Product COA: ;Product Description: Revenue recognition timing: Revenue recognition method: ; Explanation of parsing exceptions: Country Name: Customer Code: General: ; Manual analysis required: For the service type, the parsing rule name is: Service - Channel Sales - PO under the Framework; the triggering level for the parsing conclusion is: Contract + Product Code; Product COA: Product Description: Server Media Retention Service; Revenue Recognition Timing: Revenue recognition method: ; Explanation of parsing exceptions: Country Name: Customer Code: General: ; Manual analysis required: The parsing rule name is: Service - Channel Sales - PO under the Framework; the triggering level for the parsing conclusion is: Contract + Product Code; Product COA: 9221500; Product Description: Server Services; Revenue Recognition Timing: Revenue recognition method: ; Explanation of parsing exceptions: Country Name: Customer Code: General: ; Manual analysis required: For software type, the parsing rule name is: Software - Channel Sales - PO under Framework; the triggering level for the parsing conclusion is: Contract + Software License Sales Configuration; Revenue recognition time point: Revenue recognition method: ; Explanation of parsing exceptions: ; Manual analysis required: Does the payment process require software loading? For the software annual fee type, the parsing rule name is: Software Annual Fee - Channel Sales - PO under the Framework; the trigger level for the parsing conclusion is: Contract + Software Annual Fee Sales Configuration; Revenue recognition time point: Revenue recognition method: ; Explanation of parsing exceptions: General: ; Manual analysis required: .

[0130] In some embodiments, the computing device configures the above-described parsing rule structure and / or parsing rules in a revenue parsing system (specifically, a rule configurator). Thus, the revenue recognition method described in this application embodiment can be executed by running the revenue parsing system (or rule configurator). The second part, as... Figure 7 As shown, this application embodiment provides a revenue recognition method. For example, it includes the following steps: S701-S704, which can be executed by the processor of a computing device, such as a CPU.

[0131] S701, obtain the first information about the target sales contract.

[0132] A target sales contract is a sales contract for at least one product. The first piece of information includes the product type, transaction type, and contract type of the at least one product. For example, the specific quantity of each product in the sales contract can be multiple.

[0133] In some embodiments, the method further includes: obtaining the contract status of the target sales contract. In response to the contract status being in effect, determining whether there is a parsing conclusion for the target sales contract. Correspondingly, in one implementation of obtaining first information about the target sales contract, if there is no parsing conclusion for the target sales contract, the first information about the target sales contract is obtained.

[0134] In this embodiment, by first obtaining and verifying that the target sales contract is in effect before checking whether the parsing conclusion exists, invalid revenue recognition operations are avoided for ineffective contracts. Furthermore, this avoids generating duplicate parsing conclusions when they already exist for the target sales contract, improving the compliance and resource utilization efficiency of the method.

[0135] In other embodiments, based on the first information, a target parsing rule matching the first information is determined from multiple parsing rules, including: in the absence of a parsing conclusion for a target sales contract, a target parsing rule matching the first information is determined from multiple parsing rules based on the first information.

[0136] In this embodiment of the application, when there is no parsing conclusion for the target sales contract, the target parsing rule is matched from multiple parsing rules based on the first information, which can fill in the scenario where the parsing conclusion is missing and ensure the applicability of the target parsing rule.

[0137] In some embodiments, the method further includes: integrating the target sales contract. This involves first obtaining the target sales contract, then subsequently extracting first information from the target sales contract, or determining the contract status of the target sales contract before extracting the first information.

[0138] like Figure 8 As shown, this is a target sales contract for computing equipment integration.

[0139] S702, based on the first information, determine the target parsing rule that matches the first information from multiple parsing rules.

[0140] Multiple parsing rules are pre-configured in the computing device. The specific configuration process can be found in Part 1 and will not be repeated here.

[0141] In an implementation method that determines a target parsing rule matching the first information from multiple parsing rules, for each parsing rule, multiple first fields in the parsing rule are matched with the first information. If multiple first fields in the parsing rule successfully match the first information, that parsing rule is taken as the target parsing rule.

[0142] For example, the matching here can be understood as comparing the value of the first field in the parsing rule (such as the entity attribute value associated with the first field mentioned above) with the first information extracted from the sales contract (the first information is the actual value of the corresponding field). Only when the two sets of values ​​meet the preset matching method (such as the operation information being "equal to" or "included") requirements is it determined to be a successful match.

[0143] For example, if the first field of a parsing rule corresponds to the entity attribute and its value is "Product Type = Equipment (device), Transaction Type = Channel Sales, Contract Type = PO under Framework", the computing device will first extract the actual value of the first information from the sales contract, namely the product type (e.g., "Equipment"), transaction type (e.g., "Channel Sales"), and contract type (e.g., "PO under Framework") recorded in the contract. These two sets of values ​​will be compared one by one according to the corresponding attributes and the preset operation information (e.g., "equal to") in the parsing rule. If the actual value of the contract matches the entity attribute value, the first field matches successfully; if the actual product type of the contract is "License (software)", which is inconsistent with the "Equipment" preset in the rule, the match fails, and the parsing rule is directly excluded.

[0144] In this embodiment, the target parsing rule is determined by directly matching the first field of the parsing rule with the first information (such as matching core attributes such as product type, transaction type, and contract type), thereby simplifying and refining the parsing rule matching process and improving the efficiency and adaptability of the target parsing rule determination.

[0145] In some embodiments, the computing device uses a rule configurator to match multiple first fields in a parsing rule with first information for each parsing rule. If multiple first fields in a parsing rule successfully match the first information, that parsing rule is used as the target parsing rule.

[0146] For example, the computing device inputs the first information into the rule configurator, which then matches the first information with multiple first fields in multiple parsing rules. The parsing rule to which the first field that successfully matches the first information belongs is taken as the target parsing rule.

[0147] In this embodiment, the first information is precisely matched with the first field of multiple parsing rules by the rule configurator, thereby determining the target parsing rule. This automates and standardizes the rule matching process, avoids subjective bias and inefficiency caused by manual intervention in matching, and ensures accurate correspondence between the first information and the parsing rule through a preset value matching mechanism, thereby improving the efficiency and operability of determining the target parsing rule.

[0148] For example, there can be one or more target parsing rules. For instance, a sales contract might include products such as device 1 and service 1. The target parsing rule for device 1 would be determined from at least one parsing rule based on a device type-based parsing rule structure. The target parsing rule for service 1 would be determined from at least one parsing rule created from a service type-based parsing rule structure. Thus, this sales contract has two target parsing rules. As another example, a sales contract might include products such as device 1 and device 2. The target parsing rules for device 1 and device 2 would be determined from one or two parsing rules based on at least one parsing rule based on a device type-based parsing rule structure. Thus, this sales contract could have one or two target parsing rules.

[0149] In some embodiments, the method further includes: if a resolution exists for the target sales contract, recognizing revenue based on that resolution. This eliminates the need to regenerate the resolution, allowing for direct application of the existing resolution for revenue recognition, thus improving revenue recognition efficiency.

[0150] In some embodiments, after determining the target parsing rule, the method further includes: displaying a first interface, the first interface including a confirmation intervention flag, the confirmation intervention flag being used by the user to confirm whether to intervene in the modification of the target parsing rule. In response to an operation on the confirmation intervention flag, the target parsing rule is displayed for the user to confirm whether the target parsing rule needs to be modified.

[0151] For example, if a user modifies the target parsing rules, the parsing conclusion of the target sales contract will be determined based on the modified target parsing rules.

[0152] In this embodiment of the application, after determining the target parsing rules, a first interface with a confirmation intervention mark is displayed, which supports users to view and modify the target parsing rules, realizes automatic matching of manual verification and error correction of target parsing rules, adapts to the personalized needs of complex and special contracts, and ensures the accuracy and compliance of revenue recognition parsing rules.

[0153] Continue as Figure 8As shown, based on the target sales contract, the corresponding parsing rules are determined. These parsing rules are pre-configured based on a parsing rule structure, which is created based on the product type; details can be found in Part 1 and will not be repeated here.

[0154] S703, based on the target analysis rules, determines the analysis conclusion of the target sales contract. The analysis conclusion of the target sales contract is used to indicate the revenue recognition method for at least one product in the target sales contract, including the revenue recognition timing and revenue recognition method.

[0155] In an implementation method for determining the parsing conclusion of a target sales contract based on target parsing rules, the second information of the target sales contract is obtained. Based on the priority of multiple second fields included in the target parsing rules, the second fields are matched with the second information in descending order of priority until a target second field matching the second information is determined from among the multiple second fields. The parsing conclusion corresponding to the target second field is determined as the parsing conclusion of the target sales contract.

[0156] For example, the priority of multiple second fields can be found in the priority information in the first part, and will not be repeated here.

[0157] For example, if the country name in the target sales contract is The framework contract number is The second field 1 in the target parsing rule includes: country name ( ) and framework contract number ( If the second field 1 matches the second information in the target sales contract, then the corresponding parsing conclusion can be the parsing conclusion for the second field 1, such as: revenue recognition time point: acceptance time point 1; revenue recognition method: one-time recognition method 1. Another example is if the country name in the target sales contract is... Customer code is The second field 2 in the target parsing rule includes the country name ( ) and customer code ( If the second field 2 matches the second information of the target sales contract, the corresponding parsing conclusion can be the parsing conclusion corresponding to the second field 2, such as: the revenue recognition time point is: the acceptance time point 2, and the revenue recognition method is: one-time recognition method 2.

[0158] In this embodiment of the application, by obtaining the second information in the target sales contract and the second field in the parsing rules, and gradually matching multiple second fields in the target parsing rules from high to low priority until the matching parsing conclusion is determined, the accuracy and compliance of revenue recognition under different complex scenarios can be achieved.

[0159] In some embodiments, the method further includes: if no target second field matching the second information is determined among multiple second fields, then a default parsing conclusion is used to determine the parsing conclusion of the target sales contract. For example, the default parsing conclusion can be the parsing conclusion corresponding to the aforementioned "general level".

[0160] In this embodiment of the application, by enabling the default parsing conclusion (such as the parsing conclusion corresponding to the general level) when no second information is matched in multiple second fields, the problem of the revenue recognition process being interrupted due to the lack of matching rules can be avoided, thereby improving the completeness and practical reliability of the revenue recognition method.

[0161] For example, only one parsing result will be generated for the same product in the sales contract. For instance, only one parsing result will be generated for device 1 in the sales contract.

[0162] For example, if there are multiple products of a certain product type, multiple parsing results can be generated for each product. In this case, if multiple parsing results are duplicated, only one parsing result is retained and used as the parsing result for multiple products. For instance, if a sales contract includes equipment 1 and equipment 2, and equipment 1 and equipment 2 each correspond to a parsing result, if the two parsing results are identical, only one can be retained.

[0163] In addition to the revenue recognition timing and revenue recognition method mentioned above, the analytical conclusions can be obtained from the analytical rules.

[0164] In some embodiments, if the parsing conclusion includes a parsing exception description, the method may further include: monitoring whether an exception occurs during the process of determining the parsing conclusion of the target sales contract; if an exception occurs, recording the exception record information corresponding to the exception in the parsing exception description in the parsing conclusion.

[0165] In determining the parsing conclusion of the target sales contract, the generation of the parsing conclusion of the target sales contract is triggered based on the triggering level of the parsing conclusion configured in the target parsing rules. Specific triggering timings can be found in Part One and will not be repeated here.

[0166] In this embodiment, the target sales contract can generate a unique analytical conclusion that aligns with both the business scenario and IFRS 15 standards, under the dual-dimensional constraints of the analytical conclusion. Continuing as... Figure 8 As shown, the analytical conclusion is determined based on the analytical rules.

[0167] S704. Revenue recognition is based on the analytical conclusions of the target sales contract.

[0168] Specifically, revenue recognition is performed based on the revenue recognition method and timing from the analytical conclusions. For example, the revenue recognition timing is: Acceptance Point 1, and the revenue recognition method is: one-time recognition method. When recognizing revenue, the recognition process is automatically triggered upon reaching Acceptance Point 1. The transaction amount of the equipment (e.g., 1 million yuan) is extracted from the contract transaction details table and directly recorded in full as current revenue using "One-Time Recognition Method 1," without allocation. Simultaneously, the contract amount, performance acceptance amount, and financial accounting amount are confirmed to be consistent and without discrepancies. A financial voucher is then generated (e.g., summary: "POD Standard Server Acceptance Qualified Revenue Recognition," debit: Accounts Receivable 1 million yuan, credit: Main Business Revenue 1 million yuan). In this way, an automated process is sequentially implemented to achieve a closed loop of "recognition upon reaching the timing target and accounting upon compliance with the method," conforming to the requirements of IFRS 15.

[0169] In some embodiments, the method further includes: in response to a preset instruction of the target sales contract, backflipping the revenue already recognized under the target sales contract.

[0170] Preset instructions include instructions to change the content of the target sales contract or instructions to change the execution status. Revenue recognized refers to compliant revenue recorded in the company's financial statements after the revenue recognition time indicated by the analysis conclusion of the target sales contract (such as equipment acceptance date, software license effective date, service monthly milestone, etc.) is met, and the revenue recognition method indicated by the analysis conclusion (such as one-time recognition method, straight-line method) is followed. Reverse offsetting refers to operations such as canceling the original revenue recognition record and reducing the corresponding financial amount for recognized revenue.

[0171] For example, a content change instruction is used to indicate changes to the core terms of a target sales contract, such as changes to key content like first information, second information, or performance terms. An execution status change instruction is used to indicate changes to the actual execution progress or status of a target sales contract (resulting in the invalidation of the original revenue recognition premise).

[0172] In this embodiment of the application, by responding to the content change instruction or execution status change instruction of the target sales contract after revenue recognition, the recognized revenue is reversed, which can avoid the problem of revenue data not matching the actual transaction scenario after contract change, and adapt to the change management needs of the entire contract lifecycle.

[0173] like Figure 9 As shown, this application embodiment provides another revenue recognition method, which includes, for example, the following steps: S901-S904, which can be executed by the processor of a computing device, such as a CPU.

[0174] S901, Display the first interface, which includes a confirmation intervention indicator. The confirmation intervention indicator is used by the user to confirm whether to intervene in the modification of the target parsing rule.

[0175] S902, in response to the operation of the confirmation intervention flag, displays the target resolution rules, which are used by the user to confirm whether the target resolution rules need to be modified.

[0176] S903 responds to the user's modification operation on the target parsing rules and obtains the modified target parsing rules.

[0177] S904, revenue recognition is based on the modified target parsing rules.

[0178] In this embodiment of the application, during the process of automatically generating the parsing conclusion corresponding to the target sales contract, the user can view and modify the target parsing rules through the first interface displayed by the computing device, thereby realizing the automatic matching of manual verification and error correction of the target parsing rules, which can adapt to the personalized needs of complex and special contracts.

[0179] 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.

[0180] like Figure 10 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 revenue recognition method as described above.

[0181] Figure 10 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.

[0182] 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.

[0183] 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.

[0184] 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.

[0185] 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 10 As 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.

[0186] 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.

[0187] 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 10 (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 10 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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.

[0195] 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.

[0196] 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.

[0197] 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.

[0198] 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 revenue recognition method, characterized in that, include: Obtain first information about the target sales contract, wherein the target sales contract is a sales contract for at least one product, and the first information includes the product type, transaction type, and contract type of the at least one product; Based on the first information, a target parsing rule matching the first information is determined from multiple parsing rules, and the parsing rule is used to define the revenue recognition content of the sales contract. Based on the target parsing rules, the parsing conclusion of the target sales contract is determined, and the parsing conclusion of the target sales contract is used to indicate the revenue recognition content corresponding to at least one product in the target sales contract; Revenue is recognized based on the analysis results of the target sales contract.

2. The method according to claim 1, characterized in that, The parsing rule includes multiple first fields, which are fields used to match the first information; The step of determining the target parsing rule that matches the first information from multiple parsing rules based on the first information includes: For each of the plurality of parsing rules, the plurality of first fields in the parsing rule are matched with the first information; If multiple first fields in the parsing rule successfully match the first information, the parsing rule is used as the target parsing rule.

3. The method according to claim 1 or 2, characterized in that, The parsing rules include multiple second fields, and different second fields correspond to different parsing conclusions. The second fields include one or more of the following: country identifier, customer identifier, framework contract identifier, project identifier or product compliance identifier to which the target sales contract belongs. The step of determining the analysis conclusion of the target sales contract based on the target analysis rule includes: Obtain second information about the target sales contract, the second information including one or more of the following: country identifier, customer identifier, framework contract identifier, project identifier to which the target sales contract belongs, and product compliance identifier; Based on the priority of the plurality of second fields included in the target parsing rule, the second fields are matched with the second information in descending order of priority until a target second field matching the second information is determined from the plurality of second fields. The parsing conclusion corresponding to the second field of the target is determined as the parsing conclusion of the target sales contract.

4. The method according to claim 3, characterized in that, The method further includes: If no target second field matching the second information is found among the plurality of second fields, the default parsing conclusion will be determined as the parsing conclusion of the target sales contract.

5. The method according to any one of claims 1-4, characterized in that, Before determining the target parsing rule matching the first information from multiple parsing rules based on the first information, the method further includes: Obtain the contract status of the target sales contract, which indicates whether the target sales contract is in effect; In response to the contract status being in effect, determine whether there is a parsing conclusion for the target sales contract; The step of determining the target parsing rule that matches the first information from multiple parsing rules based on the first information includes: In the absence of a resolution conclusion for the target sales contract, a target resolution rule matching the first information is determined from multiple resolution rules based on the first information.

6. The method according to any one of claims 1-5, characterized in that, Before determining the target parsing rule matching the first information from multiple parsing rules based on the first information, the method further includes: Based on the configuration operation, a parsing rule structure is created for each of the preset product types; the parsing rule structure is used to define the first field and the second field of the parsing rule corresponding to the product type, as well as the priority of each second field; Based on the parsing rule structure for each product type, at least one parsing rule corresponding to each product type is determined to obtain the plurality of parsing rules.

7. The method according to claim 6, characterized in that, The number of identifiers included in different second fields varies; The more identifiers included in the second field, the higher the priority of the second field.

8. The method according to claim 6 or 7, characterized in that, Before creating the parsing rule structure for each of the preset product types according to the configuration operation, the method further includes: Based on the target company's sales operations, the various product types are determined.

9. The method according to any one of claims 1-8, characterized in that, After determining the target parsing rule that matches the first information from multiple parsing rules based on the first information, the method further includes: The first interface is displayed, which includes a confirmation intervention indicator. The confirmation intervention indicator is used by the user to confirm whether to intervene in the modification of the target parsing rule. In response to the operation of the confirmation intervention identifier, the target resolution rule is displayed for the user to confirm whether the target resolution rule needs to be modified.

10. The method according to any one of claims 1-9, characterized in that, After recognizing revenue based on the analysis conclusions of the target sales contract, the method further includes: In response to a preset instruction in connection with the target sales contract, the revenue already recognized under the target sales contract is reversed. The preset instruction may include a content change instruction or an execution status change instruction for the target sales contract.

11. A revenue recognition method, characterized in that, include: The first interface is displayed, which includes a confirmation intervention indicator. The confirmation intervention indicator is used by the user to confirm whether to intervene in the modification of the target parsing rule. The target parsing rule is a parsing rule that matches the target sales contract among multiple parsing rules. The parsing rule is used to define the revenue recognition content of the sales contract. In response to the operation of the confirmation intervention identifier, the target resolution rule is displayed for the user to confirm whether the target resolution rule needs to be modified. In response to the user's modification operation on the target parsing rule, obtain the modified target parsing rule; Revenue is recognized based on the modified target parsing rules.

12. 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-10.

Images