Version management method and device for electronic work order system, equipment and medium

Abstract

The invention relates to a version management method and device for an electronic work order system, equipment and a medium, and the version management method for the electronic work order system comprises the steps: obtaining a version updating request, and determining a current routing source of the version updating request; acquiring an updated version of a current routing source in real time; the version recording information at least comprises an updating operator and an updating type, the weight value of the updating operator is determined, a corresponding version strategy is executed according to the updating type and / or the weight value, and the version strategy at least comprises version replacement and version coexistence. When work order defects and demand changes of different sources are processed, the version coexistence strategy allows different versions to exist in the system at the same time, and the problem of important information coverage or loss caused by version replacement is avoided. The flexibility and stability of the system are improved, reliable tracking and management of multi-party operation and demand change are ensured, and version management is more accurate and efficient.

Description

Technical Field

[0001] The present invention relates to the technical field of version management for electronic work order systems, and in particular to a version management method, device, equipment and medium for electronic work order systems. Background Art

[0002] At present, in traditional electronic work order systems, version management usually relies on manual operations or simple version control tools, which have problems such as incomplete update records and irregular version replacement. Due to the lack of refined management of update operations and intelligent analysis of update content, version conflicts or information loss are prone to occur when handling work order defects and demand changes, affecting system stability and work efficiency. Summary of the invention

[0003] In order to solve the problem that version management in traditional electronic work order systems usually relies on manual operations or simple version control tools, which affects the stability and work efficiency of the system, the present application provides a version management method, device, equipment and medium for an electronic work order system.

[0004] The above-mentioned invention objective of the present application is achieved through the following technical solutions: A version management method for an electronic work order system, the version management method for an electronic work order system comprising: Get the version update request and determine the current routing source of the version update request; Obtaining an updated version of the current routing source in real time; Determine version record information according to the updated version, the version record information at least including an update operator and an update type, the update type including a defect type updated based on the work order defect instance and a requirement type updated based on requirement information; The weight value of the update operator is determined, and the corresponding version strategy is executed according to the update type and / or the weight value, wherein the version strategy at least includes version replacement and version coexistence.

[0005] By adopting the above technical solution, the version management method obtains the updated version of the current routing source in real time, and intelligently selects to execute version replacement or version coexistence strategy according to the version record information and the weight value of the update operator, thereby effectively solving the problems of version conflict and information loss in traditional systems. Especially when dealing with work order defects and demand changes from different sources, the version coexistence strategy allows different versions to exist in the system at the same time, avoiding the problem of important information coverage or loss caused by version replacement. This method not only improves the flexibility and stability of the system, but also ensures the reliable tracking and management of multi-party operations and demand changes, making version management more accurate and efficient.

[0006] In a preferred example, the present application may be further configured as follows: the step of determining the current routing source of the version update request includes: Determine whether a work order defect instance occurs in the version update request, and if so, determine record information according to the work order defect instance; Determine the historical routing source according to the recorded information, and determine the historical routing source as the current routing source; It is determined whether a work order defect instance appears in the update request, and if not, the current routing source is determined according to the demand information.

[0007] By adopting the above technical solution, the current routing source of the version update request can be accurately located according to the work order defect instance or requirement information, thereby ensuring that the system can select the most appropriate version update path according to the specific situation. This path selection mechanism improves the flexibility and accuracy of version management, especially when dealing with complex work order defect instances or requirement changes, it can avoid misjudgment and misuse of resources, and improve the overall efficiency of the system.

[0008] In a preferred example, the present application may be further configured as follows: the step of determining the current routing source of the version update request further includes: Determine defect information according to the work order defect instance; Determine the historical operator according to the recorded information; Determining a maintenance response terminal according to the historical routing source; According to the historical operators, push the information to be updated to the corresponding current operators in the maintenance response terminal; Determine the weight value of the current operator; After the current operator completes the update version, the current operator is determined as the update operator, and the subtraction value is subtracted from the weight value to generate the weight value of the update operator.

[0009] By adopting the above technical solution, it is possible to query and analyze historical records to ensure that the maintenance response terminal can accurately obtain update information and adjust the weight value according to the current operator's performance, thereby improving the system's dynamic evaluation of operator capabilities and the accuracy of update operations. Through this weight adjustment mechanism, the system can flexibly dispatch resources according to actual operating conditions, optimize the version management process, and thus improve overall maintenance efficiency.

[0010] In a preferred example, the present application may be further configured as follows: executing a corresponding version strategy according to the update type and / or weight value, wherein the version strategy at least includes the steps of version replacement and version coexistence, including: If the update type is a defect type, version replacement is performed and version record information is saved to the version database; If the update type is a demand type, determining a preset weight threshold; Acquire approval information of the updated version, and determine an added value according to the approval information, wherein the added value is greater than or equal to zero; Determine whether the sum of the weight value and the added value exceeds the preset weight threshold. If so, execute version coexistence and save the version record information to the version database. If not, execute version replacement and save the version record information to the version database.

