Purchase process data processing method and device, equipment, medium and program product

Abstract

The invention provides a purchase process data processing method which can be applied to the technical field of big data and artificial intelligence. The purchase process data processing method comprises the following steps: in response to a first configuration operation performed by a first user on a visual interface, generating first purchase process data limited by multiple layers of purchase entities, the multiple layers of purchase entities having a superior-subordinate relationship and a data collaboration relationship; in response to a second configuration operation performed by a second user on the visual interface, adjusting the multi-layer purchase entity, and generating second purchase process data limited by the adjusted multi-layer purchase entity; and based on a rule engine, state data of a selected purchase task in the first purchase process data or the second purchase process data is monitored and matched, and when the state data exceeds an early warning state, early warning information is generated. The invention further provides a purchasing process data processing device and equipment, a storage medium and a program product.

Description

Technical Field

[0001] This application relates to the fields of big data and artificial intelligence, specifically to the field of procurement engineering management systems, and more specifically to a procurement process data processing method, apparatus, equipment, medium, and program product. Background Technology

[0002] In enterprise procurement engineering management systems (such as those of large banks), procurement tasks typically involve data interaction and process linkage between multiple different levels (such as bank headquarters, branches, and departments). To ensure the efficient and smooth completion of procurement tasks, it is necessary to monitor the status of the procurement process. Current procurement process status monitoring relies on manual polling, for example, storing procurement task data using spreadsheet software templates, configuring fixed field display structures, and enabling quick filtering through project type dropdown menus. Manual comparison of planned timelines with actual completion timestamps is then performed. This manual polling method leads to delays and lags in the procurement process, impacting operational efficiency. Furthermore, when adjustments to the procurement process are needed, the existing system uses a standard, pre-built procurement template library, which cannot dynamically adjust detailed requirements, resulting in a rigid process and poor adaptability. Therefore, improving the efficiency of procurement status monitoring and the adaptability of procurement process adjustments has become a pressing technical problem. Summary of the Invention

[0003] In view of the above problems, this application provides procurement process data processing methods, devices, equipment, media, and program products to improve the efficiency of procurement status monitoring and the adaptability of procurement process adjustments.

[0004] According to a first aspect of this application, a procurement process data processing method is provided, comprising: in response to a first user performing a first configuration operation on a visual interface, generating first procurement process data defined by multi-level procurement entities, wherein the multi-level procurement entities have hierarchical relationships and data collaboration relationships; in response to a second user performing a second configuration operation on the visual interface, adjusting the multi-level procurement entities, and generating second procurement process data defined by the adjusted multi-level procurement entities; and based on a rule engine, monitoring and matching the status data of selected procurement tasks in the first procurement process data or the second procurement process data, and generating warning information when the status data exceeds the warning status.

[0005] According to an embodiment of this application, in response to a first user performing a first configuration operation on a visual interface, generating first procurement process data defined by multi-level procurement entities includes: in response to the first user configuring a top-level entity on the visual interface, generating first-level process data for the overall procurement project; in response to the first user configuring a middle-level entity on the visual interface, generating second-level process data for each independent procurement package under the overall procurement project; and in response to the first user configuring a bottom-level entity on the visual interface, generating third-level process data for each execution unit of the independent procurement package, wherein the first-level process data, the second-level process data, and the third-level process data constitute the first procurement process data.

[0006] According to an embodiment of this application, in response to a second user performing a second configuration operation on a visual interface, adjusting a multi-level procurement entity includes: in response to the second user inputting a procurement adjustment label on the visual interface, determining the procurement process element that matches the procurement adjustment label; and making corresponding adjustments to the multi-level procurement entity based on the procurement process element.

[0007] According to an embodiment of this application, determining the procurement process elements that match the procurement adjustment tags includes: parsing the procurement adjustment tags and determining the tag elements in the tag classification library based on the parsing results; and determining the procurement process elements that match the tag elements based on a rule engine.

[0008] According to an embodiment of this application, monitoring and matching the status data of selected procurement tasks in the first procurement process data or the second procurement process data based on a rule engine includes: configuring multi-dimensional early warning rule conditions using a rule engine; calling the early warning rule conditions in priority order; and monitoring and matching the collected status data.

