Service work order cancel-after-verification method and system

Abstract

The invention relates to a service work order cancel-after-verification method and system, and relates to the technical field of computer technologies. The method comprises the following steps: performing structured analysis on cancel-after-verification rules of a plurality of service work orders, clustering and unifying the same kind of rules, generating a matched cancel-after-verification page template based on a semantic association relationship, and finishing cancel-after-verification judgment in combination with a field verification rule in a template filling process. The cancel-after-verification processing process of the service work order is converted from a text-type cancel-after-verification mode which originally depends on manual understanding to an automatic presentation and automatic verification mode based on structured data. By adopting the method and the device, a uniform data expression mode can be established among the cancel-after-verification rules with different sources and different formats, so that the cancel-after-verification fields are converted into page control instances with clear meanings, controllable logic and stable structures from non-standard text expression, and the standardization degree of the cancel-after-verification rules can be remarkably improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a service work order verification method and system. Background Technology

[0002] In home appliance after-sales, installation, and repair service scenarios, service work orders from different manufacturers, product categories, and models typically require different completion information, such as fault type, parts usage, testing records, installation environment information, and supporting photos or videos. To meet manufacturers' management requirements for after-sales processes and service quality, service platforms usually need to display the corresponding service work order verification page in the service personnel's client application and perform format, quantity, or logical validation on the entered information.

[0003] Current technologies commonly employ manual or semi-manual configuration to design corresponding sales confirmation pages for each type of work order. Operations or development personnel need to manually create field types, field names, required fields, option content, hierarchical structure, and validation logic based on the manufacturer's provided reconciliation rule documents. Clearly, due to significant differences in reconciliation rules between different manufacturers and product lines, manually parsing and configuring page fields one by one requires a large amount of repetitive work, resulting in high costs and low efficiency. Furthermore, manufacturers' reconciliation rules are usually provided in natural language, with inconsistent expressions such as field naming, option expressions, and hierarchical descriptions. Manual parsing can easily lead to misunderstandings, resulting in inconsistent page configurations or errors. Summary of the Invention

[0004] Therefore, it is necessary to provide a service work order verification method and system to address the aforementioned technical issues.

[0005] Firstly, this application provides a service work order verification method, the method comprising: Obtain the reimbursement rules for multiple service tickets, parse the reimbursement rules using natural language processing technology, and obtain the data fields of the JSON object contained in each reimbursement rule; The reimbursement rules are grouped according to preset basic attributes, and the data fields of the reimbursement rules in the same group are clustered to generate a page control instance corresponding to each JSON object. The basic attributes include at least the service object and the service type. Based on the semantic relationships of each data field in the reconciliation rules of the same group, the reconciliation page templates of service work orders under each group are generated using the page control instances, and the field validation rules corresponding to each page control instance are set. In response to the reimbursement request of the target service work order, the target reimbursement page template corresponding to the target service work order is fed back to obtain the data to be filled in for each page control instance in the target reimbursement page template; The field validation rules are retrieved to validate the data entered for each page control instance. Based on the validation results, it is determined whether to perform the reconciliation process for the target service work order.

[0006] In one embodiment, the step of clustering the data fields of the same group of reimbursement rules to generate a page control instance corresponding to each JSON object includes: Cluster the data fields of the same group of reimbursement rules according to the preset JSON object categories; If multiple data fields are successfully clustered and merged, then page control instances for the selection options corresponding to those multiple data fields are generated; If the target data field cannot be clustered and merged, then an independent page control instance corresponding to the target data field is generated.

[0007] In one embodiment, natural language processing technology is used to parse the reimbursement rules to obtain the data fields of the JSON object contained in each reimbursement rule, including: The reimbursement rules are semantically identified and segmented to determine the multiple rule entries contained in the reimbursement rules; Identify the field types and required fields of the JSON object to which each rule entry belongs; Extract specific field content from the rule entries according to the field type; Configure the data fields of the JSON object based on the field type, required status, and specific field content.

[0008] In one embodiment, the semantic association includes at least the relative order of data fields, logical dependencies, and structural hierarchy.

[0009] In one embodiment, the field validation rules are obtained based on the semantic content of the verification rules, the format definition of the JSON object, the clustered data fields, and the semantic relationships between the data fields.

[0010] In one embodiment, generating the reimbursement page template for service work orders under each group using the page control instance includes: Based on the differences in field coverage of each data field in the grouped reconciliation rules, multi-level reconciliation page templates with different field completeness are generated using the page control instance.

[0011] In one embodiment, the step of responding to the reimbursement request of the target service work order and feeding back the target reimbursement page template corresponding to the target service work order includes: In response to the cancellation request of the target service work order, extract the work order attribute information corresponding to the cancellation request; Based on the search priority of the work order attribute information, the target reimbursement page template with the highest search priority that matches the work order attribute information is searched among the multi-level reimbursement page templates.