[0011] By adopting the above technical solution, when processing different types of update requests, the most appropriate version strategy can be flexibly selected according to the preset rules and the weight value of real-time evaluation, thereby ensuring that the system can perform version replacement or coexistence operations at the most appropriate time. This strategy not only improves the adaptability and response capabilities of the system, but also ensures the transparency and traceability of version management by saving detailed version records, thereby enhancing the reliability and maintainability of the system.

[0012] In a preferred example, the present application may be further configured as follows: the version record information also includes the version creation time and the modified content, and the version creation time is determined as the traceability mark of the updated version; The determining of the weight value of the update operator, and executing a corresponding version strategy according to the update type and / or the weight value, wherein the version strategy at least includes the steps of version replacement and version coexistence, further includes: Define the version management interface; Acquire management requirement information, and match corresponding version record information in the version database based on the traceability identifier and the management requirement information; Determine whether the corresponding version in the version record information is replaced. If not, call and connect the corresponding version in the version record information through the version management interface to at least manage the adjustment parameters in the modified content. If so, at least push the adjustment information in the corresponding modified content.

[0013] By adopting the above technical solution, it is possible to ensure that the creation and modification of any version can be accurately tracked and managed through precise version traceability identification and clear management interface, thereby greatly improving the system's ability to manage version history. Through this solution, the acquisition and matching of management demand information can be effectively supported, ensuring that when versions are replaced or coexist, adjusting parameters or pushing information can be executed accurately, improving the efficiency and accuracy of version management.

[0014] In a preferred example, the present application may be further configured as follows: the step of determining whether the sum of the weight value and the added value exceeds the preset weight threshold, and if so, after executing the step of version coexistence, including: At least define the protocol standard of the version requirement interface to allow external requests to access and operate the data of the current version or historical version; Obtain business demand information; According to the business requirement information, switch to the current version or the historical version through the version requirement interface.

[0015] By adopting the above technical solution, it is possible to define a standardized version requirement interface protocol to ensure that external requests can smoothly access and operate the data of the current version or historical version, thereby greatly improving the system's response speed and flexibility in processing external requirements. This switching mechanism can quickly adapt to the operational requirements of different versions according to changes in business requirements, ensuring the stable operation and efficient management of the system in a changing business environment.

[0016] The second object of the invention is achieved by the following technical solutions: The version management device for the electronic work order system includes: A first determination module is used to obtain a version update request and determine a current routing source of the version update request; An acquisition module, used for acquiring an updated version of the current routing source in real time; A second determination module is used to determine version record information according to the updated version, wherein the version record information at least includes an update operator and an update type, wherein the update type includes a defect type updated based on the work order defect instance and a requirement type updated based on requirement information; The third determination module is used to determine the weight value of the update operator, and execute the corresponding version strategy according to the update type and / or the weight value, wherein the version strategy at least includes version replacement and version coexistence.

[0017] The third objective of the present application is achieved through the following technical solutions: A computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the version management method for an electronic work order system when executing the computer program.

[0018] The fourth objective of the present application is achieved through the following technical solutions: A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the version management method for an electronic work order system are implemented.

[0019] In summary, the present application includes at least one of the following beneficial technical effects: 1. This version management method obtains the updated version of the current routing source in real time, and intelligently selects to execute version replacement or version coexistence strategy based on the version record information and the weight value of the update operator, thereby effectively solving the problems of version conflict and information loss in traditional systems. Especially when dealing with work order defects and demand changes from different sources, the version coexistence strategy allows different versions to exist in the system at the same time, avoiding the problem of important information coverage or loss caused by version replacement. This method not only improves the flexibility and stability of the system, but also ensures the reliable tracking and management of multi-party operations and demand changes, making version management more accurate and efficient. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is a flow chart of a version management method for an electronic work order system in one embodiment of the present application; Figure 2 is a flowchart for implementing S10 in a version management method for an electronic work order system in one embodiment of the present application; Figure 3 is another implementation flow chart of S10 in the version management method for an electronic work order system in one embodiment of the present application; Figure 4 is a flowchart for implementing S40 in a version management method for an electronic work order system in an embodiment of the present application; Figure 5 is another implementation flow chart of a version management method for an electronic work order system in one embodiment of the present application; Figure 6 is another implementation flow chart of S40 in the version management method for an electronic work order system in one embodiment of the present application; Figure 7 This is a principle block diagram of a version management device for an electronic work order system in one embodiment of the present application; Figure 8 It is a schematic diagram of a device in an embodiment of the present application. DETAILED DESCRIPTION

[0021] The present application is further described in detail below in conjunction with the accompanying drawings.