[0009] According to an embodiment of this application, calling the early warning rule conditions in order of priority and monitoring and matching the collected status data includes: polling the task database based on the called early warning rule conditions, extracting status data, calculating the timeliness deviation of the status data, and generating early warning information when the timeliness deviation exceeds the corresponding timeliness threshold.

[0010] According to an embodiment of this application, the method further includes: determining the warning entity to which the warning information points in the multi-level procurement entity, and pushing the warning information to the third user corresponding to the warning entity.

[0011] A second aspect of this application provides a procurement process data processing apparatus, comprising: a generation module, configured to generate first procurement process data defined by multi-level procurement entities in response to a first configuration operation performed by a first user on a visual interface, wherein the multi-level procurement entities have hierarchical relationships and data collaboration relationships; an adjustment module, configured to adjust the multi-level procurement entities in response to a second configuration operation performed by a second user on a visual interface, thereby generating second procurement process data defined by the adjusted multi-level procurement entities; and an early warning module, configured to monitor and match the status data of selected procurement tasks in the first or second procurement process data based on a rule engine, and generate early warning information when the status data exceeds the early warning status.

[0012] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0013] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0014] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0015] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0016] Figure 1 The illustration shows an application scenario diagram of the procurement process data processing method, apparatus, equipment, medium and program product according to embodiments of this application;

[0017] Figure 2 A flowchart illustrating a procurement process data processing method according to an embodiment of this application is shown schematically.

[0018] Figure 3 The diagram illustrates the architecture of a management model based on a three-tier procurement entity according to an embodiment of this application.

[0019] Figure 4 This illustration schematically shows a flowchart of adjusting the procurement process based on a procurement adjustment tag according to an embodiment of this application;

[0020] Figure 5This illustration shows a flowchart of a procurement process status monitoring and push based on a rule engine according to an embodiment of this application;

[0021] Figure 6 This illustration schematically shows the architecture of a procurement process data processing system according to an embodiment of this application;

[0022] Figure 7 This schematic diagram illustrates the structural block diagram of a procurement process data processing apparatus according to an embodiment of this application;

[0023] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a procurement process data processing method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0028] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0029] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0030] Embodiments of this application provide a procurement process data processing method, including: in response to a first user performing a first configuration operation on a visual interface, generating first procurement process data defined by multi-level procurement entities, wherein the multi-level procurement entities have hierarchical relationships and data collaboration relationships; in response to a second user performing a second configuration operation on the visual interface, adjusting the multi-level procurement entities, and generating second procurement process data defined by the adjusted multi-level procurement entities; and based on a rule engine, monitoring and matching the status data of selected procurement tasks in the first procurement process data or the second procurement process data, and generating warning information when the status data exceeds the warning status.

[0031] Figure 1 The illustration shows an application scenario diagram of the procurement process data processing method, apparatus, equipment, medium, and program product according to embodiments of this application.

[0032] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0033] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0034] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0035] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0036] It should be noted that the procurement process data processing method provided in this application embodiment can generally be executed by server 105. Correspondingly, the procurement process data processing device provided in this application embodiment can generally be located in server 105. The procurement process data processing method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the procurement process data processing device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0037] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0038] The following will be based on Figure 1 The described scene, through Figures 2-5 The procurement process data processing method according to the embodiments of this application will be described in detail.

[0039] Figure 2 A flowchart illustrating a procurement process data processing method according to an embodiment of this application is shown schematically.

[0040] like Figure 2 As shown, the procurement process data processing method of this embodiment includes operations S210 to S230, and the procurement process data processing method can be executed by server 105.

[0041] In operation S210, in response to the first user performing the first configuration operation on the visual interface, the first procurement process data defined by the multi-level procurement entities is generated. The multi-level procurement entities have hierarchical relationships and data collaboration relationships.

[0042] As an example, the first user can be a procurement process designer or a company manager. The visual interface provides various configuration elements, such as procurement entity icons, relationship lines, and data collaboration rule templates. The first user can drag and drop procurement entity icons onto the visual interface to set the attributes of each entity (such as name, scope of responsibility, and maximum processing amount for procurement), and then define the hierarchical relationships and configure data collaboration relationships through relationship lines. For example, the procurement department at the company's group headquarters can be the superior entity, and the procurement departments of each regional branch can be the subordinate entities. The procurement plans of the subordinate entities are submitted to the superior for approval, and updates to the superior's procurement policies can be automatically synchronized to the subordinates. The generated initial procurement process data can include basic information of each entity, hierarchical structure, data interaction rules, etc., forming a complete and structured initial procurement process system.