[0012] Secondly, this application also provides a service work order verification system, the system including a server and a client; The server is used for: Obtain the reimbursement rules for multiple service tickets, parse the reimbursement rules using natural language processing technology, and obtain the data fields of the JSON object contained in each reimbursement rule; The reimbursement rules are grouped according to preset basic attributes, and the data fields of the reimbursement rules in the same group are clustered to generate a page control instance corresponding to each JSON object. The basic attributes include at least the service object and the service type. Based on the semantic relationships of each data field in the reconciliation rules of the same group, the reconciliation page templates of service work orders under each group are generated using the page control instances, and the field validation rules corresponding to each page control instance are set. In response to the reconciliation request of the target service work order sent by the client, the target reconciliation page template corresponding to the target service work order is fed back to obtain the data to be filled in for each page control instance in the target reconciliation page template; The field validation rules are retrieved to validate the data entered for each page control instance. Based on the validation results, it is determined whether to perform the reconciliation process for the target service work order.

[0013] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method described in the first aspect.

[0014] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0015] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0016] The service ticket reconciliation method disclosed in this application involves structured parsing of reconciliation rules for multiple service tickets, clustering and unifying similar rules, and generating matching reconciliation page templates based on semantic relationships. During template submission, field validation rules are incorporated to complete the reconciliation judgment. This transforms the service ticket reconciliation process from a text-based model relying on manual understanding to an automated presentation and validation model based on structured data. Furthermore, this method establishes a unified data representation across reconciliation rules from different sources and in different formats. It transforms reconciliation fields from non-standard textual expressions into page control instances with clear meaning, controllable logic, and stable structures, thereby significantly improving the standardization of reconciliation rules. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the architecture of a service work order verification system in one embodiment. Figure 2 This is a flowchart illustrating a service order cancellation method in one embodiment; Figure 3 This is a flowchart illustrating a service order cancellation method in one embodiment; Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] This application provides a service order verification method. This method can be applied to the management system of a service platform that provides multiple types of services. The service platform may include a home appliance repair platform, a home appliance installation platform, a campus logistics service platform, a property management repair platform, and a comprehensive service order management platform for third-party service providers, etc. Figure 1 As shown, the management system can include a server and a client. The server can be the backend server of the service platform, and the client can be a mobile terminal, tablet, or other smart mobile device with the service platform application installed, held by the service personnel. When processing service work orders, service personnel can fill in various fields on the verification page, such as parts usage, service conclusion, on-site supporting documents, and service timeliness information, according to different manufacturers, product types, and service scenarios, and submit corresponding pictures, videos, or text records to complete the final closed loop of the work order.

[0020] In the aforementioned management system, the server acts as the core execution end of the service work order verification process. Based on the verification rules provided by the manufacturer, it creates verification pages for various service work orders and sends these pages to the client when the client applies for work order verification. After the client uploads the data to the verification page, the server further verifies the data to determine if it meets the manufacturer's verification standards. Finally, the server confirms whether the service work order has been successfully verified based on the verification results. In this process, the client acts as a supporting execution end of the verification process. It is responsible for receiving work order content from the service platform, parsing the corresponding verification requirements, displaying the required verification items, collecting uploaded data, and performing preliminary verification of the completed information. After completing repair, debugging, or installation services, service personnel can complete the verification information in the service work order by sliding the page, clicking options, and entering content on the client, thus submitting the service work order to the server.

[0021] The following will be about Figure 2 The following is a detailed explanation of a service order reconciliation method, which may include the following steps: Step 201: Obtain the reconciliation rules for multiple service work orders, and use natural language processing technology to parse the reconciliation rules to obtain the data fields of the JSON object contained in each reconciliation rule.

[0022] In implementation, equipment manufacturers, service operators, or platform administrators can formulate reimbursement rules for different service work orders and upload these rules to the service platform's server. The reimbursement rules can be in the form of structured data or natural language paragraphs. For example, a gas boiler manufacturer's reimbursement requirements might include "uploading a video of the gas proportional valve commissioning (including the voltage testing process)," "selecting repair parts (such as water pump gaskets and gas filters)," and "filling in the recommended date for the next maintenance."

[0023] After obtaining the reimbursement rules corresponding to service orders (such as boiler repair, Midea air conditioner installation, and robot vacuum cleaner debugging), the server can perform parsing processes such as word segmentation, syntactic structure analysis, entity recognition, and relation extraction on the reimbursement rules according to the requirements of the JSON field structure. This allows the server to identify the data fields of the JSON object contained in each reimbursement rule. The data fields of the JSON object can include field names (such as "repair parts"), field types (such as multiple selection, image upload, cascading selection), required fields, option lists, and hierarchical relationships. Thus, each reimbursement rule can be parsed into a standardized set of JSON field structures, facilitating subsequent control rendering and rule aggregation.

[0024] In one embodiment, the process of parsing the reconciliation rules in step 201 may specifically include the following steps: Step 2011: Perform semantic recognition and segmentation on the reconciliation rules to determine the multiple rule entries contained in the reconciliation rules.