[0022] In one embodiment, if Figure 1 As shown, the present application discloses a version management method for an electronic work order system, which specifically includes the following steps: S10, obtaining a version update request, and determining a current routing source of the version update request; In this embodiment, the version update request refers to a request signal issued by a user or system when a version update is detected. This request signal may originate from multiple modules or user terminals of the system. By obtaining the version update request, the subsequent version management process can be effectively triggered to ensure that the system can respond to the update requirements of different modules or users in a timely manner, thereby avoiding version delays or information missing. The current routing source refers to the specific source location or module that initiates the version update request. For example, the current routing source may be a specific user terminal, server node, or system module. By determining the current routing source, the system can accurately locate which module or user needs to perform a version update, and then obtain and process the updated version in a targeted manner to ensure the accuracy and pertinence of the system version update.

[0023] S20, obtaining an updated version of the current routing source in real time; In this embodiment, the updated version refers to the latest software version or configuration file corresponding to the current routing source. By obtaining the updated version in real time, the system can dynamically track and record the progress of the version update, ensuring that the version update process is up to date and synchronized, thereby avoiding version inconsistency or delay issues and improving the overall operating efficiency of the system.

[0024] S30, determining version record information according to the updated version, the version record information at least including the update operator and the update type, the update type including the defect type updated based on the work order defect instance and the requirement type updated based on the requirement information; In this embodiment, the version record information refers to all important information related to the version update process, including the identity of the update operator, the specific content of the update, the version number, and the update time. The version record information can not only record the process of each version update in detail, but also provide data support for subsequent version backtracking and problem tracking. By determining the version record information, the system can accurately save and manage the details of each update, thereby ensuring that the historical version data of the system is complete and traceable. In the step where the update type includes the defect type updated based on the work order defect instance and the requirement type updated based on the requirement information, the update type refers to the specific reason or trigger condition for the version update. The defect type update is usually to repair errors or vulnerabilities found during the operation of the system, while the requirement type update is to meet the user's new needs or improve the system function. By distinguishing the update type, the system can implement different version strategies in a targeted manner to ensure that the system can respond quickly when repairing defects, and pay more attention to the expansion and optimization of system functions when processing requirement updates.

[0025] S40: Determine the weight value of the update operator, and execute the corresponding version strategy according to the update type and / or the weight value. The version strategy at least includes version replacement and version coexistence.

[0026] In this embodiment, the weight value refers to the priority level assigned according to the role, historical contribution or authority level of the update operator in the system. By determining the weight value, the system can determine the execution priority of the version policy according to the importance of the operator, thereby avoiding unnecessary impact of updates by low-authority personnel on the system and improving the security and reliability of version management. The version policy refers to the different processing methods adopted by the system in the version management process. The version replacement strategy is usually used to solve major defects or urgent needs, while the version coexistence strategy allows multiple versions to exist in the system at the same time, especially during the requirement change or functional testing stage. By executing the corresponding version strategy, the system can flexibly respond to various update requirements, ensuring that the normal operation of other versions is not affected while solving the problem, thereby improving the scalability and robustness of the system.

[0027] In summary, this version management method obtains the updated version of the current routing source in real time, and intelligently selects to execute version replacement or version coexistence strategy based on the version record information and the weight value of the update operator, thereby effectively solving the problems of version conflict and information loss in traditional systems. Especially when dealing with work order defects and demand changes from different sources, the version coexistence strategy allows different versions to exist in the system at the same time, avoiding the problem of important information coverage or loss caused by version replacement. This method not only improves the flexibility and stability of the system, but also ensures the reliable tracking and management of multi-party operations and demand changes, making version management more accurate and efficient.

[0028] In one embodiment, if Figure 2 As shown, in S10, i.e., the step of determining the current routing source of the version update request, it includes: S101, determining whether a work order defect instance appears in the version update request, and if so, determining record information according to the work order defect instance; In this embodiment, in the step of determining whether a work order defect instance appears in the version update request, the work order defect instance refers to any error or anomaly related to the work order found during system operation or business operation. These defect instances may include long system response time, data processing errors, or user interface anomalies. When a work order defect instance is detected, the system will use it as a key factor to trigger a version update. By determining the occurrence of work order defect instances, it can ensure that the system prioritizes these issues that have a direct impact on business operations, thereby promptly repairing vulnerabilities and improving system stability and user experience.

[0029] S102, determining a historical routing source according to the recorded information, and determining the historical routing source as a current routing source; In this embodiment, in the step of determining the historical routing source based on the recorded information, the recorded information refers to detailed data related to the work order defect instance, including the time when the defect occurred, the affected modules, the historical records of processing, etc. The historical routing source refers to the module or node from which the request originated during the previous version update. By analyzing these recorded information, the system can trace back to the module or node that has previously processed the same or similar defects, thereby determining it as the routing source of the current version update request. The advantage of doing this is that historical data can be used for effective fault location and repair, avoiding repeated analysis and processing of similar problems, and improving the efficiency of problem solving.

[0030] S103: Determine whether a work order defect instance appears in the update request, and if not, determine the current routing source according to the demand information.