[0043] In operation S220, in response to the second user performing a second configuration operation on the visual interface, adjustments are made to the multi-level procurement entity, and second procurement process data defined by the adjusted multi-level procurement entity is generated.

[0044] Operation S220 involves the dynamic adjustment and optimization of the initial procurement process. The second user can be a process administrator or a person responsible for adjustments based on company changes. In some embodiments, the second user and the first user can be the same user. The second configuration operation may include, but is not limited to, modifying attribute content in existing entities, adding new procurement entities, deleting redundant entities, adjusting hierarchical relationships, and modifying data collaboration relationships. The procurement process data processing system can automatically update the hierarchical structure and data interaction logic of the procurement process based on these operations, and the generated second procurement process data can reflect changes in the company's procurement organizational structure and business rules in real time. Further details regarding the procurement process data processing system will be provided later.

[0045] When operating S230, based on the rule engine, the status data of the selected procurement task in the first procurement process data or the second procurement process data is monitored and matched. If the status data exceeds the warning status, a warning message is generated.

[0046] Operation S230 can monitor the initial procurement process (i.e., the first procurement process data) obtained from operation S210, and can also monitor the adjusted procurement process (i.e., the second procurement process data) obtained from operation S220. The rule engine can preset various early warning rules, such as overdue procurement tasks, procurement amounts exceeding the budget percentage, and abnormal supplier qualifications. The rule engine can match the collected status data with the preset rules and generate early warning information based on the matching results.

[0047] According to the embodiments of this application, through configuration operations via a visual interface, without complex programming, the first user can quickly build a multi-layered procurement process that meets the needs of the enterprise. Compared with traditional code development methods, this saves a significant amount of time and manpower costs, while also laying the foundation for adaptive adjustments to the procurement process. Based on the visual interface and multi-level procurement entities, when the procurement process needs to be adjusted, the second user can update the procurement process through simple adjustment operations, improving the flexibility and adaptability of the process. Real-time automated monitoring and early warning of procurement task status data through a rules engine improves response speed, reduces manual time spent on procurement status monitoring, and lowers the risk exposure rate.

[0048] In some embodiments, the above-described operation S210, i.e., in response to the first user performing a first configuration operation on the visual interface, generating the first procurement process data defined by the multi-layered procurement entities, may further include: in response to the first user configuring a top-level entity on the visual interface, generating the first-level process data of the overall procurement project; in response to the first user configuring a middle-level entity on the visual interface, generating the second-level process data of each independent procurement package under the overall procurement project; and in response to the first user configuring a bottom-level entity on the visual interface, generating the third-level process data of each execution unit of the independent procurement package. The first-level process data, the second-level process data, and the third-level process data constitute the first procurement process data. That is, in this embodiment, the first user can construct a procurement management model based on three-layered (i.e., top-level, middle-level, and bottom-level) procurement entities. Figure 3 The diagram illustrates the architecture of a management model based on a three-tier procurement entity according to an embodiment of this application.

[0049] like Figure 3As shown, the top-level entity can be called the project entity. The project entity can encompass the overall procurement objectives and execution framework of the project, and is associated with various financial attributes, such as the total project budget and its allocation details, and specific requirements of industry or regulatory agencies regarding the use of procurement funds. The middle-level entity can be called the sub-project entity, and a project entity can have multiple sub-project entities. For example, sub-project entities 1, 2, ..., N. A sub-project entity can be an independent procurement package belonging to the project entity, such as a supplier contract package, which can record supplier information and financial terms. The bottom-level entity can also be called the task entity. Each sub-project entity can have multiple task entities. The task entity can serve as the smallest execution unit under a sub-project, accurately tracking the status code of each task (not started, in progress, completed) and the timestamps corresponding to each status (such as start time, completion time), providing underlying data support for refined control of the procurement process. Figure 3 As shown, sub-project entity 1 can have a task entity responsible for researching potential suppliers and a task entity responsible for reviewing outsourcing risks; sub-project entity 2 can have a task entity responsible for applying for external technical resources; and sub-project entity N can have a task entity responsible for evaluation and a task entity responsible for contract signing. It should be noted that... Figure 3 The number and connections of the main project entities, sub-project entities, and task entities are merely examples and do not constitute a limitation on the management model constructed by the three-tier procurement entity. In other embodiments, these numbers and connections can be adjusted according to actual procurement needs.