[0025] In implementation, after the server obtains the reimbursement rules for a certain type of service order from the manufacturer or service provider, it uses natural language processing capabilities to perform semantic recognition on the entire rule text. This allows it to extract structured fields that can be used to generate reimbursement page controls from long paragraphs, mixed semantics, or different descriptive styles. It's easy to understand that reimbursement rules generally have strong business context and equipment characteristics, such as "upload a debugging video containing the gas proportional valve voltage detection steps," "select the spare parts to be replaced this time and ensure at least one," and "you can fill in the suggested date for the next maintenance," etc. While these descriptions reflect the manufacturer's requirements for reimbursement behavior, because they are usually presented in natural language, the server cannot directly use these rules to build the service order reimbursement page.

[0026] To address the aforementioned issues, the server can first perform statement-level semantic segmentation on the original rules. This can be achieved by identifying the structure between "action words - object words - constraints" through syntactic dependency relations, thus breaking down long texts into semantically independent rule fragments. For example, "Upload debugging video (the video must include the voltage detection process)" can be identified as a complete "upload-type field entry," while "Select spare parts used in this repair, no less than 1 item" can be identified as a "selection-type field entry." In this way, the server can extract multiple rule entries from a single complete reconciliation rule, with each rule entry corresponding to an independent page control on the subsequent reconciliation page.

[0027] Step 2012: Identify the field types and required fields of the JSON object to which each rule entry belongs.

[0028] In implementation, after obtaining multiple rule entries, the server can further identify the field types of the JSON objects contained in each rule entry. Specifically, the server can identify the field types of the JSON objects that may correspond to each rule entry through keyword matching (such as "upload video", "photo", "select spare parts", "fill in date", etc.), such as video upload, image upload, multiple selection, or date types. The server can also use category dictionaries and pre-trained models to analyze the context. For example, "select gas proportional valve debugging video" contains the word "select", but if the selected object is identified as "video", it can be identified as a typical video upload type; "fill in next maintenance time" does not explicitly mention the word "date", but the server can determine that it is a date field based on semantics such as "next" and "maintenance time". At the same time, the server can also determine the mandatory status of fields based on semantic tone. For example, descriptions such as "must upload", "must provide", "no less than", and "at least" are determined to be mandatory fields, while statements such as "optional" and "recommended to fill in" correspond to optional fields.

[0029] Step 2013: Extract specific field content from rule entries according to field type.

[0030] In implementation, after determining the field types and required fields, the server can then extract specific field content from each rule entry to construct the field's title, remarks, quantity limits, and other JSON object data fields. For example, in the rule entry "Upload debugging video (must include voltage detection process)," the server can identify "debugging video" as the field title and "includes voltage detection process" as the field remarks; in the rule entry "Select spare parts to use, no less than 1 item," "spare parts" is identified as the field name, while "no less than 1 item" is extracted as the quantity constraint; for the rule entry "Fill in the next maintenance time," "next maintenance time" will be extracted as the field title and associated with a date control.

[0031] Step 2014: Configure the data fields of the JSON object based on field type, required status, and specific field content.

[0032] Step 202: Group multiple reimbursement rules according to preset basic attributes, cluster the data fields of the reimbursement rules in the same group, and generate a page control instance corresponding to each JSON object.

[0033] The basic attributes of a service ticket can include at least the service recipient and service type. The basic attributes of a service ticket can also include product brand and product model as needed.

[0034] In implementation, after parsing the reimbursement rules, the server can group multiple reimbursement rules according to the basic attributes of the service work order. Specifically, grouping can be done according to two dimensions: service object (e.g., air conditioner, range hood, refrigerator) and service type (e.g., installation, repair, debugging), so that rules under the same business are grouped into the same rule group. For example, the reimbursement rules for "Midea air conditioner installation" and "Gree air conditioner installation" can be grouped together, while "air conditioner installation" and "air conditioner repair" can be grouped into different groups, and the reimbursement rules for "gas boiler repair" and "gas water heater repair" can be grouped together. Then, within each group, the server can perform clustering processing on the data fields of the reimbursement rules within the group to gradually converge the field heterogeneity between different reimbursement rules into a unified control expression.

[0035] In the above process, the server can comprehensively consider multi-dimensional information such as field type characteristics, business purpose, and field structure to automatically identify the logical scope that different fields can jointly present, and generate corresponding page control instances based on this. In this way, the reimbursement rules can be transformed from free text into page control instances of JSON objects with clear structured expression, realizing the unification and convergence of multiple reimbursement rules.

[0036] In one implementation, step 202 can be processed as follows: cluster the data fields of the same group of reimbursement rules according to the preset JSON object category; if multiple data fields are successfully clustered and merged, generate page control instances of the selection options corresponding to the multiple data fields; if the target data field cannot be clustered and merged, generate an independent page control instance corresponding to the target data field.

[0037] The type of JSON object can be determined based on the "type" data field. For example, when type=1, the JSON object is a radio button; when type=3, the JSON object is a text object; when type=7, the JSON object is a video object; and when type=8, the JSON object is a photo / QR code object, etc.