[0031] In this embodiment, in the step of determining whether a work order defect instance appears in the update request, if no work order defect instance is found, the system will instead determine the current routing source based on the demand information. Demand information refers to new functional requirements, performance optimization suggestions, or other improvement suggestions proposed by the system or user. These requirements are usually to meet the needs of business development or user experience optimization. When the system detects that there is no work order defect instance, by analyzing the demand information, the system can determine the module or function that needs to be updated, thereby determining the corresponding routing source. This approach ensures that the system can not only respond quickly and fix defects, but also flexibly respond to changes in business needs and achieve functional iteration and optimization.

[0032] In summary, the current routing source of the version update request can be effectively located based on the work order defect instance or requirement information, thereby ensuring that the system can select the most appropriate version update path based on the specific situation. This path selection mechanism improves the flexibility and accuracy of version management, especially when dealing with complex work order defect instances or requirement changes, which can avoid misjudgment and misuse of resources and improve the overall efficiency of the system.

[0033] In one embodiment, if Figure 3 As shown, in S10, i.e., the step of determining the current routing source of the version update request, it also includes: S104, determining defect information according to the work order defect instance; In this embodiment, defect information refers to detailed data and features extracted from work order defect instances, including but not limited to the cause of the defect, the scope of impact, the conditions for the defect, and historical repair records. By determining this defect information, the system can fully understand the abnormal situation of the current work order, thereby providing a basis for subsequent fault location, repair strategy formulation, and preventive measures. For example, if the defect information shows that a certain module frequently has the same type of fault, the system can automatically generate a corresponding warning and recommend deep optimization or replacement of the module to improve the reliability of the overall system.

[0034] S105. Determine the historical operator according to the recorded information; In this embodiment, the record information refers to all historical data related to the work order defect instance and its handling process, which may include the defect repair steps, tools used, time nodes, and participants. Historical operators refer to personnel who have previously participated in repairing the same or similar defects. By analyzing these record information, the system can identify the operator who is most experienced or most familiar with the defect and determine him as the historical operator. This approach can effectively improve the efficiency of problem solving, because historical operators usually have a deep understanding of the characteristics and handling methods of defects, and can complete troubleshooting and repair work more quickly.

[0035] S106, determining a maintenance response terminal according to a historical routing source; In this embodiment, the historical routing source refers to the request routing records when handling the same or similar defects in the past, which can reflect the node where the defect occurred and the processing flow. The maintenance response terminal refers to the specific hardware or software terminal responsible for receiving and processing defect repair tasks. By referring to the historical routing source, the system can quickly locate the most appropriate maintenance response terminal to ensure that the repair task can be communicated and processed in a timely manner. For example, if a defect occurs on a specific device, the system can directly send the repair task to the control terminal of the device, thereby shortening the response time and improving processing efficiency.

[0036] S107, according to the historical operators, push the information to be updated to the corresponding current operator in the maintenance response terminal; In this embodiment, according to the step of pushing the information to be updated to the corresponding current operator in the maintenance response terminal according to the historical operator, the information to be updated refers to all necessary data and instructions related to the current version update, such as repair steps, modules involved, precautions, etc. By pushing this information, the system can ensure that the current operator can obtain the latest update tasks in a timely manner, and refer to the experience and operation records of the historical operator, so as to perform the update operation more efficiently. This process can reduce update failures or delays caused by information asymmetry or operation errors, and ensure the smooth progress of the version update process.

[0037] S108, determining the weight value of the current operator; In this embodiment, the weight value refers to a quantitative indicator assigned by the system to each operator's participation and contribution in the version update task. This weight value is usually determined based on factors such as the operator's experience, historical participation, and task completion quality. By determining the weight value of the current operator, the system can effectively manage the task allocation of the operator and adjust the allocation strategy of subsequent tasks based on their actual performance. For example, operators with high weight values ​​may be assigned to key tasks first to ensure the success rate and quality of the version update.

[0038] S109: After the current operator completes the version update, the current operator is determined as the update operator, and the subtraction value is subtracted from the weight value to generate a weight value of the update operator.

[0039] In this embodiment, the update operator refers to the person who finally completes and submits the version update. The subtraction value refers to a value determined based on the operator's performance or task difficulty during the update process, and is usually used to balance and adjust the operator's weight value. By deducting the subtraction value from the current operator's weight value, the system can dynamically adjust the operator's weight to ensure that the weight value more accurately reflects the operator's actual contribution. This approach can not only motivate operators to maintain high-quality work performance, but also provide a reliable reference for the system's subsequent task allocation.

[0040] In summary, through the query and analysis of historical records, it is possible to ensure that the maintenance response terminal can accurately obtain update information and adjust the weight value according to the current operator's performance, thereby improving the system's dynamic evaluation of operator capabilities and the accuracy of update operations. Through this weight adjustment mechanism, the system can flexibly dispatch resources according to actual operating conditions, optimize the version management process, and thus improve overall maintenance efficiency.