[0050] By dividing the project into project entities, sub-project entities, and task entities, procurement projects can be broken down from overall objectives to specific execution units, achieving vertical penetration management from "top-level – middle-level – bottom-level." This solves the problems of fragmented processes and unclear responsibilities in traditional procurement, enabling standardized management and unified monitoring of the procurement process. It ensures that every procurement action is traceable and quantifiable, which is particularly suitable for managing multiple projects in parallel. In this way, when the S230 monitoring system detects an alert, the corresponding entity and responsible person can be quickly located.

[0051] In some embodiments, the above operation S220, namely adjusting the multi-level procurement entity in response to the second user performing a second configuration operation on the visual interface, includes: in response to the second user inputting a procurement adjustment label on the visual interface, determining the procurement process element that matches the procurement adjustment label; and making corresponding adjustments to the multi-level procurement entity based on the procurement process element.

[0052] In this embodiment, the procurement adjustment tag is an identifier used by the second user to trigger specific adjustment requests. It can be pre-set based on common adjustment scenarios in enterprise procurement operations, such as tags like "Add Procurement Department," "Change Approval Permissions," "Adjust Data Collaboration Scope," and "Delete Redundant Procurement Groups." The visual interface can provide a tag input box or a tag selection list, allowing the second user to directly input or select the corresponding tag. After the second user inputs a procurement adjustment tag, the system automatically determines the matching procurement process elements based on the tag. These procurement process elements can cover the key content required to complete the adjustment. For example, the elements corresponding to the "Add Procurement Department" tag may include the hierarchical affiliation of the new department, its scope of responsibilities, and data collaboration rules with other departments; the elements corresponding to the "Change Approval Permissions" tag may include the involved procurement entity, the specific monetary range of the permission change, and the upstream and downstream nodes of the approval process.

[0053] According to this embodiment, the second user only needs to input or select the corresponding procurement adjustment tag, and the system can automatically complete the element determination and adjustment execution. There is no need to manually search and modify the attributes and relationships of each multi-level procurement entity, reducing the operational complexity for the second user and saving adjustment time. Through precise matching of procurement adjustment tags with elements in the procurement process, incomplete or incorrect adjustments caused by missing key elements during the adjustment process can be avoided, ensuring the correctness of the operational logic of the adjusted procurement entity and improving the flexibility and compliance of procurement adjustments.

[0054] In some embodiments, determining the procurement process element that matches the procurement adjustment tag may further include: parsing the procurement adjustment tag and determining the tag element in the tag classification library based on the parsing results; and determining the procurement process element that matches the tag element based on a rule engine. Figure 4 The illustration shows a flowchart of a procurement process adjustment based on a procurement adjustment tag according to an embodiment of this application.

[0055] like Figure 4 As shown, a second user can input the tag "Single-source procurement of new technologies". The procurement process data processing system can parse this tag, determine the tag elements by calling the tag classification library, and then determine the matching procurement stage elements. For example, through rules set by the rule engine, additional audit steps can be added to the "compliance checklist", and qualification requirements can be raised for the "supplier qualification standards", thereby generating an adaptive process, i.e., the second procurement process data mentioned above. Based on the adaptive process, a new tender document or contract is output to ensure financial compliance. In this way, through the structured mapping of the tag classification library and the rule matching of the rule engine, the system can transform procurement adjustment tags in natural language form into procurement stage elements, significantly improving the efficiency and reliability of element association.

[0056] In some embodiments, the above operation S230, namely, monitoring and matching the status data of selected procurement tasks in the first procurement process data or the second procurement process data based on the rule engine, may further include: configuring multi-dimensional early warning rule conditions using the rule engine; calling the early warning rule conditions in order of priority, and monitoring and matching the collected status data.