[0038] In implementation, when the server performs clustering processing for reconciliation rules, it can further employ a two-level processing approach: "regional clustering" and "semantic clustering." Specifically, after the reconciliation rules are grouped, the server can perform regional clustering on data fields within each group to centrally process data fields belonging to the same JSON object category. This means that different data fields can be grouped into a unified control area based on field type, internal structure, and purpose. If multiple data fields are successfully clustered and merged, the server can generate page control instances for the selection options corresponding to those data fields. If the target data field cannot be clustered and merged, the server can generate an independent page control instance corresponding to the target data field. For example, in the "Air Conditioner Installation" verification rule 1, there is a single-choice JSON object for "Air Conditioner Power" with data fields including "100w-200w" and "500-700w". In the "Air Conditioner Installation" verification rule 2, there is also a single-choice JSON object for "Air Conditioner Power" with data fields including "800w-1000w" and "1200-1500w". Therefore, the data fields of the two verification rules can be clustered and merged to generate a page control instance of a single-choice JSON object for "Air Conditioner Power" that simultaneously contains the options "100w-200w", "500-700w", "800w-1000w", and "1200-1500w". Similarly, in the "Air Conditioner Repair" verification rule 1, there is a video upload JSON object with the data field "Upload Air Conditioner Normal Operation Video". In the "Air Conditioner Repair" verification rule 2, there is a video upload JSON object with the data field "Upload Air Conditioner Disassembly Video". Since the two data fields cannot be clustered and merged, separate page control instances are generated for each. It is understandable that the results of region clustering determine how controls are presented, such as merging them into a single control, constructing a multi-select control, or generating multiple independent controls according to field logic.

[0039] Furthermore, after regional clustering is completed, the server can also perform a semantic clustering phase. Semantic clustering mainly targets the differences in the expression of fields under different rule sources, primarily identifying whether the substantive content of different rules is consistent. For example, although "repair parts," "replacement parts," and "replacement parts list" have different wording, the server can identify through the model that their semantic core all points to "materials actually used in the service process," and therefore can be judged to have the same business meaning in semantic clustering. After semantic clustering, the server can ultimately unify multiple data fields from different sources, with inconsistent expressions but the same meaning, into a single page control instance, thereby achieving field standardization across manufacturers and rules.

[0040] In addition, when a semantic conflict is detected in the clustering field, the server can automatically add additional prompts, mutual exclusion validation logic, or forced single-selection strategies to the subsequent page reconciliation template. This ensures that the final generated template supports multiple rule expressions and avoids reconciliation errors caused by semantic conflicts.

[0041] Step 203: Based on the semantic relationships of each data field in the reconciliation rules of the same group, generate reconciliation page templates for service work orders under each group using page control instances, and set field validation rules corresponding to each page control instance.

[0042] In implementation, after completing data field parsing, reconciliation rule grouping, and page control instance generation, the server can further organize the page control instances corresponding to the same group of reconciliation rules into a unified template. Specifically, the server can deduce the presentation structure of page controls on the final reconciliation page based on the semantic relationships between data fields, thereby generating a service order reconciliation page template suitable for that group. During template construction, the server can not only consider the basic display method of each page control, but also determine the arrangement order and structural framework of page controls in the reconciliation page template based on the sequential logic, business triggering relationships, and display hierarchy between page controls. This ensures that the reconciliation page is presented according to a natural business process, making it easy for service personnel to quickly understand and fill out the form.

[0043] Accordingly, the aforementioned semantic relationships can include at least the relative order of data fields, logical dependencies, and structural hierarchy. By extracting these semantic relationships, the server can infer the dependency order between page controls. For example, some fields must be displayed after other fields, or some fields are subsequent logical options of preceding fields, or some fields are subordinate structural branches of parent fields.

[0044] For example, in the "Air Conditioner Installation" scenario, there is a clear logical dependency between "Installation Method" and "Upload Bracket Welding Video". Uploading the welding video is only required after "Outdoor Wall Installation" is selected. Therefore, these two can be identified as logically dependent controls and structured as parent-child controls in the page template. Similarly, "Service Items" is typically the upper-level field, while fields such as "Service Item Details" and "Accessories Selection" can be categorized as lower-level fields. The server can then display these fields in a structured hierarchical manner in the reimbursement page template.

[0045] In this way, through semantic relationships, the server can automatically optimize the display order of page controls. It can place required basic attributes at the beginning of the page and optional additional items at the end, or group related controls together in adjacent areas to make the verification page structure clear and logical, which helps improve the efficiency of service personnel in filling out forms.

[0046] The server can also configure corresponding field validation rules for each control instance, enabling timely detection of the validity, completeness, and compliance of user-entered information. Field validation rules serve as the standard for the server to automatically validate the data entered by service personnel, ultimately determining whether the service order is allowed for normal cancellation.