[0041] In one embodiment, if Figure 3 As shown, in S40, the corresponding version strategy is executed according to the update type and / or weight value, and the version strategy at least includes the steps of version replacement and version coexistence, including: S401, if the update type is a defect type, perform version replacement and save the version record information to the version database; In this embodiment, the defect type refers to the version update based on the work order defect instance, which is usually used to fix known vulnerabilities or errors in the system or program. Version replacement refers to replacing the old version with defects with the fixed new version to ensure the stability and security of the system operation. By saving the version record information to the version database, the system can track and manage the details of each update, such as the reason for the update, the modules involved, the operators, etc., so as to provide a detailed basis for subsequent version management and problem tracing. For example, in a software update, if a serious security vulnerability is found in a functional module, the system will immediately perform a version replacement and archive all relevant information for subsequent query and review.

[0042] S402: If the update type is a demand type, determine a preset weight threshold; In this embodiment, the requirement type refers to version updates based on user or business needs, which usually involve functional expansion or optimization. The preset weight threshold is a value pre-set by the system based on the importance and scope of influence of the requirement, which is used to measure the priority of the requirement update in the entire version management. By determining the preset weight threshold, the system can effectively evaluate and control the relative importance of different requirement updates, thereby reasonably allocating resources and time to ensure that key requirements are met first. For example, when a requirement update involves major improvements to core business functions, the system will set a higher weight threshold for the update to ensure that it can receive sufficient attention and resource support in version management.

[0043] S403, obtaining approval information of the updated version, determining an added value according to the approval information, and the added value is greater than or equal to zero; In this embodiment, approval information refers to the data generated by the review and approval of version update applications by managers at all levels or relevant departments within the system. The added value is a numerical value calculated based on the approval information, which reflects the degree of support or priority obtained by the updated version during the approval process. An added value greater than or equal to zero means that the version update has been partially or fully approved, and thus has the conditions to continue to advance. Through this process, the system can ensure that each version update goes through a strict approval process, prevent updates that have not been fully evaluated from entering the production environment directly, and ensure the stability and security of the system. For example, when introducing a new functional module, the system will calculate the added value based on the opinions and suggestions of the approvers. If all approvers express support, the added value will be higher, thereby promoting the implementation of the update.

[0044] S404, determine whether the sum of the weight value and the added value exceeds the preset weight threshold. If so, execute version coexistence and save the version record information to the version database. If not, execute version replacement and save the version record information to the version database.

[0045] In this embodiment, the system first adds the operator's weight value to the added value generated in the aforementioned approval process to calculate a total value. This total value is used to measure the comprehensive priority of the current version update. If it exceeds the preset weight threshold, the system will consider the update to be of sufficient importance and decide to perform version coexistence, that is, to coexist with the new version on the basis of the existing version, so that users can choose the appropriate version to operate as needed. This strategy is particularly important when dealing with functional updates or scalability requirements, and can effectively avoid system incompatibility problems caused by version replacement. If the total value does not exceed the weight threshold, the system will perform version replacement, replace the old version with the new version, and save all relevant records to ensure the integrity and traceability of version management.

[0046] In summary, when processing different types of update requests, the most appropriate version strategy can be flexibly selected based on preset rules and real-time evaluation weight values, thereby ensuring that the system can perform version replacement or coexistence operations at the most appropriate time. This strategy not only improves the adaptability and response capabilities of the system, but also ensures the transparency and traceability of version management by saving detailed version records, thereby enhancing the reliability and maintainability of the system.

[0047] The version record information also includes the version creation time and modification content, and the version creation time is determined as the traceability mark of the updated version. The version record information includes the version creation time and modification content. The version creation time is determined as the traceability mark of the updated version, which is used to identify the time node of the version update to ensure that it can be accurately traced back to a specific version when needed. By saving the version creation time, the version history can be tracked to help managers quickly locate the changes in specific versions. For example, when a problem occurs with a version, the manager can use the traceability mark to find the creation time of the version and its related modification content, and quickly make correction decisions; In one embodiment, if Figure 4 As shown, after S40, that is, determining the weight value of the update operator, executing the corresponding version strategy according to the update type and / or the weight value, the version strategy at least includes the steps of version replacement and version coexistence, and further includes: S50, define a version management interface; In this embodiment, the version management interface is defined as a standardized interface for interacting with version record information. The interface can provide functions such as query, update and deletion of version information to ensure the systematicness and controllability of the version management process. Through this interface, the record information of a specific version can be easily called and connected to perform version comparison, backtracking or update operations. For example, when a software project enters the development stage, developers can obtain the historical version information of each module through the version management interface, thereby effectively managing and coordinating the development progress of different modules. The process of obtaining management demand information is carried out by analyzing and collecting the specific needs of users or systems for version management.