[0057] As an example, the dimensions of early warning rules can cover key aspects such as time, amount, quality, and compliance. For instance, early warning rules based on time could include conditions like "the procurement task exceeds the planned completion time by 3 days" or "the tender announcement period is less than the statutory minimum period"; while early warning rules based on amount could include conditions like "the actual procurement amount exceeds the budget by 10%" or "the single supplier's single procurement amount exceeds the limit threshold." Users can flexibly add, modify, or delete these multi-dimensional early warning rules based on different procurement scenarios (such as engineering procurement and equipment procurement) and enterprise management requirements. Conditions in each dimension can exist independently or be combined. The priority order can be determined by the user in advance in the rule engine based on the risk level and business impact of the early warning rule conditions. For example, rules involving financial compliance and major quality issues can be given higher priority, while conditions that affect procurement progress but have lower risk can be given lower priority.

[0058] Based on this embodiment, multi-dimensional early warning rules can cover various anomalies that may occur in procurement tasks, avoiding monitoring blind spots caused by single rules and ensuring that all potential risks are monitored. Prioritizing rule calls allows for handling more critical issues when multiple anomalies occur simultaneously, avoiding wasting resources on non-critical warnings and improving the targeting and efficiency of monitoring. Furthermore, the rule engine allows users to flexibly adjust rule content and priority order according to business changes, improving response speed.

[0059] In some embodiments, invoking the early warning rule conditions in order of priority and monitoring and matching the collected status data may further include: polling the task database based on the invoked early warning rule conditions, extracting status data, calculating the timeliness deviation of the status data, and generating early warning information when the timeliness deviation exceeds the corresponding timeliness threshold. Figure 5 The illustration shows a flowchart of procurement process status monitoring and push according to an embodiment of the present application based on a rules engine.

[0060] like Figure 5As shown, status monitoring rules can be preset through the configured strategy engine. For example, a rule can be set to "trigger an alert if the evaluation task is not completed within 48 hours". Then, the task database can be polled through the Application Programming Interface (API) to capture status data in real time. This data could include progress percentage, exception flags, etc. The push logic is then executed; when the status data matches the strategy rule conditions, an alert is automatically generated. If the match fails, the monitoring status is returned.

[0061] By actively polling the task database, changes in the status data of procurement tasks can be captured in real time, making the monitoring of timeliness deviations more autonomous. Calculating the timeliness deviation of the status data and quantitatively comparing it with preset timeliness thresholds makes the basis for early warnings clearer and the results more reliable. This significantly reduces the workload of manual intervention, allowing managers to focus their energy on more core decision-making tasks while mitigating management risks caused by human error.

[0062] In some embodiments, the procurement process data processing method may further include: determining the warning entity to which the warning information is directed in the multi-level procurement entity, and pushing the warning information to the third user corresponding to the warning entity.

[0063] Please continue reading. Figure 5 The generated warning information can be pushed to the responsible party, i.e., the third-party user corresponding to the warning entity. The warning entity can be one or more project entities, sub-project entities, or task entities. In other words, the third-party user can be the person in charge of one or more entities. The push method can be email or message queue, which can be set according to actual needs, and this application does not make further limitations. By pushing warning information to the responsible person's mobile terminal and management system in real time, the traditional post-event accountability is transformed into pre-event intervention, which can shorten the abnormal response cycle and significantly reduce the risk of procurement delays.

[0064] Figure 6 This diagram schematically illustrates the architecture of a procurement process data processing system according to an embodiment of this application. The procurement process data processing system can be used to implement the procurement process data processing method described in the above embodiments.

[0065] like Figure 6 As shown, the procurement process data processing system may include a web front-end module, a load balancing module, an API gateway cluster module, a rules engine service module, a status monitoring service module, and a document generation service module.

[0066] The web front-end module serves as the interface for users (including primary and secondary users) to interact with the system, providing a visual interface covering procurement process management, status monitoring, and document configuration for intuitive user operation. The load balancing module handles traffic distribution and failover, allocating user requests to different nodes in the API gateway cluster based on preset routing strategies to ensure balanced system load and improve stability. The API gateway cluster is responsible for unified authentication of all requests, converting between different protocols, and then accurately routing requests to backend modules such as the rule engine service, status monitoring service, or document generation service. The rule engine service module parses policy configurations, such as various timeout warning rules, and determines whether warnings are triggered during the procurement process through rule matching and decision-making. The status monitoring service module polls the status of various aspects of the procurement task in real time, such as bidding progress and contract signing status, calculates timeliness deviations, generates corresponding monitoring indicators, and then writes this data to a time-series database. It also provides a real-time status query interface to the API gateway to ensure timely access to status information. The document generation service module can dynamically synthesize various documents required for procurement, such as tender documents and contract templates, embed adaptively adjusted clauses into them, retrieve basic templates from object storage, and finally output the generated documents to object storage, achieving efficient document management and retrieval.