[0047] Specifically, field validation rules can be determined based on the semantic content of the verification rules, the format definition of the JSON object, the clustered data fields, and the semantic relationships between the data fields. After the server generates a control instance, it can extract validation constraints based on the textual requirements of the verification rules, such as whether a video must be uploaded, whether the video needs to include specific steps, and whether there is a minimum limit on the number of images. These validation constraints are used to transform the business validation logic of the page control. Simultaneously, the format definition of the JSON object can also provide structural constraints for the validation rules. For example, certain fields must conform to numeric, date, or barcode formats; these format validation rules will be automatically included in the field validation scope during control rendering. Furthermore, the clustered data fields will have a fusion effect on the validation content. For example, multiple verification rules may have different source requirements after semantic aggregation. The server can retain these differences in the validation rules, enabling the page control to simultaneously cover business standards from multiple sources during validation.

[0048] Furthermore, the semantic relationships between fields can also affect the validation results. For example, if a control is a subordinate field of a preceding field, the server can set conditional validation logic through dependencies. This means that the subordinate field only needs to be validated if an item is selected in the preceding field. By integrating the above multi-dimensional information, the field validation rules can ultimately form a complete detection logic.

[0049] In summary, step 203 enables further processing from page control instances into a reconciliation page template, and solidifies the business constraints in the reconciliation rules onto the controls in the form of validation rules, thus making the reconciliation page both displayable and verifiable.

[0050] Optionally, some field validation rules can be configured directly in the reconciliation page template. When the reconciliation page template is sent to the client, some simple field validation rules are also sent to the client. This allows service personnel to perform preliminary validation of the data when filling it out on the client and promptly prompt the service personnel to make adjustments.

[0051] Furthermore, when the server detects that the semantic distance between the new rule and the existing cluster center exceeds a stable threshold, it automatically triggers the template partial reconstruction logic, which only partially expands or replaces the page control instances corresponding to the affected fields, without having to regenerate the entire template.

[0052] Step 204: In response to the reconciliation request of the target service work order, provide the target reconciliation page template corresponding to the target service work order to obtain the data to be filled in for each page control instance in the target reconciliation page template.

[0053] In implementation, after completing a target service order, service personnel can cancel it via client-side operations. At this point, the server receives the cancellation request for the target service order, and based on the business attributes of the target service order carried in the cancellation request, searches for the corresponding target cancellation page template in the pre-generated cancellation page templates and sends it back to the client. Upon receiving the target cancellation page template, the client dynamically renders the complete cancellation page based on the field structure, control types, default display logic, and constraint information contained in the template. This visually presents all control instances required by the cancellation rules, including text input controls, single or multiple selection controls, image upload controls, video upload controls, and cascading selection controls. Service personnel can then perform information entry operations for each page control instance on the cancellation page and click upload after completion, triggering the server to receive and retrieve the entered data from each page control instance in the target cancellation page template.

[0054] During the rendering process of the verification page, the client can also dynamically display effects based on the semantic relationships contained in the controls. For example, if a page control is identified as a subfield dependent on other fields in step 203, the client will dynamically display the page control after the user selects to trigger that other field, avoiding invalid fields on the interface and thus improving the interactive experience of the verification page. Simultaneously, for page controls with default values, sample content, or filling prompts, the client can synchronously display this information to help service personnel quickly understand the filling requirements and reduce the probability of filling errors. Through the above methods, the transformation from a template to an actual fillable interface is achieved, making the structured control system generated by the server fully visible and fillable on the client, providing a data input source for subsequent verification and reconciliation actions.

[0055] Step 205: Retrieve the field validation rules to validate the data entered for each page control instance. Based on the validation results, determine whether to execute the reconciliation process for the target service work order.

[0056] In implementation, after the server receives the data uploaded by the client, it can retrieve the field validation rules configured for each control instance in step 203 to perform completeness, legality, and semantic consistency checks on each uploaded data item by item. This ensures that the submitted data meets basic format requirements and conforms to the business logic of the verification rules. For example, it can determine whether required fields are filled, whether the number of uploaded files meets the requirements, whether the dependencies between fields are satisfied, and whether the video or image content contains information points related to specific work steps.

[0057] During the validation phase, the server can comprehensively evaluate submitted data using multiple pieces of information, including field type, field format, rule description text, and data relationships. For example, for required fields, the server can check if they contain non-empty values; for text fields, it can verify if they meet the set format rules; and for uploaded fields, it can verify the number of files, file format, and, if necessary, the content of image or video keyframes to ensure consistency with the verification rules. If there are semantic dependencies between fields, such as "after selecting a certain service item, related work images must be uploaded," the server can check if the dependency conditions are met to avoid logical conflicts in the entered content.

[0058] After the verification is completed, if all fields pass the verification, the server can determine that the target service work order meets the reconciliation conditions and then execute the subsequent reconciliation process; otherwise, the server can send the fields that failed the verification and the corresponding prompts back to the client, so that the service personnel can supplement the explanation or correct the content and resubmit it according to the prompts.