[0048] S60, obtaining management requirement information, and matching corresponding version record information in the version database based on the traceability identifier and the management requirement information; In this embodiment, based on the traceability identification, the system can match the corresponding version record information in the version database according to the management requirement information. This means that the system can intelligently identify and associate management requirements with version information, thereby providing accurate version information when needed. For example, when a user wants to roll back to the system state at a specific point in time, the system will use the traceability identification and management requirement information to find the version record that best meets the conditions in the version database and provide relevant recovery or rollback options.

[0049] S70. Determine whether the corresponding version in the version record information is replaced. If not, call and connect the corresponding version in the version record information through the version management interface to at least manage the adjustment parameters in the modified content. If so, at least push the adjustment information in the corresponding modified content.

[0050] In this embodiment, the system first determines whether the corresponding version in the version record information has been replaced. If the version has not been replaced, the system will call and connect the version in the version record information through the version management interface to at least manage the adjustment parameters in the modified content. This process ensures that the modified content can be consistent with the current version to prevent unnecessary conflicts or errors. If the version has been replaced, the system will push the adjustment information in the corresponding modified content to ensure that the manager can understand and handle the changes in the new version in a timely manner. For example, when a document editing software is shared among multiple users, if a user modifies and saves the version, the system will notify other users when they try to access the version that the version has been replaced, and push relevant modification information to avoid conflicts between multiple users.

[0051] In summary, through precise version traceability identification and clear management interfaces, we can ensure that in version management, the creation and modification of any version can be accurately tracked and managed, thereby greatly improving the system's ability to manage version history. Through this solution, the acquisition and matching of management demand information can be effectively supported, ensuring that when versions are replaced or coexist, adjusting parameters or pushing information can be executed accurately, improving the efficiency and accuracy of version management.

[0052] In one embodiment, if Figure 5 As shown, after S404, it is determined whether the sum of the weight value and the added value exceeds the preset weight threshold. If so, after executing the version coexistence step, it includes: S405. At least define the protocol standard of the version requirement interface to allow external requests to access and operate the data of the current version or the historical version; In this embodiment, at least the protocol standard of the version requirement interface is defined to allow external requests to access and operate the data of the current version or historical version. The protocol standard of the version requirement interface is a set of rules that define data transmission, access rights, operation methods, etc. These rules ensure that external systems or users can access specific version data through the interface under the premise of meeting security and permission requirements. The definition of the protocol standard can include communication protocols, data formats, authentication methods, etc. to ensure the versatility and security of the interface. For example, in a cross-platform development environment, the protocol standard of the version requirement interface can allow different tools and applications to access the version data of the project through a unified interface, thereby realizing the integrated operation of collaborative development and version management.

[0053] S406, obtaining business demand information; In this embodiment, obtaining business demand information means that the system collects the specific business requirements currently required through interaction with users or other systems. These business demand information may include requirements such as operating the current version data, querying historical version information, or performing version rollback. By obtaining business demand information, the system can understand the intention of the user or system, thereby providing support for subsequent version switching operations. For example, in enterprise management software, when a user wants to view a business report at a specific point in time, the system will obtain the user's specific needs and prepare the corresponding version data for display or analysis based on this information.

[0054] S407. Switch to the current version or the historical version through the version requirement interface according to the business requirement information.

[0055] In this embodiment, according to the business requirement information, the system switches to the current version or the historical version through the version requirement interface. This means that after receiving the business requirement information, the system can switch between the current version and the historical version according to the user's needs through the pre-defined version requirement interface. This process ensures that users can access version data that matches their needs, whether it is the latest work progress or past version records. For example, in a software development project, when a developer needs to debug an old released version, the system can switch to the historical version through the version requirement interface according to the developer's request, so that the developer can troubleshoot and fix the problem.

[0056] In summary, by defining a standardized version requirement interface protocol, we can ensure that external requests can smoothly access and operate the data of the current version or historical version, thereby greatly improving the system's response speed and flexibility in handling external requirements. This switching mechanism can quickly adapt to the operational requirements of different versions according to changes in business requirements, ensuring the stable operation and efficient management of the system in a changing business environment.

[0057] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0058] In one embodiment, a version management device for an electronic work order system is provided, and the version management device for an electronic work order system corresponds one-to-one to the version management method for an electronic work order system in the above embodiment. Figure 7 As shown, the version management device for the electronic work order system includes a first determination module, an acquisition module, a second determination module and a third determination module. Each functional module is described in detail as follows: A first determination module is used to obtain a version update request and determine a current routing source of the version update request; An acquisition module, used for acquiring an updated version of the current routing source in real time; A second determination module is used to determine version record information according to the updated version, wherein the version record information at least includes an update operator and an update type, wherein the update type includes a defect type updated based on the work order defect instance and a requirement type updated based on requirement information; The third determination module is used to determine the weight value of the update operator, and execute the corresponding version strategy according to the update type and / or the weight value, wherein the version strategy at least includes version replacement and version coexistence.