[0067] For details on the specific operation methods of each module of the procurement process data processing system, please refer to the previous description of the procurement process data processing methods, which will not be repeated here.

[0068] Based on the aforementioned procurement process data processing method and system, this application also provides a procurement process data processing apparatus. The following will be combined with... Figure 7 The device is described in detail.

[0069] Figure 7 A schematic block diagram of a procurement process data processing apparatus according to an embodiment of this application is shown.

[0070] like Figure 7 As shown, the procurement process data processing device 700 of this embodiment includes a generation module 710, an adjustment module 720, and an early warning module 730.

[0071] The generation module 710 can be used to generate first procurement process data defined by multi-level procurement entities in response to a first configuration operation performed by a first user on a visual interface. These multi-level procurement entities have hierarchical relationships and data collaboration relationships. In one embodiment, the generation module 710 can be used to execute the operation S210 described above, which will not be repeated here.

[0072] The adjustment module 720 can be used to adjust the multi-level procurement entity in response to a second user performing a second configuration operation on the visual interface, and generate second procurement process data defined by the adjusted multi-level procurement entity. In one embodiment, the adjustment module 720 can be used to perform the operation S220 described above, which will not be repeated here.

[0073] The early warning module 730 can be used to monitor and match the status data of selected procurement tasks in the first procurement process data or the second procurement process data based on a rule engine, and generate early warning information when the status data exceeds the early warning state. In one embodiment, the early warning module 730 can be used to execute the operation S230 described above, which will not be repeated here.

[0074] According to an embodiment of this application, the generation module 710 can be used to generate first-level process data for the overall procurement project in response to the first user configuring a top-level entity on the visual interface; generate second-level process data for each independent procurement package under the overall procurement project in response to the first user configuring a middle-level entity on the visual interface; and generate third-level process data for each execution unit of the independent procurement package in response to the first user configuring a bottom-level entity on the visual interface. The first-level process data, the second-level process data, and the third-level process data constitute the first procurement process data.

[0075] According to an embodiment of this application, the adjustment module 720 can be used to respond to a second user inputting a procurement adjustment label on a visual interface, determine the procurement process element that matches the procurement adjustment label, and make corresponding adjustments to the multi-level procurement entity based on the procurement process element.

[0076] According to an embodiment of this application, the adjustment module 720 can also be used to parse the procurement adjustment tags, determine the tag elements in the tag classification library based on the parsing results, and determine the procurement process elements that match the tag elements based on the rule engine.

[0077] According to an embodiment of this application, the early warning module 730 can be used to configure multi-dimensional early warning rule conditions using a rule engine; call the early warning rule conditions in order of priority; and monitor and match the collected status data.

[0078] According to an embodiment of this application, the early warning module 730 can also be used to poll the task database based on the early warning rule conditions, extract status data, calculate the timeliness deviation of the status data, and generate early warning information when the timeliness deviation exceeds the corresponding timeliness threshold.

[0079] According to an embodiment of this application, the procurement process data processing device 700 may further include a push module. The push module can be used to determine the warning entity to which the warning information points in the multi-level procurement entity, and push the warning information to the third user corresponding to the warning entity.

[0080] According to embodiments of this application, any plurality of the above modules can be combined into one module, or any one of the modules can be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules can be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the above modules can be at least partially implemented as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a System-on-Chip, a System-on-Substrate, a System-on-Package, an Application-Specific Integrated Circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of software, hardware, and firmware methods, or in a suitable combination of any of these. Alternatively, at least one of the above modules can be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0081] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a procurement process data processing method according to an embodiment of this application.