[0059] It's worth noting that in actual reconciliation scenarios, many fields appear in the rules, but their actual usage frequency is very low. If all of them are presented in the template, it will cause redundancy in the front-end interface. After the template is generated, the display priority of page controls can be dynamically adjusted based on the frequency of use of fields in historical reconciliation, the probability of being required, and the weight of the field's role. High-frequency rigid fields can be set to be displayed in a fixed manner, medium-frequency fields can be collapsed as needed, and low-frequency fields can be lazy-loaded or presented on demand.

[0060] In one embodiment, the generation process of the reconciliation page template in step 203 can also be as follows: based on the differences in field coverage of each data field in the grouped reconciliation rules, multi-level reconciliation page templates with different field completeness are generated using page control instances.

[0061] During implementation, when generating the reconciliation page template, the server can consider the differences in field coverage required by different work orders under different scenarios. Since the reconciliation rules for different manufacturers, service types, and product models often do not have completely consistent field requirements, some reconciliation rules may only require basic information and file uploads, while others may include more specialized fields, additional prompts, or supplementary verification items. To adapt to these differences, the server can divide page control instances into different levels according to the completeness of field requirements based on the differences in field coverage of each data field in the grouped reconciliation rules, thereby generating multi-level reconciliation page templates with varying degrees of field completeness.

[0062] Field coverage can be understood as the proportion of times a data field is required across all reconciliation rules in the same rule group. For example, in the "Air Conditioner Installation" rule group, "Installation Completion Photo" may appear in almost all rules, thus being identified as a basic field with high coverage. Conversely, "Refrigerant Pressure Record" and "Outdoor Unit Reinforcement Method" may only appear in rules for certain models or manufacturers, thus having only medium or low coverage. The server can build multi-level reconciliation page templates based on the prevalence of these field requirements, arranging page controls according to a gradient from basic to complete requirements. For instance, a basic template might contain high-coverage fields, a standard template might contain both high and medium-coverage fields, and an enhanced or complete template might contain all fields, including those with low coverage but necessary for specific scenarios.

[0063] In this way, the server can create a top-down hierarchical structure at the reimbursement page template level. This ensures that the reimbursement page templates not only maintain structural consistency but also accommodate the differentiated needs of various reimbursement scenarios. In subsequent work order reimbursement requests, the server can flexibly match between multi-level reimbursement page templates to provide the most suitable template for the user, without having to force the use of the same complex template for all work orders.

[0064] Based on the above scheme for generating multi-level reconciliation page templates, step 204 can be processed as follows: In response to the reconciliation request of the target service work order, extract the work order attribute information corresponding to the reconciliation request; based on the search priority of the work order attribute information, search for the target reconciliation page template with the highest search priority that matches the work order attribute information in the multi-level reconciliation page templates.

[0065] In implementation, when a client initiates a reconciliation request for a target service ticket, the server can find the most suitable target reconciliation page template among reconciliation page templates at different levels. Specifically, the server can first extract the corresponding service ticket attribute information based on the ticket ID or basic attributes in the reconciliation request. This information may include the service recipient, service type, product brand, product model, business region, etc.

[0066] After obtaining the work order attribute information, the server can perform a step-by-step matching within multi-level reimbursement page templates based on predefined search priorities. The search priority can be set to start with the most stringent and precise matching template, prioritizing the search for the highest-level reimbursement template generated for a specific product model, brand, and service type. If the attribute set of the service work order can find a completely matching template in the highest-priority templates, that template can be directly submitted as the target reimbursement page template.

[0067] However, in practical applications, not all work orders can find a completely consistent template. For example, the rule coverage for certain new models, rare devices, or cross-regional work orders may be insufficient. In such cases, the service segment can gradually lower the template matching requirements according to the search priority, continuing the search in the next level of templates. For example, if there is no specific model template, the brand-level template is matched; if the brand-level template still cannot be matched, the service type-level template is matched; if it still fails, a basic or general-level template is used. Finally, the server can select the template that is at the top of the search priority chain and still matches the work order attribute information as the target verification page template for that service work order.

[0068] Understandably, work order attribute information can generally include model, brand, product (e.g., air conditioner, washing machine), service object (e.g., home appliance, plumbing), and service type (e.g., repair, disassembly), with the search priority decreasing accordingly. For example, assuming the work order attributes are "Brand = Haier, Model = XYZ-123, Product = Air Conditioner, Service Type = Repair," the initial precise search, because the model is new and no template exists, will search for a template based on "Air Conditioner + Repair + Haier." If no template is found, it will search for a general air conditioner repair template based on "Air Conditioner + Repair." If no template is found yet, it can search for home appliance repair templates. Furthermore, under the same search priority, if multiple templates exist, they can be further filtered based on the number of templates used. Based on the above example, if multiple templates are found based on "Air Conditioner + Repair + Haier," including "Floor-standing Air Conditioner Repair Template," "Wall-mounted Air Conditioner Repair Template," and "Fresh Air Conditioner Repair Template," then the number of historical work orders for each template can be determined, and the template with a large number of historical work orders can be prioritized for feedback. Similarly, under the same search priority, if multiple templates exist, they can be filtered based on the risk of missing data fields. Templates with more high-risk missing data fields will be returned. For example, if template A, found based on "air conditioner + repair + Haier," contains the following data fields: fault type (key field), uploaded video (high risk), compressor parameter reading (high risk), and template B contains the following data fields: product appearance photo upload (low risk), repair notes (low risk), then template A can be returned based on the risk of missing data fields. Of course, considering both the risk of missing data and the number of templates used, when multiple templates exist, the search should prioritize templates based on the risk of missing data, followed by a secondary filter based on the number of templates used.