[0059] The first determining module comprises: A first judging unit, configured to judge whether a work order defect instance appears in the version update request, and if so, determine record information according to the work order defect instance; A first determining unit, configured to determine a historical routing source according to the recorded information, and determine the historical routing source as a current routing source; A second judgment unit is used to judge whether a work order defect instance appears in the update request, and if not, determine the current routing source according to the demand information; The first determining module also includes: A second determining unit, configured to determine defect information according to the work order defect instance; A third determining unit, configured to determine a historical operator according to the recorded information; A fourth determining unit, configured to determine a maintenance response terminal according to the historical routing source; A push unit, used for pushing the information to be updated to the corresponding current operator in the maintenance response terminal according to the historical operator; A fifth determining unit, used to determine a weight value of a current operator; a sixth determining unit, configured to determine the current operator as an update operator after the current operator completes the update version, and to subtract the subtraction value from the weight value to generate a weight value of the update operator; The third determination module comprises: A first execution unit, configured to execute version replacement if the update type is a defect type, and save version record information to a version database; a seventh determining unit, configured to determine a preset weight threshold if the update type is a demand type; A first acquisition unit, configured to acquire approval information of the updated version, and determine an added value according to the approval information, wherein the added value is greater than or equal to zero; A third judgment unit is used to judge whether the sum of the weight value and the added value exceeds the preset weight threshold, if so, execute version coexistence and save the version record information to the version database, if not, execute version replacement and save the version record information to the version database; The version record information also includes the version creation time and modified content, and the version creation time is determined as the traceability mark of the updated version; The version management device for the electronic work order system also includes: Definition module, used to define the version management interface; A second acquisition module is used to acquire management requirement information, and match corresponding version record information in the version database based on the traceability identifier and the management requirement information; a judgment module, used to judge whether the corresponding version in the version record information is replaced; if not, calling and connecting the corresponding version in the version record information through the version management interface to at least manage the adjustment parameters in the modified content; if so, at least pushing the adjustment information in the corresponding modified content; The third determination module also includes: A definition unit, used to define at least a protocol standard of a version requirement interface to allow external requests to access and operate data of a current version or a historical version; A second acquisition unit, used to acquire business demand information; A switching unit is used to switch to the current version or the historical version through the version requirement interface according to the business requirement information.

[0060] For the specific definition of the version management device for the electronic work order system, please refer to the definition of the version management method for the electronic work order system mentioned above, which will not be repeated here. The various modules in the above-mentioned version management device for the electronic work order system can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0061] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 8 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a version management method for an electronic work order system is implemented.

[0062] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program: S10, obtaining a version update request, and determining a current routing source of the version update request; S20, obtaining an updated version of the current routing source in real time; S30, determining version record information according to the updated version, the version record information at least including the update operator and the update type, the update type including the defect type updated based on the work order defect instance and the requirement type updated based on the requirement information; S40: Determine the weight value of the update operator, and execute the corresponding version strategy according to the update type and / or the weight value. The version strategy at least includes version replacement and version coexistence.

[0063] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented: S10, obtaining a version update request, and determining a current routing source of the version update request; S20, obtaining an updated version of the current routing source in real time; S30, determining version record information according to the updated version, the version record information at least including the update operator and the update type, the update type including the defect type updated based on the work order defect instance and the requirement type updated based on the requirement information; S40: Determine the weight value of the update operator, and execute the corresponding version strategy according to the update type and / or the weight value. The version strategy at least includes version replacement and version coexistence.

[0064] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0065] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0066] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A version management method for an electronic work order system, characterized in that: The version management method for the electronic work order system includes: Get the version update request and determine the current routing source of the version update request; Obtaining an updated version of the current routing source in real time; Determine version record information according to the updated version, the version record information at least including an update operator and an update type, the update type including a defect type updated based on the work order defect instance and a requirement type updated based on requirement information; The weight value of the update operator is determined, and the corresponding version strategy is executed according to the update type and / or the weight value, wherein the version strategy at least includes version replacement and version coexistence.

2. The version management method for an electronic work order system according to claim 1, characterized in that: The step of determining the current routing source of the version update request includes: Determine whether a work order defect instance occurs in the version update request, and if so, determine record information according to the work order defect instance; Determine the historical routing source according to the recorded information, and determine the historical routing source as the current routing source; It is determined whether a work order defect instance appears in the update request, and if not, the current routing source is determined according to the demand information.

3. The version management method for an electronic work order system according to claim 2, characterized in that: The step of determining the current routing source of the version update request further includes: Determine defect information according to the work order defect instance; Determine the historical operator according to the recorded information; Determining a maintenance response terminal according to the historical routing source; According to the historical operators, push the information to be updated to the corresponding current operators in the maintenance response terminal; Determine the weight value of the current operator; After the current operator completes the update version, the current operator is determined as the update operator, and the subtraction value is subtracted from the weight value to generate the weight value of the update operator.