[0082] like Figure 8 As shown, an electronic device 800 according to an embodiment of this application includes a processor 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage portion 808 into a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0083] RAM 803 stores various programs and data required for the operation of electronic device 800. Processor 801, ROM 802, and RAM 803 are interconnected via bus 804. Processor 801 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 802 and / or RAM 803. It should be noted that programs may also be stored in one or more memories other than ROM 802 and RAM 803. Processor 801 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0084] According to embodiments of this application, the electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to a bus 804. The electronic device 800 may also include one or more of the following components connected to the input / output (I / O) interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the input / output (I / O) interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 810 as needed so that computer programs read from it can be installed into the storage section 808 as needed.

[0085] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0086] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 802 and / or RAM 803 and / or one or more memories other than ROM 802 and RAM 803 described above.

[0087] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the procurement process data processing method provided in the embodiments of this application.

[0088] When the computer program is executed by the processor 801, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0089] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 809, and / or installed from a removable medium 811. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0090] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 809, and / or installed from the removable medium 811. When the computer program is executed by the processor 801, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0091] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method of data processing for a procurement process, characterized by, The method includes: In response to the first user performing a first configuration operation on the visual interface, first procurement process data defined by multi-level procurement entities is generated, wherein the multi-level procurement entities have hierarchical relationships and data collaboration relationships. In response to a second user performing a second configuration operation on the visualization interface, the multi-level procurement entity is adjusted, and second procurement process data defined by the adjusted multi-level procurement entity is generated. Based on the rule engine, the status data of the selected procurement task in the first procurement process data or the second procurement process data is monitored and matched, and a warning message is generated when the status data exceeds the warning status.

2. The procurement process data processing method of claim 1, wherein, The step of generating first procurement process data defined by multi-level procurement entities in response to a first user performing a first configuration operation on the visual interface includes: In response to the first user configuring a top-level entity on the visualization interface, the first-level process data of the overall procurement project is generated. In response to the first user configuring a mid-level entity on the visualization interface, second-level process data for each independent procurement package under the overall procurement project is generated. In response to the first user configuring the underlying entity on the visualization interface, third-level process data of each execution unit of the independent procurement package is generated, and the first-level process data, the second-level process data and the third-level process data constitute the first procurement process data.

3. The procurement process data processing method of claim 1, wherein, The adjustment of the multi-level procurement entity in response to a second user performing a second configuration operation on the visual interface includes: In response to the second user inputting a procurement adjustment tag on the visualization interface, the procurement process element that matches the procurement adjustment tag is determined; Based on the elements of the procurement process, the multi-level procurement entities are adjusted accordingly.

4. The procurement process data processing method of claim 3, wherein, The elements for determining the procurement process that match the procurement adjustment label include: The procurement adjustment tags are parsed, and the tag elements in the tag classification library are determined based on the parsing results; Based on the rule engine, the procurement process elements that match the tag elements are determined.

5. The procurement process data processing method of claim 1, wherein, The monitoring and matching of the status data of selected procurement tasks in the first procurement process data or the second procurement process data based on the rule engine includes: The rule engine is used to configure multi-dimensional early warning rule conditions; The warning rule conditions are invoked according to priority, and the collected status data is monitored and matched.

6. A procurement process data processing method according to claim 5, wherein, The step of invoking the early warning rule conditions according to priority and monitoring and matching the collected status data includes: Based on the invoked warning rule conditions, the task database is polled to extract the status data and calculate the timeliness deviation of the status data. If the timeliness deviation exceeds the corresponding timeliness threshold, the warning information is generated.

7. The procurement process data processing method of claim 1, wherein, The method further includes: The warning entity to which the warning information points in the multi-layered procurement entity is determined, and the warning information is pushed to the third user corresponding to the warning entity.

8. A procurement process data processing apparatus characterized by comprising: The device includes: The generation module is used to respond to the first user's first configuration operation on the visual interface and generate first procurement process data defined by the multi-level procurement entities, wherein the multi-level procurement entities have hierarchical relationships and data collaboration relationships. The adjustment module is used to respond to a second user performing a second configuration operation on the visualization interface, adjust the multi-level procurement entity, and generate second procurement process data defined by the adjusted multi-level procurement entity. The early warning module is used to monitor and match the status data of selected procurement tasks in the first procurement process data or the second procurement process data based on the rule engine, and generate early warning information when the status data exceeds the early warning status.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer readable storage medium having stored thereon a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images