[0069] The risk of missing data fields can be determined based on the field type, the verification rules provided by the manufacturer, the verification algorithms supported by the server, and the statistical results of historical work orders. For example, the risk of missing data fields for video uploads is the highest, as is the risk of missing data fields for remarks. If a data field in the verification rules corresponds to keywords such as "must," "required," or "must be provided," it will be judged as high-risk. Generally, the server supports video recognition algorithms, barcode decoding algorithms, text recognition algorithms, and image recognition algorithms. If the corresponding data field is missing, the corresponding algorithm cannot be executed, causing the work order verification logic to fail. Therefore, the data field with the corresponding algorithm can be judged as high-risk. If historical data shows that the "fault type" field of a certain brand is often the root cause of verification disputes, or the "barcode field" of a certain product often leads to rework due to missing data, or the video field of a certain model generally determines the verification pass rate, then the risk of the corresponding field can be automatically increased based on historical statistical data.

[0070] In this embodiment, by performing structured parsing of the reconciliation rules for multiple service work orders, clustering and unifying similar rules, and generating matching reconciliation page templates based on semantic relationships, and by combining field validation rules during the template filling process to complete the reconciliation judgment, the service work order reconciliation process is transformed from a text-based reconciliation mode that relies on manual understanding to an automatic presentation and automatic validation mode based on structured data. Using the service work order reconciliation method disclosed in this application, a unified data expression method can be established among reconciliation rules from different sources and in different formats. This transforms reconciliation fields from non-standard text expressions into page control instances with clear meaning, controllable logic, and stable structure, thereby significantly improving the standardization of reconciliation rules.

[0071] Based on the reconciliation page templates generated through rule grouping and control instantiation, corresponding reconciliation interfaces can be automatically generated according to the differences in business attributes of different work orders. This ensures that different types of work orders can obtain field display and filling paths that match their business scenarios during reconciliation, avoiding field redundancy, field omissions, and rule misunderstandings, making the reconciliation filling process more accurate and efficient. Simultaneously, the data submitted by the client can be automatically verified under structured and semantic validation logic, fundamentally guaranteeing the authenticity, completeness, and logical consistency of the reconciliation data, reducing the burden of manual review and lowering the probability of reconciliation errors. Through the synergistic effect of the above-mentioned structured parsing, clustering unification, template generation, and field validation, the service work order reconciliation process can be automated, standardized, and intelligentized, improving overall reconciliation efficiency and enhancing adaptability and processing reliability for multiple types of service work orders.

[0072] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0073] Based on the same inventive concept, this application also provides a service work order verification system, which includes a server and a client. The server is used for: Obtain the reimbursement rules for multiple service tickets, parse the reimbursement rules using natural language processing technology, and obtain the data fields of the JSON object contained in each reimbursement rule; The reimbursement rules are grouped according to preset basic attributes, and the data fields of the reimbursement rules in the same group are clustered to generate a page control instance corresponding to each JSON object. The basic attributes include at least the service object and the service type. Based on the semantic relationships of each data field in the reconciliation rules of the same group, the reconciliation page templates of service work orders under each group are generated using the page control instances, and the field validation rules corresponding to each page control instance are set. In response to the reconciliation request of the target service work order sent by the client, the target reconciliation page template corresponding to the target service work order is fed back to obtain the data to be filled in for each page control instance in the target reconciliation page template; The field validation rules are retrieved to validate the data entered for each page control instance. Based on the validation results, it is determined whether to perform the reconciliation process for the target service work order.

[0074] In one embodiment, the step of clustering the data fields of the same group of reimbursement rules to generate a page control instance corresponding to each JSON object includes: Cluster the data fields of the same group of reimbursement rules according to the preset JSON object categories; If multiple data fields are successfully clustered and merged, then page control instances for the selection options corresponding to those multiple data fields are generated; If the target data field cannot be clustered and merged, then an independent page control instance corresponding to the target data field is generated.

[0075] In one embodiment, natural language processing technology is used to parse the reimbursement rules to obtain the data fields of the JSON object contained in each reimbursement rule, including: The reimbursement rules are semantically identified and segmented to determine the multiple rule entries contained in the reimbursement rules; Identify the field types and required fields of the JSON object to which each rule entry belongs; Extract specific field content from the rule entries according to the field type; Configure the data fields of the JSON object based on the field type, required status, and specific field content.

[0076] In one embodiment, the semantic association includes at least the relative order of data fields, logical dependencies, and structural hierarchy.