4. The version management method for an electronic work order system according to claim 1, characterized in that: The executing of a corresponding version strategy according to the update type and / or weight value, wherein the version strategy at least includes the steps of version replacement and version coexistence, includes: If the update type is a defect type, version replacement is performed and version record information is saved to the version database; If the update type is a demand type, determining a preset weight threshold; Acquire approval information of the updated version, and determine an added value according to the approval information, wherein the added value is greater than or equal to zero; Determine whether the sum of the weight value and the added value exceeds the preset weight threshold. If so, execute version coexistence and save the version record information to the version database. If not, execute version replacement and save the version record information to the version database.

5. The version management method for an electronic work order system according to claim 4, characterized in that: The version record information also includes the version creation time and modified content, and the version creation time is determined as the traceability mark of the updated version; The determining of the weight value of the update operator, and executing a corresponding version strategy according to the update type and / or the weight value, wherein the version strategy at least includes the steps of version replacement and version coexistence, further includes: Define the version management interface; Acquire management requirement information, and match corresponding version record information in the version database based on the traceability identifier and the management requirement information; Determine whether the corresponding version in the version record information is replaced. If not, call and connect the corresponding version in the version record information through the version management interface to at least manage the adjustment parameters in the modified content. If so, at least push the adjustment information in the corresponding modified content.

6. The version management method for an electronic work order system according to claim 4, characterized in that: The step of determining whether the sum of the weight value and the added value exceeds the preset weight threshold, and if so, executing the step of version coexistence includes: At least define the protocol standard of the version requirement interface to allow external requests to access and operate the data of the current version or historical version; Obtain business demand information; According to the business requirement information, switch to the current version or the historical version through the version requirement interface.

7. A version management device for an electronic work order system, characterized in that: The version management device for the electronic work order system includes: A first determination module is used to obtain a version update request and determine a current routing source of the version update request; An acquisition module, used for acquiring an updated version of the current routing source in real time; A second determination module is used to determine version record information according to the updated version, wherein the version record information at least includes an update operator and an update type, wherein the update type includes a defect type updated based on the work order defect instance and a requirement type updated based on requirement information; The third determination module is used to determine the weight value of the update operator, and execute the corresponding version strategy according to the update type and / or the weight value, wherein the version strategy at least includes version replacement and version coexistence.

8. The version management device for an electronic work order system according to claim 7, characterized in that: The first determining module comprises: A first judging unit, configured to judge whether a work order defect instance appears in the version update request, and if so, determine record information according to the work order defect instance; A first determining unit, configured to determine a historical routing source according to the recorded information, and determine the historical routing source as a current routing source; A second judgment unit is used to judge whether a work order defect instance appears in the update request, and if not, determine the current routing source according to the demand information; The first determining module also includes: A second determining unit, configured to determine defect information according to the work order defect instance; A third determining unit, configured to determine a historical operator according to the recorded information; A fourth determining unit, configured to determine a maintenance response terminal according to the historical routing source; A push unit, used for pushing the information to be updated to the corresponding current operator in the maintenance response terminal according to the historical operator; A fifth determining unit, used to determine a weight value of a current operator; a sixth determining unit, configured to determine the current operator as an update operator after the current operator completes the update version, and to subtract the subtraction value from the weight value to generate a weight value of the update operator; The third determination module comprises: A first execution unit, configured to execute version replacement if the update type is a defect type, and save version record information to a version database; a seventh determining unit, configured to determine a preset weight threshold if the update type is a demand type; A first acquisition unit, configured to acquire approval information of the updated version, and determine an added value according to the approval information, wherein the added value is greater than or equal to zero; A third judgment unit is used to judge whether the sum of the weight value and the added value exceeds the preset weight threshold, if so, execute version coexistence and save the version record information to the version database, if not, execute version replacement and save the version record information to the version database; The version record information also includes the version creation time and modified content, and the version creation time is determined as the traceability mark of the updated version; The version management device for the electronic work order system also includes: Definition module, used to define the version management interface; A second acquisition module is used to acquire management requirement information, and match corresponding version record information in the version database based on the traceability identifier and the management requirement information; a judgment module, used to judge whether the corresponding version in the version record information is replaced; if not, calling and connecting the corresponding version in the version record information through the version management interface to at least manage the adjustment parameters in the modified content; if so, at least pushing the adjustment information in the corresponding modified content; The third determination module further includes: A definition unit, used to define at least a protocol standard of a version requirement interface to allow external requests to access and operate data of a current version or a historical version; A second acquisition unit, used to acquire business demand information; A switching unit is used to switch to the current version or the historical version through the version requirement interface according to the business requirement information.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the version management method for an electronic work order system as described in any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the version management method for an electronic work order system as claimed in any one of claims 1 to 6 are implemented.

Images