[0077] In one embodiment, the field validation rules are obtained based on the semantic content of the verification rules, the format definition of the JSON object, the clustered data fields, and the semantic relationships between the data fields.

[0078] In one embodiment, generating the reimbursement page template for service work orders under each group using the page control instance includes: Based on the differences in field coverage of each data field in the grouped reconciliation rules, multi-level reconciliation page templates with different field completeness are generated using the page control instance.

[0079] In one embodiment, the step of responding to the reimbursement request of the target service work order and feeding back the target reimbursement page template corresponding to the target service work order includes: In response to the cancellation request of the target service work order, extract the work order attribute information corresponding to the cancellation request; Based on the search priority of the work order attribute information, the target reimbursement page template with the highest search priority that matches the work order attribute information is searched among the multi-level reimbursement page templates.

[0080] In one embodiment, a computer device is provided, the internal structure of which can be shown as follows: Figure 3 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for data exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a service order verification method.

[0081] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0082] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0083] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0084] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0085] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The processors involved in the embodiments provided in this application can be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited thereto.

[0086] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0087] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A service work order verification method, characterized in that, The method includes: Obtain the reimbursement rules for multiple service tickets, parse the reimbursement rules using natural language processing technology, and obtain the data fields of the JSON object contained in each reimbursement rule; The reimbursement rules are grouped according to preset basic attributes, and the data fields of the reimbursement rules in the same group are clustered to generate a page control instance corresponding to each JSON object. The basic attributes include at least the service object and the service type. Based on the semantic relationships of each data field in the reconciliation rules of the same group, the reconciliation page templates of service work orders under each group are generated using the page control instances, and the field validation rules corresponding to each page control instance are set. In response to the reimbursement request of the target service work order, the target reimbursement page template corresponding to the target service work order is fed back to obtain the data to be filled in for each page control instance in the target reimbursement page template; The field validation rules are retrieved to validate the data entered for each page control instance. Based on the validation results, it is determined whether to execute the reconciliation process for the target service work order.

2. The method according to claim 1, characterized in that, The process of clustering the data fields of the same group of reimbursement rules to generate a page control instance corresponding to each JSON object includes: Cluster the data fields of the same group of reimbursement rules according to the preset JSON object categories; If multiple data fields are successfully clustered and merged, then page control instances for the selection options corresponding to those multiple data fields are generated; If the target data field cannot be clustered and merged, then an independent page control instance corresponding to the target data field is generated.

3. The method according to claim 1, characterized in that, The reimbursement rules are parsed using natural language processing techniques to obtain the data fields of the JSON object contained in each reimbursement rule, including: The reimbursement rules are semantically identified and segmented to determine the multiple rule entries contained in the reimbursement rules; Identify the field types and required fields of the JSON object to which each rule entry belongs; Extract specific field content from the rule entries according to the field type; Configure the data fields of the JSON object based on the field type, required status, and specific field content.

4. The method according to claim 1, characterized in that, The semantic relationships include at least the relative order of data fields, logical dependencies, and structural hierarchy.

5. The method according to claim 1, characterized in that, The field validation rules are derived based on the semantic content of the verification rules, the format definition of the JSON object, the clustered data fields, and the semantic relationships between the data fields.

6. The method according to claim 1, characterized in that, The step of generating the reimbursement page template for service orders under each group using the page control instance includes: Based on the differences in field coverage of each data field in the grouped reconciliation rules, multi-level reconciliation page templates with different field completeness are generated using the page control instance.

7. The method according to claim 6, characterized in that, The response to the reimbursement request of the target service work order includes providing the target reimbursement page template corresponding to the target service work order, including: In response to the cancellation request of the target service work order, extract the work order attribute information corresponding to the cancellation request; Based on the search priority of the work order attribute information, the target reimbursement page template with the highest search priority that matches the work order attribute information is searched among the multi-level reimbursement page templates.

8. A service work order verification system, characterized in that, The system includes a server and a client; The server is used for: Obtain the reimbursement rules for multiple service tickets, parse the reimbursement rules using natural language processing technology, and obtain the data fields of the JSON object contained in each reimbursement rule; The reimbursement rules are grouped according to preset basic attributes, and the data fields of the reimbursement rules in the same group are clustered to generate a page control instance corresponding to each JSON object. The basic attributes include at least the service object and the service type. Based on the semantic relationships of each data field in the reconciliation rules of the same group, the reconciliation page templates of service work orders under each group are generated using the page control instances, and the field validation rules corresponding to each page control instance are set. In response to the reconciliation request of the target service work order sent by the client, the target reconciliation page template corresponding to the target service work order is fed back to obtain the data to be filled in for each page control instance in the target reconciliation page template; The field validation rules are retrieved to validate the data entered for each page control instance. Based on the validation results, it is determined whether to execute the reconciliation process for the target service work order.

9. A computer device comprising a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the service order cancellation method according to any one of claims 1-7.

10. A computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the service order cancellation method according to any one of claims 1-7.

Images